Search

Search for projects by name or address

Base Chain logo
Base Chain

Badges

About

Base is an Optimistic Rollup built with the OP Stack. It offers a low-cost and builder-friendly way for anyone, anywhere, to build onchain.



Badges

About

Base is an Optimistic Rollup built with the OP Stack. It offers a low-cost and builder-friendly way for anyone, anywhere, to build onchain.


Total
Canonically BridgedCanonically Bridged ValueCanonical
Natively MintedNatively Minted TokensNative
Externally BridgedExternally Bridged ValueExternal

ETH & derivatives
Stablecoins
BTC & derivatives
Other
Compare with other projects
Chain stats
Transfer size
Under $100
$100-$1K
$1K-$10K
$10K-$100K
Over $100K
Transfer type distribution

Past Day UOPS
Past Day Ops count
Max. UOPS
Past day UOPS/TPS Ratio
Compare with other projects

The section shows the operating costs that L2s pay to Ethereum.



Total cost
Avg cost per L2 UOP
Avg cost per day

Compare with other projects

This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data toEthereumEthereum.



Data posted
Avg size per day
Avg size per L2 UOP

Compare with other projects

This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.

No ongoing anomalies detected

Avg. tx data subs. interval
Avg. state updates interval
Past 30 days anomalies
96% normal uptime

Last 30 day anomalies

All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.

No State updates were performed for 23h 21m (from 2026 Oct 08, 14:46 UTC until 2026 Oct 09, 14:08 UTC). These typically occur every 48m 29s on average.

Base Azul: multi-proof

2026 May 26th

Base activates the multiproof system combining TEE attestations and SP1 ZK proofs.

Learn more

Base leaves the Superchain

2026 Mar 4th

Base decouples from Optimism Superchain governance with its own upgrade path.

Learn more
Sequencer failureState validationData availabilityExit windowProposer failure
Sequencer failure
Self sequence

In the event of a sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. failure, users can force transactions to be included in the project’s chain by sending them to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. There can be up to a 12h delay on this operation.

State validation
Fraud proofs (1R, ZK)

Fraud proofs allow actors watching the chain to prove that the state is incorrect. Single round proofs (1R) prove the validity of a state proposal, only requiring a single transaction to resolve. A fault proof eliminates a state proposal by proving that any intermediate state transition in the proposal results in a different state rootA cryptographic hash succinctly representing a state using a Merkle tree.. For either, a ZK proof is used.

Data availability
Onchain

All of the data needed for proof construction is published on Ethereum L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..

Exit window
None

There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable. Upgrades need to be approved by 2 parties: the Base Coordinator Multisig and the Base Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups..

Proposer failure
Self propose

Anyone can be a ProposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. and propose new roots to the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge..

Base Chain
Base Chain is a
Stage 1
Optimistic Rollup.
The project passes the walkaway test: users can exit in the presence of malicious operators even if the Security Council disappears.

Learn more about Stages
Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

All data required for proofs is published on chain

All the data that is used to construct the system state is published on chain in the form of cheap blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. or calldata. This ensures that it will be available for enough time.

  1. Derivation: Batch submission - OP Mainnet specs
  2. BatchInbox - address
  3. OptimismPortal2.sol - source code, depositTransaction function
Learn more about the DA layer here: Ethereum logoEthereum
Node software

The rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. nodeA software client that participates in the network. is composed of two software components: op-node, implementing consensusAn agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon. related logic, and op-geth, implementing execution logic. The configuration file can be found here.

Compression scheme

Data batches are compressed using the zlib algorithm with best compression level.

Genesis state

The genesis file can be found here.

Data format

The format specification of SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs.’s data batches can be found here.

A diagram of the state validation
A diagram of the state validation
State root proposals

State rootsA cryptographic hash succinctly representing a state using a Merkle tree. 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 L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. 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.

Challenges

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 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. gateway. If the challenge stands until the resolution window closes, the original proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.’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.

Trusted Setups

Onchain verifier

Used in

Base Chain logoMantle logoCelo logoX Layer logoMorph logo

Projects used in

Search for projects used in

Onchain verifier

Used in

Base Chain logoMantle logoCelo logoX Layer logoMorph logo

Projects used in

Search for projects used in

Program Hashes

Name
Hash
Repository
Verification
Used in
0x00f5...568a
Base Chain logo
0x25e0...7c21
Base Chain logo
0x45c5...b0e0
Base Chain logo
A diagram of the upgrades and governance
A diagram of the upgrades and governance

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 SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. 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.

State validation runs through the AggregateVerifier game type (621), which accepts either an AWS Nitro TEE attestation or an SP1 ZK proof. The TEE proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. allowlist in the TEEProverRegistry is managed solely by the Base Coordinator Multisig (without Base Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. approval), and a separate Manager EOA can register or deregister enclave signers. The ZK arm routes through a Base-owned SP1 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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.

Governance profile

Security Council

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 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 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 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 (sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs., gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. configuration) and is Incident Responder, and the Coordinator Multisig owns TEEProverRegistry and CertManager, so it can change the TEE proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. 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 blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. both ways: neither side can upgrade alone. Below 8 available signers upgrades stall, and there is no livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. module handing control to a fallback.

Upgrades

Normal upgrade path

Task published in base/contract-deployments → 8/11 Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. approval → 3/6 Coordinator Multisig approval → execution through the 2/2 Base Governance Multisig. No timelock, and no Safe carries a delay module. Beryl verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.-hashA fixed-length fingerprint of variable-size input, produced by a hash function. 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.

