{
"architectureImage": "opstack-rollup-superchain-opfp-aggverifier",
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time.",
"risks": [],
"references": [
{
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
},
{
"title": "BatchInbox - address",
"url": "https://etherscan.io/address/0xFf00000000000000000000000000000000008453#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x66d94eE8F529b683ED6013729784e8bb44697A64#code"
}
]
}
],
"exitMechanisms": [
{
"name": "Forced messaging",
"description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
"risks": [],
"references": [
{
"title": "Forced withdrawal from an OP Stack blockchain",
"url": "https://docs.optimism.io/stack/transactions/forced-transaction"
}
]
}
],
"forceTransactions": {
"name": "Users can force any transaction",
"description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
"risks": [],
"references": [
{
"title": "Sequencing Window - OP Mainnet Specs",
"url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x66d94eE8F529b683ED6013729784e8bb44697A64#code"
}
]
},
"otherConsiderations": [
{
"name": "EVM compatible smart contracts are supported",
"description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
"risks": [],
"references": [
{
"title": "Introducing EVM Equivalence",
"url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
}
]
}
],
"stateDerivation": {
"nodeSoftware": "The rollup node is composed of two software components: [op-node](https://github.com/ethereum-optimism/optimism/tree/develop/op-node), implementing consensus related logic, and [op-geth](https://github.com/ethereum-optimism/op-geth), implementing execution logic. The configuration file can be found [here](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/base.toml).",
"compressionScheme": "Data batches are compressed using the [zlib](https://github.com/madler/zlib) algorithm with best compression level.",
"genesisState": "The genesis file can be found [here](https://raw.githubusercontent.com/base-org/node/refs/tags/v0.8.4/mainnet/genesis-l2.json).",
"dataFormat": "The format specification of Sequencer's data batches can be found [here](https://optimism.io/blog/here-s-how-you-can-reproduce-op-mainnet-s-migration-to-bedrock)."
},
"stateValidation": {
"categories": [
{
"title": "State root proposals",
"description": "State roots are proposed by calling `DisputeGameFactory.create` with the AggregateVerifier game type, posting a bond of 0.05 ETH. Each proposal must include an initial proof (TEE attestation or ZK proof) over the range of 600 L2 blocks split into sub-ranges of 30 blocks. With a single proof, the game resolves after 5d; if both proof arms commit, the window collapses to 1d.",
"references": []
},
{
"title": "Challenges",
"description": "Any party that produces a valid ZK proof of an incorrect intermediate root can call `AggregateVerifier.challenge`, contradicting a TEE-only proposal. The challenger's proof is verified onchain via the SP1 verifier gateway. If the challenge stands until the resolution window closes, the original proposer's bond is awarded to the challenger and the game resolves CHALLENGER_WINS. Soundness contradictions within a single proof arm are caught by `AggregateVerifier.nullify`, which permanently disables that arm's verifier contract for all games.",
"references": []
}
]
},
"stateValidationImage": "aggverifier",
"upgradesAndGovernance": {
"content": "All contracts are upgradable by a `ProxyAdmin` contract controlled by a nested 2/2 `Base Governance Multisig` composed of the `Base Coordinator Multisig` and the `Base Security Council`. Upgrades require approval from both parties. There is no delay on upgrades. The Guardian role for the SuperchainConfig is assigned to the Base Governance Multisig, which can pause and unpause withdrawals. `Base Multisig 1` serves as Incident Responder and can pause withdrawals but cannot unpause or extend pauses. Each pause automatically expires after 3 months if not extended by the Guardian. The single Sequencer actor can be modified by `Base Multisig 1` via the SystemConfig contract. The Base Governance multisig can also recover dispute bonds in case of bugs that would distribute them incorrectly.\n\nState validation runs through the `AggregateVerifier` game type (621), which accepts either an AWS Nitro TEE attestation or an SP1 ZK proof. The TEE prover allowlist in the `TEEProverRegistry` is managed solely by the `Base Coordinator Multisig` (without Base Security Council approval), and a separate Manager EOA can register or deregister enclave signers. The ZK arm routes through a Base-owned SP1 verifier gateway; the Base Governance Multisig can add or freeze verifier routes. The Base Governance Multisig can swap the AggregateVerifier implementation, change the respected game type, blacklist individual games, or retire all in-flight games via the AnchorStateRegistry."
"content": "All contracts are upgradable by a `ProxyAdmin` contract controlled by a nested 2/2 `Base Governance Multisig` composed of the `Base Coordinator Multisig` and the `Base Security Council`. Upgrades require approval from both parties. There is no delay on upgrades. The Guardian role for the SuperchainConfig is assigned to the Base Governance Multisig, which can pause and unpause withdrawals. `Base Multisig 1` serves as Incident Responder and can pause withdrawals but cannot unpause or extend pauses. Each pause automatically expires after 3 months if not extended by the Guardian. The single Sequencer actor can be modified by `Base Multisig 1` via the SystemConfig contract. The Base Governance multisig can also recover dispute bonds in case of bugs that would distribute them incorrectly.\n\nState validation runs through the `AggregateVerifier` game type (621), which accepts either an AWS Nitro TEE attestation or an SP1 ZK proof. The TEE prover allowlist in the `TEEProverRegistry` is managed solely by the `Base Coordinator Multisig` (without Base Security Council approval), and a separate Manager EOA can register or deregister enclave signers. The ZK arm routes through a Base-owned SP1 verifier gateway; the Base Governance Multisig can add or freeze verifier routes. The Base Governance Multisig can swap the AggregateVerifier implementation, change the respected game type, blacklist individual games, or retire all in-flight games via the AnchorStateRegistry.",
"governanceInfo": {
"securityCouncil": {
"Composition": "**8/11**, nested as one of two signers in the 2/2 `Base Governance Multisig` alongside Coinbase's 3/6 `Base Coordinator Multisig`. Base counts this as 9 of 12 entities, or 75%; the Council Safe on its own is 72.7%. Members serve staggered cohort terms and are appointed against published criteria, not elected.",
"Members public": "**Mapped (10 of 11)** — [Base publishes](https://docs.base.org/base-chain/security/security-council) Aerodrome (JP), Moonwell (BR), Blackbird (US), ChainSafe (CA), Talent Protocol (PT) and Moshicam (US) as entities, plus Seneca (US), Juan Suarez (US), Toady Hawk (CA), Roberto Bayardo (US) and Yele Bademosi (UK) as individuals. One address is unpublished, as are the people who sign for each entity. Five of the six entities are Base-ecosystem projects and two of the individuals are former Coinbase or Base contributors.",
"Charter": "**None** — the [docs page](https://docs.base.org/base-chain/security/security-council) sets out selection criteria, cohort terms and member duties, but no removal procedure, quorum-loss fallback or conflict-of-interest enforcement. Coinbase's [Neutrality Principles](https://www.coinbase.com/blog/coinbases-neutrality-principles-for-base) cover transaction ordering, user assets and exit rights, and do not bind the Council.",
"Can Coinbase bypass the Council?": "**Not for upgrades** — every `ProxyAdmin` action needs the 2/2. Elsewhere Coinbase acts alone: the 3/12 `Base Multisig 1` owns `SystemConfig` (sequencer, gas configuration) and is Incident Responder, and the Coordinator Multisig owns `TEEProverRegistry` and `NitroEnclaveVerifier`, so it can change the TEE prover allowlist, one of the two proof arms, without the Council.",
"Who can override the Council?": "**Nobody — it administers itself.** Seats are changed by the Council Safe calling itself, so 8 of the 11 sitting members decide who joins or leaves. There is no token, DAO or veto body. The 2/2 blocks both ways: neither side can upgrade alone. Below 8 available signers upgrades stall, and there is no liveness module handing control to a fallback."
},
"upgrades": {
"Normal upgrade path": "Task published in [base/contract-deployments](https://github.com/base/contract-deployments) → **8/11 Security Council approval** → **3/6 Coordinator Multisig approval** → execution through the 2/2 `Base Governance Multisig`. No timelock, and no Safe carries a delay module. Beryl verifier-hash update, June 2026: Council approved 22 Jun, Coinbase 23 Jun, executed 43 minutes later.",
"Emergency upgrade path": "**None** — the normal path executes as soon as both Safes sign, so there is no lower emergency threshold. The fastest lever is a pause: the 3/12 `Base Multisig 1` can pause withdrawals alone as Incident Responder, but only once per identifier, since the pause expires after 3mo 1d and it cannot pause again until the Guardian unpauses. The Guardian is the 2/2 `Base Governance Multisig` itself, which can also blacklist dispute games, set the respected game type and retire all in-flight games.",
"Exit window": "**None** — nothing separates the second signature from the upgrade taking effect, so users cannot withdraw ahead of an unwanted change. Tasks are published before signing and Base targets six hard forks a year, but neither is enforced onchain."
},
"tokenGovernance": {
"Governance token": "**None** — Base has no token, so no token-weighted vote enters the upgrade path. Coinbase has said it is exploring one.",
"Voting venue": "**None** — no DAO, governor contract, Snapshot space or forum vote gates an upgrade. Coordination happens in [base/contract-deployments](https://github.com/base/contract-deployments).",
"Proposal rights": "**Coinbase only** — upgrade tasks are Coinbase-authored, and no route exists for a third party to put an upgrade to the Council.",
"Execution model": "**Two Safes sign, a facilitator executes.** No permissionless `execute()`, and no delay for the public to act inside."
}
}
}
}