Search

Search for projects by name or address

Taiko Alethia logo
Taiko Alethia

Badges

About

Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko combines a preconfirmation-based sequencing mechanism with a multi-proof system using SP1, RISC0 and TEEs.



Badges

About

Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko combines a preconfirmation-based sequencing mechanism with a multi-proof system using SP1, RISC0 and TEEs.


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

ETH & derivatives
Stablecoins
BTC & derivatives
Other
Compare with other projects
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 to; previously it posted 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
99% 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 Tx data submissions were performed for 23m 36s (from 2026 Sep 24, 08:12 UTC until 2026 Sep 24, 08:35 UTC). These typically occur every 54s on average.

No Tx data submissions were performed for 9m 48s (from 2026 Sep 24, 08:02 UTC until 2026 Sep 24, 08:11 UTC). These typically occur every 54s on average.

No Tx data submissions were performed for 7d 23h (from 2026 Jun 22, 02:10 UTC until 2026 Jun 30, 01:17 UTC). These typically occur every 54s on average.

No State updates were performed for 7d 12h (from 2026 Jun 22, 02:10 UTC until 2026 Jun 29, 14:49 UTC). These typically occur every 1m 36s on average.

Unzen upgrade: validity rollup

2026 Aug 3rd

Every proven proposal range now requires at least one SP1 or RISC0 validity proofThe output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed..

Learn more

Proof system exploit

2026 Jun 22nd

An attacker exploits a vulnerability in the SGX 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. and steals USD ~1.7M.

Learn more
Sequencer failureState validationData availabilityExit windowProposer failure
Sequencer failure
Enqueue via L1

Users can submit transactions to an 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. queue, but can’t force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone. An inclusion becomes due after 9m 36s. From then on, a whitelisted 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. cannot publish another proposal without processing up to ten due inclusions.

State validation
Validity proofs

Every proposal range is verified by exactly two proofs chosen from SGX (Geth), SGX (Reth), SP1 and RISC0, with at least one SP1 or RISC0 proof required. Proof submission is gated by ProverWhitelist, which has 2 whitelisted provers. This can affect 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. but does not allow finalizing invalid state.

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.

Proposer failure
Cannot withdraw

Only the whitelisted proposers can publish state rootsA cryptographic hash succinctly representing a state using a Merkle tree. 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., so in the event of failure the withdrawals are frozen. Proposing is gated by PreconfWhitelist, which selects a single active 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. for the current epoch and has 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. fallback.

Taiko Alethia
Taiko Alethia is a
Stage 0
ZK Rollup.

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 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.. This ensures that it will be available for enough time.

Learn more about the DA layer here: Ethereum logoEthereum
Validity proofs

Taiko uses a multi-proof systemA rollup settlement concept that relies on a combination of multiple different proving systems. For example, a combination of fraud proof and validity proof. The goal is to reduce reliance on a single system-type or implementation. A more complex example of a multi-proof system: if anyone submits two conflicting state roots to a prover and both roots pass, that prover is turned off. to validate state transitions. Exactly two proofs are required from four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. At least one proof must come from SP1 or RISC0: accepted combinations are either SGX verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. plus either ZK verifier, or SP1 plus RISC0. An SGX-only pair is not accepted. New proposals target a proof submission cadence of 4h. Proving is currently centralized behind ProverWhitelist with 2 whitelisted provers. While the whitelist is non-empty, non-whitelisted actors cannot submit proofs, and the configured 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. proving delay is not used to open proving. MainnetInbox currently sets minBond=0 and livenessBond=0.

  1. MainnetInbox.sol - Etherscan source code, getConfig function
  2. MainnetInbox.sol - Etherscan source code, prove function
  3. ProverWhitelist.sol - Etherscan source code
  4. ZkRequiredVerifier.sol - Etherscan source code

Trusted Setups

Onchain verifier

Used in

Base Chain logoMantle logoCelo logoMorph logoX Layer logo

Projects used in

Search for projects used in

Onchain verifier

Used in

Base Chain logoMantle logoCelo logoMorph logoX Layer logo

Projects used in

Search for projects used in

PROVER

Trusted Setups

Used in

Base Chain logoRonin logoMegaETH logoBOB logoTaiko Alethia logo

Projects used in

Search for projects used in

Used in

Base Chain logoRonin logoMegaETH logoBOB logoTaiko Alethia logo

Projects used in

Search for projects used in

Program Hashes

Name
Hash
Repository
Verification
Used in
0x0025...e7c7
Taiko Alethia logo
0x12a1...e7c7
Taiko Alethia logo
0x0051...3be6
Taiko Alethia logo
0x28d6...3be6
Taiko Alethia logo
0xd6ab...6e10
Taiko Alethia logo
0xdd9b...c1b7
Taiko Alethia logo
A diagram of the upgrades and governance
A diagram of the upgrades and governance

Taiko Alethia has a governance structure relying primarily on a 4/5 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., checked by a token DAO that is limited to veto permissions. The closed 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. whitelists are managed by the 4/6 Taiko Multisig and related EOAs. Governance proposals (both paths) hold all important upgrade and config permissions in the system.

Standard proposals

