Search
Search for projects by name or address
Taiko Alethia
Badges
About
Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko combines a preconfirmation-based sequencing mechanism with a multi-proof system using SP1, RISC0 and TEEs.
Badges
About
Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko combines a preconfirmation-based sequencing mechanism with a multi-proof system using SP1, RISC0 and TEEs.
2025 Aug 19 — 2026 Aug 19
The section shows the operating costs that L2s pay to Ethereum.
2025 Aug 19 — 2026 Aug 19
This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data to; previously it posted to
Ethereum.
2025 Aug 19 — 2026 Aug 19
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.
2026 Jul 20 — Aug 19
Last 30 day anomalies
All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.
No State updates were performed for 3h 35m (from 2026 Jul 31, 20:36 UTC until 2026 Aug 01, 00:11 UTC). These typically occur every 1m 32s on average.
No Tx data submissions were performed for 7d 23h (from 2026 Jun 22, 02:10 UTC until 2026 Jun 30, 01:17 UTC). These typically occur every 52s on average.
No State updates were performed for 7d 12h (from 2026 Jun 22, 02:10 UTC until 2026 Jun 29, 14:49 UTC). These typically occur every 1m 32s on average.
Unzen upgrade: validity rollup
2026 Aug 3rd
Every proven proposal range now requires at least one SP1 or RISC0 validity proof.
Proof system exploit
2026 Jun 22nd
An attacker exploits a vulnerability in the SGX proof system and steals USD ~1.7M.
Funds can be stolen if
Users can be censored if
MEV can be extracted if
Users can submit transactions to an L1 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 proposer 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 liveness but does not allow finalizing invalid state.
All of the data needed for proof construction is published on Ethereum L1.
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 roots on L1, so in the event of failure the withdrawals are frozen. Proposing is gated by PreconfWhitelist, which selects a single active operator for the current epoch and has no permissionless fallback.
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 blobs. This ensures that it will be available for enough time.
EthereumTaiko uses a multi-proof system to validate state transitions. Exactly two proofs are required from four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. At least one proof must come from SP1 or RISC0: accepted combinations are either SGX verifier plus either ZK verifier, or SP1 plus RISC0. An SGX-only pair is not accepted. New proposals target a proof submission cadence of 4h. Proving is currently centralized behind ProverWhitelist with 2 whitelisted provers. While the whitelist is non-empty, non-whitelisted actors cannot submit proofs, and the configured permissionless proving delay is not used to open proving. MainnetInbox currently sets minBond=0 and livenessBond=0.
Trusted Setups
Onchain verifier
Used in
Projects used in
Search for projects used in
Onchain verifier | Used in Projects used inSearch for projects used in |
Trusted Setups
Onchain verifier
Used in
Projects used in
Search for projects used in
Used in Projects used inSearch for projects used in |
Taiko Alethia has a governance structure relying primarily on a 7/9 Security Council, checked by a token DAO that is limited to veto permissions. The closed operator 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 5 approving Security Council members is required to forward a Standard proposal to the OptimisticTokenVotingPlugin contract. It can be vetoed by 10% of votable TAIKO tokens during a 10d public veto period. If not vetoed, a further 7d timelock applies before the proposal can be executed.
Emergency proposals
Emergency proposals are encrypted at proposal time and can only be read by Security Council members. If approved by 7 Security Council members, they can be immediately decrypted and executed.
Proof system and operators
The proof system currently does not require zk proofs to validate state transitions and state can be finalized with SGX proofs only. The optional zk verifier contracts can be upgraded by Multisigs. Operator roles (sequencer, proposer) are closed and the whitelist is managed by the Taiko Multisig and related EOAs.
Governance profile
Security Council
| Composition | 5/9 standard · 7/9 emergency — 9-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 Taiko Labs employees. Members can appoint EOA agents to act for them. |
|---|---|
| Members public | Mapped — Taiko publishes a member wallet-to-entity mapping. The 9 current onchain members are Aragon, Chainbound, Drew Van der Werff, Gattaca, Taiko Labs, Halborn, L2BEAT, Nethermind, and Toni Wahrstätter. 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 — 7 Security Council approvals execute an encrypted proposal immediately, with no TAIKO-holder veto or delay. Standard proposals require 5 approvals and remain vetoable. The council controls most core upgrades but no longer has permissions over Treasury funds. |
| DAO can override SC? |
Upgrades
| Normal upgrade path | Security Council member creates a public executable payload → 5 council approvals → 10d token-holder veto period → if less than 10% of eligible TAIKO vetoes, 7d timelock → permissionless execution of the approved onchain actions. |
|---|---|
| Emergency upgrade path | 7 Security Council 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 |
|
|---|---|
| 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 Council 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 + permissionless execution. The Security Council approves the exact onchain actions. Token holders can only veto; if the threshold is not reached and the 7d timelock expires, anyone can call |
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
2026 August 17, 08:30 UTC9changesMultisig changes.
Multisig changes.
| contract Taiko Foundation Treasury Multisig (eth:0x363e846B91AF677Fb82f709b6c35BD1AaFc6B3Da) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.0: | |
| + | "eth:0xA1D62c7df45847089cfB052396Abe4cDa7879d25" |
| values.$members.1: | |
| + | "eth:0xDC4ece5620659F4d5d1536Cab52BD5e5B15F8a0a" |
| values.$members.0: | |
| - | "eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a" |
| + | "eth:0x7A5299927F93ffCf33cf381CB0C03C2486b9299A" |
| values.$threshold: | |
| - | 2 |
| + | 3 |
| values.multisigThreshold: | |
| - | "2 of 3 (67%)" |
| + | "3 of 5 (60%)" |
| } |
| 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.2: | |
| - | "eth:0x000cb000E880A92a8f383D69dA2142a969B93DE7" |
| } |
2026 August 04, 09:57 UTCHigh severity55changesThis is the onchain deployment of the Unzen upgrade, which will be activated on Aug 6. MainnetInbox diff: https://disco.l2beat.com/diff/eth:0x64523f2580f4E7038a121D55b220a9C12C1E8f01/eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9 - adds back forced txs - no self-proposal though ZK verifier diff: https://disco.l2beat.com/diff/eth:0x71808449A6217898d602c1a392D95b931Ac5d878/eth:0x7284aaC05555Ae6559bdAd8B4221eC9584254Eec - ZK proof always required: Taiko is a Stage 0 validity rollup add TEE and ZK program hashes for the new Unzen programs (ZK is reproduced here) L2BEAT SC member safe moves to 1/1 (single signer: sekuba).
This is the onchain deployment of the Unzen upgrade, which will be activated on Aug 6.
MainnetInbox diff: https://disco.l2beat.com/diff/eth:0x64523f2580f4E7038a121D55b220a9C12C1E8f01/eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9
- adds back forced txs
- no self-proposal though
ZK verifier diff: https://disco.l2beat.com/diff/eth:0x71808449A6217898d602c1a392D95b931Ac5d878/eth:0x7284aaC05555Ae6559bdAd8B4221eC9584254Eec
- ZK proof always required: Taiko is a Stage 0 validity rollup
add TEE and ZK program hashes for the new Unzen programs (ZK is reproduced here)
L2BEAT SC member safe moves to 1/1 (single signer: sekuba).
| 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: | |
| - | "0xa38d1fac63aa6a553fdb6fea01fdc96534564c31de916aaafe5f5a1dd3bb908b" |
| + | "0x5a818b4c7dc80e9ba85d55492c20c263c67238724e3982f76d15a158e501210b" |
| +++ 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: | |
| - | "0x868b5154ae01a9a045051da2d7ba2e21d4132c7ec096da343fa24149407fefef" |
| + | "0x9cfcc1b34a98853c3c5873a4d456726e528246f7f03a4ea35f27c2543aa6e7f0" |
| } |
| 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: | |
| - | "0xbefb2c7ec44cefe57f4ff0ca815a8b8f15e05631bf3abe36cbc12d28f778fa36" |
| + | "0x2d2216efbe9d8e80ba24b86606ccd5ce9faf11033d31ad9e5d3c5c89965c8a57" |
| } |
| EOA (eth:0x3D4997AAC0834BEb5ede861c424807Aa3F29b5bB) { | |
| +++ description: None | |
| receivedPermissions: | |
| + | [{"permission":"interact","from":"eth:0x0F95E6968EC1B28c794CF1aD99609431de5179c2","description":"configure an agent address that represents this entity in the Security Council","role":".multisigSigners","via":[{"address":"eth:0xf1cF63589A1e012F9124182c9eAa36B5333e5f06"}]}] |
| } |
| 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. | |
| template: | |
| - | "taiko/MainnetInboxRestricted" |
| + | "taiko/MainnetInbox" |
| sourceHashes.1: | |
| - | "0xd6d3af78f692a4c928f8e1b046eca6884ed0d15d120df586c3509c802795d433" |
| + | "0xa0a8e3ebc196ae2703fc2c0dc5bc16012644bbcd103c34bf6241389ccadc0fd0" |
| description: | |
| - | "The core Layer 1 entrypoint for the Taiko rollup where L2 block batches are proposed and their corresponding state transitions are proven. Forced inclusion submission and processing are disabled in this implementation. Proposals must come from the configured proposer checker, and if the configured prover whitelist is non-empty, proofs from non-whitelisted provers revert; the configured permissionless proving delay is not used to open proving." |
| + | "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." |
| values.$implementation: | |
| - | "eth:0x64523f2580f4E7038a121D55b220a9C12C1E8f01" |
| + | "eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9" |
| values.$pastUpgrades.3: | |
| + | ["2026-08-03T12:46:23.000Z","0x64875b5b84b41b520551854696c0ce408fb3e0aa2ede604cc95a5919b6140ea7",["eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9"]] |
| values.$upgradeCount: | |
| - | 3 |
| + | 4 |
| values.getConfig.proofVerifier: | |
| - | "eth:0x71808449A6217898d602c1a392D95b931Ac5d878" |
| + | "eth:0x7284aaC05555Ae6559bdAd8B4221eC9584254Eec" |
| +++ severity: HIGH | |
| values.getCurrentForcedInclusionFee: | |
| - | 1020000 |
| + | 1000000 |
| values.impl: | |
| - | "eth:0x64523f2580f4E7038a121D55b220a9C12C1E8f01" |
| + | "eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9" |
| values.noForce: | |
| - | [true] |
| fieldMeta.noForce: | |
| - | {"severity":"HIGH","description":"Forced inclusions are disabled in this implementation: saveForcedInclusion() always reverts and propose() only accepts zero forced inclusions."} |
| implementationNames.eth:0x64523f2580f4E7038a121D55b220a9C12C1E8f01: | |
| - | "MainnetInbox" |
| implementationNames.eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9: | |
| + | "MainnetInbox" |
| } |
| - | Status: DELETED |
| contract MainnetVerifier (eth:0x71808449A6217898d602c1a392D95b931Ac5d878) [taiko/MainnetVerifier] | |
| +++ description: Immutable verifier policy contract for Taiko mainnet. Each accepted proof must contain exactly two ordered sub-proofs: either SGX-GETH plus SGX-RETH/RISC0-RETH/SP1-RETH, or SGX-RETH plus SGX-GETH/RISC0-RETH/SP1-RETH. It routes each sub-proof to the corresponding downstream verifier. |
| 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: | |
| - | "0x007594632ec31fae9d44799b97316fcbcaa3ff6b5db268c7a5d8025b3bbb487e" |
| + | "0x00ad090221a8fa0f09e1be7a53feb67be010f01310d4b2314a69d10152ee1ce0" |
| +++ 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: | |
| - | "0x3aca319730c7eba7288f33727316fcbc551ffb5a76c9a31e4bb004b63bbb487e" |
| + | "0x568481106a3e83c23c37cf4a3feb67be008780984352c8c514d3a20252ee1ce0" |
| +++ 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: | |
| - | "0x00e91cb391c22d6fd015e4c6041dbbe6efb2d8be6d4046eec28f12acba5a17bc" |
| + | "0x000b11691352e55fcf64f62620cefaa700161600093f2751032fe71ea912264d" |
| +++ 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: | |
| - | "0x748e59c8708b5bf402bc98c041dbbe6e7d96c5f335011bbb051e25593a5a17bc" |
| + | "0x0588b48954b957f36c9ec4c40cefaa7000b0b00024fc9d44065fce3d2912264d" |
| } |
| 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: | |
| - | "0xdccd8f30ea4a137ddfa63d743e3aa7c7a8e80585912d19c4b66f7d8d6098bec4" |
| + | "0x90c79e65d6d0f83d658ff96cd0ef1204438f20b406c93cf1d4fafa0cff29842e" |
| +++ description: Trusted SGX enclave measurements accepted by attestation verification. | |
| +++ severity: HIGH | |
| values.mrEnclaves.1: | |
| - | "0x92dd96a170d1ffb998afa210b3ef8af8c408ab76c4717e0eb8076d4a5da4e740" |
| + | "0x041cadb0541bf8249c368482172d218608f3693975b65f74beb2ed6f0044f951" |
| } |
| contract Gustavo Gonzalez Taiko (eth:0xb47fE76aC588101BFBdA9E68F66433bA51E8029a) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.0: | |
| - | "eth:0xAC5898b0FFFd23F4Ef09F0E50Fa1bC4896eF7163" |
| + | "eth:0xCf76A87E24FE2054DCF02a5f65eAc0F24A34c439" |
| } |
| contract L2BEAT (eth:0xf1cF63589A1e012F9124182c9eAa36B5333e5f06) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.1: | |
| - | "eth:0x6dcB04fCC1c597DAFad86e2886bE463d53CaFAdf" |
| values.$threshold: | |
| - | 2 |
| + | 1 |
| values.multisigThreshold: | |
| - | "2 of 2 (100%)" |
| + | "1 of 1 (100%)" |
| receivedPermissions: | |
| - | [{"permission":"interact","from":"eth:0x0F95E6968EC1B28c794CF1aD99609431de5179c2","description":"configure an agent address that represents this entity in the Security Council","role":".multisigSigners"}] |
| directlyReceivedPermissions: | |
| + | [{"permission":"interact","from":"eth:0x0F95E6968EC1B28c794CF1aD99609431de5179c2","description":"configure an agent address that represents this entity in the Security Council","role":".multisigSigners"}] |
| } |
| 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:0x000cb000E880A92a8f383D69dA2142a969B93DE7" |
| + | "eth:0x5F62d006C10C009ff50C878Cd6157aC861C99990" |
| values.operatorMapping.2: | |
| - | "eth:0x5F62d006C10C009ff50C878Cd6157aC861C99990" |
| + | "eth:0x000cb000E880A92a8f383D69dA2142a969B93DE7" |
| } |
| + | Status: CREATED |
| contract ZkRequiredVerifier (eth:0x7284aaC05555Ae6559bdAd8B4221eC9584254Eec) [taiko/ZkRequiredVerifier] | |
| +++ description: Immutable verifier 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. |
2026 July 29, 11:38 UTC2changesOperator rotation.
Operator rotation.
| contract PreconfWhitelist (eth:0xFD019460881e6EeC632258222393d5821029b2ac) [taiko/PreconfWhitelist] { | |
| +++ description: Contains the whitelist of addresses eligible to propose batches on L1 and issue preconfirmations. It dynamically selects a single active operator for each epoch using a delayed Ethereum beacon block root as randomness. There is no fallback proposer path in this contract: non-selected operators cannot propose for the current epoch. | |
| values.operatorMapping.1: | |
| - | "eth:0x5F62d006C10C009ff50C878Cd6157aC861C99990" |
| values.operatorMapping.2: | |
| + | "eth:0x5F62d006C10C009ff50C878Cd6157aC861C99990" |
| } |
2026 July 23, 13:53 UTC1changeA third preconfirmation operator was added to the whitelist.
A third preconfirmation operator was added to the whitelist.
| 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.2: | |
| + | "eth:0x2267C7246523191b8bf7615B86b3bdEE612b7D9E" |
| } |
2026 July 17, 07:45 UTCHigh severity8changesOne Security Council agent is changed. The Unzen upgrade proposal moves into the optimistic public phase.
One Security Council agent is changed. The Unzen upgrade proposal moves into the optimistic public phase.
| contract SignerList (Security Council) (eth:0x0F95E6968EC1B28c794CF1aD99609431de5179c2) [taiko/SignerList] { | |
| +++ description: A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here. | |
| values.$members.4: | |
| - | "eth:0xbC40317A69CB1D1aF2CBcfE32C8B7a6840Dc287a" |
| + | "eth:0x4236f57E9dBc238878EFac4AeF0A16D4dD06DC1A" |
| } |
| contract OptimisticTokenVotingPlugin (eth:0x989E348275b659d36f8751ea1c10D146211650BE) [taiko/OptimisticTokenVotingPlugin] { | |
| +++ description: An optimistic governance module. Standard proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d. Emergency proposals can be executed without delay. | |
| values.proposalCount: | |
| - | 36 |
| + | 37 |
| values.proposalIds.36: | |
| + | "607065748551507217783827454409519139164457533476" |
| } |
| contract Multisig (eth:0xD7dA1C25E915438720692bC55eb3a7170cA90321) [taiko/Multisig] { | |
| +++ description: Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security Council standard proposals). | |
| +++ description: total standard proposal count. | |
| +++ severity: HIGH | |
| values.proposalCount: | |
| - | 21 |
| + | 22 |
| } |
| 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.2: | |
| - | "eth:0xCbeB5d484b54498d3893A0c3Eb790331962e9e9d" |
| } |
The system uses whitelist-based sequencing and proving
The system uses a whitelist-based sequencing mechanism to allow for fast preconfirmations on the L2. On the L1, batch proposing is permissioned through the PreconfWhitelist contract, which currently has 2 active operators registered.
For each epoch, PreconfWhitelist selects a single active operator that can propose to MainnetInbox. There is no fallback proposer 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 prover 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 L1 by publishing a blob containing one L2 block 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 proposer’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 permissionless 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.
Ethereum
Actors:
A Multisig with 7/9 threshold. A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here.
- Can upgrade with 7d delay
- AutomataDcapV3Attestation DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Taiko Token DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- MainnetInbox DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- TaikoDAOController DAO with 7d delay (emergency proposals bypass the delay)
- AutomataDcapV3Attestation DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- DefaultResolver DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- MainnetERC20Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- DAO DAO with 7d delay (emergency proposals bypass the delay)
- SignalService DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- MainnetBridge DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- ProverWhitelist DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- TaikoDAOController DAO with 7d delay (emergency proposals bypass the delay)
- PreconfWhitelist DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with TaikoRisc0Verifier
- manage trusted RISC Zero image IDs with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with SignerList (Security Council)
- 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 AutomataDcapV3Attestation
- 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) → TaikoDAOController
- Can interact with EmergencyMultisig
- 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 SecureSgxVerifier
- add SGX instances without DCAP attestation and delete registered instances with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with MainnetInbox
- pause and unpause the 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) → TaikoDAOController
- Can interact with TaikoSP1Verifier
- manage trusted SP1 program verification keys with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with AutomataDcapV3Attestation
- 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) → TaikoDAOController
- 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) → TaikoDAOController
- Can interact with OptimisticTokenVotingPlugin
- 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 MainnetERC20Vault
- pause and unpause token bridge flows and change the bridged token implementation for a canonical token after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- 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 SecureSgxVerifier
- add SGX instances without DCAP attestation and delete registered instances with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with SignalService
- pause and unpause signal proof verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with MainnetBridge
- 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 prover whitelist with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with PreconfWhitelist
- pause/unpause, add or remove operators, and manage ejecter roles with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
A Multisig with 4/6 threshold.
- Can interact with SecureSgxVerifier
- register SGX instances after DCAP attestation verification
- Can interact with SecureSgxVerifier
- register SGX instances after DCAP attestation verification
- Can interact with SignalService
- pause and unpause signal proof verification
- Can interact with QuotaManager
- update token withdrawal quotas and the quota refill period
- Can interact with MainnetBridge
- Can interact with ProverWhitelist
- manage the prover whitelist
- Can interact with PreconfWhitelist
- manage the ejecter role
Shared vault for Taiko chains for bridged ERC20 tokens. Pausing stops token sends, message-triggered releases, and recalls. Released or minted tokens are subject to the configured quota manager.
- Can interact with QuotaManager
- consume ERC20 withdrawal quota when tokens leave the vault
Shared bridge escrow for Taiko chains for bridged ETH and arbitrary bridge messages. Pausing stops sending, processing, recalling, retrying, and failing messages. ETH released from the bridge is subject to the configured quota manager.
- Can interact with QuotaManager
- consume ETH withdrawal quota when ETH leaves the bridge
A Multisig with 3/5 threshold.
- Can interact with TimelockController
- cancel queued transactions
- execute transactions that are ready
- manage all access control roles with 3d delay TimelockController with 3d delay
- propose transactions
- Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
- Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
- Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
- Can interact with RiscZeroVerifierRouter
- add/remove verifiers and the selectors they are mapped to with 3d delay TimelockController with 3d delay
- Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
- Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
A Multisig with 3/5 threshold.
A Multisig with 1/2 threshold. Member of Taiko Foundation Treasury Multisig, Taiko Multisig, Gustavo Gonzalez Taiko.
Member of Halborn, SignerList (Security Council).
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council Halborn
Member of Gattaca.
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council Gattaca
Member of L2BEAT.
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council L2BEAT
Member of SignerList (Security Council), Toni Wahrstätter.
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council Toni Wahrstätter
Member of Halborn.
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council Halborn
Member of SignerList (Security Council), Gattaca.
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council Gattaca
Member of Toni Wahrstätter.
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council Toni Wahrstätter
Ethereum
Gating router contract to verify batches using RISC Zero.
- Roles:
- owner: TaikoDAOController; ultimately SignerList (Security Council)
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.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
Immutable verifier 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: TaikoDAOController; ultimately SignerList (Security Council)
Defines the prover whitelist queried by the inbox before accepting proofs. If the inbox is configured with this contract and the whitelist is non-empty, only whitelisted provers can prove proposals.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
- proverManager: Taiko Multisig
Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.
- Roles:
- admin: DAO; ultimately SignerList (Security Council)
- owner: DAO
The main contract and entrypoint of the Aragon-based DAO governance framework. Fine-grained DAO permissions, proposals, voting and thresholds are configured here.
- Roles:
- currentSignerListPermissions: SignerList (Security Council) (emergency proposals bypass the delay)
- daoPermissions: DAO; ultimately SignerList (Security Council)
Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.
- Roles:
- admin: DAO; ultimately SignerList (Security Council)
- owner: DAO
A timelock with access control. The current minimum delay is 3d.
- Roles:
- canceller: Safe
- defaultAdmin: TimelockController; ultimately Safe
- executor: Safe
- proposer: Safe
Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
ERC20 contract implementing the TAIKO token. It defines a list of addresses designated as non-voting.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
Modular Governance contract allowing for proposing, voting on and executing encrypted proposals (e.g. for Security Council emergency proposals).
- Roles:
- dao: DAO; ultimately SignerList (Security Council)
Verifier contract for SGX proven blocks. Registered SGX instances can sign accepted proofs until their instance expiry.
- Roles:
- owner: TaikoDAOController; ultimately SignerList (Security Council)
- registrar: Taiko Multisig
Set verifier contract for RISC Zero proofs (version 0.9.0). It allows verifying a whole set of proofs identified with a Merkle root at once, afterwards each individual proof could be efficiently verified just by checking Merkle inclusion against the verified root.
Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (TimelockController).
- Roles:
- owner: TimelockController; ultimately Safe
Maps chainId-name pairs to contract addresses. Bridge and vault contracts resolve their counterparties through this registry, so changes in this mapping effectively act as contract upgrades. The pause function is intentionally disabled in this implementation.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
An optimistic governance module. Standard proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d. Emergency proposals can be executed without delay.
- Roles:
- dao: DAO; ultimately SignerList (Security Council)
Facilitates secure cross-chain message passing by storing signals and state-root checkpoints. Bridge escrows and other applications use it to prove that a specific L1<->L2 signal or checkpointed state transition occurred via Merkle proofs. Pausing disables signal proof verification.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
- pauser: Taiko Multisig
Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security Council standard proposals).
- Roles:
- dao: DAO; ultimately SignerList (Security Council)
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.
- Roles:
- _ejectorManager: Taiko Multisig
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- ejecters: EOA 1, EOA 5
- operatorMapping: EOA 2, EOA 6
- owner: TaikoDAOController; ultimately SignerList (Security Council)
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).