Token governance

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.

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 permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execute(), and no delay for the public to act inside.

Past upgrades

The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

Count of upgrades
63
Last upgrade
4d 12h ago
Avg upgrade interval
5mo 18d

Ossification

Contracts our research team classifies as critical form the project's critical perimeter. Its clock starts at the ossification genesis, and every critical change resets it (changes within 24 hours count as one). The ossification score is the share of recorded code-bug exploits whose exploited code was younger than this perimeter is today. Battle-tested exposure is the value secured, summed over that unchanged period.

Ossification %
25since 2026 Oct 07
TVS & changes (1Y)
Battle-tested exposure
$36.17 M·years
Critical changes / year
8.0across 24 contracts
Exit window

Discovery updates

2026 October 09, 09:36 UTC
High severity
7changes

OptimismPortal2 6.0.0 → 6.0.1: a failed withdrawal call to a 7702-delegated EOA now reverts instead of finalizing, upgraded by the Base Governance Multisig. https://disco.l2beat.com/diff/eth:0xcA5ca23502eFf4254bc11Ac0bEC4Dbb7495Bd06C/eth:0x03863Ab7F64B733cFF85C8fF44a86601C568Ca70

contract OptimismPortal2 (eth:0x49048044D57e1C92A77f79988d21Fa8fAF74E97e) [opstack/OptimismPortal2] {
+++ description: The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the AggregateVerifier.
sourceHashes.1:
- "0xe19e03ee1eceea55b82f2982dcbf9d11d2a194352be04181edc1b6cfe1e9dcb3"
+ "0xa3692169a2d67b0edeeee11f2dd643e4bebd7d1178b87d899f03ff7c580d5dc2"
values.$implementation:
- "eth:0xcA5ca23502eFf4254bc11Ac0bEC4Dbb7495Bd06C"
+ "eth:0x03863Ab7F64B733cFF85C8fF44a86601C568Ca70"
values.$pastUpgrades.12:
+ ["2026-10-07T17:44:47.000Z","0x12b3bf5bb0a8f921321f9a91303240ce01fde9f99ba9f97234f89d114c077bf6",["eth:0x03863Ab7F64B733cFF85C8fF44a86601C568Ca70"]]
values.$upgradeCount:
- 12
+ 13
values.version:
- "6.0.0"
+ "6.0.1"
implementationNames.eth:0xcA5ca23502eFf4254bc11Ac0bEC4Dbb7495Bd06C:
- "OptimismPortal2"
implementationNames.eth:0x03863Ab7F64B733cFF85C8fF44a86601C568Ca70:
+ "OptimismPortal2"
}
2026 October 02, 14:24 UTC
Critical state change
61changes

Base Cobalt upgrade. Version changes and implementation diffs: - OptimismPortal2 5.2.0 - 6.0.0: https://disco.l2beat.com/diff/eth:0x66d94eE8F529b683ED6013729784e8bb44697A64/eth:0xcA5ca23502eFf4254bc11Ac0bEC4Dbb7495Bd06C - SystemConfig 3.13.2 - 3.14.0: https://disco.l2beat.com/diff/eth:0x0507Aaa21c678976FCdC7e804836ACd6ebc17a44/eth:0x56ca4f4F5Ba9B42d360B48429e8C4a60C5A0795D - DisputeGameFactory 1.4.0 - 1.5.0: https://disco.l2beat.com/diff/eth:0x468C2345D1d409d5b0F2f8bE4aE2082150cC1a0c/eth:0x94eab8f73fd83407D26C006D159923760D483029 - TEEProverRegistry 0.5.0 - 0.6.1: https://disco.l2beat.com/diff/eth:0xeaB9b34BDD26Ad451B381B0934a30fAa6ED5E316/eth:0x1d8728CabC8BC022005dd08D02a749B8a32Af440 - AggregateVerifier 0.1.0 - 0.2.0 (new game type 621 implementation): https://disco.l2beat.com/diff/eth:0xeE303bA054c5F1E14A8EF87f1C7E285af45A1ba2/eth:0xeF9eCeA15265321753047EBF7D54C858D53cB94f OptimismPortal2 and SystemConfig drop ETHLockbox support. DisputeGameFactory deploys games with CREATE2. AggregateVerifier: new TEE image hash, ZK range hash and ZK aggregation hash. Games commit to the upgrade schedule in the new ProtocolVersions contract (admin ProxyAdmin, incident responder Base Multisig 1). TEEProverRegistry: signer attestations are validated by the new NitroValidator, CertManager (owner Base Coordinator Multisig, revoker the TEEProverRegistry manager) and P384Verifier. NitroEnclaveVerifier and the RISC Zero verifier contracts with their TimelockController and Safe are removed.