A threshold of 3 approving Security Council members is required to forward a Standard proposal to the OptimisticTokenVotingPlugin contract. It can be vetoed by 10% of votable TAIKO tokens during a 10d public veto period. If not vetoed, a further 7d timelock applies before the proposal can be executed.

Emergency proposals

Emergency proposals are encrypted at proposal time and can only be read by Security Council members. If approved by 4 Security Council members, they can be immediately decrypted and executed.

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. and operators

The proof system currently does not require zk proofs to validate state transitions and state can be finalized with SGX proofs only. The optional zk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts can be upgraded by Multisigs. Operator roles (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., 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.) are closed and the whitelist is managed by the Taiko Multisig and related EOAs.

Governance profile

Security Council

Composition

3/5 standard · 4/5 emergency — 5-member signer set shared by custom Aragon OSx standard and emergency multisig plugins. Members were appointed by the Taiko team rather than elected and include the Taiko Labs multisig and a Taiko co-founder. Members can appoint EOA agents to act for them.

Members public

Mapped — Taiko publishes a member wallet-to-entity mapping. The 5 current onchain members are Sebastian Kugler, Aragon, Taiko Labs, Gustavo Gonzalez, Daniel Wang. Gustavo Gonzalez and Daniel Wang sign as plain EOAs rather than multisigs. Each member wallet is mapped to its voting agent onchain.

Charter

No public charter — the DAO values define the council’s security mission and principles, while the proposal guidelines restrict emergency proposals to protocol-security and integrity matters. Council selection, terms, conflicts, and accountability are not defined in a public charter.

Can bypass DAO?

Yes, for emergencies — 4 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. approvals execute an encrypted proposal immediately, with no TAIKO-holder veto or delay. Standard proposals require 3 approvals and remain vetoable. The council controls most core upgrades but no longer has permissions over Treasury funds.

DAO can override SC?

No — 10% of eligible TAIKO can 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. a standard proposal but never an emergency one. Token holders cannot create proposals, approve payloads, remove council members, or block emergency proposals; changing the signer list requires another council-approved proposal.

Upgrades

Normal upgrade path

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. member creates a public executable payload → 3 council approvals → 10d token-holder veto period → if less than 10% of eligible TAIKO vetoes, 7d timelock → 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. execution of the approved onchain actions.

Emergency upgrade path

4 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. approvals, instant — proposal metadata and actions stay encrypted while approvals are collected. A council member decrypts the payload, which is integrity-checked against the approved ciphertext and executed without a token-holder veto or timelock; its contents become public upon execution or expiry.

Exit window

17d standard · 0 emergency — the standard path provides 10d of public vetoing followed by a 7d timelock. Emergency proposals bypass both.

Token governance

Governance token

TAIKO on Ethereum — 1,000,000,000 total supply, all minted at initialization; the current implementation has no further mint function. One delegated TAIKO equals one veto vote, snapshotted when the proposal is created. The Foundation treasury, DAO controller, canonical ERC20 vault, and zero address are excluded from eligible supply.

Voting venue

Taiko DAO for onchain vetoes; proposals and temperature checks are discussed on the Taiko forum.

Proposal threshold

No TAIKO threshold — only a 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. member can create an onchain proposal. Community members can submit forum proposals, but a council member must sponsor the idea and supply the executable payload.

Quorum

No approval quorum; 10% veto threshold. Standard proposals pass optimistically unless at least 10% of eligible TAIKO at the proposal snapshot vetoes. Unused and undelegated eligible tokens still count in the denominator.

Execution model

Council-gated optimistic veto + 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. execution. The 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. approves the exact onchain actions. Token holders can only veto; if the threshold is not reached and the 7d timelock expires, anyone can call execute(). Emergency proposals skip the veto and delay.

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
42
Last upgrade
1mo 26d ago
Avg upgrade interval
4mo 1d
2026 September 22, 11:58 UTC
High severity
41changes

Two proposals executed: 1. Security Council reduced from 9 to 5 members, thresholds now 3/5 standard and 4/5 emergency (This removes the 'correctly set-up' qualification for a Security Council - too few participants and threshold too low). 2. Raiko2 proving set updated v0.6.0 - v0.8.0-rc1 (RISC0 image IDs, SP1 vkeys, SGX mrEnclaves, old SGX instances deleted).

