The Pacaya Hardfork, a crucial step toward based preconfirmations, is coming to the Taiko Alethia mainnet next week. This marks one of the most important milestones for Taiko to date.

Let’s take a closer look at what’s about to happen.

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. The hardfork will happen at Block 1,166,000, which is estimated to occur at May 21, 2025 UTC. All Taiko Alethia node operators must update their Taiko Alethia node and Raiko instances before this date. Please consult the documentation on the necessary steps to upgrading your Raiko instance here.

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.

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 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, find out more here.

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.

Let’s keep building towards the based future of Ethereum.

Explore open positions on our job board.

Get the latest from Taiko:

• Website: https://taiko.xyz.

• Discord: https://discord.gg/taikoxyz.

• GitHub: https://github.com/taikoxyz.

• Twitter: https://twitter.com/taikoxyz.

• Community forum: https://community.taiko.xyz.

• YouTube: https://www.youtube.com/@taikoxyz.

• Warpcast: https://warpcast.com/taikoxyz.

Contribute to Taiko on GitHub and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the contributing manual.