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 Jun 19 — 2026 Jun 19
The section shows the operating costs that L2s pay to Ethereum.
2025 Jun 19 — 2026 Jun 19
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 — Jun 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 May 20 — Jun 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 7h 28m 12s (from 2026 Jun 05, 13:41 UTC until 2026 Jun 05, 21:10 UTC). These typically occur every 31min 37s on average.
No Tx data submissions were performed for 7h 15m 12s (from 2026 Jun 05, 13:47 UTC until 2026 Jun 05, 21:02 UTC). These typically occur every 6min 28s on average.
No Tx data submissions were performed for 9min 24s (from 2026 Jun 04, 01:57 UTC until 2026 Jun 04, 02:06 UTC). These typically occur every 6min 28s on average.
No Tx data submissions were performed for 10min (from 2026 May 29, 17:44 UTC until 2026 May 29, 17:54 UTC). These typically occur every 6min 28s on average.
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 2 whitelisted provers 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. 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. 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.
Program Hashes
Name | Hash | Repository | Verification | Used in | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x0026...06e7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x137f...06e7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x008e...bfe7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x4712...bfe7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0079...82f8 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x3cb4...82f8 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0002...0c7c | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0156...0c7c | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0033...dff1 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x19f1...dff1 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x009d...e540 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x4e93...e540 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x779c...2544 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x26ab...cee7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x46ef...727b | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0xdfbc...039e | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0xbee1...5f92 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0xcecc...2249 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 create a Standard proposal. It is delayed while being publicly auditable by 7d in the OptimisticTokenVotingPlugin contract and can be vetoed by 10% of votable TAIKO tokens during that time. If not vetoed, the standard proposal passes and 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.
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
2026 June 16, 09:48 UTCHigh severity2changesPropose 'Enable SP1 v6 on mainnet': new programhashes.
Propose ‘Enable SP1 v6 on mainnet’: new programhashes.
| 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: | |
| - | 20 |
| + | 21 |
| } |
2026 June 10, 14:36 UTCHigh severity6changesAdd raiko2 images, proposal https://dao.taiko.xyz/plugins/community-proposals/ /proposals/30 , all regenerated.
Add raiko2 images, proposal https://dao.taiko.xyz/plugins/community-proposals/#/proposals/30 , all regenerated.
| 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.4: | |
| + | "0xbee1be4cbe2bdf9b0034a1ab6572061a76019e73189ff96322e58ab229b75f92" |
| +++ 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.5: | |
| + | "0xcecc85819e15d173c2991577727525b136e820728f7aaaede612f1281cac2249" |
| } |
| contract TaikoSP1Verifier (eth:0x96337327648dcFA22b014009cf10A2D5E2F305f6) [taiko/SP1Verifier] { | |
| +++ description: Gating router contract to verify batches using SP1. | |
| +++ description: Taiko specific Image IDs (i.e. program digest) of SP1 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.trustedPrograms.8: | |
| + | "0x0033e2cccc3296e7def7b381a4fb96fafec64f45420b6d24686779ef6236dff1" |
| +++ description: Taiko specific Image IDs (i.e. program digest) of SP1 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.trustedPrograms.9: | |
| + | "0x19f166660ca5b9f75ef670344fb96faf76327a2a082db49150cef3de6236dff1" |
| +++ description: Taiko specific Image IDs (i.e. program digest) of SP1 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.trustedPrograms.10: | |
| + | "0x009d26a03d10b4e70eef6a339187c258a7701d6a0150524684cb46b56cf9e540" |
| +++ description: Taiko specific Image IDs (i.e. program digest) of SP1 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.trustedPrograms.11: | |
| + | "0x4e93501e442d39c35ded4672187c258a3b80eb500541491a09968d6a6cf9e540" |
| } |
2026 June 02, 13:03 UTC2changesOperator rotation.
Operator rotation.
| contract PreconfWhitelist (eth:0xFD019460881e6EeC632258222393d5821029b2ac) [taiko/PreconfWhitelist] { | |
| +++ description: 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. | |
| values.operatorMapping.1: | |
| - | "eth:0x000cb000E880A92a8f383D69dA2142a969B93DE7" |
| values.operatorMapping.2: | |
| + | "eth:0x000cb000E880A92a8f383D69dA2142a969B93DE7" |
| } |
2026 May 28, 10:13 UTC12changesEOA removed from the Risc0 timelock accessControl (Multisig remains). One SC signer changed their local ms signer.
EOA removed from the Risc0 timelock accessControl (Multisig remains). One SC signer changed their local ms signer.
| 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:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.accessControl.CANCELLER_ROLE.members.0: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.accessControl.EXECUTOR_ROLE.members.0: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.Canceller.0: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.Executor.0: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| values.Proposer.0: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } |
| contract Taiko Multisig (eth:0x9CBeE534B5D8a6280e01a14844Ee8aF350399C7F) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.4: | |
| - | "eth:0x0F026a3efE44E0Fe34B87375EFe69b16c05D0438" |
| + | "eth:0xF28C8D6b44361255FA7C116d09ccD5F914398C10" |
| } |
| contract Gustavo Gonzalez Taiko (eth:0xb47fE76aC588101BFBdA9E68F66433bA51E8029a) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.3: | |
| - | "eth:0x30bc4C0Baf55A37Ccf2d626Bc592bd7715b75De2" |
| + | "eth:0xF28C8D6b44361255FA7C116d09ccD5F914398C10" |
| } |
| contract ProverWhitelist (eth:0xEa798547d97e345395dA071a0D7ED8144CD612Ae) [taiko/ProverWhitelist] { | |
| +++ description: Defines the whitelist of addresses allowed to prove proposals. Non-whitelisted provers must wait for the permissionless proving delay before they can submit proofs. | |
| values.proverCount: | |
| - | 1 |
| + | 2 |
| } |
2026 May 21, 09:20 UTC4changesRisc0 emergency stop moved from EOA to multisig.
Risc0 emergency stop moved from EOA to multisig.
| contract Safe (eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609) [GnosisSafe] { | |
| +++ description: None | |
| receivedPermissions.5: | |
| + | {"permission":"interact","from":"eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696","description":"pause the verifier.","role":".owner"} |
| } |
| 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.owner: | |
| - | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| + | "eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609" |
| } |
| EOA (eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412) { | |
| +++ description: None | |
| receivedPermissions.5: | |
| - | {"permission":"interact","from":"eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696","description":"pause the verifier.","role":".owner"} |
| } |
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 3 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 2 whitelisted provers.
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
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
- QuotaManager 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
- L1SharedAddressManager 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
- Bridge DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- ERC20Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- SignalService DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- L2AddressManager DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Anchor DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- DelegateController DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Can interact with TaikoRisc0Verifier
- update the trusted image ids with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with SgxVerifier
- can add new instances without a DCAP attestation 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
- can update the program being verified 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 MainnetInbox
- pause and unpause the rollup system with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with AutomataDcapV3Attestation
- can update the program being verified with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with TaikoSP1Verifier
- manage trusted program hashes 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 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 SignalService
- pause and unpause proofs and verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with SgxVerifier
- can add new instances without a DCAP attestation with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- 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 L1SharedAddressManager
- can update the contract address for a given name with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with PreconfWhitelist
- pause/unpause, manage operator and ejector roles with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with SignalService
- pause and unpause proofs and verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Can interact with L2AddressManager
- can update the contract address for a given name with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
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 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. It manages bonds, validates batch parameters, and acts as the state machine for the L2.
- 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)
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 SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
- proverManager: Taiko Multisig
Shared vault for Taiko chains for bridged ERC20 tokens.
- Roles:
- admin: TaikoDAOController; 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. 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
Verifier contract for SGX proven blocks.
- Roles:
- owner: TaikoDAOController; ultimately SignerList (Security Council)
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 attestation certificates.
- 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)
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 attestation certificates.
- 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
Defines withdrawal limits per token.
- Roles:
- admin: 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 (messages) and state root checkpoints. It allows applications like the bridge escrows to prove that a specific L1<->L2 signal or state transition occurred via Merkle proofs.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
Verifier contract for SGX proven blocks.
- Roles:
- owner: TaikoDAOController; ultimately SignerList (Security Council)
Shared bridge escrow for Taiko chains for bridged ETH.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
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)
Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security Council)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
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 SignerList (Security Council)
- ejecters: EOA 2, EOA 4
- operatorMapping: EOA 1, EOA 5, EOA 7
- owner: TaikoDAOController; ultimately SignerList (Security Council)
Taiko Alethia
Middleware contract that can maintain ownership of DAO-controlled assets and contracts. It can only be invoked by the TaikoDAOController on L1 through the L2 bridge.
- Roles:
- admin: DelegateController; ultimately SignerList (Security Council)
- daoController: TaikoDAOController
Bridge escrow holding preminted ETH on Taiko.
- Roles:
- admin: DelegateController; ultimately SignerList (Security Council)
Escrow for L2-native tokens sent to L1 via the canonical bridge.
- Roles:
- admin: DelegateController; ultimately SignerList (Security Council)
Facilitates secure cross-chain message passing by storing signals (messages) and state root checkpoints. It allows applications like the bridge escrows to prove that a specific L1<->L2 signal or state transition occurred via Merkle proofs.
- Roles:
- admin: DelegateController; ultimately SignerList (Security Council)
- owner: DelegateController; ultimately SignerList (Security Council)
Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.
- Roles:
- admin: DelegateController; ultimately SignerList (Security Council)
- owner: DelegateController; ultimately SignerList (Security Council)
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).
Program Hashes
Name | Hash | Repository | Verification | Used in | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x0026...06e7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x137f...06e7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x008e...bfe7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x4712...bfe7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0079...82f8 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x3cb4...82f8 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0002...0c7c | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0156...0c7c | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0033...dff1 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x19f1...dff1 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x009d...e540 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x4e93...e540 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x779c...2544 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x26ab...cee7 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x46ef...727b | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0xdfbc...039e | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0xbee1...5f92 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0xcecc...2249 | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||