contract TaikoRisc0Verifier (eth:0x059dAF31F571da48Ab4e74Ae12F64f907681Cd8b) [taiko/Risc0Verifier] {
+++ description: Gating router contract to verify batches using RISC Zero.
+++ description: Taiko specific Image IDs (i.e. program digest) of Risc0 programs (block proving and aggregation program separately) trusted by this verifier gateway. Only proofs for these programs can be successfully verified. Note that proofs contains image ID data within them.
+++ severity: HIGH
values.trustedImages.0:
- "0x5a818b4c7dc80e9ba85d55492c20c263c67238724e3982f76d15a158e501210b"
+ "0xd6ab71c22201c23ef512b706f2e2d720f6da1b559fb76834aa9d4e35276f6e10"
+++ description: Taiko specific Image IDs (i.e. program digest) of Risc0 programs (block proving and aggregation program separately) trusted by this verifier gateway. Only proofs for these programs can be successfully verified. Note that proofs contains image ID data within them.
+++ severity: HIGH
values.trustedImages.1:
- "0x9cfcc1b34a98853c3c5873a4d456726e528246f7f03a4ea35f27c2543aa6e7f0"
+ "0xdd9b8abff96c409ae2418edfb51d893ea2bd10f4873a0226f17a6998c1afc1b7"
}
- Status: DELETED
contract Safe (eth:0x0F40268Ec0Dc8D88CF2f22E227A29a0b478b6351) [GnosisSafe]
+++ description: None
contract SignerList (Security Council) (eth:0x0F95E6968EC1B28c794CF1aD99609431de5179c2) [taiko/SignerList] {
+++ description: A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here.
values.$members.0:
- "eth:0xCf76A87E24FE2054DCF02a5f65eAc0F24A34c439"
values.$members.1:
- "eth:0x93533a3511E9b0d5c17b1CBD0e1737781DEf61a6"
values.$members.2:
- "eth:0x884c3e8235788ae52C2106E847e30BD84F2FBCb8"
values.$members.3:
- "eth:0x22aD66bcEaeff83e1461772Fa85CbeB01f0915f4"
values.$members.4:
- "eth:0x4236f57E9dBc238878EFac4AeF0A16D4dD06DC1A"
+ "eth:0x736d9e59cDd406aEee09253fF18BA6cb7be67CBD"
values.$members.6:
- "eth:0x18B4f2afe456Dc89bddE9710476dCfC62D01d656"
+ "eth:0x884c3e8235788ae52C2106E847e30BD84F2FBCb8"
values.$members.7:
- "eth:0x1d955983044548E03DAA583B36A37cA4bdE6F556"
+ "eth:0xF74F2bBaEd41e3e4AbAcbA24563a5Ce5aB071C8A"
values.$members.8:
- "eth:0xc4414B079bC4A013916B3dc241555F6f505c1619"
+ "eth:0xe63E61BbB3aa1b82d44471AbcAb490102C17c986"
values.addresslistLength:
- 9
+ 5
values.multisigSigners.0:
- "eth:0x436a1075099A145417EBFc74BBaC9605e3e4f1A7"
values.multisigSigners.3:
- "eth:0x0F40268Ec0Dc8D88CF2f22E227A29a0b478b6351"
values.multisigSigners.4:
- "eth:0x5353c607e6eca6C63FEC5c6C0F5CC3a5348d5c95"
values.multisigSigners.5:
- "eth:0x25d3E89bAcE2040Ed3aF7c4c7B505cfBB72fD6f1"
values.multisigSigners.6:
- "eth:0xa384E224A3F3D664F43eBE33395eF0DCcE67e894"
values.multisigSigners.3:
+ "eth:0xe63E61BbB3aa1b82d44471AbcAb490102C17c986"
values.multisigSigners.8:
- "eth:0x6268d189E011Aa53A2f09A1FE159445BeB3d878E"
+ "eth:0xF74F2bBaEd41e3e4AbAcbA24563a5Ce5aB071C8A"
values.settings.minSignerListLength:
- 8
+ 4
}
contract AutomataDcapV3Attestation (eth:0x0ffa4A625ED9DB32B70F99180FD00759fc3e9261) [taiko/AutomataDcapV3Attestation] {
+++ description: Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
+++ description: Trusted SGX enclave measurements accepted by attestation verification.
+++ severity: HIGH
values.mrEnclaves.0:
- "0x2d2216efbe9d8e80ba24b86606ccd5ce9faf11033d31ad9e5d3c5c89965c8a57"
+ "0x5f7da556f3b75dcc71465030e1b7274e82df9e9120c0b3eaf5bb76246a514005"
}
- Status: DELETED
contract Safe (eth:0x25d3E89bAcE2040Ed3aF7c4c7B505cfBB72fD6f1) [GnosisSafe]
+++ description: None
contract EmergencyMultisig (eth:0x2AffADEb2ef5e1F2a7F58964ee191F1e88317ECd) [taiko/EmergencyMultisig] {
+++ description: Modular Governance contract allowing for proposing, voting on and executing encrypted proposals (e.g. for Security Council emergency proposals).
values.lastMultisigSettingsChange:
- 24269141
+ 25997731
+++ severity: HIGH
values.minApprovals:
- 7
+ 4
values.multisigSettings.minApprovals:
- 7
+ 4
}
- Status: DELETED
contract Safe (eth:0x436a1075099A145417EBFc74BBaC9605e3e4f1A7) [GnosisSafe]
+++ description: None
- Status: DELETED
contract Safe (eth:0x5353c607e6eca6C63FEC5c6C0F5CC3a5348d5c95) [GnosisSafe]
+++ description: None
- Status: DELETED
contract Safe (eth:0x6268d189E011Aa53A2f09A1FE159445BeB3d878E) [GnosisSafe]
+++ description: None
contract TaikoSP1Verifier (eth:0x73A0Db393ef87ce781ac7957bE10D6628432100F) [taiko/SP1Verifier] {
+++ description: Gating router contract to verify batches using SP1.
+++ description: Taiko-specific SP1 program verification keys trusted by this verifier gateway. Only proofs for these programs can be successfully verified.
+++ severity: HIGH
values.trustedPrograms.0:
- "0x00ad090221a8fa0f09e1be7a53feb67be010f01310d4b2314a69d10152ee1ce0"
+ "0x0025425c22e827507428a3d9c7b0f89635be5462f34bb6780563e3d6086be7c7"
+++ description: Taiko-specific SP1 program verification keys trusted by this verifier gateway. Only proofs for these programs can be successfully verified.
+++ severity: HIGH
values.trustedPrograms.1:
- "0x568481106a3e83c23c37cf4a3feb67be008780984352c8c514d3a20252ee1ce0"
+ "0x12a12e113a09d41d05147b387b0f89632df2a3174d2ed9e00ac7c7ac086be7c7"
+++ description: Taiko-specific SP1 program verification keys trusted by this verifier gateway. Only proofs for these programs can be successfully verified.
+++ severity: HIGH
values.trustedPrograms.2:
- "0x000b11691352e55fcf64f62620cefaa700161600093f2751032fe71ea912264d"
+ "0x0051ac1d9e8cfd4196e37f9cfefd08e9b0f7ce653bad4634cd1ee84b71ca3be6"
+++ description: Taiko-specific SP1 program verification keys trusted by this verifier gateway. Only proofs for these programs can be successfully verified.
+++ severity: HIGH
values.trustedPrograms.3:
- "0x0588b48954b957f36c9ec4c40cefaa7000b0b00024fc9d44065fce3d2912264d"
+ "0x28d60ecf233f50655c6ff39f6fd08e9b07be73296eb518d31a3dd09671ca3be6"
}
contract AutomataDcapV3Attestation (eth:0x8d7C954960a36a7596d7eA4945dDf891967ca8A3) [taiko/AutomataDcapV3Attestation] {
+++ description: Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
+++ description: Trusted SGX enclave measurements accepted by attestation verification.
+++ severity: HIGH
values.mrEnclaves.0:
- "0x90c79e65d6d0f83d658ff96cd0ef1204438f20b406c93cf1d4fafa0cff29842e"
+ "0x3564b6a30089fcb3e2f69c19b22d23f84ce148387cd7a15f5c1df165b2ae5847"
+++ description: Trusted SGX enclave measurements accepted by attestation verification.
+++ severity: HIGH
values.mrEnclaves.1:
- "0x041cadb0541bf8249c368482172d218608f3693975b65f74beb2ed6f0044f951"
+ "0xae2c7b92b2a71238226cb624ecd1171b66bf943cc372314affca0e6748ccecdf"
}
contract OptimisticTokenVotingPlugin (eth:0x989E348275b659d36f8751ea1c10D146211650BE) [taiko/OptimisticTokenVotingPlugin] {
+++ description: An optimistic governance module. Standard proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d. Emergency proposals can be executed without delay.
values.proposalCount:
- 39
+ 40
values.proposalIds.39:
+ "609097156697645562436844254022738698161067393063"
}
- Status: DELETED
contract Safe (eth:0xa384E224A3F3D664F43eBE33395eF0DCcE67e894) [GnosisSafe]
+++ description: None
contract Multisig (eth:0xD7dA1C25E915438720692bC55eb3a7170cA90321) [taiko/Multisig] {
+++ description: Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security Council standard proposals).
values.lastMultisigSettingsChange:
- 24588180
+ 25997731
+++ severity: HIGH
values.minApprovals:
- 5
+ 3
values.multisigSettings.minApprovals:
- 5
+ 3
+++ description: total standard proposal count.
values.proposalCount:
- 24
+ 25
}
2026 September 15, 11:26 UTC
6changes