contract ProxyAdmin (eth:0x0475cBCAebd9CE8AfA5025828d5b98DFb67E059E) [global/ProxyAdmin] {
+++ description: None
directlyReceivedPermissions.10:
+ {"permission":"upgrade","from":"eth:0x7480Afc8D99a5c645c247dB5A1e4a4f440e6e095","role":"admin"}
}
- Status: DELETED
contract TimelockController (eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711) [global/TimelockController]
+++ description: A timelock with access control. The current minimum delay is 3d.
contract Base Multisig 1 (eth:0x14536667Cd30e52C0b458BaACcB9faDA7046E056) [GnosisSafe] {
+++ description: None
receivedPermissions.1:
+ {"permission":"interact","from":"eth:0x7480Afc8D99a5c645c247dB5A1e4a4f440e6e095","description":"delay the activation of a scheduled upgrade.","role":".incidentResponder"}
}
contract TEEProverRegistry (eth:0x1af2A7E537DE2eE795DE5B8BfbB1Ad0DD513A5aA) [base/TEEProverRegistry] {
+++ description: Registry of authorized TEE enclave signers and proposer addresses. Signer registration requires a valid AWS Nitro attestation document.
sourceHashes.1:
- "0x9831f0365a1629899a27a5e77f1445d6b78de4d90376053079da107921dda3a2"
+ "0xede8082a5b614fbd752ea8f214321a92d5c97db36aac1070675b57e45a775d5d"
values.$implementation:
- "eth:0xeaB9b34BDD26Ad451B381B0934a30fAa6ED5E316"
+ "eth:0x1d8728CabC8BC022005dd08D02a749B8a32Af440"
values.$pastUpgrades.1:
+ ["2026-09-28T20:38:11.000Z","0x356e1dd97cb22e3d6129ec91557b1bec8971f0c2e0b4d6c1fb54e8b014dd659b",["eth:0x1d8728CabC8BC022005dd08D02a749B8a32Af440"]]
values.$upgradeCount:
- 1
+ 2
+++ description: TEE image hash (PCR0) of the AggregateVerifier registered in the DisputeGameFactory for gameType. Derived, not stored in this contract.
values.getExpectedImageHash:
- "0x58557c709e93357a135041297107aecc4bc6ba616509098a4aa8dbef774d212a"
+ "0x45c538bc396fe4a01b3f9ddc999494c3b993480ecac0a917e2f1af230d78b0e0"
values.NITRO_VERIFIER:
- "eth:0x7F3a16E1fe6Fda64c5AC4296E13ECB9F7B44F6fb"
values.version:
- "0.5.0"
+ "0.6.1"
values.NITRO_VALIDATOR:
+ "eth:0x47C1ab20fac92c789d9e5708D06641c79b03C460"
implementationNames.eth:0xeaB9b34BDD26Ad451B381B0934a30fAa6ED5E316:
- "TEEProverRegistry"
implementationNames.eth:0x1d8728CabC8BC022005dd08D02a749B8a32Af440:
+ "TEEProverRegistry"
}
- Status: DELETED
contract RiscZeroVerifierEmergencyStop (eth:0x1efDd13f831ceeEa14940806705A53D3211CD698) [risc0/RiscZeroVerifierEmergencyStop]
+++ description: A verifier wrapper for the eth:0xafB31f5b70623CDF4b20Ada3f7230916A5A79df9 that allows pausing (emergency stop) the verifier by its owner.
- Status: DELETED
contract RiscZeroGroth16Verifier (eth:0x20ff7C2Cf391a5F096A2Cc181cb41916680f8E97) [taiko/RiscZeroGroth16Verifier]
+++ description: Verifier contract for RISC Zero Groth16 proofs (version 2.0.0-rc.3).
- Status: DELETED
contract RiscZeroGroth16Verifier (eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D) [taiko/RiscZeroGroth16Verifier]
+++ description: Verifier contract for RISC Zero Groth16 proofs (version 3.0.0).
- Status: DELETED
contract Safe (eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609) [GnosisSafe]
+++ description: None
contract DisputeGameFactory (eth:0x43edB88C4B80fDD2AdFF2412A7BebF9dF42cB40e) [opstack/DisputeGameFactory_v2] {
+++ description: The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them. This variant exposes per-type reads only; the legacy array views (gameImpls[], initBonds[]) were removed in the new implementation.
sourceHashes.1:
- "0x780eaf9d8daa77c3325b79e5f3467c1bd8eec57b5d7e84651bdf2d24754d6838"
+ "0x580049b41f9d831de51dfb5920cb1d45c4c229d3eb702b5422231a00759af5a1"
values.$implementation:
- "eth:0x468C2345D1d409d5b0F2f8bE4aE2082150cC1a0c"
+ "eth:0x94eab8f73fd83407D26C006D159923760D483029"
values.$pastUpgrades.6:
+ ["2026-09-28T20:38:11.000Z","0x356e1dd97cb22e3d6129ec91557b1bec8971f0c2e0b4d6c1fb54e8b014dd659b",["eth:0x94eab8f73fd83407D26C006D159923760D483029"]]
values.$upgradeCount:
- 6
+ 7
+++ severity: HIGH
values.game621:
- "eth:0xeE303bA054c5F1E14A8EF87f1C7E285af45A1ba2"
+ "eth:0xeF9eCeA15265321753047EBF7D54C858D53cB94f"
values.version:
- "1.4.0"
+ "1.5.0"
implementationNames.eth:0x468C2345D1d409d5b0F2f8bE4aE2082150cC1a0c:
- "DisputeGameFactory"
implementationNames.eth:0x94eab8f73fd83407D26C006D159923760D483029:
+ "DisputeGameFactory"
}
- Status: DELETED
contract RiscZeroVerifierEmergencyStop (eth:0x44c220f0598345195cE99AD6A57aDfFcb9Ea33e7) [risc0/RiscZeroVerifierEmergencyStop]
+++ description: A verifier wrapper for the eth:0xf70aBAb028Eb6F4100A24B203E113D94E87DE93C that allows pausing (emergency stop) the verifier by its owner.
contract OptimismPortal2 (eth:0x49048044D57e1C92A77f79988d21Fa8fAF74E97e) [opstack/OptimismPortal2] {
+++ description: The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the AggregateVerifier.
sourceHashes.1:
- "0x247eac30dea3a06b4a7142ac53d0b9ad882952c87406f165ec8721b0d97bd6da"
+ "0xe19e03ee1eceea55b82f2982dcbf9d11d2a194352be04181edc1b6cfe1e9dcb3"
values.$implementation:
- "eth:0x66d94eE8F529b683ED6013729784e8bb44697A64"
+ "eth:0xcA5ca23502eFf4254bc11Ac0bEC4Dbb7495Bd06C"
values.$pastUpgrades.11:
+ ["2026-09-28T20:38:11.000Z","0x356e1dd97cb22e3d6129ec91557b1bec8971f0c2e0b4d6c1fb54e8b014dd659b",["eth:0xcA5ca23502eFf4254bc11Ac0bEC4Dbb7495Bd06C"]]
values.$upgradeCount:
- 11
+ 12
+++ severity: HIGH
values.ethLockbox:
- "eth:0x0000000000000000000000000000000000000000"
values.version:
- "5.2.0"
+ "6.0.0"
implementationNames.eth:0x66d94eE8F529b683ED6013729784e8bb44697A64:
- "OptimismPortal2"
implementationNames.eth:0xcA5ca23502eFf4254bc11Ac0bEC4Dbb7495Bd06C:
+ "OptimismPortal2"
}
- Status: DELETED
contract RiscZeroSetVerifier (eth:0x5005aBa3DFf7C940fcc1e48DccCAD611a80eEB85) [risc0/RiscZeroSetVerifier]
+++ description: Set verifier contract for RISC Zero proofs (version 0.9.0). It allows verifying a whole set of proofs identified with a Merkle root at once, afterwards each individual proof could be efficiently verified just by checking Merkle inclusion against the verified root.
- Status: DELETED
contract RiscZeroGroth16Verifier (eth:0x54aCE3ED46529B4d4F3770C8Bad5dDC48717B9bF) [taiko/RiscZeroGroth16Verifier]
+++ description: Verifier contract for RISC Zero Groth16 proofs (version 2.0.3).
- Status: DELETED
contract RiscZeroVerifierEmergencyStop (eth:0x68dC2cB4e61774873971c499D9b239ec5Ac540E3) [risc0/RiscZeroVerifierEmergencyStop]
+++ description: A verifier wrapper for the eth:0x20ff7C2Cf391a5F096A2Cc181cb41916680f8E97 that allows pausing (emergency stop) the verifier by its owner.
contract SystemConfig (eth:0x73a79Fab69143498Ed3712e519A88a918e1f4072) [opstack/SystemConfig] {
+++ description: Contains configuration parameters such as the Sequencer address, gas limit on this chain and the unsafe block signer address.
sourceHashes.1:
- "0x05f19560cc64e41a40dcb3e2efd7011156ab03192fcc0bfadffccd4019c99e8e"
+ "0x8ee185d15557b411e4a37287ec10583b4c685af295ff63b63c09edf12c6dbe9a"
values.$implementation:
- "eth:0x0507Aaa21c678976FCdC7e804836ACd6ebc17a44"
+ "eth:0x56ca4f4F5Ba9B42d360B48429e8C4a60C5A0795D"
values.$pastUpgrades.15:
+ ["2026-09-28T20:38:11.000Z","0x356e1dd97cb22e3d6129ec91557b1bec8971f0c2e0b4d6c1fb54e8b014dd659b",["eth:0x56ca4f4F5Ba9B42d360B48429e8C4a60C5A0795D"]]
values.$upgradeCount:
- 15
+ 16
values.version:
- "3.13.2"
+ "3.14.0"
implementationNames.eth:0x0507Aaa21c678976FCdC7e804836ACd6ebc17a44:
- "SystemConfig"
implementationNames.eth:0x56ca4f4F5Ba9B42d360B48429e8C4a60C5A0795D:
+ "SystemConfig"
}
contract Base Governance Multisig (eth:0x7bB41C3008B3f03FE483B28b8DB90e19Cf07595c) [GnosisSafe] {
+++ description: None
receivedPermissions.1:
+ {"permission":"interact","from":"eth:0x7480Afc8D99a5c645c247dB5A1e4a4f440e6e095","description":"register upgrades, set their activation timestamps and the minimum protocol version, and appoint the incident responder.","role":".proxyAdminOwner"}
receivedPermissions.14:
+ {"permission":"upgrade","from":"eth:0x7480Afc8D99a5c645c247dB5A1e4a4f440e6e095","role":"admin","via":[{"address":"eth:0x0475cBCAebd9CE8AfA5025828d5b98DFb67E059E"}]}
}
- Status: DELETED
contract NitroEnclaveVerifier (eth:0x7F3a16E1fe6Fda64c5AC4296E13ECB9F7B44F6fb) [base/NitroEnclaveVerifier]
+++ description: ZK-based verifier of AWS Nitro Enclave attestation documents. Used by TEEProverRegistry to validate new enclave signer registrations against the AWS Nitro PKI.
- Status: DELETED
contract RiscZeroVerifierEmergencyStop (eth:0x844D5f01161E3559d36f23d0Aa9E9620949aF782) [risc0/RiscZeroVerifierEmergencyStop]
+++ description: A verifier wrapper for the eth:0x5005aBa3DFf7C940fcc1e48DccCAD611a80eEB85 that allows pausing (emergency stop) the verifier by its owner.
- Status: DELETED
contract RiscZeroVerifierRouter (eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319) [risc0/RiscZeroVerifierRouter]
+++ description: A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711).
contract Base Coordinator Multisig (eth:0x9855054731540A48b28990B63DcF4f33d8AE46A1) [GnosisSafe] {
+++ description: None
receivedPermissions.1:
+ {"permission":"interact","from":"eth:0x7227d8C477CD0A9EC1446A19b1FCf940Ba3Fba17","description":"revoke the root certificate, unrevoke certificates and set the revoker.","role":".owner"}
}
- Status: DELETED
contract RiscZeroVerifierEmergencyStop (eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696) [risc0/RiscZeroVerifierEmergencyStop]
+++ description: A verifier wrapper for the eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D that allows pausing (emergency stop) the verifier by its owner.
- Status: DELETED
contract RiscZeroGroth16Verifier (eth:0xafB31f5b70623CDF4b20Ada3f7230916A5A79df9) [taiko/RiscZeroGroth16Verifier]
+++ description: Verifier contract for RISC Zero Groth16 proofs (version 2.2.0).
EOA (eth:0xd87488Dbb5b6F47cc6c15Dd95Bb60c83D3031b04) {
+++ description: None
receivedPermissions.1:
+ {"permission":"interact","from":"eth:0x7227d8C477CD0A9EC1446A19b1FCf940Ba3Fba17","description":"revoke non-root certificates.","role":".revoker"}
}
- Status: DELETED
contract RiscZeroVerifierEmergencyStop (eth:0xDa8f3de6fBBdb261Ac771B813a578A7aBdA6B2b1) [risc0/RiscZeroVerifierEmergencyStop]
+++ description: A verifier wrapper for the eth:0x54aCE3ED46529B4d4F3770C8Bad5dDC48717B9bF that allows pausing (emergency stop) the verifier by its owner.
- Status: DELETED
contract AggregateVerifier (eth:0xeE303bA054c5F1E14A8EF87f1C7E285af45A1ba2) [opstack/AggregateVerifier]
+++ description: Game type implementation that combines a TEE attestation arm and a ZK proof arm. A single un-nullified proof of either type can resolve a game (PROOF_THRESHOLD = 1). When both arms commit, the finalization window collapses from SLOW_FINALIZATION_DELAY (5d) to FAST_FINALIZATION_DELAY (1d).
- Status: DELETED
contract RiscZeroGroth16Verifier (eth:0xf70aBAb028Eb6F4100A24B203E113D94E87DE93C) [taiko/RiscZeroGroth16VerifierLegacy]
+++ description: Verifier contract for RISC Zero Groth16 proofs. This older implementation exposes control-root and selector constants but does not expose a VERSION getter.
+ Status: CREATED
contract NitroValidator (eth:0x47C1ab20fac92c789d9e5708D06641c79b03C460) [base/NitroValidator]
+++ description: Onchain validator of AWS Nitro Enclave attestation documents.
+ Status: CREATED
contract CertManager (eth:0x7227d8C477CD0A9EC1446A19b1FCf940Ba3Fba17) [base/CertManager]
+++ description: Verifies and caches AWS Nitro certificate chains against a pinned root certificate.
+ Status: CREATED
contract ProtocolVersions (eth:0x7480Afc8D99a5c645c247dB5A1e4a4f440e6e095) [base/ProtocolVersions]
+++ description: Registry of L2 upgrade activation timestamps. Dispute games commit to the upgrades active at their ending L2 block and proofs must match that commitment.
+ Status: CREATED
contract P384Verifier (eth:0xe0aa6868e14300355001130C6DC29f2f4467D86c) [base/P384Verifier]
+++ description: Stateless verifier of P-384 ECDSA signatures.
+ Status: CREATED
contract AggregateVerifier (eth:0xeF9eCeA15265321753047EBF7D54C858D53cB94f) [opstack/AggregateVerifier]
+++ description: Game type implementation that combines a TEE attestation arm and a ZK proof arm. A single un-nullified proof of either type can resolve a game (PROOF_THRESHOLD = 1). When both arms commit, the finalization window collapses from SLOW_FINALIZATION_DELAY (5d) to FAST_FINALIZATION_DELAY (1d).
2026 July 28, 08:08 UTC
1change

