Mina’s Mesa Upgrade – What to Expect

The Mesa Upgrade is Mina’s next major hard fork, bringing five significant improvements to the protocol – each designed to unlock greater developer capability, improve network performance, and streamline how future upgrades are carried out.

Development and testing of Mesa have already progressed through several key milestones. Internal testing, including multiple end-to-end upgrade dry runs, was then followed by the Mesa Testnet – a pre-flight network used to explore the new features. From there, we launched Mesa Trail, simulating the complete hard fork process from Berkeley to Mesa with the community, validating the upgrade process under realistic network conditions.

With these phases complete, Mesa will be deployed to Mina’s Devnet on August 19th, 2026 before progressing to the final mainnet upgrade. This post outlines what to expect across each phase of the process for both network upgrades.

What’s Included in the Mesa Upgrade

The Mesa Upgrade encompasses four Mina Improvement Proposals (MIPs) and one upgrade mechanism enhancement: 

• Slot Reduction (MIP6)*: Reduces slot time to 90 seconds, increasing transaction throughput and improving the overall user and developer experience.
• Increase On-Chain State Size Limit (MIP7): Expands the number of on-chain state fields from 8 to 32, giving developers more flexibility.
• Event/Action Limit Increase (MIP8): Raises the current limits on events and actions, enabling more expressive applications and reducing the number of transactions end users need to approve.
• Account Update Limit Increase (MIP9): Raises the limit on account updates per zkApp transaction, allowing more complex logic to be executed within a single transaction.
• Hard Fork Automation: Introduces new automation infrastructure for conducting future hard forks, making the upgrade process simpler, less manual, and more efficient.

*While this MIP proposed removing the zkApp soft limit entirely, initial stress testing revealed RAM spikes that could cause Out of Memory (OOM) issues for some nodes. The zkApp transaction limit will be temporarily set to 12 per block at launch. Because Mesa halves slot time, this preserves the same total zkApp throughput over time — zkApps have the same capacity, just with faster confirmations.

The Upgrade Process

The upgrade can be broken down into three phases: pre-upgrade, upgrade, and post-upgrade. Thanks to the automated hard fork process Mesa introduces, much of this process is more streamlined compared to previous upgrades. Network downtime is expected to be approximately 8 hours.

Note: Blocks will be empty for a 5-hour period from the stop transaction slot until the new network is deployed. 

Pre-Upgrade

• Pre-upgrade release: Node operators and exchanges should update to the pre-upgrade build published by o1Labs. This build contains the predetermined stop slots needed to initiate the upgrade. The majority of active stake will need to have upgraded to the pre-upgrade build for the fork to proceed successfully. 
• Archive node schema upgrade: In parallel, archive node operators should begin their schema migration. Documentation for this process will be released alongside the pre-upgrade build. Migration should be completed before the stop network slot is reached.

Active stake is defined as the total stake delegated to block producers that have produced at least one block in the last 10,000 blocks.

State Finalization

During the upgrade process, there will be approximately 8 hours of network downtime. Once the active stake threshold is met and the predetermined slot is reached, the network will enter the State Finalization phase and downtime begins: 

• Stop Transaction Slot: From this slot onward, upgraded block producers will produce empty blocks containing no transactions. Blocks with transactions will not be accepted. This behavior confirms the network is operating as expected ahead of the fork.

It is crucial that block producers continue running at least one node through to the stop network slot so the network can reach consensus on the block from which the upgrade will proceed. Note that block rewards will not be generated during this period, as blocks will be empty.

• Stop Network Slot: 100 slots after the stop transaction slot, the stop network slot is reached. At this point, upgraded block producers will stop producing new blocks and no new blocks are accepted. Block producers who have not upgraded will not have the stop slots configured and may continue producing blocks, which will be rejected by the network.

Upgrade

During this window, the following steps will take place:

• Mesa Package Generation: o1Labs will export the state at the fork block and generate the post-upgrade package. The ledger state and migrated archive node will be validated before the build is released.
• Automode Upgrade: Nodes running in automated mode – a new option introduced with Mesa – will independently generate their own post-fork configuration and restart on the new chain without manual intervention. Operators who prefer the manual process can still follow that path.
• Post-upgrade Release Published: Once validated, the post-upgrade release is tagged and release notes are shared with the community. Node operators operating in manual mode should begin upgrading as soon as this release is available.
• Network Deployment: Seeds, archive nodes, and monitoring infrastructure are deployed and validated ahead of block production restarting.

Post-Upgrade

• First Mesa Block: Block production resumes with the first Mesa block, expected shortly after the post-upgrade release becomes available and block producers have upgraded.
• Block Producers Upgrade: Block producers who have not yet upgraded to the post-upgrade build should do so as quickly as possible to rejoin consensus.
• Network Monitoring: The team will conduct extensive network monitoring following the upgrade to verify chain quality and confirm that the majority of stake has upgraded to the new build.

Key Roles

Node operators should monitor the #mesa-upgrade-testnet-announcements channel in Discord and their registered email for the latest release information and timing updates. Block producers must keep at least one node running through to the stop network slot. 

Exchanges should upgrade their Mina nodes to the pre-upgrade version when notified. Any transactions submitted after the stop transaction slot will not be present on the chain post-upgrade. MINA deposits and withdrawals during the downtime window will be paused. Exchanges relying on the archive node database directly should evaluate whether their integrations will be affected by the schema changes included in this upgrade.

Keep an eye on Mina Protocol Discord server, the Telegram channel or  X for the latest updates on Mesa timelines and next steps.