This proposal explores running an evaluation of an automated, continuous smart contract security layer against a representative slice of Scroll’s existing codebase (zkEVM components, L1/L2 bridge contracts, and the rollup contract suite). The toolkit applies static analysis, automated unit and mutation test generation, and a deterministic internal audit agent that produces actionable findings and bug proof-of-concepts on every commit. The intent is purely to benchmark signal quality against Scroll’s prior audit findings there is no commercial commitment implied by this evaluation.
TL;DR
This proposal explores running a time-boxed evaluation of an automated, continuous smart contract security layer against a representative slice of Scroll’s existing codebase (zkEVM components, L1/L2 bridge contracts, and the rollup contract suite). The toolkit applies static analysis, automated unit and mutation test generation, and a deterministic internal audit agent that produces actionable findings and bug proof-of-concepts on every commit. The intent is purely to benchmark signal quality against Scroll’s prior audit findings - there is no commercial commitment implied by this evaluation.
Summary
Scroll is one of the most mature zkEVM rollups in production, with a security stack that already includes reviews from Trail of Bits, OpenZeppelin, Zellic, and KALOS, dual bug bounty programs on Immunefi and Remedy, and an internal review process that has caught and patched non-trivial circuit-level issues such as missing constraints in the modulo and SHL/SHR opcodes during the pre-mainnet phase.
The question this proposal asks the community to consider is narrower: as Scroll’s surface area continues to expand across zkEVM circuits, prover infrastructure, the L1/L2 message queues, the ScrollChain rollup contract, and bridge contracts, would an always-on tool that exercises this code between audit cycles meaningfully improve early-stage signal? An evaluation is the only honest way to find out.
Motivation
The 2025-2026 hack data points to a pattern that is uncomfortable for protocols relying on an “audit + bounty” posture alone:
-
The Kelp DAO incident in April 2026 drained roughly $292M after a verification bug in a Merkle Mountain Range cross-chain message proof was introduced during a routine upgrade and missed by two independent audits.
-
Multiple bridge and rollup-adjacent incidents in the same window have stemmed from upgrade-introduced regressions, not greenfield logic - exactly the class of change that occurs between scheduled audits.
-
Industry post-mortems through 2025 increasingly point to verification logic in cross-chain messaging, message replay protection, and proof-system glue code as the dominant residual attack surface on L2-class systems.
Scroll’s threat model touches every one of those surfaces directly: a zkEVM prover network, a multi-message bridge with separate L1 and L2 message queues, and a rollup contract that gates all state transitions. Continuous, automated checks between audit cycles are well-suited to catch the upgrade-introduced regressions that drove most of the recent industry losses.
Problem Statement
Even with Scroll’s strong audit history, there are structural gaps that no point-in-time review can fully close:
-
Audits are time-boxed. Code keeps moving. Most of the high-severity 2026 incidents were introduced in commits that landed after the last audit of the affected component.
-
Bridge and rollup contracts have a small attack surface but high blast radius. A single mistaken assumption in a message-passing code path can compromise the entire rollup’s funds.
-
zk-rollup correctness depends on tight coupling between Solidity contracts, off-chain prover code, and circuit constraints. Inconsistencies between these layers are notoriously hard to surface in a manual review of any single one.
-
Auditor attention is finite. Auditors operating on noisy code spend disproportionate time on lower-severity implementation issues that automated tooling can flag instantly, leaving less bandwidth for protocol-level invariants.
Evaluating earlier-stage tooling is a way to test, on Scroll’s own code, whether shifting a class of findings left would let downstream audits focus on what only humans can catch.
How Mature Teams Sequence Security Tooling
Teams running security at scale typically operate a layered funnel:
-
Static analysis - surface structural and implementation flaws on every commit.
-
Automated unit and mutation testing - verify that developer intent is actually exercised by the test suite, and that tests are sensitive to faults.
-
Invariant and property testing - validate system-level assumptions across the full state space.
-
Manual audit and expert review - focus on protocol-level correctness, economic design, and cross-component interactions.
Skipping the first two layers makes downstream review slower, more brittle, and more expensive. The hypothesis in this proposal is that a continuous SDLC layer would let Scroll’s audit partners spend more of their fixed engagement time on (3) and (4) - which is where the highest-severity issues tend to live.
Proposed Evaluation Approach
Run the Olympix smart contract security toolkit against a representative pre-audit commit (or set of commits) in Scroll’s history, and benchmark its output against the actual audit findings that were ultimately produced for that revision.
The toolkit applies, on every code change:
-
Static analysis tuned for Solidity and EVM-specific anti-patterns
-
Automated unit test generation, with mutation testing to validate test effectiveness
-
An internal audit agent built on a deterministic architecture that produces findings together with executable bug proof-of-concepts where applicable
A deterministic architecture matters here: it makes the output reproducible, comparable across runs, and easier for the community to inspect. The same input commit yields the same finding set.
Olympix currently works with some of the largest Defi protocols, institutions, and blockchains in the space, and the framing of this proposal mirrors the approach - community-visible, benchmark-driven, and intentionally scoped to data-gathering rather than procurement.
Scope
A practical first cut would be a limited evaluation against an already-audited Scroll commit - a candidate set might include the bridge and message queue contracts, the ScrollChain rollup contract, or a circuit-adjacent Solidity component. Selection would be made collaboratively with the core team to ensure the evaluation reflects code Scroll actually cares about.
Output would include:
-
Repository and CI integration sufficient to run on every change to the selected scope
-
A finding set with severity, reproduction steps, and (where applicable) bug proof-of-concepts
-
A comparison against the original audit findings for the same commit, to assess overlap, false-positive rate, and coverage of issues the prior audits missed
The evaluation is intentionally read-only with respect to Scroll’s existing security stack. No audit, bounty, or formal verification process is altered, paused, or replaced by this exercise.
Relationship to Existing Security Efforts
This proposal is exploratory and additive. It does not displace Scroll’s existing relationships with Trail of Bits, OpenZeppelin, Zellic, or KALOS, nor the Immunefi and Remedy bug bounty programs. The evaluation is positioned upstream of audits, not in competition with them - the goal is to test whether earlier signal makes the existing stack more effective, not to substitute for any part of it.
Expected Benefits
If the evaluation produces useful signal, the community would have evidence on:
-
Whether earlier visibility into vulnerabilities measurably reduces the per-audit finding count on lower-severity implementation issues.
-
Whether automatically generated tests and POCs improve the developer feedback loop for changes to bridge, rollup, and message-passing code.
-
Whether continuous coverage between audit cycles closes the upgrade-regression gap that has driven a disproportionate share of recent L2 and bridge losses.
-
Whether audit budget can be reallocated toward higher-leverage protocol-level review.
If the evaluation produces weak signal, the community has equally useful evidence: that Scroll’s existing process already captures this class of finding, and the ecosystem can continue with confidence in the current stack.
Next Steps
If there is interest from the community and the core contributors, the next step would be to:
-
Agree on a target commit and scope for the evaluation
-
Run the tool suite and produce a findings report
-
Publish a comparison against the prior audit findings for the same scope
-
Discuss, openly on this forum, whether a broader proof-of-concept makes sense
Happy to answer questions, refine the scope, or adjust the evaluation parameters based on community feedback.