Refresh config-derived discovery metadata at the main-branch block.

New and verified contracts

+ Status: CREATED
contract DelayedWETH (eth:0x2453c1216E49704d84eA98a4daCd95738F2fC8Ec) [opstack/DelayedWETH]
+++ description: Contract designed to hold the bonded ETH for each game. It is designed as a wrapper around WETH to allow an owner to function as a backstop if a game would incorrectly distribute funds.
2026 July 28, 08:08 UTC
Critical state change
8changes

Redeployed aggregate verifier with different range and aggregation prog hashes and no code changes: https://disco.l2beat.com/diff/eth:0x1bd8db5139Ba7aC9277684650c15e6E341761919/eth:0xeE303bA054c5F1E14A8EF87f1C7E285af45A1ba2. Both programs are regenreated from sources. Disabled Groth16 SP1 verifier and enabled Plonk v6.1.0 SP1 verifier. It is an already known contract, regenerated from sources.

- Status: DELETED
contract AggregateVerifier (eth:0x1bd8db5139Ba7aC9277684650c15e6E341761919) [opstack/AggregateVerifier]
+++ description: Game type implementation that combines a TEE attestation arm and a ZK proof arm. A single un-nullified proof of either type can resolve a game (PROOF_THRESHOLD = 1). When both arms commit, the finalization window collapses from SLOW_FINALIZATION_DELAY (5d) to FAST_FINALIZATION_DELAY (1d).
contract DisputeGameFactory (eth:0x43edB88C4B80fDD2AdFF2412A7BebF9dF42cB40e) [opstack/DisputeGameFactory_v2] {
+++ description: The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them. This variant exposes per-type reads only; the legacy array views (gameImpls[], initBonds[]) were removed in the new implementation.
+++ severity: HIGH
values.game621:
- "eth:0x1bd8db5139Ba7aC9277684650c15e6E341761919"
+ "eth:0xeE303bA054c5F1E14A8EF87f1C7E285af45A1ba2"
}
- Status: DELETED
contract SP1Verifier (eth:0xb69f2584CBcFf99a58C4e7002E8b89Af54a6f4e2) [succinct/SP1Verifier]
+++ description: Verifier contract for SP1 proofs (v6.1.0).
contract SP1VerifierGateway (eth:0xdc32E228636273285Befa5F001dBB5142517C106) [succinct/SP1VerifierGateway] {
+++ description: This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifier contracts, routing each identifier to the corresponding verifier contract.
values.activeVerifiers.0.verifier:
- "eth:0xb69f2584CBcFf99a58C4e7002E8b89Af54a6f4e2"
+ "eth:0xc3c6dDDAc8829b233Dc6536Ec024775a57b0AF2A"
values.activeVerifiers.0.selector:
- "0x4388a21c"
+ "0x5a093a2f"
+++ description: All verifiers that were ever routed to by this gateway.
values.allVerifiers.1:
+ {"selector":"0x5a093a2f","verifier":"eth:0xc3c6dDDAc8829b233Dc6536Ec024775a57b0AF2A"}
}
+ Status: CREATED
contract SP1Verifier (eth:0xc3c6dDDAc8829b233Dc6536Ec024775a57b0AF2A) [shared-sp1/SP1Verifier]
+++ description: None
+ Status: CREATED
contract AggregateVerifier (eth:0xeE303bA054c5F1E14A8EF87f1C7E285af45A1ba2) [opstack/AggregateVerifier]
+++ description: Game type implementation that combines a TEE attestation arm and a ZK proof arm. A single un-nullified proof of either type can resolve a game (PROOF_THRESHOLD = 1). When both arms commit, the finalization window collapses from SLOW_FINALIZATION_DELAY (5d) to FAST_FINALIZATION_DELAY (1d).
2026 July 21, 15:38 UTC
2changes

