Taiko Alethia - L2BEAT

Recategorisation

13d

04h

15m

11s

The project will be classified as "Other" due to its specific risks that set it apart from the standard classifications.

The project will move to Others because:

The proof system isn't fully functional

Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.

Learn more about the recategorisation

Value Secured

2024 Jun 05 — 2025 Jun 05

View TVS breakdown

Total value securedTotal

$153.53 M10.4%

Canonically BridgedCanonically Bridged ValueCanonical

$58.57 M20.2%

Natively MintedNatively Minted TokensNative

$0.000.00%

Externally BridgedExternally Bridged ValueExternal

$94.95 M3.16%

View TVS breakdown

Activity

Onchain costs

The section shows the operating costs that L2s pay to Ethereum.

2024 Jun 05 — 2025 Jun 04

Show data posted

1 year total cost

$11.16 M

Avg cost per L2 UOP

$0.013978

1 year data posted

83.48 GiB

Avg size per L2 UOP

112.21 B

Liveness

The chart illustrates how "live" the project's operators are by displaying how frequently they submit transactions of the selected type and if these intervals deviate from their typical schedule.

30D avg. tx data subs. interval

30D avg. state updates interval

Past 30 days anomalies

Milestones & Incidents

Plonky3 vulnerability patch

2025 Jun 4th

SP1 verifier is patched to fix critical vulnerability in Plonky3 proof system (SP1 dependency).

Learn more

Taiko Pacaya Hardfork

2025 May 21st

Taiko Pacaya hardfork replaces the contestable rollup design with a batch based protocol.

Learn more

Risk summary

Funds can be stolen if

a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL),
a malicious block is proven by compromised SGX instances.

Risk analysis

Sequencer failureState validationData availabilityExit windowProposer failure

Sequencer failure

Self sequence

The system uses a based (or L1-sequenced) rollup sequencing mechanism, meaning that users can propose L2 blocks directly on the Taiko L1 contract. Proposers are required to also prove blocks within 2h, or forfeit half of their liveness bond (125.0 TAIKO).

State validation

Multi-proofs

A multi-proof system is used. There are four verifiers available: SGX (Geth), SGX (Reth), SP1 and RISC0. Two of them must be used to prove a block, and SGX (Geth) is mandatory. A block can be proved without providing a ZK proof as SGX (Geth) + SGX (Reth) is a valid combination.

Data availability

Onchain

All of the data needed for proof construction is published on Ethereum L1.

Exit window

None

There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

Proposer failure

Self propose

Anyone can be a Proposer and propose new roots to the L1 bridge. Provers are required to submit two valid proofs for blocks, one of which must be SGX (Geth), and the other can be either SGX (Reth), SP1, or RISC0. If the proposer fails to prove the block within the proving window, they forfeit half of their liveness bond.

Rollup stage

Taiko Alethia is a

Stage 0

ZK Rollup.

Learn more about Rollup stages

Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

Data availability

All data required for proofs is published on chain

All the data that is used to construct the system state is published on chain in the form of blobs. This ensures that it will be available for enough time.

Learn more about the DA layer here:

Ethereum

State validation

Validity proofs

Taiko uses a multi-proof system to validate state transitions. The system requires two proofs among four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. The use of SGX (Geth) is mandatory, while the other three can be used interchangeably. This means that a block can be proven without providing a ZK proof if SGX (Geth) and SGX (Reth) are used together. Batch proposers are required to stake a liveness bond of 125.0 TAIKO, half of which is forfeited if they fail to prove the block within the proving window of 2h. The multi-proof system allows to detect bugs in the verifiers if they produce different results for the same block. If such a bug is detected, the system gets automatically paused.

Funds can be stolen if a malicious block is proven by compromised SGX instances.

TaikoL1.sol - Etherscan source code, liveness bond

Operator

The system uses a based sequencing mechanism

The system uses a based (or L1-sequenced) sequencing mechanism. Anyone can sequence Taiko L2 blocks by proposing them directly on the TaikoL1 contract. The proposer of a block is assigned the designated prover role, and will be the only entity allowed to provide a proof for the block during the 2h proving window. Currently, proving a block requires the block proposer to run a SGX instance with Geth, plus either SGX (Reth), SP1, or RISC0 to prove the block. Unless the block proposer proves the block within the proving window, it will forfeit half of its liveness bond to the TaikoL1 smart contract.

TaikoL1.sol - Etherscan source code, proposeBatch function

Users can force any transaction

The system is designed to allow users to propose L2 blocks directly on L1. Note that this would require the user to run two of the available proving systems, or forfeit half the liveness bond of 125.0 TAIKO. Moreover, users can submit a blob containing a standalone transaction by calling the storeForcedInclusion() function on the ForcedInclusionStore contract. This forced transaction mechanism allows users to submit a transaction without running a prover. This mechanism ensures that at least one forced transaction from the queue is processed every 255 batches. However, if many transactions (k) are added to the queue, an individual transaction could experience a worst-case delay of up to k * 255 batches while waiting for its turn.

Withdrawals

Regular exit

The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Actors:

Taiko Multisig 0x9CBe…9C7F

A Multisig with 4/6 threshold.
Can upgrade with no delay
- ForcedInclusionStore
- TaikoL1
- AutomataDcapV3Attestation
- Taiko Token
- DefaultResolver
- ProverSet
- Risc0VerifierGateway
- SgxVerifier
- AutomataDcapV3Attestation
- DefaultResolver
- QuotaManager
- MainnetERC20Vault
- MainnetSignalService
- SgxVerifier
- TaikoWrapper
- VerifierGateway
- SP1VerifierGateway
- MainnetBridge
- L1SharedAddressManager
Can interact with AutomataDcapV3Attestation
- can update the program being verified
Can interact with DefaultResolver
- can update the contract address for a given name
Can interact with Risc0VerifierGateway
- can update the program being verified
Can interact with SgxVerifier
- can add new instances without a DCAP attestation
Can interact with AutomataDcapV3Attestation
- can update the program being verified
Can interact with DefaultResolver
- can update the contract address for a given name
Can interact with SgxVerifier
- can add new instances without a DCAP attestation
Can interact with SP1VerifierGateway
- can update the program being verified
Can interact with L1SharedAddressManager
- can update the contract address for a given name