Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Shasta Fork

Protocol architecture for proposal-based derivation and checkpoint-driven finalization.

Shasta is the protocol architecture that Unzen currently runs on. It superseded Pacaya by reworking Taiko around a separate inbox, proposal-based derivation, and explicit L1/L2 routing for checkpoints and anchoring.

Unzen is the current Taiko protocol fork. It keeps Shasta's proposal and finalization architecture, then adds execution-layer changes such as block-level zk gas metering. See Unzen Fork for the current fork details.

Proposal-Based Derivation

Shasta organizes L2 block construction around proposals rather than the older batch terminology.

Under this model:

  • proposals are identified by sequential proposal IDs
  • proposal data is carried in blob-backed derivation sources
  • forced inclusions are processed first and the proposer's source is appended last

This keeps forced inclusion inside the normal proposal pipeline rather than treating it as a side path.

Sequential Finalization with Checkpoints

Shasta keeps proving on Ethereum L1, but finalization becomes more explicitly checkpoint-driven.

In practice:

  • ShastaInbox accepts proposals and proofs for contiguous proposal ranges
  • successful proving advances finalization in order
  • finalization writes a checkpoint into the signal service

This gives the rest of the protocol a fresh L1-backed checkpoint as Shasta-based proposals finalize.

L1/L2 Routing and Anchoring

Shasta also changes how L1 state is reflected on L2.

  • Anchor stores anchored L1 checkpoints on L2 and records metadata used by the preconfirmation flow
  • SignalServiceForkRouter switches signal-service behavior across the Pacaya/Shasta fork boundary
  • the fork routing model lets Pacaya-era and Shasta-era logic coexist cleanly during transition

This is one of the main architectural differences from the simpler Pacaya overview.

Preconfirmation-Oriented Permissioning

Shasta is built to support the staged preconfirmation rollout.

It introduces:

  • proposer authorization through PreconfWhitelist
  • prover whitelisting with permissionless fallback after delay
  • permissionless proposal fallback when forced inclusions stay too old

These controls keep the fast path structured without removing the protocol's escape hatches.

Key Contract Changes

Shasta introduces or elevates several contracts:

  • ShastaInbox becomes the Shasta L1 protocol entry point
  • Anchor becomes the Shasta L2 anchoring contract
  • PreconfWhitelist controls proposer authorization
  • ProverWhitelist controls early proving access
  • SignalServiceForkRouter handles cross-fork signal-service routing

See Preconfirmations, Proving System, and Contract Addresses for related details.