Search
Search for projects by name or address
Taiko Alethia
Badges
About
Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko aims at combining based sequencing and a multi-proof system through SP1, RISC0 and TEEs.
Badges
About
Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko aims at combining based sequencing and a multi-proof system through SP1, RISC0 and TEEs.
Why is the project listed in others?
Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.
Learn more about the recategorisation here.
2025 Jul 30 — 2026 Jul 30
The section shows the operating costs that L2s pay to Ethereum.
2025 Jul 30 — 2026 Jul 30
This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data to
Ethereum.
2026 Apr 02 — Jul 30
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 Jun 30 — Jul 30
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 7d 23h 7m (from 2026 Jun 22, 02:10 UTC until 2026 Jun 30, 01:17 UTC). These typically occur every 6min 23s on average.
No State updates were performed for 7d 12h 39m (from 2026 Jun 22, 02:10 UTC until 2026 Jun 29, 14:49 UTC). These typically occur every 31min 43s on average.
Proof system exploit
2026 Jun 22nd
An attacker exploits a vulnerability in the SGX proof system and steals USD ~1.7M.
Preconfs introduction
2025 Aug 11th
Taiko implements preconfs - whitelisted actors provide fast soft confirmations for L2 txs.
Funds can be stolen if
Users can be censored if
MEV can be extracted if
There is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled. Forced inclusions are disabled in the current MainnetInbox implementation, so sequencer failure or censorship leads to non-inclusion.
A multi-proof system is used. There are four verifiers available: SGX (Geth), SGX (Reth), SP1 and RISC0. Two of them must be used to prove a proposal range, and SGX (Geth) is mandatory. The end state root is supplied during the prove call and is checked against the accompanying SGX/zkVM proof. Proving is currently gated by ProverWhitelist, which has 2 whitelisted provers in discovery. While the whitelist is non-empty, non-whitelisted actors cannot submit proofs.
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 fallback proposer path.
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. The system requires two proofs among four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. This means that a proposal range can be proven without providing a ZK proof if SGX (Geth) and SGX (Reth) are used together. 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. The multi-proof system allows detecting bugs in the verifiers if they produce different results for the same proposal range. If such a bug is detected, the system gets automatically paused.
Funds can be stolen if a malicious block is proven by compromised SGX instances.
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 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" |
| } |
2026 July 08, 11:21 UTC5changesQuota changes 150K - 250K per day for stables (USDT and USDC).
Quota changes 150K -> 250K per day for stables (USDT and USDC).
| contract QuotaManager (eth:0xBaCb003f0B13CeAF09Eb9Baf5915A640BD4Bc6cC) [taiko/QuotaManager] { | |
| +++ description: Defines withdrawal quotas for ETH and ERC20 releases from the shared bridge. A token quota of zero means unlimited withdrawals for that token. | |
| values.tokenQuotas.3.quota: | |
| - | "150,000" |
| + | "250,000" |
| values.tokenQuotas.4.quota: | |
| - | "150,000" |
| + | "250,000" |
| } |
| 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" |
| } |
2026 July 02, 07:58 UTCHigh severity11changesBridges unpaused. Taiko is live again, without forced transactions or proposer fallback.
Bridges unpaused. Taiko is live again, without forced transactions or proposer fallback.
| 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:0x4236f57E9dBc238878EFac4AeF0A16D4dD06DC1A" |
| + | "eth:0xbC40317A69CB1D1aF2CBcfE32C8B7a6840Dc287a" |
| } |
| contract EmergencyMultisig (eth:0x2AffADEb2ef5e1F2a7F58964ee191F1e88317ECd) [taiko/EmergencyMultisig] { | |
| +++ description: Modular Governance contract allowing for proposing, voting on and executing encrypted proposals (e.g. for Security Council emergency proposals). | |
| +++ description: total count of encrypted emergency proposals created. | |
| +++ severity: HIGH | |
| values.proposalCount: | |
| - | 34 |
| + | 35 |
| } |
| 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: | |
| - | 35 |
| + | 36 |
| values.proposalIds.35: | |
| + | "606707631305171219093581685850458871248271179811" |
| } |
| contract MainnetERC20Vault (eth:0x996282cA11E5DEb6B5D122CC3B9A1FcAAD4415Ab) [taiko/SharedERC20Vault] { | |
| +++ description: 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. | |
| +++ severity: HIGH | |
| values.paused: | |
| - | true |
| + | false |
| } |
| contract MainnetBridge (eth:0xd60247c6848B7Ca29eDdF63AA924E53dB6Ddd8EC) [taiko/TaikoBridge] { | |
| +++ description: 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. | |
| +++ severity: HIGH | |
| values.paused: | |
| - | true |
| + | false |
| } |
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 3 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.
Currently, proving a proposal requires SGX (Geth), plus either SGX (Reth), SP1, or RISC0.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can't force any transaction
There is no general mechanism to force the sequencer to include a transaction.
Forced inclusions are disabled in the current MainnetInbox implementation: saveForcedInclusion() always reverts and propose() only accepts zero forced inclusions.
If the selected proposer is down or censoring, user transactions that are not included by the permissioned proposer remain non-included.
Users can be censored if the operator refuses to include their transactions.
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 2/3 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 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. 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.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
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. Member of Taiko Foundation Treasury Multisig.
- 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 2, EOA 5
- operatorMapping: EOA 1, EOA 3, 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).