critical contracts and severities for the ossification perimeter

New and verified contracts

+ Status: CREATED
contract Bridge (taiko:0x1670000000000000000000000000000000000001) [taiko/L2Bridge]
+++ description: Bridge escrow holding preminted ETH on Taiko.
+ Status: CREATED
contract ERC20Vault (taiko:0x1670000000000000000000000000000000000002) [taiko/L2ERC20Vault]
+++ description: Escrow for L2-native tokens sent to L1 via the canonical bridge.
+ Status: CREATED
contract SignalService (taiko:0x1670000000000000000000000000000000000005) [taiko/SignalService]
+++ description: Facilitates secure cross-chain message passing by storing signals and state-root checkpoints. Bridge escrows and other applications use it to prove that a specific L1<->L2 signal or checkpointed state transition occurred via Merkle proofs. Pausing disables signal proof verification.
+ Status: CREATED
contract L2AddressManager (taiko:0x1670000000000000000000000000000000000006) [taiko/L2AddressManager]
+++ description: Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.
+ Status: CREATED
contract Anchor (taiko:0x1670000000000000000000000000000000010001) [taiko/Anchor]
+++ description: Stores L1 block details on L2 as a cross-layer oracle and manages EIP-1559 gas pricing for L2 operations.
+ Status: CREATED
contract DelegateController (taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C) [taiko/DelegateController]
+++ description: Middleware contract that can maintain ownership of DAO-controlled assets and contracts. It can only be invoked by the TaikoDAOController on L1 through the L2 bridge.
2026 September 15, 11:26 UTC
1change

