Search
Search for projects and tokens by name or address
Taiko AlethiaTaiko Alethia
There are impactful changes and part of the information might be outdated.
Badges
About
Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko combines a preconfirmation-based sequencing mechanism with a multi-proof system using SP1, RISC0 and TEEs.
- Compromising ≥75% of the Security Council should be the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window.
Badges
About
Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko combines a preconfirmation-based sequencing mechanism with a multi-proof system using SP1, RISC0 and TEEs.
The section shows the operating costs that L2s pay to Ethereum.
This section shows how much data the project publishes to Ethereum over time. It leaves out data posted to other data-availability (DA) layers. The project currently posts data to
Ethereum.
This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.
Last 30 day anomalies
All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.
No State updates were performed for 3h 19m (from 2026 Oct 15, 15:43 UTC until 2026 Oct 15, 19:03 UTC). These typically occur every 1m 39s on average.
No Tx data submissions were performed for 23m 36s (from 2026 Sep 24, 08:12 UTC until 2026 Sep 24, 08:35 UTC). These typically occur every 56s on average.
No Tx data submissions were performed for 9m 48s (from 2026 Sep 24, 08:02 UTC until 2026 Sep 24, 08:11 UTC). These typically occur every 56s 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 56s 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 39s on average.
Bridge recalls disabled
2026 Oct 12th
Failed bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. messages must be retried successfully, with no source-chain refund path.
Unzen upgrade: validity rollup
2026 Aug 3rd
Every proven proposal range now requires at least one SP1 or RISC0 validity proofThe output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed..
Funds can be stolen if
Funds can be frozen if
Users can be censored if
MEV can be extracted if
Users can submit transactions to an L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. queue, but can’t force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone. An inclusion becomes due after 9m 36s. From then on, a whitelisted proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. cannot publish another proposal without processing up to ten due inclusions.
Every proposal range is verified by exactly two proofs chosen from SGX (Geth), SGX (Reth), SP1 and RISC0, with at least one SP1 or RISC0 proof required. Proof submission is gated by ProverWhitelist, which has 2 whitelisted provers. This can affect livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. but does not allow finalizing invalid state.
All of the data needed for proof construction is published on Ethereum L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
Only the whitelisted proposers can publish state rootsA cryptographic hash succinctly representing a state using a Merkle tree. on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., so in the event of failure the withdrawals are frozen. Proposing is gated by PreconfWhitelist, which selects a single active operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. for the current epoch and has no permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. 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 blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. This ensures that it will be available for enough time.
EthereumTaiko uses a multi-proof systemA rollup settlement concept that relies on a combination of multiple different proving systems. For example, a combination of fraud proof and validity proof. The goal is to reduce reliance on a single system-type or implementation. A more complex example of a multi-proof system: if anyone submits two conflicting state roots to a prover and both roots pass, that prover is turned off. to validate state transitions. Exactly two proofs are required from four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. At least one proof must come from SP1 or RISC0: accepted combinations are either SGX verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. 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 permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. proving delay is not used to open proving. MainnetInbox currently sets minBond=0 and livenessBond=0.
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
Used in |
Taiko Alethia has a governance structure relying primarily on a 4/5 Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., checked by a token DAO that is limited to veto permissions. The closed operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. whitelists are managed by the 4/6 Taiko Multisig and related EOAs. Governance proposals (both paths) hold all important upgrade and config permissions in the system.
Standard proposals
A threshold of 3 approving Security Council members is required to forward a Standard proposal to the 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 4 Security Council members, they can be immediately decrypted and executed.
Proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. and operators
A separate 2/5 Safe controls shared RISC0 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. routes through a 3d timelock. It can also freeze RISC0 verifiers immediately. Operator roles (sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs., proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.) are closed and the whitelist is managed by the Taiko Multisig and related EOAs.
Governance profile
Security Council
| Composition | 3/5 standard · 4/5 emergency — 5-member signer set shared by custom Aragon OSx standard and emergency multisig plugins. Members were appointed by the Taiko team rather than elected and include the Taiko Labs multisig and a Taiko co-founder. Members can appoint EOA agents to act for them. |
|---|---|
| Members public | Mapped — Taiko publishes a member wallet-to-entity mapping. The 5 current onchain members are Sebastian Kugler, Aragon, Taiko Labs, Gustavo Gonzalez, Daniel Wang. Gustavo Gonzalez and Daniel Wang sign as plain EOAs rather than multisigs. Each member wallet is mapped to its voting agent onchain. |
| Charter | No public charter — the DAO values define the council’s security mission and principles, while the proposal guidelines restrict emergency proposals to protocol-security and integrity matters. Council selection, terms, conflicts, and accountability are not defined in a public charter. |
| Can bypass DAO? | Yes, for emergencies — 4 Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. approvals execute an encrypted proposal immediately, with no TAIKO-holder veto or delay. Standard proposals require 3 approvals and remain vetoable. The council controls most core upgrades but no longer has permissions over Treasury funds. |
| DAO can override SC? | No — 10% of eligible TAIKO can blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. a standard proposal but never an emergency one. Token holders cannot create proposals, approve payloads, remove council members, or block emergency proposals; changing the signer list requires another council-approved proposal. |
Upgrades
| Normal upgrade path | Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. member creates a public executable payload → 3 council approvals → 10d token-holder veto period → if less than 10% of eligible TAIKO vetoes, 7d timelock → permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execution of the approved onchain actions. |
|---|---|
| Emergency upgrade path | 4 Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. approvals, instant — proposal metadata and actions stay encrypted while approvals are collected. A council member decrypts the payload, which is integrity-checked against the approved ciphertext and executed without a token-holder veto or timelock; its contents become public upon execution or expiry. |
| Exit window | 17d standard · 0 emergency — the standard path provides 10d of public vetoing followed by a 7d timelock. Emergency proposals bypass both. |
Token governance
| Governance token |
|
|---|---|
| Voting venue | Taiko DAO for onchain vetoes; proposals and temperature checks are discussed on the Taiko forum. |
| Proposal threshold | No TAIKO threshold — only a Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. member can create an onchain proposal. Community members can submit forum proposals, but a council member must sponsor the idea and supply the executable payload. |
| Quorum | No approval quorum; 10% veto threshold. Standard proposals pass optimistically unless at least 10% of eligible TAIKO at the proposal snapshot vetoes. Unused and undelegated eligible tokens still count in the denominator. |
| Execution model | Council-gated optimistic veto + permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execution. The Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. approves the exact onchain actions. Token holders can only veto; if the threshold is not reached and the 7d timelock expires, anyone can call |
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
Ossification
Contracts our research team classifies as critical form the project's critical perimeter. Its clock starts at the ossification genesis, and every critical change resets it (changes within 24 hours count as one). The ossification score is the share of recorded code-bug exploits whose exploited code was younger than this perimeter is today. Battle-tested exposure is the value secured, summed over that unchanged period.
Discovery updates
2026 October 14, 08:33 UTC5changesRISC Zero verifier owner Safe: ownership transfer of the five RiscZeroVerifierEmergencyStops to an EOA started ( pendingOwner ).
RISC Zero verifier owner Safe: ownership transfer of the five RiscZeroVerifierEmergencyStops to an EOA started (pendingOwner).
| contract RiscZeroVerifierEmergencyStop (eth:0x1efDd13f831ceeEa14940806705A53D3211CD698) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0xafB31f5b70623CDF4b20Ada3f7230916A5A79df9 that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x68dC2cB4e61774873971c499D9b239ec5Ac540E3) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x20ff7C2Cf391a5F096A2Cc181cb41916680f8E97 that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x844D5f01161E3559d36f23d0Aa9E9620949aF782) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x5005aBa3DFf7C940fcc1e48DccCAD611a80eEB85 that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
| contract RiscZeroVerifierEmergencyStop (eth:0xDa8f3de6fBBdb261Ac771B813a578A7aBdA6B2b1) [risc0/RiscZeroVerifierEmergencyStop] { | |
| +++ description: A verifier wrapper for the eth:0x54aCE3ED46529B4d4F3770C8Bad5dDC48717B9bF that allows pausing (emergency stop) the verifier by its owner. | |
| values.pendingOwner: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412" |
| } | |
2026 October 12, 07:16 UTCCritical state change198changesL2 bridges and vaults upgrade. Recalls are disabled, so failed deliveries can strand funds until they succeed (recall proves a message failed on the destination and refunds funds on the source chain). ERC20 deposits add signed permits, and ETH sends receive more gas. The separate RISC0 governance Safe lowers its threshold from 3/5 to 2/5. - L1 Bridge, first upgrade - L1 Bridge, second upgrade - L1 ERC20Vault, first upgrade - L1 ERC20Vault, second upgrade - L2 Bridge, first upgrade - L2 Bridge, second upgrade - L2 ERC20Vault, first upgrade - L2 ERC20Vault, second upgrade - L1 ERC721Vault - L1 ERC1155Vault - L2 ERC721Vault - L2 ERC1155Vault - L2 resolver replacement - L1 NFT resolver replacement - L1 default ERC20 - L1 default ERC721 - L1 default ERC1155 - L2 default ERC20 - L2 default ERC721 - L2 default ERC1155
L2 bridges and vaults upgrade. Recalls are disabled, so failed deliveries can strand funds until they succeed (recall proves a message failed on the destination and refunds funds on the source chain). ERC20 deposits add signed permits, and ETH sends receive more gas. The separate RISC0 governance Safe lowers its threshold from 3/5 to 2/5.
- L1 Bridge, first upgrade
- L1 Bridge, second upgrade
- L1 ERC20Vault, first upgrade
- L1 ERC20Vault, second upgrade
- L2 Bridge, first upgrade
- L2 Bridge, second upgrade
- L2 ERC20Vault, first upgrade
- L2 ERC20Vault, second upgrade
- L1 ERC721Vault
- L1 ERC1155Vault
- L2 ERC721Vault
- L2 ERC1155Vault
- L2 resolver replacement
- L1 NFT resolver replacement
- L1 default ERC20
- L1 default ERC721
- L1 default ERC1155
- L2 default ERC20
- L2 default ERC721
- L2 default ERC1155
| contract ERC721Vault (eth:0x0b470dd3A0e1C41228856Fb319649E7c08f419Aa) [taiko/ERC721Vault] { | |
| +++ description: Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault. | |
| name: | |
| - | "MainnetERC721Vault" |
| + | "ERC721Vault" |
| sourceHashes.1: | |
| - | "0x18fe27b80aff596fa58d3499fbe1ac44e8bd72cdc9ce0942afb53c5d9caa4b6e" |
| + | "0x783ac50fedc4522f4b68132d77dbab84b7738869e0c79eccc12ecca89e33be01" |
| values.$implementation: | |
| - | "eth:0xA4C5c20aB33C96B1c281Dca37D03E23609274C49" |
| + | "eth:0x611f3Dc278A14b6ED14410Cd9d56E1721cf33802" |
| values.$pastUpgrades.6: | |
| + | ["2026-10-12T01:04:35.000Z","0x935e4a93cf26e7bef2ac3c445815e253496d82d51e4205e7073a3d511a9111f4",["eth:0x611f3Dc278A14b6ED14410Cd9d56E1721cf33802"]] |
| values.$upgradeCount: | |
| - | 6 |
| + | 7 |
| values.addressManager: | |
| - | "eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa" |
| values.impl: | |
| - | "eth:0xA4C5c20aB33C96B1c281Dca37D03E23609274C49" |
| + | "eth:0x611f3Dc278A14b6ED14410Cd9d56E1721cf33802" |
| values.lastUnpausedAt: | |
| - | 0 |
| +++ description: Immutable resolver selecting trusted bridge and vault counterparties and default token implementations. | |
| values.resolver: | |
| + | "eth:0x8Efa01564425692d0a0838DC10E300BD310Cb43e" |
| errors: | |
| - | {"proxiableUUID":"Processing error occurred."} |
| implementationNames.eth:0xA4C5c20aB33C96B1c281Dca37D03E23609274C49: | |
| - | "MainnetERC721Vault" |
| implementationNames.eth:0x611f3Dc278A14b6ED14410Cd9d56E1721cf33802: | |
| + | "ERC721Vault" |
| template: | |
| + | "taiko/ERC721Vault" |
| description: | |
| + | "Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault." |
| critical: | |
| + | true |
| fieldMeta: | |
| + | {"owner":{"severity":"MEDIUM"},"pendingOwner":{"severity":"MEDIUM"},"paused":{"severity":"MEDIUM"},"resolver":{"description":"Immutable resolver selecting trusted bridge and vault counterparties and default token implementations."}} |
| } | |
| 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. | |
| receivedPermissions.1: | |
| + | {"permission":"interact","from":"eth:0x0b470dd3A0e1C41228856Fb319649E7c08f419Aa","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.9: | |
| - | {"permission":"interact","from":"eth:0x91f67118DD47d502B1f0C354D0611997B022f29E","description":"update token withdrawal quotas and the quota refill period.","role":".owner","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.11.description: | |
| - | "pause and unpause token bridge flows and change the bridged token implementation for a canonical token after the migration delay." |
| + | "pause and unpause token flows and change a canonical token's bridged representation after the migration delay." |
| receivedPermissions.15: | |
| + | {"permission":"interact","from":"eth:0xaf145913EA4a56BE22E120ED9C24589659881702","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.15.description: | |
| - | "pause and unpause bridge message flows and execute one-time bridge recovery initializers." |
| + | "pause and unpause bridge flows and run one-time message recovery initializers." |
| receivedPermissions.18: | |
| - | {"permission":"interact","from":"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa","description":"can update the contract address for a given name","role":".owner","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.20: | |
| + | {"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000001","description":"pause and unpause bridge flows and run one-time message recovery initializers.","role":".owner","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.21: | |
| + | {"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000002","description":"pause and unpause token flows and change a canonical token's bridged representation after the migration delay.","role":".owner","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.22: | |
| + | {"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000003","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.23: | |
| + | {"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000004","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.21.description: | |
| - | "can update the contract address for a given name" |
| + | "update the contract address registered for any chainId-name pair." |
| receivedPermissions.21.from: | |
| - | "taiko:0x1670000000000000000000000000000000000006" |
| + | "taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984" |
| receivedPermissions.29: | |
| - | {"permission":"upgrade","from":"eth:0x91f67118DD47d502B1f0C354D0611997B022f29E","role":"admin","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.36: | |
| - | {"permission":"upgrade","from":"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa","role":"admin","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.44: | |
| - | {"permission":"upgrade","from":"taiko:0x1670000000000000000000000000000000000006","role":"admin","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| receivedPermissions.47: | |
| + | {"permission":"upgrade","from":"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984","role":"admin","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]} |
| } | |
| contract Safe (eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.3: | |
| - | "eth:0xd5D43445d0227a47cA2eACCb9392352746eD9926" |
| + | "eth:0x9a017883e4A6BB2a6261D92D70f71107F2C39D12" |
| values.$threshold: | |
| - | 3 |
| + | 2 |
| values.multisigThreshold: | |
| - | "3 of 5 (60%)" |
| + | "2 of 5 (40%)" |
| } | |
| contract TaikoDAOController (eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a) [taiko/TaikoDAOController] { | |
| +++ description: Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum. | |
| directlyReceivedPermissions.2: | |
| + | {"permission":"interact","from":"eth:0x0b470dd3A0e1C41228856Fb319649E7c08f419Aa","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner"} |
| directlyReceivedPermissions.8: | |
| - | {"permission":"interact","from":"eth:0x91f67118DD47d502B1f0C354D0611997B022f29E","description":"update token withdrawal quotas and the quota refill period.","role":".owner"} |
| directlyReceivedPermissions.9.description: | |
| - | "pause and unpause token bridge flows and change the bridged token implementation for a canonical token after the migration delay." |
| + | "pause and unpause token flows and change a canonical token's bridged representation after the migration delay." |
| directlyReceivedPermissions.12: | |
| + | {"permission":"interact","from":"eth:0xaf145913EA4a56BE22E120ED9C24589659881702","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner"} |
| directlyReceivedPermissions.12.description: | |
| - | "pause and unpause bridge message flows and execute one-time bridge recovery initializers." |
| + | "pause and unpause bridge flows and run one-time message recovery initializers." |
| directlyReceivedPermissions.14: | |
| - | {"permission":"interact","from":"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa","description":"can update the contract address for a given name","role":".owner"} |
| directlyReceivedPermissions.22: | |
| - | {"permission":"upgrade","from":"eth:0x91f67118DD47d502B1f0C354D0611997B022f29E","role":"admin"} |
| directlyReceivedPermissions.28: | |
| - | {"permission":"upgrade","from":"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa","role":"admin"} |
| } | |
| contract DefaultResolver (eth:0x8Efa01564425692d0a0838DC10E300BD310Cb43e) [taiko/DefaultResolver] { | |
| +++ description: 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. | |
| values.namedAddresses.10.address: | |
| - | "eth:0x65666141a541423606365123Ed280AB16a09A2e1" |
| + | "eth:0x9ccB9eBa4335096c5B64f050C3c734632D497c3b" |
| values.namedAddresses.11.address: | |
| - | "eth:0xC3310905E2BC9Cfb198695B75EF3e5B69C6A1Bf7" |
| + | "eth:0xD9c9dB7519011437C54BCD32495c0347A410bc4D" |
| values.namedAddresses.12.address: | |
| - | "eth:0x3c90963cFBa436400B0F9C46Aa9224cB379c2c40" |
| + | "eth:0x35001aB6f53CF9fE583653Ca3F56cae75E8C385e" |
| } | |
| - | Status: DELETED |
| contract QuotaManager (eth:0x91f67118DD47d502B1f0C354D0611997B022f29E) [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. | |
| contract ERC20Vault (eth:0x996282cA11E5DEb6B5D122CC3B9A1FcAAD4415Ab) [taiko/ERC20Vault] { | |
| +++ description: Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridge controls access to the refund callback. | |
| name: | |
| - | "MainnetERC20Vault" |
| + | "ERC20Vault" |
| template: | |
| - | "taiko/SharedERC20Vault" |
| + | "taiko/ERC20Vault" |
| sourceHashes.1: | |
| - | "0x9b624be34d3f91047fd5ee6a056fd5d81ed43c3ba757e53661aeb4e4dabfe4aa" |
| + | "0x3a8df12e5f7ee6611bebe6784bc06bdd7ff8cc3c63d230e0260ca7ef9c97ead8" |
| 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." |
| + | "Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridge controls access to the refund callback." |
| values.$implementation: | |
| - | "eth:0x024253C6FDC27d3161aFd43fb0241411A28dDc3c" |
| + | "eth:0xd429A698d19b5789ce6Eb72d8B3ae9fad3b28A92" |
| values.$pastUpgrades.9: | |
| + | ["2026-10-08T07:28:47.000Z","0x17c27b257bb1445a512d4426c962de5c5f4b282f459c7e851c413702ad11d10c",["eth:0x32E47c04E8c329E8c10062731448e7658aDEEB8e"]] |
| values.$pastUpgrades.10: | |
| + | ["2026-10-12T01:04:35.000Z","0x935e4a93cf26e7bef2ac3c445815e253496d82d51e4205e7073a3d511a9111f4",["eth:0xd429A698d19b5789ce6Eb72d8B3ae9fad3b28A92"]] |
| values.$upgradeCount: | |
| - | 9 |
| + | 11 |
| values.impl: | |
| - | "eth:0x024253C6FDC27d3161aFd43fb0241411A28dDc3c" |
| + | "eth:0xd429A698d19b5789ce6Eb72d8B3ae9fad3b28A92" |
| values.proxiableUUID: | |
| - | "EXPECT_REVERT" |
| values.PERMIT2: | |
| + | "eth:0x000000000022D473030F116dDEE9F6B43aC78BA3" |
| fieldMeta.quotaManager.description: | |
| - | "Quota manager that rate-limits ERC20 tokens released or minted by this vault." |
| + | "Immutable quota manager limiting successful token deliveries. Refunds consume no quota. The zero address disables quotas." |
| fieldMeta.btokenDenylist.description: | |
| - | "Bridged tokens denied by migration logic. Denied tokens cannot be sent through the vault." |
| + | "Bridged tokens excluded from sends by token migration logic." |
| fieldMeta.owner: | |
| + | {"severity":"MEDIUM"} |
| fieldMeta.pendingOwner: | |
| + | {"severity":"MEDIUM"} |
| fieldMeta.resolver: | |
| + | {"description":"Immutable registry resolving the bridge, counterpart vaults and default bridged token implementation."} |
| implementationNames.eth:0x024253C6FDC27d3161aFd43fb0241411A28dDc3c: | |
| - | "MainnetERC20Vault" |
| implementationNames.eth:0xd429A698d19b5789ce6Eb72d8B3ae9fad3b28A92: | |
| + | "ERC20Vault" |
| } | |
| contract Taiko Multisig (eth:0x9CBeE534B5D8a6280e01a14844Ee8aF350399C7F) [GnosisSafe] { | |
| +++ description: None | |
| receivedPermissions.4.description: | |
| - | "pause and unpause bridge message flows and fund the bridge through direct ETH transfers." |
| + | "pause and unpause bridge flows and fund the bridge through direct ETH transfers." |
| } | |
| contract ERC1155Vault (eth:0xaf145913EA4a56BE22E120ED9C24589659881702) [taiko/ERC1155Vault] { | |
| +++ description: Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault. | |
| name: | |
| - | "MainnetERC1155Vault" |
| + | "ERC1155Vault" |
| sourceHashes.1: | |
| - | "0x4493f2ac281fab06a2ac9a899815cfeb485eb5f3c813020f91d6091bb85f101b" |
| + | "0xf2cbbe079d267fc8e34c5014c14f0dd4269da004cf9c1dc223ac4cb9ec351163" |
| values.$implementation: | |
| - | "eth:0x838ed469db456b67EB3b0B74D759Be4DA999b9c8" |
| + | "eth:0xca775D0Bb8CEFe388E344f75De91Aebd0E73c58E" |
| values.$pastUpgrades.6: | |
| + | ["2026-10-12T01:04:35.000Z","0x935e4a93cf26e7bef2ac3c445815e253496d82d51e4205e7073a3d511a9111f4",["eth:0xca775D0Bb8CEFe388E344f75De91Aebd0E73c58E"]] |
| values.$upgradeCount: | |
| - | 6 |
| + | 7 |
| values.addressManager: | |
| - | "eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa" |
| values.impl: | |
| - | "eth:0x838ed469db456b67EB3b0B74D759Be4DA999b9c8" |
| + | "eth:0xca775D0Bb8CEFe388E344f75De91Aebd0E73c58E" |
| values.lastUnpausedAt: | |
| - | 0 |
| +++ description: Immutable resolver selecting trusted bridge and vault counterparties and default token implementations. | |
| values.resolver: | |
| + | "eth:0x8Efa01564425692d0a0838DC10E300BD310Cb43e" |
| errors: | |
| - | {"proxiableUUID":"Processing error occurred."} |
| implementationNames.eth:0x838ed469db456b67EB3b0B74D759Be4DA999b9c8: | |
| - | "MainnetERC1155Vault" |
| implementationNames.eth:0xca775D0Bb8CEFe388E344f75De91Aebd0E73c58E: | |
| + | "ERC1155Vault" |
| template: | |
| + | "taiko/ERC1155Vault" |
| description: | |
| + | "Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault." |
| critical: | |
| + | true |
| fieldMeta: | |
| + | {"owner":{"severity":"MEDIUM"},"pendingOwner":{"severity":"MEDIUM"},"paused":{"severity":"MEDIUM"},"resolver":{"description":"Immutable resolver selecting trusted bridge and vault counterparties and default token implementations."}} |
| } | |
| contract Bridge (eth:0xd60247c6848B7Ca29eDdF63AA924E53dB6Ddd8EC) [taiko/Bridge] { | |
| +++ description: Bridge escrow for ETH and cross-chain messages. Pausing stops all message flows. The immutable recallEnabled setting controls failed-message refunds. Successful ETH releases use the configured quota manager. | |
| name: | |
| - | "MainnetBridge" |
| + | "Bridge" |
| template: | |
| - | "taiko/TaikoBridge" |
| + | "taiko/Bridge" |
| sourceHashes.1: | |
| - | "0x61b87867a3f041292eb5da7940c9fc5d33aee32c063a7cf1696beb6eafac4a2b" |
| + | "0x765f8d75f0a63f536ea3c68dd988c86a2d844ec6fb08baeabbe309578bb04a01" |
| 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." |
| + | "Bridge escrow for ETH and cross-chain messages. Pausing stops all message flows. The immutable recallEnabled setting controls failed-message refunds. Successful ETH releases use the configured quota manager." |
| values.$implementation: | |
| - | "eth:0x1c94D798CFA08F396E5BA9F81697289c53273381" |
| + | "eth:0xe6BF63dCc936063caD2300f32DaA67d9eE5c57b6" |
| values.$pastUpgrades.13: | |
| + | ["2026-10-08T07:28:47.000Z","0x17c27b257bb1445a512d4426c962de5c5f4b282f459c7e851c413702ad11d10c",["eth:0xA15dca0A72da684f20e0FC708DECFb230a715462"]] |
| values.$pastUpgrades.14: | |
| + | ["2026-10-12T01:04:35.000Z","0x935e4a93cf26e7bef2ac3c445815e253496d82d51e4205e7073a3d511a9111f4",["eth:0xe6BF63dCc936063caD2300f32DaA67d9eE5c57b6"]] |
| values.$upgradeCount: | |
| - | 13 |
| + | 15 |
| values.impl: | |
| - | "eth:0x1c94D798CFA08F396E5BA9F81697289c53273381" |
| + | "eth:0xe6BF63dCc936063caD2300f32DaA67d9eE5c57b6" |
| values.proxiableUUID: | |
| - | "EXPECT_REVERT" |
| +++ description: Immutable switch controlling failMessage, recallMessage and the failed branch of retryMessage. When false, failed deliveries must succeed on retry to release their funds. | |
| values.recallEnabled: | |
| + | false |
| fieldMeta.quotaManager.description: | |
| - | "Quota manager that rate-limits ETH released by processed or recalled bridge messages." |
| + | "Immutable quota manager limiting successful ETH releases. The zero address disables quotas." |
| fieldMeta.signalService.description: | |
| - | "Signal service used to prove cross-chain message delivery and failure signals." |
| + | "Immutable signal service proving cross-chain message delivery and failure signals." |
| fieldMeta.owner: | |
| + | {"severity":"MEDIUM"} |
| fieldMeta.pendingOwner: | |
| + | {"severity":"MEDIUM"} |
| fieldMeta.recallEnabled: | |
| + | {"description":"Immutable switch controlling failMessage, recallMessage and the failed branch of retryMessage. When false, failed deliveries must succeed on retry to release their funds."} |
| fieldMeta.resolver: | |
| + | {"description":"Immutable registry resolving the trusted counterpart bridge on each chain."} |
| implementationNames.eth:0x1c94D798CFA08F396E5BA9F81697289c53273381: | |
| - | "MainnetBridge" |
| implementationNames.eth:0xe6BF63dCc936063caD2300f32DaA67d9eE5c57b6: | |
| + | "Bridge" |
| } | |
| - | Status: DELETED |
| contract L1SharedAddressManager (eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa) [taiko/L1SharedAddressManager] | |
| +++ description: Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades. | |
| EOA (taiko:0x0000000000000000000000000000000000000000) { | |
| +++ description: None | |
| receivedPermissions: | |
| + | [{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000001","description":"pause and unpause bridge flows and fund the bridge through direct ETH transfers.","role":".pauser"}] |
| } | |
| contract Bridge (taiko:0x1670000000000000000000000000000000000001) [taiko/Bridge] { | |
| +++ description: Bridge escrow holding preminted ETH on Taiko. Failed messages remain retryable, but message failure and source-chain refunds are disabled. | |
| template: | |
| - | "taiko/L2Bridge" |
| + | "taiko/Bridge" |
| sourceHashes.1: | |
| - | "0xfada2b71cfef6dfc63b33a9681baa712699f12de05eaf91f635ed3387a304791" |
| + | "0x765f8d75f0a63f536ea3c68dd988c86a2d844ec6fb08baeabbe309578bb04a01" |
| values.$implementation: | |
| - | "taiko:0x95ae2918dcbc6aFF8B4c1F1BCC1bf819b6e08B83" |
| + | "taiko:0xF372Db3F06AcaB3347697866d2047a54D1BA8eB3" |
| values.$pastUpgrades.8: | |
| + | ["2026-10-08T07:30:21.000Z","0xc61c925bbc9b815715c6bc009cfcb50c16e93904dc07e799c913953a2b6be095",["taiko:0xa200c2268d77737a8Fd2CA1698dA6eeab2a85CEb"]] |
| values.$pastUpgrades.9: | |
| + | ["2026-10-12T01:07:17.000Z","0xe8c9d02693ed235dce16a36685a7d07f2929b6927054e07be41293cec00d194d",["taiko:0xF372Db3F06AcaB3347697866d2047a54D1BA8eB3"]] |
| values.$upgradeCount: | |
| - | 8 |
| + | 10 |
| values.addressManager: | |
| - | "taiko:0x1670000000000000000000000000000000000006" |
| values.bridgeWatchdog: | |
| - | "taiko:0x0000000000000000000000000000000000000000" |
| values.chainWatchdog: | |
| - | "taiko:0x0000000000000000000000000000000000000000" |
| values.impl: | |
| - | "taiko:0x95ae2918dcbc6aFF8B4c1F1BCC1bf819b6e08B83" |
| + | "taiko:0xF372Db3F06AcaB3347697866d2047a54D1BA8eB3" |
| values.lastUnpausedAt: | |
| - | 0 |
| +++ severity: MEDIUM | |
| values.pauser: | |
| + | "taiko:0x0000000000000000000000000000000000000000" |
| +++ description: Immutable switch controlling failMessage, recallMessage and the failed branch of retryMessage. When false, failed deliveries must succeed on retry to release their funds. | |
| values.recallEnabled: | |
| + | false |
| +++ description: Immutable registry resolving the trusted counterpart bridge on each chain. | |
| values.resolver: | |
| + | "taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984" |
| fieldMeta.addressManager: | |
| - | {"severity":"HIGH"} |
| fieldMeta.signalService.severity: | |
| - | "HIGH" |
| fieldMeta.signalService.description: | |
| + | "Immutable signal service proving cross-chain message delivery and failure signals." |
| fieldMeta.quotaManager.severity: | |
| - | "HIGH" |
| fieldMeta.quotaManager.description: | |
| - | "only relevant if not zero address" |
| + | "Immutable quota manager limiting successful ETH releases. The zero address disables quotas." |
| fieldMeta.chainWatchdog: | |
| - | {"severity":"MEDIUM","description":"only relevant if not zero address"} |
| fieldMeta.bridgeWatchdog: | |
| - | {"severity":"MEDIUM","description":"only relevant if not zero address"} |
| fieldMeta.owner: | |
| + | {"severity":"MEDIUM"} |
| fieldMeta.pauser: | |
| + | {"severity":"MEDIUM"} |
| fieldMeta.recallEnabled: | |
| + | {"description":"Immutable switch controlling failMessage, recallMessage and the failed branch of retryMessage. When false, failed deliveries must succeed on retry to release their funds."} |
| fieldMeta.resolver: | |
| + | {"description":"Immutable registry resolving the trusted counterpart bridge on each chain."} |
| implementationNames.taiko:0x95ae2918dcbc6aFF8B4c1F1BCC1bf819b6e08B83: | |
| - | "Bridge" |
| implementationNames.taiko:0xF372Db3F06AcaB3347697866d2047a54D1BA8eB3: | |
| + | "Bridge" |
| category: | |
| + | {"name":"Shared Infrastructure","priority":4} |
| } | |
| contract ERC20Vault (taiko:0x1670000000000000000000000000000000000002) [taiko/ERC20Vault] { | |
| +++ description: Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridge controls access to the refund callback. | |
| template: | |
| - | "taiko/L2ERC20Vault" |
| + | "taiko/ERC20Vault" |
| sourceHashes.1: | |
| - | "0x9cc2e724dd00141e1e07621839efbb2f8c96ed9f67d6fbe50664ea8b6531c118" |
| + | "0x3a8df12e5f7ee6611bebe6784bc06bdd7ff8cc3c63d230e0260ca7ef9c97ead8" |
| description: | |
| - | "Escrow for L2-native tokens sent to L1 via the canonical bridge." |
| + | "Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridge controls access to the refund callback." |
| values.$implementation: | |
| - | "taiko:0xb96AbB41b01E3ad519D00E80355a1c3801910F62" |
| + | "taiko:0x25D8465fD0C8D89bfdE910E47c41f4E465672B5c" |
| values.$pastUpgrades.4: | |
| + | ["2026-10-08T07:30:21.000Z","0xc61c925bbc9b815715c6bc009cfcb50c16e93904dc07e799c913953a2b6be095",["taiko:0xa01d464ca3982DAa97B19fa7F8a232eB11A9DDb3"]] |
| values.$pastUpgrades.5: | |
| + | ["2026-10-12T01:07:17.000Z","0xe8c9d02693ed235dce16a36685a7d07f2929b6927054e07be41293cec00d194d",["taiko:0x25D8465fD0C8D89bfdE910E47c41f4E465672B5c"]] |
| values.$upgradeCount: | |
| - | 4 |
| + | 6 |
| values.addressManager: | |
| - | "taiko:0x1670000000000000000000000000000000000006" |
| values.impl: | |
| - | "taiko:0xb96AbB41b01E3ad519D00E80355a1c3801910F62" |
| + | "taiko:0x25D8465fD0C8D89bfdE910E47c41f4E465672B5c" |
| values.lastUnpausedAt: | |
| - | 1716811943 |
| values.PERMIT2: | |
| + | "taiko:0x000000000022D473030F116dDEE9F6B43aC78BA3" |
| +++ description: Immutable quota manager limiting successful token deliveries. Refunds consume no quota. The zero address disables quotas. | |
| values.quotaManager: | |
| + | "taiko:0x0000000000000000000000000000000000000000" |
| +++ description: Immutable registry resolving the bridge, counterpart vaults and default bridged token implementation. | |
| values.resolver: | |
| + | "taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984" |
| fieldMeta.addressManager: | |
| - | {"severity":"HIGH"} |
| fieldMeta.owner: | |
| + | {"severity":"MEDIUM"} |
| fieldMeta.resolver: | |
| + | {"description":"Immutable registry resolving the bridge, counterpart vaults and default bridged token implementation."} |
| fieldMeta.quotaManager: | |
| + | {"description":"Immutable quota manager limiting successful token deliveries. Refunds consume no quota. The zero address disables quotas."} |
| fieldMeta.btokenDenylist: | |
| + | {"description":"Bridged tokens excluded from sends by token migration logic."} |
| implementationNames.taiko:0xb96AbB41b01E3ad519D00E80355a1c3801910F62: | |
| - | "ERC20Vault" |
| implementationNames.taiko:0x25D8465fD0C8D89bfdE910E47c41f4E465672B5c: | |
| + | "ERC20Vault" |
| category: | |
| + | {"name":"Shared Infrastructure","priority":4} |
| } | |
| contract ERC721Vault (taiko:0x1670000000000000000000000000000000000003) [taiko/ERC721Vault] { | |
| +++ description: Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault. | |
| sourceHashes.1: | |
| - | "0xdb576f6eacda08057701d15f09fa5c2b615ae34b565d935a56dc43245eb46703" |
| + | "0x783ac50fedc4522f4b68132d77dbab84b7738869e0c79eccc12ecca89e33be01" |
| values.$implementation: | |
| - | "taiko:0xd532f20a4751156C566Da7745db95E7f80145B36" |
| + | "taiko:0x4cAb75DBE321084fD15c7AA9f7398e073A7EaBd0" |
| values.$pastUpgrades.3: | |
| + | ["2026-10-12T01:07:17.000Z","0xe8c9d02693ed235dce16a36685a7d07f2929b6927054e07be41293cec00d194d",["taiko:0x4cAb75DBE321084fD15c7AA9f7398e073A7EaBd0"]] |
| values.$upgradeCount: | |
| - | 3 |
| + | 4 |
| values.addressManager: | |
| - | "taiko:0x1670000000000000000000000000000000000006" |
| values.impl: | |
| - | "taiko:0xd532f20a4751156C566Da7745db95E7f80145B36" |
| + | "taiko:0x4cAb75DBE321084fD15c7AA9f7398e073A7EaBd0" |
| values.lastUnpausedAt: | |
| - | 0 |
| +++ description: Immutable resolver selecting trusted bridge and vault counterparties and default token implementations. | |
| values.resolver: | |
| + | "taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984" |
| errors: | |
| - | {"proxiableUUID":"Processing error occurred."} |
| implementationNames.taiko:0xd532f20a4751156C566Da7745db95E7f80145B36: | |
| - | "ERC721Vault" |
| implementationNames.taiko:0x4cAb75DBE321084fD15c7AA9f7398e073A7EaBd0: | |
| + | "ERC721Vault" |
| template: | |
| + | "taiko/ERC721Vault" |
| description: | |
| + | "Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault." |
| critical: | |
| + | true |
| fieldMeta: | |
| + | {"owner":{"severity":"MEDIUM"},"pendingOwner":{"severity":"MEDIUM"},"paused":{"severity":"MEDIUM"},"resolver":{"description":"Immutable resolver selecting trusted bridge and vault counterparties and default token implementations."}} |
| } | |
| contract ERC1155Vault (taiko:0x1670000000000000000000000000000000000004) [taiko/ERC1155Vault] { | |
| +++ description: Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault. | |
| sourceHashes.1: | |
| - | "0x7325669dd281de5a8bb65da63dfffe0a322aca151892bffa8464934fbfafaa31" |
| + | "0xf2cbbe079d267fc8e34c5014c14f0dd4269da004cf9c1dc223ac4cb9ec351163" |
| values.$implementation: | |
| - | "taiko:0xBBBC4ad39488b990E095042fa6c59A90d3817846" |
| + | "taiko:0xe148CceFFcd5494301c20e047634995C60611e57" |
| values.$pastUpgrades.3: | |
| + | ["2026-10-12T01:07:17.000Z","0xe8c9d02693ed235dce16a36685a7d07f2929b6927054e07be41293cec00d194d",["taiko:0xe148CceFFcd5494301c20e047634995C60611e57"]] |
| values.$upgradeCount: | |
| - | 3 |
| + | 4 |
| values.addressManager: | |
| - | "taiko:0x1670000000000000000000000000000000000006" |
| values.impl: | |
| - | "taiko:0xBBBC4ad39488b990E095042fa6c59A90d3817846" |
| + | "taiko:0xe148CceFFcd5494301c20e047634995C60611e57" |
| values.lastUnpausedAt: | |
| - | 0 |
| +++ description: Immutable resolver selecting trusted bridge and vault counterparties and default token implementations. | |
| values.resolver: | |
| + | "taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984" |
| errors: | |
| - | {"proxiableUUID":"Processing error occurred."} |
| implementationNames.taiko:0xBBBC4ad39488b990E095042fa6c59A90d3817846: | |
| - | "ERC1155Vault" |
| implementationNames.taiko:0xe148CceFFcd5494301c20e047634995C60611e57: | |
| + | "ERC1155Vault" |
| template: | |
| + | "taiko/ERC1155Vault" |
| description: | |
| + | "Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault." |
| critical: | |
| + | true |
| fieldMeta: | |
| + | {"owner":{"severity":"MEDIUM"},"pendingOwner":{"severity":"MEDIUM"},"paused":{"severity":"MEDIUM"},"resolver":{"description":"Immutable resolver selecting trusted bridge and vault counterparties and default token implementations."}} |
| } | |
| - | Status: DELETED |
| contract L2AddressManager (taiko:0x1670000000000000000000000000000000000006) [taiko/L2AddressManager] | |
| +++ description: Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades. | |
| contract DelegateController (taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C) [taiko/DelegateController] { | |
| +++ description: 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. | |
| directlyReceivedPermissions.0: | |
| + | {"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000001","description":"pause and unpause bridge flows and run one-time message recovery initializers.","role":".owner"} |
| directlyReceivedPermissions.1: | |
| + | {"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000002","description":"pause and unpause token flows and change a canonical token's bridged representation after the migration delay.","role":".owner"} |
| directlyReceivedPermissions.2: | |
| + | {"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000003","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner"} |
| directlyReceivedPermissions.3: | |
| + | {"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000004","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner"} |
| directlyReceivedPermissions.1.description: | |
| - | "can update the contract address for a given name" |
| + | "update the contract address registered for any chainId-name pair." |
| directlyReceivedPermissions.1.from: | |
| - | "taiko:0x1670000000000000000000000000000000000006" |
| + | "taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984" |
| directlyReceivedPermissions.7: | |
| - | {"permission":"upgrade","from":"taiko:0x1670000000000000000000000000000000000006","role":"admin"} |
| directlyReceivedPermissions.12: | |
| + | {"permission":"upgrade","from":"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984","role":"admin"} |
| } | |
| + | Status: CREATED |
| contract DefaultResolver (taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984) [taiko/DefaultResolver] | |
| +++ description: 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. | |
New and verified contracts
| + | Status: CREATED |
| contract MainnetERC721Vault (eth:0x0b470dd3A0e1C41228856Fb319649E7c08f419Aa) [N/A] | |
| +++ description: None | |
| + | Status: CREATED |
| contract QuotaManager (eth:0x91f67118DD47d502B1f0C354D0611997B022f29E) [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. | |
| + | Status: CREATED |
| contract MainnetERC1155Vault (eth:0xaf145913EA4a56BE22E120ED9C24589659881702) [N/A] | |
| +++ description: None | |
| + | Status: CREATED |
| contract L1SharedAddressManager (eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa) [taiko/L1SharedAddressManager] | |
| +++ description: Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades. | |
| + | Status: CREATED |
| contract ERC721Vault (taiko:0x1670000000000000000000000000000000000003) [N/A] | |
| +++ description: None | |
| + | Status: CREATED |
| contract ERC1155Vault (taiko:0x1670000000000000000000000000000000000004) [N/A] | |
| +++ description: None | |
2026 October 01, 10:34 UTC5changes- Two new standard DAO proposals (25 and 26), both still open in their veto period: - veto ends 2026-10-04: upgrades MainnetBridge, MainnetERC20Vault, MainnetERC721Vault, MainnetERC1155Vault, registers addresses in DefaultResolver and sends an L1- L2 message. - veto ends 2026-10-10: upgrades MainnetInbox, changes trusted RISC Zero image IDs and SP1 programs, changes MrEnclave values in both AutomataDcapV3Attestation contracts and deletes SGX instances in both SecureSgxVerifiers. Reviewed here: https://gist.github.com/sekuba/fd963174c4054a34ffb8c49f2c8bbf29.
- Two new standard DAO proposals (25 and 26), both still open in their veto period:
- veto ends 2026-10-04: upgrades MainnetBridge, MainnetERC20Vault, MainnetERC721Vault, MainnetERC1155Vault, registers addresses in DefaultResolver and sends an L1->L2 message.
- veto ends 2026-10-10: upgrades MainnetInbox, changes trusted RISC Zero image IDs and SP1 programs, changes MrEnclave values in both AutomataDcapV3Attestation contracts and deletes SGX instances in both SecureSgxVerifiers. Reviewed here: https://gist.github.com/sekuba/fd963174c4054a34ffb8c49f2c8bbf29.
| 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: | |
| - | 40 |
| + | 42 |
| values.proposalIds.40: | |
| + | "609192021977025249345447570106396801273767657512" |
| values.proposalIds.41: | |
| + | "609381197194961808191081799941267350559458852905" |
| } | |
| 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. | |
| values.proposalCount: | |
| - | 25 |
| + | 27 |
| } | |
| 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:0x35376dD47C061Bc3b8c8e8d61987019e7ED58f06" |
| } | |
2026 September 22, 11:58 UTCCritical state change41changesTwo proposals executed: 1. Security Council reduced from 9 to 5 members, thresholds now 3/5 standard and 4/5 emergency (This removes the 'correctly set-up' qualification for a Security Council - too few participants and threshold too low). 2. Raiko2 proving set updated v0.6.0 - v0.8.0-rc1 (RISC0 image IDs, SP1 vkeys, SGX mrEnclaves, old SGX instances deleted).
Two proposals executed:
- Security Council reduced from 9 to 5 members, thresholds now 3/5 standard and 4/5 emergency (This removes the ‘correctly set-up’ qualification for a Security Council - too few participants and threshold too low).
- Raiko2 proving set updated v0.6.0 -> v0.8.0-rc1 (RISC0 image IDs, SP1 vkeys, SGX mrEnclaves, old SGX instances deleted).
| 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: | |
| - | "0x5a818b4c7dc80e9ba85d55492c20c263c67238724e3982f76d15a158e501210b" |
| + | "0xd6ab71c22201c23ef512b706f2e2d720f6da1b559fb76834aa9d4e35276f6e10" |
| +++ 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: | |
| - | "0x9cfcc1b34a98853c3c5873a4d456726e528246f7f03a4ea35f27c2543aa6e7f0" |
| + | "0xdd9b8abff96c409ae2418edfb51d893ea2bd10f4873a0226f17a6998c1afc1b7" |
| } | |
| - | Status: DELETED |
| contract Safe (eth:0x0F40268Ec0Dc8D88CF2f22E227A29a0b478b6351) [GnosisSafe] | |
| +++ description: None | |
| 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.0: | |
| - | "eth:0xCf76A87E24FE2054DCF02a5f65eAc0F24A34c439" |
| values.$members.1: | |
| - | "eth:0x93533a3511E9b0d5c17b1CBD0e1737781DEf61a6" |
| values.$members.2: | |
| - | "eth:0x884c3e8235788ae52C2106E847e30BD84F2FBCb8" |
| values.$members.3: | |
| - | "eth:0x22aD66bcEaeff83e1461772Fa85CbeB01f0915f4" |
| values.$members.4: | |
| - | "eth:0x4236f57E9dBc238878EFac4AeF0A16D4dD06DC1A" |
| + | "eth:0x736d9e59cDd406aEee09253fF18BA6cb7be67CBD" |
| values.$members.6: | |
| - | "eth:0x18B4f2afe456Dc89bddE9710476dCfC62D01d656" |
| + | "eth:0x884c3e8235788ae52C2106E847e30BD84F2FBCb8" |
| values.$members.7: | |
| - | "eth:0x1d955983044548E03DAA583B36A37cA4bdE6F556" |
| + | "eth:0xF74F2bBaEd41e3e4AbAcbA24563a5Ce5aB071C8A" |
| values.$members.8: | |
| - | "eth:0xc4414B079bC4A013916B3dc241555F6f505c1619" |
| + | "eth:0xe63E61BbB3aa1b82d44471AbcAb490102C17c986" |
| values.addresslistLength: | |
| - | 9 |
| + | 5 |
| values.multisigSigners.0: | |
| - | "eth:0x436a1075099A145417EBFc74BBaC9605e3e4f1A7" |
| values.multisigSigners.3: | |
| - | "eth:0x0F40268Ec0Dc8D88CF2f22E227A29a0b478b6351" |
| values.multisigSigners.4: | |
| - | "eth:0x5353c607e6eca6C63FEC5c6C0F5CC3a5348d5c95" |
| values.multisigSigners.5: | |
| - | "eth:0x25d3E89bAcE2040Ed3aF7c4c7B505cfBB72fD6f1" |
| values.multisigSigners.6: | |
| - | "eth:0xa384E224A3F3D664F43eBE33395eF0DCcE67e894" |
| values.multisigSigners.3: | |
| + | "eth:0xe63E61BbB3aa1b82d44471AbcAb490102C17c986" |
| values.multisigSigners.8: | |
| - | "eth:0x6268d189E011Aa53A2f09A1FE159445BeB3d878E" |
| + | "eth:0xF74F2bBaEd41e3e4AbAcbA24563a5Ce5aB071C8A" |
| values.settings.minSignerListLength: | |
| - | 8 |
| + | 4 |
| } | |
| 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: | |
| - | "0x2d2216efbe9d8e80ba24b86606ccd5ce9faf11033d31ad9e5d3c5c89965c8a57" |
| + | "0x5f7da556f3b75dcc71465030e1b7274e82df9e9120c0b3eaf5bb76246a514005" |
| } | |
| - | Status: DELETED |
| contract Safe (eth:0x25d3E89bAcE2040Ed3aF7c4c7B505cfBB72fD6f1) [GnosisSafe] | |
| +++ description: None | |
| 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). | |
| values.lastMultisigSettingsChange: | |
| - | 24269141 |
| + | 25997731 |
| +++ severity: HIGH | |
| values.minApprovals: | |
| - | 7 |
| + | 4 |
| values.multisigSettings.minApprovals: | |
| - | 7 |
| + | 4 |
| } | |
| - | Status: DELETED |
| contract Safe (eth:0x436a1075099A145417EBFc74BBaC9605e3e4f1A7) [GnosisSafe] | |
| +++ description: None | |
| - | Status: DELETED |
| contract Safe (eth:0x5353c607e6eca6C63FEC5c6C0F5CC3a5348d5c95) [GnosisSafe] | |
| +++ description: None | |
| - | Status: DELETED |
| contract Safe (eth:0x6268d189E011Aa53A2f09A1FE159445BeB3d878E) [GnosisSafe] | |
| +++ description: None | |
| 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: | |
| - | "0x00ad090221a8fa0f09e1be7a53feb67be010f01310d4b2314a69d10152ee1ce0" |
| + | "0x0025425c22e827507428a3d9c7b0f89635be5462f34bb6780563e3d6086be7c7" |
| +++ 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: | |
| - | "0x568481106a3e83c23c37cf4a3feb67be008780984352c8c514d3a20252ee1ce0" |
| + | "0x12a12e113a09d41d05147b387b0f89632df2a3174d2ed9e00ac7c7ac086be7c7" |
| +++ 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: | |
| - | "0x000b11691352e55fcf64f62620cefaa700161600093f2751032fe71ea912264d" |
| + | "0x0051ac1d9e8cfd4196e37f9cfefd08e9b0f7ce653bad4634cd1ee84b71ca3be6" |
| +++ 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: | |
| - | "0x0588b48954b957f36c9ec4c40cefaa7000b0b00024fc9d44065fce3d2912264d" |
| + | "0x28d60ecf233f50655c6ff39f6fd08e9b07be73296eb518d31a3dd09671ca3be6" |
| } | |
| 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: | |
| - | "0x90c79e65d6d0f83d658ff96cd0ef1204438f20b406c93cf1d4fafa0cff29842e" |
| + | "0x3564b6a30089fcb3e2f69c19b22d23f84ce148387cd7a15f5c1df165b2ae5847" |
| +++ description: Trusted SGX enclave measurements accepted by attestation verification. | |
| +++ severity: HIGH | |
| values.mrEnclaves.1: | |
| - | "0x041cadb0541bf8249c368482172d218608f3693975b65f74beb2ed6f0044f951" |
| + | "0xae2c7b92b2a71238226cb624ecd1171b66bf943cc372314affca0e6748ccecdf" |
| } | |
| 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: | |
| - | 39 |
| + | 40 |
| values.proposalIds.39: | |
| + | "609097156697645562436844254022738698161067393063" |
| } | |
| - | Status: DELETED |
| contract Safe (eth:0xa384E224A3F3D664F43eBE33395eF0DCcE67e894) [GnosisSafe] | |
| +++ description: None | |
| 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). | |
| values.lastMultisigSettingsChange: | |
| - | 24588180 |
| + | 25997731 |
| +++ severity: HIGH | |
| values.minApprovals: | |
| - | 5 |
| + | 3 |
| values.multisigSettings.minApprovals: | |
| - | 5 |
| + | 3 |
| +++ description: total standard proposal count. | |
| values.proposalCount: | |
| - | 24 |
| + | 25 |
| } | |
2026 September 15, 11:26 UTC6changescritical contracts and severities for the ossification perimeter
critical contracts and severities for the ossification perimeter
New and verified contracts
| + | Status: CREATED |
| contract Bridge (taiko:0x1670000000000000000000000000000000000001) [taiko/L2Bridge] | |
| +++ description: Bridge escrow holding preminted ETH on Taiko. | |
| + | Status: CREATED |
| contract ERC20Vault (taiko:0x1670000000000000000000000000000000000002) [taiko/L2ERC20Vault] | |
| +++ description: Escrow for L2-native tokens sent to L1 via the canonical bridge. | |
| + | Status: CREATED |
| contract SignalService (taiko:0x1670000000000000000000000000000000000005) [taiko/SignalService] | |
| +++ description: 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. | |
| + | Status: CREATED |
| contract L2AddressManager (taiko:0x1670000000000000000000000000000000000006) [taiko/L2AddressManager] | |
| +++ description: Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades. | |
| + | Status: CREATED |
| contract Anchor (taiko:0x1670000000000000000000000000000000010001) [taiko/Anchor] | |
| +++ description: Stores L1 block details on L2 as a cross-layer oracle and manages EIP-1559 gas pricing for L2 operations. | |
| + | Status: CREATED |
| contract DelegateController (taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C) [taiko/DelegateController] | |
| +++ description: 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. | |
The system uses whitelist-based sequencing and proving
The system uses a whitelist-based sequencingA sequencing strategy for L2s based on Ethereum's own block building pipeline, which gets reused to also build L2 blocks. This strategy is in contrast to centralized sequencing or decentralized sequencing mechanisms that use networks external to Ethereum. mechanism to allow for fast preconfirmations on the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. On the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., batch proposing is permissioned through the PreconfWhitelist contract, which currently has 2 active operators registered.
For each epoch, PreconfWhitelist selects a single active operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. that can propose to MainnetInbox. There is no fallback proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. path, and non-selected operators cannot propose for the current epoch.
Proving is controlled separately by ProverWhitelist, which currently has 2 whitelisted provers.
While the proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist is non-empty, non-whitelisted actors cannot submit proofs. MainnetInbox currently sets minBond=0 and livenessBond=0.
Proving a proposal range requires exactly two proofs and at least one of them must be a ZK proof. Accepted combinations are SGX (Geth or Reth) plus SP1 or RISC0, or SP1 plus RISC0.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can enqueue transactions
Users can submit a forced inclusion directly to MainnetInbox on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. by publishing a blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. containing one L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. manifest and calling saveForcedInclusion().
Requests are stored in a FIFO queue and cost a dynamic fee that starts at 0.001 ETH. The fee increases linearly with the queue size and doubles when 50 requests are pending.
After 9m 36s, a request is due. Every subsequent proposal must process the due requests at the head of the queue, up to ten per proposal, before the proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.’s own derivation source. This prevents an active proposer from advancing the chain while selectively skipping a due request.
However, propose() still unconditionally checks PreconfWhitelist. The configured 1d 1h 36m permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. inclusion threshold is not used, so users and other unpermissioned actors cannot process the queue themselves. If all whitelisted proposers stop, the queue and the whole chain stop progressing.
Users can be censored if the operator is offline or refuses to process the queue.
Regular exit
Users initiate withdrawals on Taiko and claim them on Ethereum with a Merkle proof after state finalization. ETH and ERC20 releases consume configured withdrawal quotas. Failed deliveries remain retryable, but source-chain refunds are disabled on both bridges.
Funds can be frozen if a bridge message cannot be delivered successfully, because failed-message refunds are disabled.
Ethereum
Actors:
A Multisig with 4/5 threshold. A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here.
- Can upgrade with 7d delay
- ERC721Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- 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
- ERC20Vault 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
- ERC1155Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. DAO with 7d delay (emergency proposals bypass the delay) → 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
- Bridge DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- ERC20Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- ERC721Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- ERC1155Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- SignalService DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Anchor DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- DefaultResolver 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
- manage trusted RISC Zero image IDs with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with ERC721Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- add/remove members from the Security Council and change its minimum size with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
- Can interact with 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 rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. system, activate the inbox, and execute the one-time state recovery path with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → 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 ERC20Vault
- pause and unpause token flows and change a canonical token’s bridged representation after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → 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 ERC1155Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Can interact with Bridge
- pause and unpause bridge flows and run one-time message recovery initializers with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → 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 proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → 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
- Can interact with Bridge
- pause and unpause bridge flows and run one-time message recovery initializers with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Can interact with ERC20Vault
- pause and unpause token flows and change a canonical token’s bridged representation after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Can interact with ERC721Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Can interact with ERC1155Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Can interact with SignalService
- pause and unpause signal proof verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- 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 → DelegateController
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 BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.
- Can interact with ProverWhitelist
- manage the proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist
- Can interact with PreconfWhitelist
- manage the ejecter role
Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. controls access to the refund callback.
- Can interact with QuotaManager
- consume ERC20 withdrawal quota when tokens leave the vault
BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrow for ETH and cross-chain messages. Pausing stops all message flows. The immutable recallEnabled setting controls failed-message refunds. Successful ETH releases use the configured quota manager.
- Can interact with QuotaManager
- consume ETH withdrawal quota when ETH leaves the bridge
A Multisig with 2/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 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.
- 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.
- Can interact with SP1VerifierGateway
- affect the livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. and safety of the gateway - can transfer ownership, add and freeze verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. routes
A Multisig with 3/5 threshold.
A Multisig with 1/2 threshold. Member of Taiko Foundation Treasury Multisig, Taiko Multisig, Taiko Labs.
- Can interact with PreconfWhitelist
- eligible to propose batches on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.; only the selected current-epoch operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. can successfully propose
Member of Sebastian Kugler.
- Can interact with SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- configure an agent address that represents this entity in the Security Council Sebastian Kugler
Member of SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.).
- Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council
- Can interact with RiscZeroVerifierEmergencyStop
- pause the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.
Taiko Alethia
Actors:
- Can interact with BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.
Ethereum
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 2.0.0-rc.3).
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 3.0.0).
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 2.0.3).
Immutable verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. policy contract for Taiko mainnet. Every accepted proof contains exactly two ordered sub-proofs and at least one must be a ZK proof. Accepted pairs are SGX-GETH or SGX-RETH with RISC0-RETH or SP1-RETH, and RISC0-RETH with SP1-RETH. The SGX-GETH plus SGX-RETH pair is not accepted.
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 2.2.0).
Defines the proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist queried by the inbox before accepting proofs. If the inbox is configured with this contract and the whitelist is non-empty, only whitelisted provers can prove proposals.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
- proverManager: Taiko Multisig
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs. This older implementation exposes control-root and selector constants but does not expose a VERSION getter.
Defines withdrawal quotas for ETH and ERC20 releases from the shared bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.. A token quota of zero means unlimited withdrawals for that token.
Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.
- Roles:
- admin: DAO; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DAO
The main contract and entrypoint of the Aragon-based DAO governance framework. Fine-grained DAO permissions, proposals, voting and thresholds are configured here.
- Roles:
- currentSignerListPermissions: SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) (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 CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DAO
Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- 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 CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
Modular Governance contract allowing for proposing, voting on and executing encrypted proposals (e.g. for Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. emergency proposals).
- Roles:
- dao: DAO; ultimately SignerList (Security Council)
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SGX proven blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.. Registered SGX instances can sign accepted proofs until their instance expiry.
- Roles:
- owner: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- registrar: Taiko Multisig
Set verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero proofs (version 0.9.0). It allows verifying a whole set of proofs identified with a Merkle root at once, afterwards each individual proof could be efficiently verified just by checking Merkle inclusion against the verified root.
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. BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. and vault contracts resolve their counterparties through this registry, so changes in this mapping effectively act as contract upgrades. The pause function is intentionally disabled in this implementation.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- 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 CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
Facilitates secure cross-chain message passing by storing signals and state-root checkpoints. BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrows and other applications use it to prove that a specific L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.<->L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. signal or checkpointed state transition occurred via Merkle proofsHashing the pairs of values at each level and climbing up the (Merkle) Tree until you obtain the root hash. Merkle proofs help check if the data belongs to a set without having to store the entire set.. Pausing disables signal proof verification.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
- pauser: Taiko Multisig
Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. standard proposals).
- Roles:
- dao: DAO; ultimately SignerList (Security Council)
Contains the whitelist of addresses eligible to propose batches on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. and issue preconfirmations. It dynamically selects a single active operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. for each epoch using a delayed Ethereum beacon blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. root as randomness. There is no fallback proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. path in this contract: non-selected operators cannot propose for the current epoch.
- Roles:
- _ejectorManager: Taiko Multisig
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- ejecters: EOA 2, EOA 5
- operatorMapping: EOA 3, EOA 6
- owner: TaikoDAOController; ultimately SignerList (Security Council)
This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts, routing each identifier to the corresponding verifier contract.
- Roles:
- owner: SP1VerifierGatewayMultisig
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.1.0).
Gating router contract to verify batches using RISC Zero.
- Roles:
- owner: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
The core Layer 1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. entrypoint for the Taiko rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. where L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. batches are proposed and their corresponding state transitions are proven. Users can enqueue forced inclusions by publishing an L1 blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. Once an inclusion is due, subsequent proposals must process it, but proposing remains restricted by the configured proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. checker. If the configured proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist is non-empty, proofs from non-whitelisted provers revert.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
Gating router contract to verify batches using SP1.
- Roles:
- owner: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
A timelock with access control. The current minimum delay is 3d.
- Roles:
- canceller: Safe
- defaultAdmin: TimelockController; ultimately Safe
- executor: Safe
- proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.: Safe
Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
- Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
Taiko Alethia
Stores L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. details on L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. as a cross-layer oracle and manages EIP-1559 gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. pricing for L2 operations.
- Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrow holding preminted ETH on Taiko. Failed messages remain retryable, but message failure and source-chain refunds are disabled.
- Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)
- pauser: EOA 1
Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. controls access to the refund callback.
- Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)
Middleware contract that can maintain ownership of DAO-controlled assets and contracts. It can only be invoked by the TaikoDAOController on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. through the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge..
- Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- daoController: TaikoDAOController
Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
- Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)
Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
- Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)
Facilitates secure cross-chain message passing by storing signals and state-root checkpoints. BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrows and other applications use it to prove that a specific L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.<->L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. signal or checkpointed state transition occurred via Merkle proofsHashing the pairs of values at each level and climbing up the (Merkle) Tree until you obtain the root hash. Merkle proofs help check if the data belongs to a set without having to store the entire set.. Pausing disables signal proof verification.
- Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)
Maps chainId-name pairs to contract addresses. BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. and vault contracts resolve their counterparties through this registry, so changes in this mapping effectively act as contract upgrades. The pause function is intentionally disabled in this implementation.
- Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- 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).