TEEProverRegistry: both registered enclave signers rotated.

contract TEEProverRegistry (eth:0x1af2A7E537DE2eE795DE5B8BfbB1Ad0DD513A5aA) [base/TEEProverRegistry] {
+++ description: Registry of authorized TEE enclave signers and proposer addresses used by the TEEVerifier. Owner can add or remove allowlisted proposers via setProposer (onlyOwner) and set the AggregateVerifier game type lookup. Owner and Manager can register or deregister enclave signers via registerSigner / deregisterSigner. Registration requires a Risc0 ZK proof of a valid AWS Nitro attestation document verified by the NITRO_VERIFIER.
+++ severity: LOW
values.getRegisteredSigners.0:
- "eth:0x3354226FDDD041367AE68F7245Cd5166e11013f3"
+ "eth:0x9a73d6848BBe8562CBb6BF1c92B33610B80a98cC"
+++ severity: LOW
values.getRegisteredSigners.1:
- "eth:0xE32f95a9c06159c3cB3DC39f7573215ddAB86E59"
+ "eth:0xd7D60ED09A8069DedA10d721bDF2F04F0F80F69d"
}

Users can force any transaction

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.

  1. Sequencing Window - OP Mainnet Specs
  2. OptimismPortal2.sol - source code, depositTransaction function

