Search for projects by name or address
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.
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 its data-availability (DA) layer over time. The project currently posts data to; previously it posted 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.
All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.
No Tx data submissions were performed for 23m 36s (from 2026 Sep 24, 08:12 UTC until 2026 Sep 24, 08:35 UTC). These typically occur every 54s 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 54s 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 54s 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 36s on average.
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..
Proof system exploit
2026 Jun 22nd
An attacker exploits a vulnerability in the SGX 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 steals USD ~1.7M.
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 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.
Taiko 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.
Onchain verifier
Onchain verifier |
Onchain verifier

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.
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 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.
The proof system currently does not require zk proofs to validate state transitions and state can be finalized with SGX proofs only. The optional zk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts can be upgraded by Multisigs. 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.
| 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. |
| 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. |
| 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 |
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
Two 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:
| 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 |
| } | |
critical contracts and severities for the ossification perimeter
critical contracts and severities for the ossification perimeter
| + | 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. | |
Operator changes.
Operator changes.
| 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" |
| } | |
SC proposal moving to veto phase.
SC proposal moving to veto phase.
| contract SignerList (Security Council) (eth:0x0F95E6968EC1B28c794CF1aD99609431de5179c2) [taiko/SignerList] { | |
| +++ description: A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here. | |
| values.$members.0: | |
| - | "eth:0xAC5898b0FFFd23F4Ef09F0E50Fa1bC4896eF7163" |
| + | "eth:0xCf76A87E24FE2054DCF02a5f65eAc0F24A34c439" |
| } | |
| 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: | |
| - | 38 |
| + | 39 |
| values.proposalIds.38: | |
| + | "608479335948875503511285097395089134668700712998" |
| } | |
| contract Taiko Multisig (eth:0x9CBeE534B5D8a6280e01a14844Ee8aF350399C7F) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.0: | |
| - | "eth:0xAC5898b0FFFd23F4Ef09F0E50Fa1bC4896eF7163" |
| + | "eth:0xFa92ff698D57f7B875570D9F59501812B843CD44" |
| } | |
Add proposal that reduces the Security Council to a 4/5 multisig. The resulting Council is not a valid Security Council after the L2BEAT criteria: https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52, https://forum.l2beat.com/t/stage-1-requirements-update-security-council-walkaway-test/412 . full review of the proposal: https://gist.github.com/sekuba/b19aa30b123d7247280e96f5a49e5c15 .
Add proposal that reduces the Security Council to a 4/5 multisig. The resulting Council is not a valid Security Council after the L2BEAT criteria: https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52, https://forum.l2beat.com/t/stage-1-requirements-update-security-council-walkaway-test/412 .
full review of the proposal: https://gist.github.com/sekuba/b19aa30b123d7247280e96f5a49e5c15 .
| 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: | |
| - | 37 |
| + | 38 |
| values.proposalIds.37: | |
| + | "608325339122031231284005618251537221674155900965" |
| } | |
| contract Multisig (eth:0xD7dA1C25E915438720692bC55eb3a7170cA90321) [taiko/Multisig] { | |
| +++ description: Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security Council standard proposals). | |
| +++ description: total standard proposal count. | |
| +++ severity: HIGH | |
| values.proposalCount: | |
| - | 23 |
| + | 24 |
| } | |
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 1 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 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.
The user initiates the withdrawal by submitting a regular transaction on this chain. When the 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. containing that transaction is finalized the funds become available for withdrawal 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.. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

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.
A Multisig with 4/6 threshold.
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.
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. 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.
A Multisig with 3/5 threshold.
A Multisig with 2/3 threshold.
A Multisig with 3/5 threshold.
A Multisig with 1/2 threshold. Member of Taiko Foundation Treasury Multisig, Taiko Multisig, Taiko Labs.
Member of 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.).


Gating router contract to verify batches using RISC Zero.
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).
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.
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.
Gating router contract to verify batches using SP1.
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.
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.
The main contract and entrypoint of the Aragon-based DAO governance framework. Fine-grained DAO permissions, proposals, voting and thresholds are configured here.
Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.
A timelock with access control. The current minimum delay is 3d.
Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
ERC20 contract implementing the TAIKO token. It defines a list of addresses designated as non-voting.
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).
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.
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.
Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (TimelockController).
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.
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.
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.
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).
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.
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v5.0.0).
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.
VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.0.0).
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).
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.
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..
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.
Escrow for 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.-native tokens sent to 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. via the canonical 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..
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.
Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.
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).