Skip to content

Pacaya Fork Taiko Alethia

The Taiko Alethia protocol has successfully transitioned into the Pacaya fork as of May 21st 2025 UTC!

This entails a full transition into the new batch based protocol, which introduces several key changes in the interest of addressing limitations of the original contestable rollup design that will be covered in this page.

Batch Based Protocol

As a based rollup, we use L1 as our sequencer and must propose every block to L1. Every block proposal is another L1 on chain call, which can get very expensive very quickly. Due to this design, bigger blocks including more transactions are most profitable and many small blocks are unprofitable. This is a problem for based preconfirmations, as we want to be able to confirm transactions as fast as possible. To address this and maintain gas efficiency, we are transitioning to a batch based protocol.

Blocks are now proposed in batches, with each batch capable of containing zero, one, or multiple blocks. All blocks within a batch share metadata and pull transactions from the same source (calldata or blobs). This design allows for small, frequent blocks to be only marginally more expensive than large infrequent blocks.

Simplified Proving Mechanism

In the interest of simplifying the protocol and removing the added security risk that Guardian provers introduce, we have removed proof contestation entirely. This change also conveniently aligns us better as a Stage 1 L2 protocol.

In it’s place we are introducing Multiproving: every batch will be required to have multiple proofs, which will be verified by a single verifier contract. This verifier contract will handle sub-proof verifiers, and will be responsible for verifying the proofs. The required proofs will be a sgxGeth (Gaiko) proof and the original sgxReth (Raiko) proof; the sgxGeth proof will be a TEE, and the sgxReth proof will be a TEE/ZK proof. Proposers will have to register some new images to ensure a smooth transition.

We have also shortened the proving and cooldown windows to 2 hours, with further reductions planned to enable faster withdrawals.

TLDR Protocol Changes

The Pacaya fork will contain some major protocol contract changes. Here is a brief overview of the changes:

  • TaikoL1 Contract: The TaikoL1 contract has been replaced by the TaikoInbox contract. The proposeBlock, proveBlock and verifyBlock functions have been replaced in favor of their corresponding batch based functions; the rest of the functions remain the same as current TaikoL1.

  • TaikoL2 Contract: The TaikoL2 contract has been replaced by the TaikoAnchor contract. The only new function is the anchorV3 function, which will be used post Pacaya fork. Everything else remains the same.

  • ForcedInclusionStore Contract: The ForcedInclusionStore contract allows the protocol to remain censorship-resistant while in Stage 1 Preconfs. It allows users to submit transactions and force their inclusion irregardless of the preconfers, preventing targeted censorship from malicious preconfers.

  • ComposeVerifier Contract: The ComposeVerifier contract is a new contract that will be used to verify the sgxGeth and sgxReth proofs. It will be responsible for verifying the proofs and ensuring that the batch proofs are valid.

  • ERC20 Solver Support: Thanks to Nethermind’s contribution, ERC20Vault now supports solvers for faster ERC20 withdrawals. (Bridge UI support is coming soon.)

You can find more release notes here.

Based Preconfirmations

Based Preconfirmations are a brand new feature that will improve the UX of the Taiko Alethia protocol drastically.

The Pacaya upgrade marks the first step toward preconfirmation. Given the nature of the protocol, we must ensure that blocks can be both proved and verified across the upgrade block number (fork height) before enabling preconfirmation. Activating preconfirmation does not require another contract or software upgrade, there will be no additional work on the end of node operators or users.

This initial phase of preconfirmation is not the full implementation: it uses a whitelist-based approach without integrating a lookahead contract or preconfer registry. A staking or restaking-based approach will be introduced and tested in the next phase, followed by slashing rules.

The initial launching partners include Nethermind, Gattaca, and Chainbound. In a post-whitelist phase, the community will be able to run these solutions themselves as secured-by-stake preconfirmers.

The solutions are fully opensource and can be found here:

While a whitelist-based approach is technically permissioned, it is a necessary step in testing preconfirmation, a complex feature that impacts nearly every aspect of Taiko’s Alethia codebase. Rolling it out incrementally allows us to validate the design, mitigate risks, and gather early feedback to refine future iterations. That said, Taiko remains committed to full permissionlessness, and this phased approach is simply a stepping stone toward that vision.

Read more about Based Preconfirmations here.