Transactions are ordered by a centralized sequencer

Base uses a single centralized sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. for fast confirmations. Users can bypass it with one Ethereum transaction to the OptimismPortal. Base nodes derive the deposited transaction from Ethereum, including it after at most one sequencing window.

Centralized sequencing spec sheet
Trusted preconfirmation
2 s L2 block time
Trusted ordering
Fee order per Flashblock
Sequencer
5-instance Raft HA
Real-time censorship resistance
Forced inclusion
1 L1 tx: portal deposit
Inclusion delay
3,600 L1 blocks
Inclusion mechanics
Address alias
Exit delay
12h inclusion + 20m + 5d state
Exit economics
ZK proof required

Censorship resistance

The centralized sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. provides no real-time censorship resistance. The Ethereum deposit path provides eventual censorship resistance, assuming the deposit is included on Ethereum.

  1. Base documentation - Flashblocks
  2. Base engineering - Sequencer architecture
  3. Base source code - Mainnet chain configuration
  4. Base Beryl - Reduced withdrawal delay
  5. OptimismPortal2 - source code
  6. AggregateVerifier - source code

Forced messaging

If the user experiences censorship from the operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. with regular L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.->L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. 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.

  1. Forced withdrawal from an OP Stack blockchain

EVM compatible smart contracts are supported

OP stack chains are pursuing the EVM EquivalenceA perfect degree of compatibility; where one system or concept is indistinguishable from another in the domain being compared. In the context of rollups, it generally refers to the proximity to the EVM and to Ethereum architecture. model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. can be deployed on L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups..

  1. Introducing EVM Equivalence
A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner

Ethereum

Actors:

Base Governance Multisig0x7bB4…595c

