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 Apr 10 — 2026 Apr 10
The section shows the operating costs that L2s pay to Ethereum.
2025 Apr 10 — 2026 Apr 10
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 — 10
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.
Preconfs introduction
2025 Aug 11th
Taiko implements preconfs - whitelisted actors provide fast soft confirmations for L2 txs.
Plonky3 vulnerability patch
2025 Jun 4th
SP1 verifier is patched to fix critical vulnerability in Plonky3 proof system (SP1 dependency).
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 1 whitelisted prover in discovery, and becomes permissionless only after an unproven proposal is > 5d old.
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.
Anyone can propose after 1d 1h if forced inclusions are ignored, and proving becomes permissionless after 5d if a proposal remains unproven.
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. The use of SGX (Geth) is mandatory, while the other three can be used interchangeably. 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 1 whitelisted prover. Non-whitelisted actors must wait 5d before the whitelist is dropped, and 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.
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
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, whitelisted preconfirmers can propose Taiko L2 data to the MainnetInbox contract.
The whitelist is managed by the PreconfWhitelist contract, which currently has 2 active operators registered.
Forced inclusions become mandatory after 9m 36s and proposing becomes permissionless after 1d 1h if the queue is still ignored.
Proving is controlled separately by ProverWhitelist, which currently has 1 whitelisted prover.
Non-whitelisted actors must wait 5d after an unproven proposal before the whitelist is dropped. 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 force any transaction via L1
Users can submit a blob reference containing a standalone transaction by calling the saveForcedInclusion() function on the MainnetInbox contract.
Once any forced inclusion has been queued for 9m 36s, whitelisted proposers cannot submit new proposals unless they process all due forced inclusions.
If the oldest queued forced inclusion is still ignored for 1d 1h, proposing becomes permissionless and anyone can include it.
Ethereum
Roles:
Actors:
The main contract and entrypoint of the Aragon-based DAO governance framework. Fine-grained DAO permissions, proposals, voting and thresholds are configured here.
- Can upgrade with no delay
- AutomataDcapV3Attestation TaikoDAOController
- Taiko Token TaikoDAOController
- TaikoDAOController
- AutomataDcapV3Attestation TaikoDAOController
- QuotaManager TaikoDAOController
- MainnetERC20Vault TaikoDAOController
- SignalServiceForkRouter TaikoDAOController
- MainnetBridge TaikoDAOController
- ProverWhitelist TaikoDAOController
- L1SharedAddressManager TaikoDAOController
- TaikoDAOController
- PreconfWhitelist TaikoDAOController
- Can interact with TaikoRisc0Verifier
- update the trusted image ids TaikoDAOController
- Can interact with SgxVerifier
- can add new instances without a DCAP attestation TaikoDAOController
- Can interact with AutomataDcapV3Attestation
- can update the program being verified TaikoDAOController
- Can interact with AutomataDcapV3Attestation
- can update the program being verified TaikoDAOController
- Can interact with TaikoSP1Verifier
- manage trusted program hashes TaikoDAOController
- Can interact with SgxVerifier
- can add new instances without a DCAP attestation TaikoDAOController
- Can interact with ProverWhitelist
- manage the prover whitelist TaikoDAOController
- Can interact with L1SharedAddressManager
- can update the contract address for a given name TaikoDAOController
- Can interact with PreconfWhitelist
- pause/unpause, manage operator and ejector roles TaikoDAOController
A Multisig with 2/4 threshold.
- Can upgrade with no delay
- MainnetInbox
- Can interact with MainnetInbox
- pause and unpause the rollup system
A Multisig with 4/6 threshold.
- Can interact with ProverWhitelist
- manage the prover whitelist
- Can interact with PreconfWhitelist
- manage the ejecter role
A Multisig with 2/3 threshold.
- A Sequencer - acting directly
- 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 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
Taiko Alethia
Actors:
- Can interact with SignalService
- pause and unpause proofs and verification
Ethereum
Gating router contract to verify batches using RISC Zero.
- Roles:
- owner: TaikoDAOController; ultimately DAO
Gating router contract to verify batches using SP1.
- Roles:
- owner: TaikoDAOController; ultimately DAO
Enforces the Taiko Multiprover policy and routes to the downstream router contracts.
Defines the whitelist of addresses allowed to prove proposals. Non-whitelisted provers must wait for the permissionless proving delay before they can submit proofs.
- Roles:
- admin: TaikoDAOController; ultimately DAO
- owner: TaikoDAOController; ultimately DAO
- proverManager: Taiko Multisig
Shared vault for Taiko chains for bridged ERC20 tokens.
- Roles:
- admin: TaikoDAOController; ultimately DAO
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
- owner: DAO
Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.
- Roles:
- admin: DAO
- owner: DAO
A timelock with access control. The current minimum delay is 3d.
- Roles:
- canceller: EOA 3
- defaultAdmin: TimelockController; ultimately EOA 3
- executor: EOA 3
- proposer: EOA 3
A signer list for registering agents, similar to a Multisig.
Contract managing SGX attestation certificates.
- Roles:
- admin: TaikoDAOController; ultimately DAO
- owner: TaikoDAOController; ultimately DAO
ERC20 contract implementing the TAIKO token. It defines a list of addresses designated as non-voting.
- Roles:
- admin: TaikoDAOController; ultimately DAO
Modular Governance contract allowing for proposing, voting on and executing encrypted proposals (e.g. for Security Council emergency proposals).
A registry for signers (of the Security Council) to appoint agents to operate on their behalf. These agents can also register their encryption keys for encrypted emergency proposal support.
Contract managing SGX attestation certificates.
- Roles:
- admin: TaikoDAOController; ultimately DAO
- owner: TaikoDAOController; ultimately DAO
A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (TimelockController).
- Roles:
- owner: TimelockController; ultimately EOA 3
Defines withdrawal limits per token.
- Roles:
- admin: TaikoDAOController; ultimately DAO
An optimistic governance module. Proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d.
Facilitates secure cross-chain message passing by storing signals (messages) and state root checkpoints. It allows applications to prove that a specific L2 signal or state transition occurred via Merkle proofs.
Shared bridge for Taiko chains for bridged ETH.
- Roles:
- admin: TaikoDAOController; ultimately DAO
Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security Council standard proposals).
Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.
- Roles:
- admin: TaikoDAOController; ultimately DAO
- owner: TaikoDAOController; ultimately DAO
Contains the whitelist of addresses allowed to propose batches on L1 and issue preconfirmations. It dynamically selects a single operator for a given epoch using the Ethereum beacon block root as a source of randomness.
- Roles:
- _ejectorManager: Taiko Multisig
- admin: TaikoDAOController; ultimately DAO
- operatorMapping: EOA 1, EOA 2
- owner: TaikoDAOController; ultimately DAO
Taiko Alethia
Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.
- Roles:
- admin: DelegateController
- owner: DelegateController
- Roles:
- admin: DelegateController
Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.
- Roles:
- admin: DelegateController
- owner: DelegateController
Facilitates secure cross-chain message passing by storing signals (messages) and state root checkpoints. It allows applications to prove that a specific L2 signal or state transition occurred via Merkle proofs.
- Roles:
- owner: EOA 4
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).