Operator changes.

contract PreconfWhitelist (eth:0xFD019460881e6EeC632258222393d5821029b2ac) [taiko/PreconfWhitelist] {
+++ description: Contains the whitelist of addresses eligible to propose batches on L1 and issue preconfirmations. It dynamically selects a single active operator for each epoch using a delayed Ethereum beacon block root as randomness. There is no fallback proposer path in this contract: non-selected operators cannot propose for the current epoch.
values.operatorMapping.1:
- "eth:0x35376dD47C061Bc3b8c8e8d61987019e7ED58f06"
}
2026 September 01, 12:13 UTC
4changes

SC proposal moving to veto phase.

contract SignerList (Security Council) (eth:0x0F95E6968EC1B28c794CF1aD99609431de5179c2) [taiko/SignerList] {
+++ description: A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here.
values.$members.0:
- "eth:0xAC5898b0FFFd23F4Ef09F0E50Fa1bC4896eF7163"
+ "eth:0xCf76A87E24FE2054DCF02a5f65eAc0F24A34c439"
}
contract OptimisticTokenVotingPlugin (eth:0x989E348275b659d36f8751ea1c10D146211650BE) [taiko/OptimisticTokenVotingPlugin] {
+++ description: An optimistic governance module. Standard proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d. Emergency proposals can be executed without delay.
values.proposalCount:
- 38
+ 39
values.proposalIds.38:
+ "608479335948875503511285097395089134668700712998"
}
contract Taiko Multisig (eth:0x9CBeE534B5D8a6280e01a14844Ee8aF350399C7F) [GnosisSafe] {
+++ description: None
values.$members.0:
- "eth:0xAC5898b0FFFd23F4Ef09F0E50Fa1bC4896eF7163"
+ "eth:0xFa92ff698D57f7B875570D9F59501812B843CD44"
}
2026 August 27, 12:06 UTC
High severity
3changes

Add proposal that reduces the Security Council to a 4/5 multisig. The resulting Council is not a valid Security Council after the L2BEAT criteria: https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52, https://forum.l2beat.com/t/stage-1-requirements-update-security-council-walkaway-test/412 . full review of the proposal: https://gist.github.com/sekuba/b19aa30b123d7247280e96f5a49e5c15 .

contract OptimisticTokenVotingPlugin (eth:0x989E348275b659d36f8751ea1c10D146211650BE) [taiko/OptimisticTokenVotingPlugin] {
+++ description: An optimistic governance module. Standard proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d. Emergency proposals can be executed without delay.
values.proposalCount:
- 37
+ 38
values.proposalIds.37:
+ "608325339122031231284005618251537221674155900965"
}
contract Multisig (eth:0xD7dA1C25E915438720692bC55eb3a7170cA90321) [taiko/Multisig] {
+++ description: Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security Council standard proposals).
+++ description: total standard proposal count.
+++ severity: HIGH
values.proposalCount:
- 23
+ 24
}

The system uses whitelist-based sequencing and proving

The system uses a whitelist-based sequencingA sequencing strategy for L2s based on Ethereum's own block building pipeline, which gets reused to also build L2 blocks. This strategy is in contrast to centralized sequencing or decentralized sequencing mechanisms that use networks external to Ethereum. mechanism to allow for fast preconfirmations on 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.. On 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., batch proposing is permissioned through the PreconfWhitelist contract, which currently has 1 active operators registered. For each epoch, PreconfWhitelist selects a single active 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. that can propose to MainnetInbox. There is no fallback 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. path, and non-selected operators cannot propose for the current epoch. Proving is controlled separately by ProverWhitelist, which currently has 2 whitelisted provers. While the 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. whitelist is non-empty, non-whitelisted actors cannot submit proofs. MainnetInbox currently sets minBond=0 and livenessBond=0. Proving a proposal range requires exactly two proofs and at least one of them must be a ZK proof. Accepted combinations are SGX (Geth or Reth) plus SP1 or RISC0, or SP1 plus RISC0.

  • MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

  1. MainnetInbox.sol - Etherscan source code, propose function
  2. MainnetInbox.sol - Etherscan source code, prove function
  3. PreconfWhitelist.sol - Etherscan source code
  4. ProverWhitelist.sol - Etherscan source code

Users can enqueue transactions

Users can submit a forced inclusion directly to MainnetInbox 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. by publishing a blobThe 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. containing one 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. 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. manifest and calling saveForcedInclusion(). Requests are stored in a FIFO queue and cost a dynamic fee that starts at 0.001 ETH. The fee increases linearly with the queue size and doubles when 50 requests are pending. After 9m 36s, a request is due. Every subsequent proposal must process the due requests at the head of the queue, up to ten per proposal, before the 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 own derivation source. This prevents an active proposer from advancing the chain while selectively skipping a due request. However, propose() still unconditionally checks PreconfWhitelist. The configured 1d 1h 36m 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. inclusion threshold is not used, so users and other unpermissioned actors cannot process the queue themselves. If all whitelisted proposers stop, the queue and the whole chain stop progressing.

  • Users can be censored if the operator is offline or refuses to process the queue.

  1. MainnetInbox.sol - Etherscan source code, saveForcedInclusion function
  2. MainnetInbox.sol - Etherscan source code, propose function

