TL;DR
This proposal explores adding a proactive smart contract security layer to complement Compound’s existing audits, formal verification, and monitoring by applying continuous static analysis, unit test generation, mutation testing, and an internal audit agent leveraging deterministic architecture to surface findings and automatically generate bug proof-of-concepts earlier in development, before audits and deployment.
Summary
This proposal suggests adding a proactive smart contract security layer to Compound’s existing security stack. The goal is to complement audits, formal verification, and monitoring with automated, developer-side security testing that runs on every code change to surface vulnerabilities and implementation issues earlier in the SDLC, before progressing to formal verification or external audit.
The proposed tooling is easy to integrate, largely automated, and continuously active. It is designed to reduce noise earlier in development, strengthen test suites, and allow downstream security efforts to focus on higher-value review and verification.Motivation
Compound is among the most security-mature protocols in DeFi, with strong investments in audits, formal verification, and monitoring. Formal verification in particular is an excellent and rigorous technique designed to prove deep semantic properties such as protocol invariants, safety and liveness conditions, and core economic rules. These methods are most effective when lower-level bugs, incorrect assumptions, and implementation noise have already been addressed earlier in development.
Automated SDLC tooling helps achieve this by clearing away issues that are not the target of formal methods, allowing verification efforts to be more comprehensive, efficient, and resilient.
Despite best practices, audits alone are not foolproof. Several high-profile incidents such as Balancer, GMX, and Cork occurred in contracts that had been audited, often due to changes introduced after audit or assumptions that were difficult to validate manually. In these cases, proactive testing during development would have surfaced the underlying issues earlier.
As a protocol governed through frequent upgrades and iterative improvements, Compound faces similar dynamics. The Balancer incident in particular highlights how incremental changes can introduce new risk and reinforces the value of continuously validating assumptions as code evolves.
Problem Statement
While Compound already benefits from audits, formal verification, and runtime monitoring, there remains an opportunity to strengthen security earlier in the development lifecycle:
-
Small or incremental changes can introduce risk between audits
-
Developers benefit from faster, automated feedback during active development
-
Formal verification is not optimized to wade through noisy, low-level bugs
-
Earlier SDLC tooling enables a layered, shift-left security approach
Introducing automated security tooling earlier helps ensure later-stage verification and audits can focus on the semantic properties that matter most.How Mature Teams Sequence Security Tooling
Teams operating security at scale tend to follow a layered funnel rather than relying on a single technique:
-
Static analysis to remove obvious and structural flaws early
-
Unit testing and mutation testing to ensure developer intent is actually exercised
-
Formal verification to prove critical invariants and protocol rules
-
Audit and review to apply human judgment where automated methods fall short
Skipping earlier layers makes downstream techniques slower, more brittle, and more expensive. Proactive SDLC tooling helps narrow the funnel so formal verification and audits can operate on cleaner, higher-signal code.
Proposed Approach
Introduce a proactive smart contract security toolkit that integrates directly into existing development workflows and runs automatically on every code change. The approach combines static analysis, automated unit test generation, mutation testing, and an internal audit agent leveraging deterministic architecture to surface findings and automatically generate bug proof-of-concepts.
The goal is to surface vulnerabilities earlier, strengthen test suites, and increase developer velocity by automating multiple forms of testing during development rather than adding another point-in-time review.
This model is already in use in other ecosystems, including an active engagement with the Uniswap Foundation, where similar tooling is applied to improve early-stage security testing and downstream audit outcomes.
Scope
An initial step could be a custom demo run against a pre-audit commit of already audited Compound code. This would allow the community to evaluate signal quality, benchmark findings against prior audits, and assess effectiveness before proceeding to a formal proof-of-concept.
Potential scope includes:
-
Integration with existing repositories and CI workflows
-
Automated testing on every code change
-
Reporting focused on actionable findings and generated proof-of-concepts
Exact scope and duration would be defined collaboratively.Relationship to Existing Security Efforts
This proposal is intentionally additive. It does not replace audits, formal verification, monitoring, or incident response. Instead, it strengthens earlier stages of the SDLC so downstream security processes can operate on cleaner, higher-signal code.Expected Benefits
-
Earlier detection of vulnerabilities during development
-
Stronger and more comprehensive test suites
-
Increased effectiveness of formal verification through reduced noise
-
Improved developer velocity via automated, continuous testing
Next Steps
If there is interest from the community, the next step would be to run a custom demo on existing Compound code to demonstrate effectiveness and benchmark results, followed by discussion of a scoped proof-of-concept.
Happy to answer questions or refine scope based on community feedback.