For rollups, DA on L1 means the sequencer cannot withhold data - anyone can read it from Ethereum and verify state transitions independently. For Validiums and Optimiums, DA lives off-chain, so the sequencer can withhold data, making fraud proofs unconstructable and Validium users unable to reconstruct the state.
This framework builds on the DA risk framework and closes that gap in three stages:
-
Stage 0: Proof system enforces state validity when data is accessible. DA commitments are posted onchain, allowing data witholding attack (DWA) detection by querying the DA layer
-
Stage 1: DA verification on L1 makes the proof system enforceable, and removes trust in the sequencer for L1 funds safety
-
Stage 2: DA backed by economic security (staking/slashing), not reputation alone
Note that these stages use the same naming/structure as the rollup Stages framework, but at every stage, alt-DA systems carry an additional trust assumption - the DA layer - that rollup stages do not. For instance, a Stage 1 Validium is not equivalent to a Stage 1 Rollup. Even at Stage 2, alt-DA systems can only make DA compromise economically secure, never trustless.
Stage 0
| # | Requirement | Replaces/Mirrors |
|---|---|---|
| 1 | The project identifies as a Validium or Optimium | Replaces “calls itself a rollup” but not really a requirement |
| 2 | State roots post to Ethereum L1 | Same as rollup |
| 3 | Source-available software can reconstruct L2 state | Removes “from L1 data” from rollup Stages |
| 4 | A proof system is functional (fraud proofs or validity proofs) | Same as rollup |
| 5 | DA is attested by a committee or external DA layer, not solely by the sequencer | New |
| 6 | At least 5 external actors can submit fraud proofs (optimistic systems) | Same as rollup |
Why require the proof system (#4**)?** Without it, the sequencer is trusted for both DA and state validity - it can steal by posting invalid roots or by withholding data. With it, the sequencer can only steal by withholding data. Invalid state transitions get caught whenever data is accessible. This narrows the attack surface.
Why require a DA committee (#5**)?** The sequencer is required to post a commitment pointing at the blob on the DA layer. An independent DA committee is important for DWA detection: anyone running a node can verify independently by querying the DA layer.
Who qualifies today: Validiums/Optimiums with a functional proof system and a DAC or external DA layer. Projects without proof systems (many OP Stack Optimiums with NO_PROOFS) fail requirements #4 and #6 and remain unrated.
Stage 1
Principle: “The only ways (other than bugs) to steal funds or block withdrawals indefinitely are: (1) compromising ≥75% of the Security Council to push a malicious upgrade, or (2) the sequencer colluding with the DA committee to withhold data and finalize invalid state roots.”
The L1 contract now verifies DA attestations onchain. Two attack paths remain: the SC for malicious upgrades, and sequencer + DAC for data withholding.
| # | Requirement | New/Same |
|---|---|---|
| 1 | Users can exit without permissioned operators | Same as rollup - conditional on DA |
| 2 | Users have ≥7 days to exit before unwanted upgrades take effect | Same as rollup |
| 3 | Security Council properly configured (≥8 members, 75% threshold) | Same as rollup |
| 4 | ZK proof system and DA verifier meet verifiability requirements | Same as rollup - extended to DA verifier |
| 5 | Secure DA verifier integration on L1 - the L1 contract verifies DA proofs/attestations onchain ( see DA verifier integration requirements and applications) | New - the defining gate for Stage 1 |
| 6 | DA verifier is non-upgradeable or carries ≥7-day independent exit window | New |
| 7 | DA committee/layer meets minimum decentralization: DAC ≥5 external members with honest-minority assumption; or external DA chain with attestation verifier | New |
Why #5 is the defining gate: At Stage 0, the L1 contract accepts state roots regardless of whether data was posted. At Stage 1, it verifies DA attestation. Challengers can now trust that data was declared available by the DA committee because L1 checked, and can retrieve it to construct proofs.
Why #7 matters: This mirrors the DA risk framework’s bridge/committee security requirement, applied to the DA layer’s decentralization. For external DA chains (Celestia, EigenDA), the DA verifier from #5 is the key gate.
Stage 2
| # | Requirement | New/Same |
|---|---|---|
| 1 | Proof system is permissionless | Same as rollup |
| 2 | Upgrades provide ≥30-day exit window (including DA verifier upgrades) | Extended - covers DA verifier |
| 3 | Security Council limited to adjudicable on-chain bugs | Same as rollup |
| 4 | DA verifier is non-upgradeable or carries ≥30-day independent exit window | New |
| 5 | DA mechanism has economic security (as per DA risk framework) - staked assets at risk for misbehavior; reputational security alone is insufficient | New - the defining gate for Stage 2 |
Why #4: Instant upgradeability nullifies DA guarantees - an attacker could swap in a permissive verifier and bypass verification. This parallels the rollup requirement that proof systems cannot be overridden without exit windows.
Why #5 is the defining gate: At Stage 1, the committee’s honesty rests on reputation. At Stage 2, DA must be backed by staked assets slashable on misbehavior. Pure DACs with reputational-only security are capped at Stage 1.
Feedback from the community is welcome at this stage. We look forward to implementing this framework and working with DA layers and L2s to meet these requirements.