A Multisig with 2/2 threshold.

  • Can upgrade with no delay
    • OptimismMintableERC20Factory
    • TEEProverRegistry
    • DelayedWETH
    • L1StandardBridge
    • DisputeGameFactory
    • OptimismPortal2
    • L1ERC721Bridge
    • DelayedWETH
    • SystemConfig
    • ProtocolVersions
    • L1CrossDomainMessenger
    • AnchorStateRegistry
    • SuperchainConfig
    • DelayedWETH
  • Can interact with DisputeGameFactory
    • set the dispute game implementation and initial bond for any game type
  • Can interact with ProtocolVersions
    • register upgrades, set their activation timestamps and the minimum protocol version, and appoint the incident responder
  • Can interact with AddressManager
    • set and change address mappings
  • Can interact with SuperchainConfig
    • Allowed to pause withdrawals. In op stack systems with a proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system., the Guardian can also blacklist dispute games and set the respected game type (permissioned / permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants.)
  • Can interact with SP1VerifierGateway
    • affect the livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. and safety of the gateway - can transfer ownership, add and freeze verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. routes
Base Multisig 10x1453…E056

A Multisig with 3/12 threshold.

  • Can interact with SystemConfig
    • it can update the preconfer address, the batch submitter (SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs.) address and the gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. configuration of the system
  • Can interact with ProtocolVersions
    • delay the activation of a scheduled upgrade
  • Can interact with SuperchainConfig
    • can pause for up to 3mo 1d, but cannot unpause or extend pauses
Base Coordinator Multisig0x9855…46A1

A Multisig with 3/6 threshold. Member of Base Governance Multisig.

  • Can interact with TEEProverRegistry
    • add or remove allowlisted proposers, set the game type, and register or deregister TEE enclave signers
  • Can interact with CertManager
    • revoke the root certificate, unrevoke certificates and set the revoker
  • Can interact with SystemConfig
    • Allowed to commit transactions from the current layer to the host chain
  • Can interact with TEEProverRegistry
    • register and deregister TEE enclave signers and transfer the manager role
  • Can interact with CertManager
    • revoke non-root certificates

Base Chain

Actors:

Base Governance Multisig - L2 Alias0x8cC5…6a6d
  • Can upgrade with no delay
    • L2CrossDomainMessenger
    • L2StandardBridge
    • SequencerFeeVault
    • OptimismMintableERC20Factory
    • L1BlockNumber
    • L2ERC721Bridge
    • L1Block
    • L2ToL1MessagePasser
    • OptimismMintableERC721Factory
    • ProxyAdmin
    • BaseFeeVault
    • L1FeeVault
    • SchemaRegistry
    • EAS
  • Can upgrade with no delay
    • FeeDisburser
A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner
A diagram of the smart contract architecture
A diagram of the smart contract architecture

Ethereum

The dispute game factory allows the creation of dispute games, used to propose state rootsA cryptographic hash succinctly representing a state using a Merkle tree. and eventually challenge them. This variant exposes per-type reads only; the legacy array views (gameImpls[], initBonds[]) were removed in the new implementation.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
    • owner: Base Governance Multisig

The OptimismPortal contract is the main entry point to deposit funds from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. to L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the AggregateVerifier.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
The following tokens are included in the value secured calculation:
ETH token logo

Contains configuration parameters such as the SequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. address, gas limitThe maximum amount of gas a transaction or block may consume. on this chain and the unsafe blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. signer address.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
    • batcherHash: EOA 1
    • owner: Base Multisig 1

Base’s own SuperchainConfig, used to manage pause states for the Base chain. The guardian and incident responder roles are immutable and set at construction time. Each pause automatically expires after 3mo 1d.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
    • guardian: Base Governance Multisig
    • incident_responder: Base Multisig 1

The main entry point to deposit ERC20 tokens from host chain to this chain.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig

All supported tokens in this escrow are included in the value secured calculation.

Implementation used in:

Used to bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. ERC-721 tokens from host chain to this chain.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
Implementation used in:

Sends messages from host chain to this chain, and relays messages back onto host chain. In the event that a message sent from host chain to this chain is rejected for exceeding this chain’s epoch gas limitThe maximum amount of gas a transaction or block may consume., it can be resubmitted via this contract’s replay function.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
Implementation used in:
HistoryStorage0x0000…2935

EIP-2935 system contract storing the last 8191 L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. blockhashes. BytecodeGenerally, an instruction set designed for efficient execution by a software interpreter or a virtual machine. Unlike human-readable source code, bytecode is expressed numerically. Within the context of rollups, often related to the concept of compatibility: whether the bytecode of programs on the rollup are capable of being run as-is on Ethereum as well, and vice versa. is canonical to the EIP, deployed at the same address across networks.

  1. Source Code
ProxyAdmin0x0475…059E
  • Roles:
    • owner: Base Governance Multisig

A helper contract that generates OptimismMintableERC20 contracts on the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. it’s deployed to. OptimismMintableERC20 is a standard extension of the base ERC20 token contract designed to allow the L1StandardBridge contracts to mint and burn tokens. This makes it possible to use an OptimismMintableERC20 as this chain’s representation of a token on the host chain, or vice-versa.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
Implementation used in:

Registry of authorized TEE enclave signers and proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. addresses. Signer registration requires a valid AWS Nitro attestation document.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
    • manager: EOA 3
    • owner: Base Coordinator Multisig
PreimageOracle0x1fb8…aDD3

The PreimageOracle contract is used to load the required data from L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. for a dispute game.

Implementation used in:
TEEVerifier0x1FbA…2228

Stateless verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. of TEE proofs. Recovers an ECDSA signature over the journal and checks that the signer is registered in the TEEProverRegistry with the expected enclave image hashA fixed-length fingerprint of variable-size input, produced by a hash function.. Can be permanently nullified.