Regular exit

The user initiates the withdrawal by submitting a regular transaction on this chain. When the 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. containing that transaction is finalized the funds become available for withdrawal 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.. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

A dashboard to explore contracts and permissions
Go to Disco
Disco UI Banner

Ethereum

Actors:

SignerList (Security Council)0x0F95…79c2

A Multisig with 4/5 threshold. A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here.

  • Can upgrade with 7d delay
    • AutomataDcapV3Attestation
    • Taiko Token
    • MainnetInbox
    • TaikoDAOController
    • AutomataDcapV3Attestation
    • DefaultResolver
    • MainnetERC20Vault
    • DAO
    • SignalService
    • MainnetBridge
    • ProverWhitelist
    • TaikoDAOController
    • PreconfWhitelist
    • 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.
    • ERC20Vault
    • SignalService
    • L2AddressManager
    • Anchor
    • DelegateController
  • Can interact with TaikoRisc0Verifier
    • manage trusted RISC Zero image IDs with 7d delay
  • Can interact with SignerList (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.)
    • add/remove members from the Security Council and change its minimum size with 7d delay
  • Can interact with AutomataDcapV3Attestation
    • manage trusted SGX measurements, revoked certificate serial numbers, TCB info, QE identity, and local report checks with 7d delay
  • Can interact with EmergencyMultisig
    • manage critical settings (e.g. threshold and multisig settings) for the emergency proposal governance path with 7d delay
  • Can interact with SecureSgxVerifier
    • add SGX instances without DCAP attestation and delete registered instances with 7d delay
  • Can interact with MainnetInbox
    • pause and unpause 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. system, activate the inbox, and execute the one-time state recovery path with 7d delay
  • Can interact with TaikoSP1Verifier
    • manage trusted SP1 program verification keys with 7d delay
  • Can interact with AutomataDcapV3Attestation
    • manage trusted SGX measurements, revoked certificate serial numbers, TCB info, QE identity, and local report checks with 7d delay
  • Can interact with DefaultResolver
    • update the contract address registered for any chainId-name pair with 7d delay
  • Can interact with OptimisticTokenVotingPlugin
    • manage critical settings (e.g. thresholds, delays and proposal acceptance criteria) for all governance proposals with 7d delay
  • Can interact with MainnetERC20Vault
    • pause and unpause token bridge flows and change the bridged token implementation for a canonical token after the migration delay with 7d delay
  • Can interact with DAO
    • define all permissions of the central DAO smart contract with 7d delay
  • Can interact with SecureSgxVerifier
    • add SGX instances without DCAP attestation and delete registered instances with 7d delay
  • Can interact with SignalService
    • pause and unpause signal proof verification with 7d delay
  • Can interact with MainnetBridge
    • pause and unpause bridge message flows and execute one-time bridge recovery initializers with 7d delay
  • Can interact with Multisig
    • manage critical settings (e.g. threshold and multisig settings) for the standard proposal governance path with 7d delay
  • Can interact with ProverWhitelist
    • manage the 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. whitelist with 7d delay
  • Can interact with PreconfWhitelist
    • pause/unpause, add or remove operators, and manage ejecter roles with 7d delay
  • Can interact with SignalService
    • pause and unpause signal proof verification with 7d delay
  • Can interact with L2AddressManager
    • can update the contract address for a given name with 7d delay
Taiko Multisig0x9CBe…9C7F

A Multisig with 4/6 threshold.

  • Can interact with SecureSgxVerifier
    • register SGX instances after DCAP attestation verification
  • Can interact with SecureSgxVerifier
    • register SGX instances after DCAP attestation verification
  • Can interact with SignalService
    • pause and unpause signal proof verification
  • Can interact with QuotaManager
    • update token withdrawal quotas and the quota refill period
  • Can interact with MainnetBridge
    • pause and unpause 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. message flows and fund the bridge through direct ETH transfers
  • Can interact with ProverWhitelist
    • manage the 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. whitelist
  • Can interact with PreconfWhitelist
    • manage the ejecter role
MainnetERC20Vault0x9962…15Ab

Shared vault for Taiko chains for bridged ERC20 tokens. Pausing stops token sends, message-triggered releases, and recalls. Released or minted tokens are subject to the configured quota manager.

  • Can interact with QuotaManager
    • consume ERC20 withdrawal quota when tokens leave the vault
MainnetBridge0xd602…d8EC

Shared 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. escrow for Taiko chains for bridged ETH and arbitrary bridge messages. Pausing stops sending, processing, recalling, retrying, and failing messages. ETH released from the bridge is subject to the configured quota manager.

  • Can interact with QuotaManager
    • consume ETH withdrawal quota when ETH leaves the bridge

A Multisig with 3/5 threshold.

  • Can interact with TimelockController
    • cancel queued transactions
    • execute transactions that are ready
    • manage all access control roles with 3d delay
    • propose transactions
  • Can interact with RiscZeroVerifierEmergencyStop
    • pause the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.
  • Can interact with RiscZeroVerifierEmergencyStop
  • Can interact with RiscZeroVerifierEmergencyStop
  • Can interact with RiscZeroVerifierRouter
    • add/remove verifiers and the selectors they are mapped to with 3d delay
  • Can interact with RiscZeroVerifierEmergencyStop
  • Can interact with RiscZeroVerifierEmergencyStop
