Search
Search projects, tokens and protocols by name or address
Taiko AlethiaTaiko Alethia
There are impactful changes and part of the information might be outdated.
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.
- Compromising ≥75% of the Security Council should be the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window.
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.
The section shows the operating costs that L2s pay to Ethereum.
This section shows how much data the project publishes to Ethereum over time. It leaves out data posted to other data-availability (DA) layers. The project currently posts data to
Ethereum.
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.
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 10m 24s (from until ). These typically occur every 57s on average.
No Tx data submissions were performed for 10m 24s (from until ). These typically occur every 57s on average.
No Tx data submissions were performed for 7d 23h (from until ). These typically occur every 57s on average.
No State updates were performed for 7d 12h (from until ). These typically occur every 1m 41s on average.
Bridge recalls disabled
12 Oct 2026
Failed 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. messages must be retried successfully, with no source-chain refund path.
Unzen upgrade: validity rollup
3 Aug 2026
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..
Funds can be stolen if
Funds can be frozen if
Users can be censored if
MEV can be extracted if
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.
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.
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..
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
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 Preconf
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.
EthereumTaiko 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. The RISC0 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. also accepts 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 under a verifying key that matches no published RISC Zero trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits.. 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.
- MainnetInbox.sol - Etherscan source code, getConfig function
- MainnetInbox.sol - Etherscan source code, prove function
- ProverWhitelist.sol - Etherscan source code
- ZkRequiredVerifier.sol - Etherscan source code
- RiscZeroGroth16Verifier.sol v3.1.0 - Etherscan source code, verifying key
- Groth16Verifier.sol - RISC Zero published verifying key
Trusted Setups
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 ETHBEAT 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 Optimistic
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
A single EOA controls shared RISC0 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. routes through a 3d timelock. It can also freeze RISC0 verifiers immediately. 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.
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 ETHBEAT 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 ETHBEAT 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 ETHBEAT 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
TAIKOon 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 ETHBEAT 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 ETHBEAT 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.
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.
Discovery updates
Critical state change6changesThe RISC Zero EOA 0xF616…d412 executed the scheduled addVerifier(0xe71e6620, 0x5144…) through the timelock, after the 3d delay. Taiko's RISC0 proofs can now also route through the estop 0x5144… to a second RiscZeroGroth16Verifier v3.1.0 (eth:0x8c915b5071206C6E328BC18529586c513408aB3b). Its code and Groth16 verifying key equal the v3.1.0 verifier of route 0x8b38038c, only the control root differs (0xe6feef13…551d). The control root fixes which zkVM recursion circuits the verifier accepts. The verifying key, control root and BN254 control ID appear in no public RISC Zero release or published trusted setup. This time the contract is verified. https://disco.l2beat.com/diff/eth:0x953814e6dfC46d007557B511Dc4F2954dAaf2c9e/eth:0x8c915b5071206C6E328BC18529586c513408aB3b Config: the RiscZeroVerifierRouter template reads the new selector, the new estop and verifier are critical, and the ZK catalog lists the verifier as not verified.
The RISC Zero EOA 0xF616…d412 executed the scheduled addVerifier(0xe71e6620, 0x5144…) through the timelock, after the 3d delay. Taiko’s RISC0 proofs can now also route through the estop 0x5144… to a second Risc
Config: the Risc
| contract TimelockController (eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711) [global/TimelockController] { | |
| +++ description: A timelock with access control. The current minimum delay is 3d. | |
| values.callsExecuted.22: | |
| + | {"id":"0xf40a937e65e41f9adb997f8f4b5a1b39d83bb01cdb8b9e4f7e63c6bdb80d2d12","index":0,"target":"eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319","value":0,"data":"0xd0a6af30e71e6620000000000000000000000000000000000000000000000000000000000000000000000000000000005144a37e65fd032f628663cb21e16490378a8630"} |
| values.callsScheduled.25: | |
| + | {"id":"0xf40a937e65e41f9adb997f8f4b5a1b39d83bb01cdb8b9e4f7e63c6bdb80d2d12","index":0,"target":"eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319","value":0,"data":"0xd0a6af30e71e6620000000000000000000000000000000000000000000000000000000000000000000000000000000005144a37e65fd032f628663cb21e16490378a8630","predecessor":"0x0000000000000000000000000000000000000000000000000000000000000000","delay":259200} |
| } | |
| 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). | |
| +++ severity: MEDIUM | |
| values.verifier_e71e6620: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0x5144A37e65fd032F628663Cb21E16490378a8630" |
| } | |
| EOA (eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412) { | |
| +++ description: None | |
| receivedPermissions.6: | |
| + | {"permission":"interact","from":"eth:0x5144A37e65fd032F628663Cb21E16490378a8630","description":"pause the verifier.","role":".owner"} |
| } | |
| + | Status: CREATED |
| contract RiscZeroVerifierEmergencyStop (eth:0x5144A37e65fd032F628663Cb21E16490378a8630) [risc0/RiscZeroVerifierEmergencyStop] | |
| +++ description: A verifier wrapper for the eth:0x8c915b5071206C6E328BC18529586c513408aB3b that allows pausing (emergency stop) the verifier by its owner. | |
| + | Status: CREATED |
| contract RiscZeroGroth16Verifier (eth:0x8c915b5071206C6E328BC18529586c513408aB3b) [taiko/RiscZeroGroth16Verifier] | |
| +++ description: Verifier contract for RISC Zero Groth16 proofs (version 3.1.0). | |
2changesThe ejecter 0x45D44033 removed the preconfirmation operator 0x5F62d006 from the PreconfWhitelist and re-added it, twice. The whitelist still holds the same two operators, in swapped order.
The ejecter 0x45D44033 removed the preconfirmation operator 0x5F62d006 from the Preconf
| 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.0: | |
| - | "eth:0x5F62d006C10C009ff50C878Cd6157aC861C99990" |
| values.operatorMapping.1: | |
| + | "eth:0x5F62d006C10C009ff50C878Cd6157aC861C99990" |
| } | |
Critical state change11changesThe RISC Zero EOA 0xF616…d412 executed the scheduled addVerifier(0x8b38038c, 0x9660…) through the timelock. Taiko's RISC0 proofs can now route through the estop 0x9660… to RiscZeroGroth16Verifier v3.1.0. Its code equals v3.0.0. Only the constants differ: the Groth16 verifying key, control root and BN254 control ID. None of them appear in a public RISC Zero release or published trusted setup. The deployer left the contract unverified. L2BEAT verified the reconstructed source on etherscan and sourcify with an exact bytecode match. Current Taiko RISC0 proofs still use selector 0x73c457ba (v3.0.0). https://disco.l2beat.com/diff/eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D/eth:0x953814e6dfC46d007557B511Dc4F2954dAaf2c9e The Safe 0xF28C…, a member of the Taiko Foundation Treasury Multisig, moved to the canonical Safe 1.5.0 singleton. https://disco.l2beat.com/diff/eth:0x41675C099F32341bf84BFc5382aF534df5C7461a/eth:0xFf51A5898e281Db6DfC7855790607438dF2ca44b
The RISC Zero EOA 0xF616…d412 executed the scheduled addVerifier(0x8b38038c, 0x9660…) through the timelock. Taiko’s RISC0 proofs can now route through the estop 0x9660… to Risc
The Safe 0xF28C…, a member of the Taiko Foundation Treasury Multisig, moved to the canonical Safe 1.5.0 singleton. https://disco.l2beat.com/diff/eth:0x41675C099F32341bf84BFc5382aF534df5C7461a/eth:0xFf51A5898e281Db6DfC7855790607438dF2ca44b
| contract TimelockController (eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711) [global/TimelockController] { | |
| +++ description: A timelock with access control. The current minimum delay is 3d. | |
| values.callsExecuted.21: | |
| + | {"id":"0x682e79774f6b8e0fc1dbddd69bfca4374e9827b815d8fb2a73d602d541714c82","index":0,"target":"eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319","value":0,"data":"0xd0a6af308b38038c000000000000000000000000000000000000000000000000000000000000000000000000000000009660bd6dcdf455dcfb30c07c642ab22e7cb89f50"} |
| } | |
| 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). | |
| +++ severity: MEDIUM | |
| values.verifier_8b38038c: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0x9660bD6dCDf455DCFb30c07c642Ab22E7Cb89F50" |
| } | |
| contract Safe (eth:0xF28C8D6b44361255FA7C116d09ccD5F914398C10) [GnosisSafe] { | |
| +++ description: None | |
| sourceHashes.1: | |
| - | "0xe23c519b7324d6dc9132c8567ac55ae72bdf168c914d22825c7614d822364b0f" |
| + | "0xb66849da6643e8cd188f73efe4edb32704a1540eda5b1aef77a2217ad2d81f78" |
| values.$implementation: | |
| - | "eth:0x41675C099F32341bf84BFc5382aF534df5C7461a" |
| + | "eth:0xFf51A5898e281Db6DfC7855790607438dF2ca44b" |
| values.getChainId: | |
| - | 1 |
| values.VERSION: | |
| - | "1.4.1" |
| + | "1.5.0" |
| implementationNames.eth:0x41675C099F32341bf84BFc5382aF534df5C7461a: | |
| - | "Safe" |
| implementationNames.eth:0xFf51A5898e281Db6DfC7855790607438dF2ca44b: | |
| + | "Safe" |
| } | |
| EOA (eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412) { | |
| +++ description: None | |
| receivedPermissions.9: | |
| + | {"permission":"interact","from":"eth:0x9660bD6dCDf455DCFb30c07c642Ab22E7Cb89F50","description":"pause the verifier.","role":".owner"} |
| } | |
| + | Status: CREATED |
| contract RiscZeroGroth16Verifier (eth:0x953814e6dfC46d007557B511Dc4F2954dAaf2c9e) [taiko/RiscZeroGroth16Verifier] | |
| +++ description: Verifier contract for RISC Zero Groth16 proofs (version 3.1.0). | |
| + | Status: CREATED |
| contract RiscZeroVerifierEmergencyStop (eth:0x9660bD6dCDf455DCFb30c07c642Ab22E7Cb89F50) [risc0/RiscZeroVerifierEmergencyStop] | |
| +++ description: A verifier wrapper for the eth:0x953814e6dfC46d007557B511Dc4F2954dAaf2c9e that allows pausing (emergency stop) the verifier by its owner. | |
Critical code change49changesDAO proposal 0024 (2026-10-19) upgraded the MainnetInbox: the whole basefee now goes to the block's coinbase, and the reentrancy lock moved to transient storage. The same proposal rotated the trusted RISC Zero images, SP1 programs and SGX enclave measurements. The RISC Zero timelock regranted proposer, executor and canceller to the EOA 0xF616…d412 (2026-10-20). The 2/5 Safe renounced its roles (2026-10-22), so one signer now governs the RiscZeroVerifierRouter behind a 3-day delay. The EOA scheduled addVerifier(0x8b38038c, 0x9660bd6d…) , executable from 2026-10-26. The estops moved to the same EOA. Discovery now watches the timelock's scheduled and executed calls, as bob does: the router emits no event on verifier changes.
DAO proposal 0024 (2026-10-19) upgraded the MainnetInbox: the whole basefee now goes to the block’s coinbase, and the reentrancy lock moved to transient storage. The same proposal rotated the trusted RISC Zero images, SP1 programs and SGX enclave measurements.
The RISC Zero timelock regranted proposer, executor and canceller to the EOA 0xF616…d412 (2026-10-20). The 2/5 Safe renounced its roles (2026-10-22), so one signer now governs the RiscaddVerifier(0x8b38038c, 0x9660bd6d…), executable from 2026-10-26. The estops moved to the same EOA.
Discovery now watches the timelock’s scheduled and executed calls, as bob does: the router emits no event on verifier changes.
| 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: | |
| - | "0xd6ab71c22201c23ef512b706f2e2d720f6da1b559fb76834aa9d4e35276f6e10" |
| + | "0x88712dad7dc78126ee7bb592282d3102569c706f1b9db80580a582e5ffd1dfb0" |
| +++ 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: | |
| - | "0xdd9b8abff96c409ae2418edfb51d893ea2bd10f4873a0226f17a6998c1afc1b7" |
| + | "0x04480b22e244d60165f3d0898bc61ea084d9c76221464a8a3c3343c74889040a" |
| } | |
| contract TimelockController (eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711) [global/TimelockController] { | |
| +++ description: A timelock with access control. The current minimum delay is 3d. | |
| values.accessControl.PROPOSER_ROLE.members.0: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.accessControl.CANCELLER_ROLE.members.0: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.accessControl.EXECUTOR_ROLE.members.0: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.callsExecuted.18: | |
| + | {"id":"0xb88d38cc5995760c99a754e1fef6919fc7ee643d4de92b098d916b906b359910","index":0,"target":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","value":0,"data":"0x2f2ff15db09aa5aeb3702cfd50b6b62bc4532604938f21248a27a1d5ca736082b6819cc1000000000000000000000000f616a4f81857cfee54a4a049ec187172574bd412"} |
| values.callsExecuted.19: | |
| + | {"id":"0xb88d38cc5995760c99a754e1fef6919fc7ee643d4de92b098d916b906b359910","index":1,"target":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","value":0,"data":"0x2f2ff15dd8aa0f3194971a2a116679f7c2090f6939c8d4e01a2a8d7e41d55e5351469e63000000000000000000000000f616a4f81857cfee54a4a049ec187172574bd412"} |
| values.callsExecuted.20: | |
| + | {"id":"0xb88d38cc5995760c99a754e1fef6919fc7ee643d4de92b098d916b906b359910","index":2,"target":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","value":0,"data":"0x2f2ff15dfd643c72710c63c0180259aba6b2d05451e3591a24e58b62239378085726f783000000000000000000000000f616a4f81857cfee54a4a049ec187172574bd412"} |
| values.callsScheduled.24: | |
| + | {"id":"0x682e79774f6b8e0fc1dbddd69bfca4374e9827b815d8fb2a73d602d541714c82","index":0,"target":"eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319","value":0,"data":"0xd0a6af308b38038c000000000000000000000000000000000000000000000000000000000000000000000000000000009660bd6dcdf455dcfb30c07c642ab22e7cb89f50","predecessor":"0x0000000000000000000000000000000000000000000000000000000000000000","delay":259200} |
| +++ severity: MEDIUM | |
| values.Canceller.0: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| +++ description: Executing proposals is only open to all addresses if this resolves to the 0x0 address | |
| +++ severity: MEDIUM | |
| values.Executor.0: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| +++ severity: MEDIUM | |
| values.Proposer.0: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| 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: | |
| - | "0x5f7da556f3b75dcc71465030e1b7274e82df9e9120c0b3eaf5bb76246a514005" |
| + | "0x8c23c79045b9b6bb827eab208e0fe58d7446a57a55f3dfc825c90e904953105b" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x1efDd13f831ceeEa14940806705A53D3211CD698) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0xafB31f5b70623CDF4b20Ada3f7230916A5A79df9 that allows pausing (emergency stop) the verifier by its owner. | |
| +++ severity: MEDIUM | |
| values.owner: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.pendingOwner: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| } | |
| - | Status: DELETED |
| contract Safe (eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609) [GnosisSafe] | |
| +++ description: None | |
| contract RiscZeroVerifierEmergencyStop (eth:0x68dC2cB4e61774873971c499D9b239ec5Ac540E3) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x20ff7C2Cf391a5F096A2Cc181cb41916680f8E97 that allows pausing (emergency stop) the verifier by its owner. | |
| +++ severity: MEDIUM | |
| values.owner: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.pendingOwner: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| } | |
| contract MainnetInbox (eth:0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f) [taiko/MainnetInbox] { | |
| +++ description: The core Layer 1 entrypoint for the Taiko rollup where L2 block batches are proposed and their corresponding state transitions are proven. Users can enqueue forced inclusions by publishing an L1 blob. Once an inclusion is due, subsequent proposals must process it, but proposing remains restricted by the configured proposer checker. If the configured prover whitelist is non-empty, proofs from non-whitelisted provers revert. | |
| sourceHashes.1: | |
| - | "0xa0a8e3ebc196ae2703fc2c0dc5bc16012644bbcd103c34bf6241389ccadc0fd0" |
| + | "0x2dcf603b82b38ffd0745a55af8329dd811aff4e0b4e754f1fc240cc39e6b474e" |
| values.$implementation: | |
| - | "eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9" |
| + | "eth:0xA18431d42C8dF9778905fBEa912aCF1881b49D2e" |
| values.$pastUpgrades.4: | |
| + | ["2026-10-19T01:27:59.000Z","0x3f8f55e6651184d5794e4362661ebe709ae3a33df2424f664dc2bf235465859f",["eth:0xA18431d42C8dF9778905fBEa912aCF1881b49D2e"]] |
| values.$upgradeCount: | |
| - | 4 |
| + | 5 |
| values.getConfig.basefeeSharingPctg: | |
| - | 75 |
| + | 100 |
| values.impl: | |
| - | "eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9" |
| + | "eth:0xA18431d42C8dF9778905fBEa912aCF1881b49D2e" |
| implementationNames.eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9: | |
| - | "MainnetInbox" |
| implementationNames.eth:0xA18431d42C8dF9778905fBEa912aCF1881b49D2e: | |
| + | "MainnetInbox" |
| } | |
| 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: | |
| - | "0x0025425c22e827507428a3d9c7b0f89635be5462f34bb6780563e3d6086be7c7" |
| + | "0x0012b97234e59f2319d44202c7b093fed9c9a51b2068e38d26625c139d668c97" |
| +++ 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: | |
| - | "0x12a12e113a09d41d05147b387b0f89632df2a3174d2ed9e00ac7c7ac086be7c7" |
| + | "0x095cb91a3967c8c63a8840587b093fed4e4d28d901a38e344cc4b8271d668c97" |
| +++ 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: | |
| - | "0x0051ac1d9e8cfd4196e37f9cfefd08e9b0f7ce653bad4634cd1ee84b71ca3be6" |
| + | "0x0017912dfd72308e2e2cd4211b05ed73a97eb7f576816adec2606a37507de51e" |
| +++ 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: | |
| - | "0x28d60ecf233f50655c6ff39f6fd08e9b07be73296eb518d31a3dd09671ca3be6" |
| + | "0x0bc896fe5c8c238b459a8423305ed73a4bf5bfab5a05ab7b04c0d46e507de51e" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x844D5f01161E3559d36f23d0Aa9E9620949aF782) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x5005aBa3DFf7C940fcc1e48DccCAD611a80eEB85 that allows pausing (emergency stop) the verifier by its owner. | |
| +++ severity: MEDIUM | |
| values.owner: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.pendingOwner: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| } | |
| 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: | |
| - | "0x3564b6a30089fcb3e2f69c19b22d23f84ce148387cd7a15f5c1df165b2ae5847" |
| + | "0xfeabd725eb5bb621b5c6a5071d1702bcbe06a643b42a0db8f381d5bc07dd81bf" |
| +++ description: Trusted SGX enclave measurements accepted by attestation verification. | |
| +++ severity: HIGH | |
| values.mrEnclaves.1: | |
| - | "0xae2c7b92b2a71238226cb624ecd1171b66bf943cc372314affca0e6748ccecdf" |
| + | "0x6f3c8c55ec62fe48b83e57463e8717aa9f8594418203c9520f0f80e6f4fc4d87" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D that allows pausing (emergency stop) the verifier by its owner. | |
| +++ severity: MEDIUM | |
| values.owner: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.pendingOwner: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0xDa8f3de6fBBdb261Ac771B813a578A7aBdA6B2b1) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x54aCE3ED46529B4d4F3770C8Bad5dDC48717B9bF that allows pausing (emergency stop) the verifier by its owner. | |
| +++ severity: MEDIUM | |
| values.owner: | |
| - | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.pendingOwner: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| + | "eth:0x0000000000000000000000000000000000000000" |
| } | |
| EOA (eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412) { | |
| +++ description: None | |
| receivedPermissions.0: | |
| + | {"permission":"interact","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","description":"cancel queued transactions.","role":".Canceller"} |
| receivedPermissions.1: | |
| + | {"permission":"interact","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","description":"execute transactions that are ready.","role":".Executor"} |
| receivedPermissions.2: | |
| + | {"permission":"interact","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","description":"manage all access control roles.","role":".defaultAdminAC","via":[{"address":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","delay":259200}]} |
| receivedPermissions.3: | |
| + | {"permission":"interact","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","description":"propose transactions.","role":".Proposer"} |
| receivedPermissions.4: | |
| + | {"permission":"interact","from":"eth:0x1efDd13f831ceeEa14940806705A53D3211CD698","description":"pause the verifier.","role":".owner"} |
| receivedPermissions.6: | |
| + | {"permission":"interact","from":"eth:0x68dC2cB4e61774873971c499D9b239ec5Ac540E3","description":"pause the verifier.","role":".owner"} |
| receivedPermissions.7: | |
| + | {"permission":"interact","from":"eth:0x844D5f01161E3559d36f23d0Aa9E9620949aF782","description":"pause the verifier.","role":".owner"} |
| receivedPermissions.8: | |
| + | {"permission":"interact","from":"eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319","description":"add/remove verifiers and the selectors they are mapped to.","role":".owner","via":[{"address":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","delay":259200}]} |
| receivedPermissions.9: | |
| + | {"permission":"interact","from":"eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696","description":"pause the verifier.","role":".owner"} |
| receivedPermissions.10: | |
| + | {"permission":"interact","from":"eth:0xDa8f3de6fBBdb261Ac771B813a578A7aBdA6B2b1","description":"pause the verifier.","role":".owner"} |
| directlyReceivedPermissions: | |
| + | [{"permission":"act","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","delay":259200,"role":".Executor"}] |
| } | |
5changesRISC Zero verifier owner Safe: ownership transfer of the five RiscZeroVerifierEmergencyStops to an EOA started ( pendingOwner ).
RISC Zero verifier owner Safe: ownership transfer of the five RiscpendingOwner).
| contract RiscZeroVerifierEmergencyStop (eth:0x1efDd13f831ceeEa14940806705A53D3211CD698) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0xafB31f5b70623CDF4b20Ada3f7230916A5A79df9 that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x68dC2cB4e61774873971c499D9b239ec5Ac540E3) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x20ff7C2Cf391a5F096A2Cc181cb41916680f8E97 that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x844D5f01161E3559d36f23d0Aa9E9620949aF782) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x5005aBa3DFf7C940fcc1e48DccCAD611a80eEB85 that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0xDa8f3de6fBBdb261Ac771B813a578A7aBdA6B2b1) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x54aCE3ED46529B4d4F3770C8Bad5dDC48717B9bF that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
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 2 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.
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.
Regular exit
Users initiate withdrawals on Taiko and claim them on Ethereum with a Merkle proof after state finalization. ETH and ERC20 releases consume configured withdrawal quotas. Failed deliveries remain retryable, but source-chain refunds are disabled on both bridges.
Funds can be frozen if a bridge message cannot be delivered successfully, because failed-message refunds are disabled.
Ethereum
Actors:
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
- ERC721Vault DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - Automata
Dcap V3 Attestation DAO with 7d delay (emergency proposals bypass the delay) → Taiko DAOController - Taiko Token DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - MainnetInbox DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - Taiko
DAOController DAO with 7d delay (emergency proposals bypass the delay) - Automata
Dcap V3 Attestation DAO with 7d delay (emergency proposals bypass the delay) → Taiko DAOController - DefaultResolver DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - ERC20Vault DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - DAO DAO with 7d delay (emergency proposals bypass the delay)
- SignalService DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - ERC1155Vault DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - 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. DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - ProverWhitelist DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController - Taiko
DAOController DAO with 7d delay (emergency proposals bypass the delay) - Preconf
Whitelist DAO with 7d delay (emergency proposals bypass the delay) → Taiko DAOController - Bridge DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller - ERC20Vault DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller - ERC721Vault DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller - ERC1155Vault DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller - SignalService DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller - Anchor DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller - DefaultResolver DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller - Delegate
Controller DAO with 7d delay (emergency proposals bypass the delay) → Taiko DAOController → Delegate Controller
- ERC721Vault DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Taiko
Risc0 Verifier - manage trusted RISC Zero image IDs with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- manage trusted RISC Zero image IDs with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with ERC721Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- 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 ETHBEAT 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 DAO with 7d delay (emergency proposals bypass the delay)
- Can interact with Automata
Dcap V3 Attestation - manage trusted SGX measurements, revoked certificate serial numbers, TCB info, QE identity, and local report checks with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- manage trusted SGX measurements, revoked certificate serial numbers, TCB info, QE identity, and local report checks with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Emergency
Multisig - manage critical settings (e.g. threshold and multisig settings) for the emergency proposal governance path with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
- Can interact with Secure
Sgx Verifier - add SGX instances without DCAP attestation and delete registered instances with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- add SGX instances without DCAP attestation and delete registered instances with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- 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 DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- 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 DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Taiko
SP1 Verifier - manage trusted SP1 program verification keys with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- manage trusted SP1 program verification keys with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Automata
Dcap V3 Attestation - manage trusted SGX measurements, revoked certificate serial numbers, TCB info, QE identity, and local report checks with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- manage trusted SGX measurements, revoked certificate serial numbers, TCB info, QE identity, and local report checks with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with DefaultResolver
- update the contract address registered for any chainId-name pair with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- update the contract address registered for any chainId-name pair with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Optimistic
Token Voting Plugin - manage critical settings (e.g. thresholds, delays and proposal acceptance criteria) for all governance proposals with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
- Can interact with ERC20Vault
- pause and unpause token flows and change a canonical token’s bridged representation after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- pause and unpause token flows and change a canonical token’s bridged representation after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with DAO
- define all permissions of the central DAO smart contract with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
- Can interact with Secure
Sgx Verifier - add SGX instances without DCAP attestation and delete registered instances with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- add SGX instances without DCAP attestation and delete registered instances with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with SignalService
- pause and unpause signal proof verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- pause and unpause signal proof verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with ERC1155Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Bridge
- pause and unpause bridge flows and run one-time message recovery initializers with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- pause and unpause bridge flows and run one-time message recovery initializers with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Multisig
- manage critical settings (e.g. threshold and multisig settings) for the standard proposal governance path with 7d delay DAO with 7d delay (emergency proposals bypass the 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 DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- 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 DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Preconf
Whitelist - pause/unpause, add or remove operators, and manage ejecter roles with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController
- pause/unpause, add or remove operators, and manage ejecter roles with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with Bridge
- pause and unpause bridge flows and run one-time message recovery initializers with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller
- pause and unpause bridge flows and run one-time message recovery initializers with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with ERC20Vault
- pause and unpause token flows and change a canonical token’s bridged representation after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller
- pause and unpause token flows and change a canonical token’s bridged representation after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with ERC721Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with ERC1155Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with SignalService
- pause and unpause signal proof verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller
- pause and unpause signal proof verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
- Can interact with DefaultResolver
- update the contract address registered for any chainId-name pair with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
DAOController → Delegate Controller
- update the contract address registered for any chainId-name pair with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → Taiko
A Multisig with 4/6 threshold.
- Can interact with Secure
Sgx Verifier - register SGX instances after DCAP attestation verification
- Can interact with Secure
Sgx Verifier - 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 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.
- 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 Preconf
Whitelist - manage the ejecter role
Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The 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. controls access to the refund callback.
- Can interact with QuotaManager
- consume ERC20 withdrawal quota when tokens leave the vault
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 ETH and cross-chain messages. Pausing stops all message flows. The immutable recallEnabled setting controls failed-message refunds. Successful ETH releases use the configured quota manager.
- Can interact with QuotaManager
- consume ETH withdrawal quota when ETH leaves the bridge
A Multisig with 2/3 threshold.
- Can interact with SP1
Verifier Gateway - 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
A Multisig with 3/5 threshold.
A Multisig with 1/2 threshold. Member of Taiko Foundation Treasury Multisig, Taiko Multisig, Taiko Labs.
- Can interact with Preconf
Whitelist - 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 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 ETHBEAT 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 Sebastian Kugler
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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.).
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council
- Can interact with Timelock
Controller - cancel queued transactions
- execute transactions that are ready
- manage all access control roles with 3d delay Timelock
Controller with 3d delay - propose transactions
- Can interact with Risc
Zero Verifier Emergency Stop - pause the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.
- Can interact with Risc
Zero Verifier Emergency Stop - pause the verifier
- Can interact with Risc
Zero Verifier Emergency Stop - pause the verifier
- Can interact with Risc
Zero Verifier Emergency Stop - pause the verifier
- Can interact with Risc
Zero Verifier Emergency Stop - pause the verifier
- Can interact with Risc
Zero Verifier Router - add/remove verifiers and the selectors they are mapped to with 3d delay Timelock
Controller with 3d delay
- add/remove verifiers and the selectors they are mapped to with 3d delay Timelock
- Can interact with Risc
Zero Verifier Emergency Stop - pause the verifier
- Can interact with Risc
Zero Verifier Emergency Stop - pause the verifier
- Can interact with Risc
Zero Verifier Emergency Stop - pause the verifier
Taiko Alethia
Actors:
- Can interact with 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.
Ethereum
Gating router contract to verify batches using RISC Zero.
- Roles:
- owner: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: Taiko
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).
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).
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).
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: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Taiko
DAOController; ultimately SignerList (Security Council)
- admin: Taiko
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.
Gating router contract to verify batches using SP1.
- Roles:
- owner: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: Taiko
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.1.0).
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).
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: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Taiko
DAOController; ultimately SignerList (Security Council) - proverManager: Taiko Multisig
- admin: Taiko
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.
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.
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 ETHBEAT 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:
- current
Signer : 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) (emergency proposals bypass the delay)List Permissions - daoPermissions: DAO; ultimately SignerList (Security Council)
- current
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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DAO
A timelock with access control. The current minimum delay is 3d.
- Roles:
- canceller: EOA 7
- defaultAdmin: Timelock
Controller; ultimately EOA 7 - executor: EOA 7
- 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.: EOA 7
Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local 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., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
- Roles:
- admin: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Taiko
DAOController; ultimately SignerList (Security Council)
- admin: Taiko
Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
- Roles:
- admin: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Taiko
DAOController; ultimately SignerList (Security Council)
- admin: Taiko
ERC20 contract implementing the TAIKO token. It defines a list of addresses designated as non-voting.
- Roles:
- admin: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- admin: Taiko
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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. emergency proposals).
- Roles:
- dao: DAO; ultimately SignerList (Security Council)
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: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - registrar: Taiko Multisig
- owner: Taiko
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.
Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
- Roles:
- admin: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Taiko
DAOController; ultimately SignerList (Security Council)
- admin: Taiko
A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (Timelock
- Roles:
- owner: Timelock
Controller; ultimately EOA 7
- owner: Timelock
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: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Taiko
DAOController; ultimately SignerList (Security Council)
- admin: Taiko
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 ETHBEAT 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: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Taiko
DAOController; ultimately SignerList (Security Council) - pauser: Taiko Multisig
- admin: Taiko
Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local 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., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
- Roles:
- admin: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Taiko
DAOController; ultimately SignerList (Security Council)
- admin: Taiko
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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. standard proposals).
- Roles:
- dao: DAO; ultimately SignerList (Security Council)
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: Taiko
DAOController; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - ejecters: EOA 2, EOA 5
- operatorMapping: EOA 3, EOA 6
- owner: Taiko
DAOController; ultimately SignerList (Security Council)
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: SP1
Verifier Gateway Multisig
- owner: SP1
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).
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: Delegate
Controller; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- admin: Delegate
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. Failed messages remain retryable, but message failure and source-chain refunds are disabled.
- Roles:
- admin: Delegate
Controller; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Delegate
Controller; ultimately SignerList (Security Council) - pauser: EOA 1
- admin: Delegate
Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The 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. controls access to the refund callback.
- Roles:
- admin: Delegate
Controller; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Delegate
Controller; ultimately SignerList (Security Council)
- admin: Delegate
Middleware contract that can maintain ownership of DAO-controlled assets and contracts. It can only be invoked by the Taiko
- Roles:
- admin: Delegate
Controller; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - daoController: Taiko
DAOController
- admin: Delegate
Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local 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., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
- Roles:
- admin: Delegate
Controller; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Delegate
Controller; ultimately SignerList (Security Council)
- admin: Delegate
Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local 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., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
- Roles:
- admin: Delegate
Controller; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Delegate
Controller; ultimately SignerList (Security Council)
- admin: Delegate
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: Delegate
Controller; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Delegate
Controller; ultimately SignerList (Security Council)
- admin: Delegate
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: Delegate
Controller; 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 ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) - owner: Delegate
Controller; ultimately SignerList (Security Council)
- admin: Delegate
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).