Contract designed to hold the bonded ETH for each game. It is designed as a wrapper around WETH to allow an owner to function as a backstop if a game would incorrectly distribute funds.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
Implementation used in:
NitroValidator0x47C1…C460

Onchain validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier of AWS Nitro Enclave attestation documents.

PermissionedDisputeGame0x58bf…266A

Same as FaultDisputeGame, but only two permissioned addresses are designated as proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. and challenger.

Implementation used in:

The MIPS contract is used to execute the final step of the dispute game which objectively determines the winner of the dispute.

Implementation used in:

Contract designed to hold the bonded ETH for each game. It is designed as a wrapper around WETH to allow an owner to function as a backstop if a game would incorrectly distribute funds.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
Implementation used in:
FaultDisputeGame0x6dDB…7499

Logic of the dispute game. When a state rootA cryptographic hash succinctly representing a state using a Merkle tree. is proposed, a dispute game contract is deployed. Challengers can use such contracts to challenge the proposed state root.

CertManager0x7227…ba17

Verifies and caches AWS Nitro certificate chains against a pinned root certificate.

  • Roles:
    • owner: Base Coordinator Multisig
    • revoker: EOA 3

Registry of L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. upgrade activation timestamps. Dispute games commit to the upgrades active at their ending L2 blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. and proofs must match that commitment.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
    • incidentResponder: Base Multisig 1
    • proxyAdminOwner: Base Governance Multisig

Simple escrow that accepts tokens and allows to configure permissioned addresses that can access the tokens.

Contains the latest confirmed state rootA cryptographic hash succinctly representing a state using a Merkle tree. that can be used as a starting point in a dispute game. This variant stores respectedGameType, retirementTimestamp, and disputeGameFinalityDelaySeconds locally and drops the legacy *FromGame fields, since the AggregateVerifier model does not expose vm()/weth()/absolutePrestate() on its game implementation.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig

Escrow for custom external tokens that use the canonical bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. for messaging but are governed externally.

The following tokens are included in the value secured calculation:
wstETH token logo

Custom bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. for USDS and sUSDS managed by Sky governance.

ZkVerifier0xB88D…9B75

Thin router that forwards SP1 ZK proof verification to the SP1VerifierGateway. Can be permanently nullified.

SP1Verifier0xc3c6…AF2A

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.1.0).

Implementation used in:

Contract designed to hold the bonded ETH for each game. It is designed as a wrapper around WETH to allow an owner to function as a backstop if a game would incorrectly distribute funds.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig
SP1VerifierGateway0xdc32…C106

This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts, routing each identifier to the corresponding verifier contract.

  • Roles:
    • owner: Base Governance Multisig
P384Verifier0xe0aa…D86c

Stateless verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. of P-384 ECDSA signatures.

AggregateVerifier0xeF9e…B94f

Game type implementation that combines a TEE attestation arm and a ZK proof arm. A single un-nullified proof of either type can resolve a game (PROOF_THRESHOLD = 1). When both arms commit, the finalization window collapses from SLOW_FINALIZATION_DELAY (5d) to FAST_FINALIZATION_DELAY (1d).

Base Chain

Contract used to disburse funds from system FeeVault contracts, shares revenue with Optimism and bridges the rest of funds to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..

  • Roles:
    • admin: EOA 2
Can be upgraded by:

The L2CrossDomainMessenger (L2xDM) contract sends messages from L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., and relays messages from L1 onto L2 with a system tx. In the event that a message sent from L2 to L1 is rejected for exceeding the L1 gas limitThe maximum amount of gas a transaction or block may consume., it can be resubmitted via this contract’s replay function.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2 Alias

The L2StandardBridge contract is the main entry point to deposit or withdraw ERC20 tokens from L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. This contract can store any token.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2 Alias

Collects the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. fees, which are withdrawable to the FeesCollector on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias

Factory contract to create bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. compliant ERC20 IOU token representations of bridged L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. ERC20 tokens.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias

Simple contract that returns the latest L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. number.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias

The L2ERC721Bridge contract is the main entry point to deposit or withdraw ERC721 tokens from L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.. This contract can store any token.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2 Alias

Simple contract that returns information about the latest L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over., which is derived permissionlessly from the L1 chain.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias

Contract used internally by the L2CrossDomainMessenger to send messages to L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., including withdrawals. It can also be used directly as a low-level interface.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias

Factory contract to create bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. compliant ERC721 IOU token representations of bridged L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. ERC721 tokens.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias
  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias
    • owner: Base Governance Multisig - L2 Alias

Collects EIP-1559 base fees, which are withdrawable to the FeesCollector on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias

Collects the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. portion of the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. transaction fees, which are withdrawable to the FeesCollector on L1.

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2 Alias

Contracts to register schemas for the Ethereum Attestation Service (EAS).

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias

Contract containing the main logic for the Ethereum Attestation Service (EAS).

  • Roles:
    • admin: ProxyAdmin; ultimately Base Governance Multisig - L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. Alias

The current deployment carries some associated risks:

  • Funds can be stolen if a contract receives a malicious code upgrade. Upgrades must be approved by 2 parties: the Base Coordinator Multisig and the Base Security Council. There is no delay on upgrades.

Program Hashes

Name
Hash
Repository
Verification
Used in
0x00f5...568a
Base Chain logo
0x25e0...7c21
Base Chain logo
0x45c5...b0e0
Base Chain logo