Protocol Overview
Taiko is an Ethereum-equivalent (type-1) based rollup that scales Ethereum without compromising its core properties: censorship resistance, permissionless access, and decentralization. Unlike traditional rollups that rely on centralized sequencers, Taiko delegates block sequencing to Ethereum L1 validators, making it a natural extension of Ethereum itself.
What Makes Taiko Different
Based rollup. Ethereum L1 validators order Taiko proposal transactions on L1. Under the current Shasta rollout, the fast proposing path is preconf-whitelisted, with permissionless fallback preserved through forced inclusion rules. See Based Rollups for a deep dive.
Type-1 ZK-EVM. Taiko runs an unmodified Ethereum execution layer. Every opcode, every precompile, every tool that works on Ethereum works on Taiko without modification. Developers deploy the same Solidity contracts with the same tooling (Hardhat, Foundry, etc.) -- no code changes needed.
Multi-proof verification. Taiko uses a multi-proof architecture combining SGX (TEE-based) proofs and ZK proofs. A single proof type is never sufficient on its own -- multiple independent proof systems must agree on state transitions. See Proving System for details.
Key Components
| Component | Role |
|---|---|
| Proposers | Submit proposals containing one or more L2 blocks to Ethereum L1 via Inbox. |
| Provers | Generate validity proofs (SGX + ZK) confirming that proposed blocks were executed correctly. |
| Inbox | L1 smart contract managing proposal intake, proof submission, checkpointing, and finalization. |
| Anchor | L2 smart contract that anchors L1 checkpoints and related metadata into the L2 chain. |
| Bridge | Cross-chain messaging system for transferring assets and messages between L1 and L2. |
| Signal Service | Low-level cross-chain signaling contract used by the bridge for Merkle-proof-based message verification. |
| ComposeVerifier / MainnetVerifier | Verifier contract that orchestrates multiple sub-verifiers (SGX, ZK) for multi-proof validation. |
How Blocks Flow Through the Protocol
Under Shasta, a Taiko block moves through two protocol states: proposed, then proved and finalized in a single step.
1. Proposed
A proposer submits one or more L2 blocks as a proposal to Inbox on Ethereum L1 by calling propose. Proposal data is carried through blob-backed derivation sources, and forced inclusions are processed first when due.
At this point, the proposal exists on L1 but has not yet advanced finalization. Nodes can derive and execute the L2 blocks optimistically.
2. Proved and Finalized
Provers generate validity proofs for a contiguous range of proposals. The proof submitted to Inbox.prove is checked through a composed verifier, with sufficient proof pairs such as sgxGeth + sgxReth, sgxGeth + RISC0, or sgxReth + SP1.
In Shasta, a successful proof submission finalizes the proven range directly. Inbox checks that the range links to the current finalized head, writes a checkpoint into the signal service, and updates the finalized proposal ID and block hash. There is no separate post-proving finalization step: once a proposal range is proved, it is final.
Block States Summary
| State | Meaning | Finality |
|---|---|---|
| Proposed | Submitted to Inbox on L1. Data is available for derivation, but the proposal has not yet advanced finalization. | Soft -- derivable but not finalized by the protocol. |
| Proved and Finalized | A valid proof has been accepted, the proven range has advanced the finalized proposal head, and a checkpoint has been written to the signal service. | Final at the protocol level, with L1-backed checkpointing. |
A Taiko L2 block also inherits Ethereum's Safe and Finalized designations through its L1 origin. Each L2 block maps to an L1 origin block. If that L1 block is Safe, the L2 block is also considered Safe. Shasta finalization is the protocol's own ordered checkpoint-finalization step on top of that L1 anchoring model.
Current Protocol Design: Shasta Fork
The Shasta fork reorganized the protocol around proposals, checkpoint-driven finalization, and explicit L1/L2 routing.
Proposal-based derivation. Blocks are organized around proposals handled by a separate Inbox
Checkpoint-driven finalization. Successful proof submission finalizes proposal ranges in order and writes checkpoints into the signal service.
Whitelist-first rollout controls. Proposer authorization and prover whitelisting structure the fast path during the preconfirmation rollout, while forced inclusion and delayed permissionless proving preserve escape hatches.
Key contracts introduced:- Inbox becomes the main Shasta L1 protocol entry point
- Anchor becomes the Shasta L2 anchoring contract
- ComposeVerifier orchestrates multi-proof verification
- ForcedInclusionStore preserves censorship resistance during the preconfirmation rollout
- SignalServiceForkRouter handles routing across the Pacaya/Shasta fork boundary
Further Reading
- Based Rollups -- how L1-sequenced block ordering works
- Shasta Fork -- the current fork: proposal-based derivation and checkpoint finalization
- Proving System -- multi-proof verification architecture
- Bridging -- cross-chain messaging and asset transfers
- Economics -- fees, bonds, and token utility
- Preconfirmations -- faster transaction finality via based preconfirmations
- Pacaya Fork -- historical: the earlier batch-based protocol design
- Differences from Ethereum -- EVM version, account abstraction, and chain-specific behavior