Jakarta Protocol Upgrade

The Jakarta protocol upgrade, the ninth amendment to the Tezos protocol, activated on Mainnet in June 2022. It introduced two major technical features: Transaction Optimistic Rollups (TORUs) and the Sapling integration for shielded transactions. TORUs represented the first step in Tezos's rollup-centric scaling roadmap, enabling the optimistic execution of transactions off-chain with on-chain dispute resolution. The Sapling feature integrated the Zcash Sapling circuit into the Michelson type system, allowing developers to build privacy-preserving applications with shielded pools directly on Tezos.

For operators and integration teams, Jakarta's primary operational impact was the introduction of new Michelson types and operations for both TORU communication and Sapling state management. Bakers and node operators were required to upgrade to a compatible Octez client version to validate these new operations. The upgrade did not alter the consensus mechanism or block time, which remained on Tenderbake with 30-second blocks, but it expanded the protocol's computational surface with new cryptographic primitives and the rollup inbox mechanism.

Jakarta's legacy is now defined by deprecation risk. TORUs were superseded by the more general Smart Rollups introduced in Mumbai and activated on Mainnet in Nairobi, making the Jakarta-era TORU implementation a dead-end path. Teams that built on TORUs must migrate to Smart Rollups. The Sapling state, while still present, has seen limited adoption. Builders maintaining legacy Jakarta-era contracts should assess their dependency on deprecated rollup operations and plan migration work. Chainscore Labs can assist with a structured review of legacy TORU integrations and Sapling contract dependencies to identify breaking changes and migration requirements.

The Jakarta protocol upgrade introduced Transaction Optimistic Rollups (TORUs) as Tezos's first optimistic rollup solution on Mainnet. TORUs function by moving transaction execution off-chain, where a rollup operator batches transactions and posts only the resulting state commitments to the Tezos Layer 1. The protocol enforces correctness through a dispute window, during which any observer can challenge an invalid state transition by posting a fraud proof. If a challenge succeeds, the operator is penalized, and the chain reverts to the last valid state. This mechanism shifts the trust assumption from requiring every validator to re-execute all transactions to a model where a single honest watcher can protect the system's integrity.

The upgrade also activated the Sapling state, integrating the Sapling zero-knowledge proving system directly into the Tezos protocol. This introduced two new Michelson types: sapling_state and sapling_transaction. A smart contract can maintain a sapling_state as part of its storage, allowing users to submit shielded sapling_transactions that encrypt sender, receiver, and amount data. The protocol verifies the associated zero-knowledge proofs on-chain, ensuring transaction validity without revealing the underlying data. This enshrined privacy primitive allows developers to build confidential token contracts and shielded DeFi applications without relying on external privacy layers.

Operationally, TORUs introduced a new rollup node software component that operators must run alongside their Layer 1 node to monitor the rollup state and submit fraud proofs when necessary. The security of any TORU-based application depends on the presence of active, honest watchers during the dispute window. For the Sapling state, integration teams must handle new RPC endpoints for shielded balance queries and ensure their wallet and indexer infrastructure can process the opaque sapling_transaction operation type. Both features represent a significant expansion of the protocol's surface area, introducing new trust assumptions and operational requirements that demand careful review.