On August 8, 2025, Scroll encountered a problem that most Ethereum Layer 2 users would never think to look for.
Its sequencer and proving software had reached different conclusions about the same transaction. The sequencer recorded a failed execution, while the prover calculated a different result. That disagreement produced incompatible state roots, preventing Scroll from finalizing new batches on Ethereum.
The problem was eventually resolved. According to the Scroll Security Council, no user funds were at risk. But withdrawals were delayed, and the incident exposed a distinction that can easily disappear behind a familiar transaction status: Success.
On a Layer 2 network, a transaction can be processed successfully long before Ethereum has verified the validity proof covering it. Those two events normally occur as part of the same workflow, but they do not happen at the same time.
The difference becomes especially important when something goes wrong with the software responsible for producing the proof.
Scroll’s experience provides a documented example of what happens when execution and finalization stop moving together.
A Transaction Can Be Confirmed Without Being Final
Consider a user swapping ETH for USDC on an Ethereum Layer 2.
The swap executes, the wallet reflects the new balance, and the block explorer shows a successful transaction. The user can generally continue interacting with applications on that network.
Nothing about that experience necessarily means the transaction has reached its final settlement stage on Ethereum.
In its transaction lifecycle documentation, Scroll separates the process into three stages: Confirmed, Committed, and Finalized.
A transaction becomes confirmed when it has been executed and included in an L2 block. This establishes its inclusion in the sequencer’s chain, although an included transaction can also have a failed execution result.
Committed comes later. Scroll groups transactions into batches and submits their data to Ethereum. Once the relevant commitment is finalized on L1, the underlying transaction data can be used to reconstruct the corresponding L2 state.
Finalized requires another step. A validity proof covering the batch must be generated and verified by the rollup’s Ethereum contracts, followed by finalization of the corresponding L1 transaction.
These stages provide different assurances.
Confirmation tells users that the L2 has processed their transaction. Commitment makes the transaction data available through Ethereum. Proof verification establishes that the claimed state transition satisfies the rollup’s validity rules.
Even Ethereum’s own consensus finality remains a separate consideration when discussing settlement precisely.
The practical difference is easy to miss because users usually don’t need to examine all these stages individually. An application usually cares whether a transaction is executed successfully on its network.
A bridge releasing funds on Ethereum, however, needs stronger evidence.
That distinction helps explain why a functioning L2 application and a delayed withdrawal can coexist without contradicting each other.
The Scroll Bug That Produced Two Different Answers
Scroll’s August 2025 incident began with a technical error in its EuclidV2 prover implementation.
The underlying problem involved account-code information used when processing certain transactions related to EIP-7702.
EIP-7702 allows externally owned Ethereum accounts to delegate execution to existing smart-contract code. The change expands what ordinary accounts can do, but it also introduces execution paths that software implementations must handle consistently.
Under the EIP-7702 specification, the EXTCODESIZE instruction can be used to inspect the size of an account’s code, including its delegation indicator.
In Scroll’s prover, some code paths failed to initialize the relevant code_size field.
As a result, the prover’s implementation EXTCODESIZE returned zero where the execution client recognized a non-zero code size.
That seemingly small difference mattered because smart-contract execution can depend on the value returned by an opcode.
In the Security Council’s incident report, Scroll identified an example involving a delegate-and-call transaction that reverted in its execution client, known as l2geth, but did not revert when processed by the prover.
The two systems therefore calculated different resulting states.
A validity proof must correspond to the state transition that the rollup is attempting to finalize. When the prover’s result diverges from the sequencer’s result, the necessary proof cannot be completed correctly for that state.
Scroll reported a state-root mismatch and stopped finalizing blocks.
This is an important distinction. The documented transaction did not succeed on the sequencer while somehow becoming invalid afterward. It reverted during L2 execution. The failure arose because the prover disagreed with that execution result.
Nor did the report establish that Ethereum accepted an invalid state transition.
Instead, the mismatch stopped the finalization process.
The incident illustrates how a bug in the proving environment can interrupt settlement even when the immediate problem is not the ordinary act of submitting a transaction.
What Scroll’s 20-Hour Recovery Reveals
The official incident timeline offers a closer look at how much of the recovery depended on fixing software and how much depended on coordination.
Scroll received alerts about failed chunk proving at 21:00 UTC on August 8, 2025.
Within an hour, the team had confirmed that a newer prover version could reproduce the execution client’s results. By 23:00 UTC, a new verifier contract had been deployed.
Yet deployment alone was not enough to restore finalization.
The pending chunks and batches still needed to be processed using the corrected prover. Scroll reported completing that work and manually testing the resulting proofs by 09:00 UTC on August 9.
At 11:00 UTC, the verifier upgrade transaction was submitted to the Security Council.
Approval followed at 17:00 UTC, after which the upgrade was executed and pending proven bundles were finalized.
Based on those published timestamps, 20 hours elapsed between the first monitoring alert and the Security Council’s approval and execution of the upgrade.
That is not a measurement of how long every affected transaction waited. The report does not provide enough information to calculate individual withdrawal delays or the exact duration of the finalization backlog from its beginning.
Still, the sequence is revealing.
The team identified a compatible prover version near the beginning of the incident. By the following morning, the pending proofs had been regenerated. Another six hours elapsed between submitting the upgrade to the Security Council and receiving approval.
Recovery therefore involved two distinct processes: restoring agreement between the execution and proving software and obtaining authorization to change the verifier used on Ethereum.
The second process matters just as much as the first when assessing how a rollup behaves under stress.
Cryptographic verification determines which state transitions can be accepted. Operational procedures determine how quickly the system can recover when its proving machinery breaks.
An emergency upgrade mechanism can be valuable because it allows maintainers to correct a serious problem. At the same time, the need for approval introduces a human coordination dependency into recovery.
Both properties exist together.
For users, the relevant question is not simply whether a rollup has a validity-proof system. It is also what happens when that system cannot produce a valid proof: who can repair it and how long the repair process might take.
Why Withdrawal Delays Matter More Than a Status Label
The consequences of delayed finalization are not necessarily visible to someone who keeps using applications entirely within a Layer 2 network.
They become more concrete when assets need to move back to Ethereum.
Scroll’s withdrawal documentation explains that withdrawals initiated on L2 generate messages included in a withdrawal tree.
The root of that tree is finalized on Ethereum alongside the corresponding L2 state root.
Only after the relevant withdrawal root has been finalized can a valid inclusion proof be used to execute the withdrawal on L1.
This creates an important dependency.
A user might have successfully initiated a withdrawal on Scroll, but the assets are not yet available in their Ethereum wallet. The L2 action and the subsequent L1 release are different operations.
If finalization stops, the withdrawal cannot be completed through that normal canonical process until the required state and withdrawal root are finalized.
Imagine a trader who expects to use funds withdrawn from an L2 to meet an obligation on Ethereum.
A successful withdrawal-initiation transaction would not be enough. The trader needs the corresponding assets to become available on L1.
The financial consequences would depend on the size of the position, the duration of the delay, and whether the trader had another source of liquidity. The Scroll incident report does not provide data that would allow for the calculation of those costs.
It does, however, demonstrate why an interruption can matter even without a reported loss of user funds.
There is a difference between assets being protected against an invalid state transition and assets being accessible at the moment their owner needs them.
Users may also encounter third-party bridges that advance liquidity before canonical settlement. Those services can offer a different experience, but their speed depends on separate liquidity arrangements, risk assumptions, and counterparties.
They do not eliminate the distinction between an L2 execution result and the canonical rollup’s finality.
For anyone evaluating the reliability of a Layer 2 network, withdrawal completion is therefore a more demanding test than the speed at which an ordinary swap receives a transaction receipt.
The Finality Gap Did Not Disappear With One Fix
Scroll’s August 2025 repair addressed a particular implementation error. It did not mean the broader challenge of keeping a sequencer and processor consistent had permanently disappeared.
In February 2026, another issue involving the proving environment was reported through a bug bounty disclosure.
This time, the problem concerned the ecPairing precompile and a missing subgroup check for a cryptographic curve point.
According to the Security Council’s March 2026 disclosure, the omission could cause the execution client and prover to return different results for certain inputs, potentially leading to finalization failure.
The team patched the issue and deployed the correction on February 23.
Unlike the August incident, the February report describes a vulnerability that could have produced a finalization failure. It does not establish that such a failure actually occurred on mainnet.
The distinction matters. A reported vulnerability, an observed outage, and a successfully completed repair represent different forms of evidence.
Another useful example arrived in September 2026, this time without an unexpected prover failure.
Scroll announced an upgrade from OpenVM v1.6.0 to v2.0.0, replacing the underlying proving system with SWIRL and incorporating security fixes.
In its September 15 upgrade announcement, Scroll explained that transactions, deposits, and L2 execution would continue normally while L1 batch finalization was expected to pause for approximately one hour.
The upgrade was subsequently confirmed as successfully executed on September 22. The announcement did not establish the precise finalization delay experienced during the upgrade.
Even so, the planned separation is instructive.
Scroll expected ordinary execution to continue while the proving and verification infrastructure was being replaced. The network could keep performing one part of its job while temporarily pausing the other.
That is the same architectural distinction exposed by the earlier incident, but under controlled circumstances rather than an unexpected software disagreement.
Taken together, these events reveal something more useful than a simple judgment about whether Scroll is reliable.
They show how finality depends on several layers of technology and operation: consistent execution, successful proof generation, verification on Ethereum, and the mechanisms governing upgrades when those components need attention.
Not every Layer 2 uses the same approach. Optimistic rollups, for example, have different validation and withdrawal-finality mechanisms from validity rollups such as Scroll. Their confirmation and settlement assumptions should not be treated as interchangeable.
But the broader lesson travels across the category.
Transaction speed describes how quickly a network processes activity. Settlement assurance describes what has been established about that activity and which dependencies remain unresolved.
Those are different things to measure.
A successful Layer 2 transaction can be perfectly valid as an execution result while still waiting for the evidence required by Ethereum. Usually, users never need to consider that waiting period.
When the proof stops arriving, however, the distinction becomes impossible to ignore.
The transaction may be finished from the application’s perspective.
The settlement process is not.
