Skip to content

Pacaya Fork

What’s Changing?

The Taiko Alethia protocol in it’s current iteration (Ontake fork) utilizes the based contestable rollup design. The design has been battle-tested and proven to be secure and cheaper to use than L1 over almost 1M blocks and 653M transactions! However, it has also revealed some limitations to the contestable rollup design specifically with regards to UX.

With this in mind, the Taiko team has been working on a protocol upgrade in conjunction with our partners to address these limitations. The primary driver is being able to support based preconfirmations, which will improve the UX by reducing confirmation times drastically; this new feature is however, incompatible with the current contestable rollup design.

Hence, the Taiko Alethia protocol will be undergoing a major upgrade with the upcoming Pacaya fork. This page will cover some of the key changes that will be introduced with the fork.

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 pivot and an extra proof; the pivot proof will be a TEE, and the extra proof will be a TEE/ZK proof. Proposers will have to register some new images to ensure a smooth transition, find out more here.

Please note that for the upcoming Taiko Hekla upgrade we have temporarily set the pivot proof to be an optimistic proof.

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 pivot and extra 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. If you’re interested in joining the whitelist as a preconfer, feel free to reach out to us. However, we can only add you after discussions to ensure that your infrastructure meets some liveness requirements.

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.

Upcoming Changes for Proposers

The move to a batch based protocol necessitates some changes to the liveness bond mechanism. Previously, the liveness bond was set to 125 TAIKO per block: the 125 liveness bond is now per batch, with every block in the batch also having a liveness bond of 5 TAIKO. This may require proposers to adjust their liveness bond strategy.

Proposers will also need to register new raiko images for the upcoming Pacaya fork. The new images are required for the pivot and extra proofs, which will be verified by the new verifier contract. The process will be similar to the current image registration process, in the steps shown below.

Proposer Image Registration

The roadmap ahead can essentially be summarized as follows:

Pacaya -> Pacaya with Pivot (multiproving) -> Based Preconfirmations

Documentation coming soon.