Used in:
SP1VerifierGatewayMultisig0xCafE…6878

A Multisig with 2/3 threshold.

  • 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
Used in:
Taiko Foundation Treasury Multisig0x363e…B3Da

A Multisig with 3/5 threshold.

A Multisig with 1/2 threshold. Member of Taiko Foundation Treasury Multisig, Taiko Multisig, Taiko Labs.

Participants (2):

0x4757…45c30x7057…595C
  • Can interact with PreconfWhitelist
    • add operators after a two-epoch activation delay and remove existing operators immediately

Member of Sebastian Kugler.

  • Can interact with SignerList (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.)
    • configure an agent address that represents this entity in the Security Council
  • Can interact with PreconfWhitelist
    • eligible to propose batches 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.; only the selected current-epoch 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. can successfully propose

Member of SignerList (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.).

  • Can interact with RiscZeroVerifierEmergencyStop
    • pause the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.
Used in:
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

TaikoRisc0Verifier0x059d…Cd8b

Gating router contract to verify batches using RISC Zero.

  • Roles:
    • owner: TaikoDAOController; ultimately SignerList (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.)
RiscZeroGroth16Verifier0x20ff…8E97

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 2.0.0-rc.3).

Implementation used in:
RiscZeroGroth16Verifier0x2a09…a84D

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 3.0.0).

Implementation used in:
RiscZeroGroth16Verifier0x54aC…B9bF

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 2.0.3).

Implementation used in:

The core Layer 1Layer 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. entrypoint for the Taiko 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. where 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. 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. batches are proposed and their corresponding state transitions are proven. Users can enqueue forced inclusions by publishing an L1 blobThe 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.. Once an inclusion is due, subsequent proposals must process it, but proposing remains restricted by the configured 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. checker. If the configured 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. whitelist is non-empty, proofs from non-whitelisted provers revert.

  • Roles:
    • admin: TaikoDAOController; ultimately SignerList (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.)
    • owner: TaikoDAOController; ultimately SignerList (Security Council)
ZkRequiredVerifier0x7284…4Eec

Immutable verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. policy contract for Taiko mainnet. Every accepted proof contains exactly two ordered sub-proofs and at least one must be a ZK proof. Accepted pairs are SGX-GETH or SGX-RETH with RISC0-RETH or SP1-RETH, and RISC0-RETH with SP1-RETH. The SGX-GETH plus SGX-RETH pair is not accepted.

TaikoSP1Verifier0x73A0…100F

Gating router contract to verify batches using SP1.

  • Roles:
    • owner: TaikoDAOController; ultimately SignerList (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.)
RiscZeroGroth16Verifier0xafB3…9df9

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 2.2.0).

Implementation used in:

Defines the 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. whitelist queried by the inbox before accepting proofs. If the inbox is configured with this contract and the whitelist is non-empty, only whitelisted provers can prove proposals.

  • Roles:
    • admin: TaikoDAOController; ultimately SignerList (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.)
    • owner: TaikoDAOController; ultimately SignerList (Security Council)
    • proverManager: Taiko Multisig
RiscZeroGroth16Verifier0xf70a…E93C

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs. This older implementation exposes control-root and selector constants but does not expose a VERSION getter.

Implementation used in:
QuotaManager0xBaCb…c6cC

Defines withdrawal quotas for ETH and ERC20 releases from the shared 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.. A token quota of zero means unlimited withdrawals for that token.

  • Roles:
    • bridge: MainnetBridge
    • erc20Vault: MainnetERC20Vault
    • owner: Taiko Multisig

Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.

  • Roles:
    • admin: DAO; ultimately SignerList (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.)
    • owner: DAO

The main contract and entrypoint of the Aragon-based DAO governance framework. Fine-grained DAO permissions, proposals, voting and thresholds are configured here.

  • Roles:
    • currentSignerListPermissions: SignerList (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.) (emergency proposals bypass the delay)
    • daoPermissions: DAO; ultimately SignerList (Security Council)

Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.

  • Roles:
    • admin: DAO; ultimately SignerList (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.)
    • owner: DAO
TimelockController0x0b14…b711

A timelock with access control. The current minimum delay is 3d.

  • Roles:
    • canceller: Safe
    • defaultAdmin: TimelockController; ultimately Safe
    • executor: Safe
    • 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.: Safe
Implementation used in:

Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.

  • Roles:
    • admin: TaikoDAOController; ultimately SignerList (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.)
    • owner: TaikoDAOController; ultimately SignerList (Security Council)

ERC20 contract implementing the TAIKO token. It defines a list of addresses designated as non-voting.

  • Roles:
    • admin: TaikoDAOController; ultimately SignerList (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.)
RiscZeroVerifierEmergencyStop
4 instances
0x1efD…D6980x68dC…40E30x9F99…e6960xDa8f…B2b1

A verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. wrapper for the RiscZeroGroth16Verifier that allows pausing (emergency stop) the verifier by its owner.

  • Roles:
    • owner: Safe
