Mesa upgrade

Mina’s Mesa upgrade halted the layer-1 blockchain for eight hours on September 3, forcing zero-knowledge applications to regenerate their verification keys before resuming operation. The disruption highlights the technical complexity of coordinating major protocol changes across decentralized networks and dependent applications.

• Network halted transaction processing for approximately eight hours during September 3 mainnet transition to Mesa release.
• Slot time reduced from three minutes to 90 seconds, and zkApp transactions temporarily capped at 12 per block.
• Deployed zkApps require new Mesa-compatible verification keys compiled with o1js 3.0 before proof-authorized transactions resume.

• 8 hours Total network downtime during mainnet transition from pre-Mesa to Mesa release
• 90 sec New slot time after upgrade, halved from previous three-minute interval
• 12 Temporary transaction limit per block for zkApp activity during Mesa launch
• 18:00 UTC Time of first completed Mesa slot on September 3

Background on Mina and Zero-Knowledge Proofs

Mina Protocol distinguishes itself as a minimal blockchain by focusing on succinct zero-knowledge proofs rather than storing complete transaction history. Zero-knowledge applications, or zkApps, represent a core feature enabling privacy-preserving and computationally efficient smart contracts. The Mesa upgrade represents one of Mina’s most significant protocol updates, addressing performance bottlenecks and improving the developer experience for zkApp creators.

Unlike traditional blockchains that store gigabytes of historical data, Mina maintains a constant blockchain size of approximately 22 kilobytes through cryptographic proofs. This design philosophy makes Mina attractive for mobile and resource-constrained environments, but it also creates unique challenges when upgrading core protocol parameters that zkApps depend on.

Coordinated Upgrade Timeline and Phases

Mina’s transition to the Mesa upgrade on September 3 split into distinct phases as the network migrated its core protocol. The first phase lasted five hours, during which block producers continued generating blocks without processing transactions. A second phase of roughly three hours followed, in which the network produced no blocks at all.

Transaction processing officially stopped at 10:00 UTC, with exchanges suspending MINA deposits and withdrawals as a precautionary measure. Upgraded block producers began creating empty blocks at 100 slots before block production halted entirely at 15:00 UTC. This structured approach, though disruptive, allowed the network to migrate safely without leaving the protocol in an inconsistent state.

The staged shutdown reduced risks associated with partial upgrades or split consensus where some nodes run different protocol versions. Mina Foundation provided detailed upgrade runbooks to guide node operators through each phase, establishing clear checkpoints and rollback procedures if critical issues emerged during the transition.

Mesa Package Released and First Slot Completed by Evening

The Mesa package released at 16:30 UTC, with the first Mesa slot completing at 18:00 UTC on September 3.

Mina’s official upgrade runbook marked both milestones as completed, signaling successful protocol migration. Archive-node and manual node upgrades remained in progress the following morning, though the protocol itself had successfully transitioned. Each exchange retained discretion over when to resume MINA transfer support, meaning deposit and withdrawal availability varied across platforms even after the network came back online.

This decentralized approach to exchange participation reflected industry norms where centralized platforms maintain their own risk management procedures independent of blockchain protocol governance. Some exchanges resumed trading immediately after network recovery, while others implemented additional verification periods.

Slot Time Halved and zkApp Verification Keys Now Incompatible

The Mesa upgrade reduces slot time from three minutes to 90 seconds, accelerating block production across the network by 200 percent. Faster slots enable higher transaction throughput and reduce confirmation times for users, addressing one of the primary scalability concerns raised by Mina community members. However, this performance improvement comes with coordination requirements for downstream applications.

The release also temporarily caps zkApp transactions at 12 per block, a restriction imposed after stress tests revealed memory spikes when developers experimented with removing the previous soft limit on zero-knowledge application throughput. The memory issues indicated that zkApp compilation and proof verification consume resources proportional to transaction volume, requiring careful capacity management during the early Mesa period.

The more immediate problem for zkApp developers stems from protocol-level changes to circuit constraints and constants. Mesa altered these parameters so thoroughly that proofs generated against pre-upgrade verification keys no longer verify under the new protocol. Each deployed zkApp must now regenerate its verification key using o1js 3.0 and submit the new key on-chain before it can process any proof-authorized transactions.

Mina emphasizes this is an on-chain compatibility update, not a permanent contract failure.

Temporary Fallback to Signature Authorization While Keys Update

Mina’s migration path provides a grace period during which zkApps can continue limited activity without immediately deploying updated keys. Verification-key permissions set to proof or impossible temporarily fall back to signature authorization, allowing developers time to compile and update their Mesa-compatible keys. An access permission set to proof receives the same fallback treatment.

Permissions set to impossible remain locked, preserving the security model of applications that explicitly forbid certain transaction types. Once a zkApp updates its key on-chain, the account’s transaction version advances and its original verification-key permission rules return automatically. Mina imposed no fixed deadline for this migration, meaning the signature-authorization fallback remains active indefinitely until individual developers update their keys.

This grace-period approach balances the need for protocol modernization against the practical challenges developers face when updating deployed applications. It mirrors similar upgrade procedures across other blockchain ecosystems, where breaking changes sometimes require extended transition periods.

Proof-authorized zkApp activity remains paused across the network despite the blockchain’s successful resumption, pending individual key updates from each application developer. The speed at which major zkApp projects complete their key migration will determine when the full range of zero-knowledge applications can resume normal operation on Mesa, with ecosystem observers watching for widespread adoption of the o1js 3.0 migration tooling.