Paris Protocol Upgrade

Bakers must upgrade to a Paris-compatible Octez client version before activation. The reduction to 10-second block times and the new Adaptive Issuance mechanism require updated daemon configurations. Validate that your baking infrastructure can handle the increased attestation frequency and that your reward payout scripts correctly interpret the new staking and issuance balances. Failure to upgrade will result in missed endorsements and potential slashing.

The shift to Adaptive Issuance fundamentally changes the economic model for bakers and delegators. Staking is now a distinct, non-custodial action from delegation. Bakers must configure their staking parameters and ensure their delegators understand the new mechanism to avoid losing yield. Exchanges and custodians need to build new transaction workflows to support staking operations, distinct from simple delegation, to maintain competitive offerings.

The Mainnet activation of the DAL requires dedicated infrastructure. DAL node operators must provision sufficient storage and bandwidth to attest to and distribute slot data for Smart Rollups. Bakers who also run DAL nodes need to coordinate their attestation schedules. Rollup operators should immediately begin testing their kernel's ability to publish and fetch data from the DAL, moving away from calldata-based availability solutions.

The new protocol introduces breaking changes for Smart Rollups, including new inbox structures and proof system adjustments tied to the DAL. Rollup operators must upgrade their kernels and nodes to a compatible version. DApp teams should test their full transaction lifecycle on Ghostnet, focusing on the increased finality speed and new gas model. Verify that indexers and front-end RPC calls correctly parse the new operation types and balance updates.

Chainscore Labs provides a structured readiness assessment for the Paris upgrade. We review your baker infrastructure, staking configuration, rollup kernel compatibility, and indexer schemas against the activated protocol. Our team can simulate the activation on Ghostnet, verify your operational playbooks, and audit integration code for new staking and DAL workflows to ensure a seamless Mainnet transition.

Start with the Octez protocol documentation for Paris before relying on secondary summaries. Treat it as the canonical technical reference for protocol-layer changes such as Mainnet DAL activation, 10-second block timing, and Adaptive Issuance and Staking behavior. Operators should map each listed change to an owner: baker operations, DAL node operations, indexer schema updates, wallet UX, exchange confirmation policy, or staking product logic. If internal runbooks reference older Oxford or Nairobi assumptions, update them against the Paris protocol page and record any unresolved interpretation questions for engineering review.

Paris readiness depends on running Octez components that understand the activated protocol and any required node, baker, accuser, signer, and DAL-node behavior. Use the official Octez release stream to confirm supported versions, migration notes, and any known operational warnings. Infrastructure teams should test the exact production build in staging, validate snapshot import and node replay behavior, confirm baker daemon flags, and verify that monitoring still captures consensus, mempool, DAL, and staking-related signals after the upgrade.

For protocol engineers and auditors, the Tezos source repository is the authority for implementation details behind the Paris protocol. Use it to inspect protocol code, tests, RPC behavior, economic constants, and DAL-related modules rather than relying only on release announcements. Teams maintaining indexers, custody systems, wallets, or formal verification pipelines should pin the relevant commit or release tag used in their analysis, document any assumptions about protocol hashes, and avoid copying constants from blog posts without checking the implementation.

Use the official Tezos documentation as the operational bridge between protocol changes and application behavior. For Paris, this is especially relevant for teams that need to understand how staking, baking, rollups, and the Data Availability Layer are represented to builders and infrastructure operators. Wallets and staking products should review user-facing terminology and delegation or staking flows; rollup and data teams should validate DAL assumptions; exchanges should confirm whether faster block production changes deposit-crediting or reorg-risk policies.

Tezos Agora is useful for reconstructing the governance context around Paris: proposal discussion, amendment-cycle materials, and ecosystem rationale. Risk teams should separate governance narrative from protocol facts, but the governance record is still important for explaining why Adaptive Issuance, Staking, DAL activation, and block-time changes were introduced together. Use it for audit trails, stakeholder briefings, and identifying unresolved ecosystem debates that may affect baker participation, staker behavior, or future parameter-change proposals.

After Paris activation, verify real network behavior with reputable explorers and indexers rather than assuming the upgrade completed cleanly for every dependency. Monitor block cadence near the 10-second target, missed attestations, baker performance, staking balance movements, DAL-related activity, and indexer lag. Exchanges, custodians, and DeFi protocols should compare their internal views with external explorers to catch parsing errors, delayed balance updates, or confirmation-policy mismatches introduced by the new protocol economics and timing assumptions.