Implementation used in:

Modular Governance contract allowing for proposing, voting on and executing encrypted proposals (e.g. for 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. emergency proposals).

SecureSgxVerifier
2 instances
0x41e7…84Ee0x9D3C…FFd8

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SGX proven 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.. Registered SGX instances can sign accepted proofs until their instance expiry.

  • Roles:
    • owner: TaikoDAOController; ultimately SignerList (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.)
    • registrar: Taiko Multisig
RiscZeroVerifierEmergencyStop0x44c2…33e7

A verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. wrapper for the RiscZeroGroth16Verifier that allows pausing (emergency stop) the verifier by its owner.

  • Roles:
    • owner: EOA 5
Implementation used in:
RiscZeroSetVerifier0x5005…EB85

Set verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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.

Implementation used in:
RiscZeroVerifierEmergencyStop0x844D…F782

A verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. wrapper for the RiscZeroSetVerifier that allows pausing (emergency stop) the verifier by its owner.

  • Roles:
    • owner: Safe
Implementation used in:

Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.

  • Roles:
    • admin: TaikoDAOController; ultimately SignerList (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.)
    • owner: TaikoDAOController; ultimately SignerList (Security Council)
RiscZeroVerifierRouter0x8EaB…D319

A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (TimelockController).

  • Roles:
    • owner: TimelockController; ultimately Safe
Implementation used in:

Maps chainId-name pairs to contract addresses. 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. and vault contracts resolve their counterparties through this registry, so changes in this mapping effectively act as contract upgrades. The pause function is intentionally disabled in this implementation.

  • Roles:
    • admin: TaikoDAOController; ultimately SignerList (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.)
    • owner: TaikoDAOController; ultimately SignerList (Security Council)

An optimistic governance module. Standard proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d. Emergency proposals can be executed without delay.

  • Roles:
    • dao: DAO; ultimately SignerList (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.)

Facilitates secure cross-chain message passing by storing signals and state-root checkpoints. 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. escrows and other applications use it to prove that a specific 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.<->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. signal or checkpointed state transition occurred via Merkle proofsHashing the pairs of values at each level and climbing up the (Merkle) Tree until you obtain the root hash. Merkle proofs help check if the data belongs to a set without having to store the entire set.. Pausing disables signal proof verification.

  • Roles:
    • admin: TaikoDAOController; ultimately SignerList (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.)
    • owner: TaikoDAOController; ultimately SignerList (Security Council)
    • pauser: Taiko Multisig

Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for 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. standard proposals).

Contains the whitelist of addresses eligible to propose batches 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. and issue preconfirmations. It dynamically selects a single active 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. for each epoch using a delayed Ethereum beacon 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. root as randomness. There is no fallback 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. path in this contract: non-selected operators cannot propose for the current epoch.

  • Roles:
    • _ejectorManager: Taiko Multisig
    • admin: TaikoDAOController; ultimately SignerList (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.)
    • ejecters: EOA 1, EOA 3
    • operatorMapping: EOA 4
    • owner: TaikoDAOController; ultimately SignerList (Security Council)
SP1Verifier0x0459…C459

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

Implementation used in:
SP1VerifierGateway0x3B60…185e

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: SP1VerifierGatewayMultisig
Implementation used in:
SP1Verifier0x8a0f…Fc5C

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

Implementation used in:
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:

Taiko Alethia

Stores 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. details 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. as a cross-layer oracle and manages EIP-1559 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. pricing for L2 operations.

  • Roles:
    • admin: DelegateController; ultimately SignerList (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.)

Middleware contract that can maintain ownership of DAO-controlled assets and contracts. It can only be invoked by the TaikoDAOController 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. through 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. 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..

  • Roles:
    • admin: DelegateController; ultimately SignerList (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.)
    • daoController: TaikoDAOController

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. escrow holding preminted ETH on Taiko.

  • Roles:
    • admin: DelegateController; ultimately SignerList (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.)

Escrow for 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.-native tokens sent 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. via 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..

  • Roles:
    • admin: DelegateController; ultimately SignerList (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.)

Facilitates secure cross-chain message passing by storing signals and state-root checkpoints. 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. escrows and other applications use it to prove that a specific 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.<->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. signal or checkpointed state transition occurred via Merkle proofsHashing the pairs of values at each level and climbing up the (Merkle) Tree until you obtain the root hash. Merkle proofs help check if the data belongs to a set without having to store the entire set.. Pausing disables signal proof verification.

  • Roles:
    • admin: DelegateController; ultimately SignerList (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.)
    • owner: DelegateController; ultimately SignerList (Security Council)

Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.

  • Roles:
    • admin: DelegateController; ultimately SignerList (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.)
    • owner: DelegateController; ultimately SignerList (Security Council)

The current deployment carries some associated risks:

  • Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).

Program Hashes

Name
Hash
Repository
Verification
Used in
0x0025...e7c7
Taiko Alethia logo
0x12a1...e7c7
Taiko Alethia logo
0x0051...3be6
Taiko Alethia logo
0x28d6...3be6
Taiko Alethia logo
0xd6ab...6e10
Taiko Alethia logo
0xdd9b...c1b7
Taiko Alethia logo