The past nine months since the Berkeley upgrade have brought significant developments across the Mina ecosystem.
After careful consideration and extensive testing, we at o1Labs believe now is the time to outline our commitments for the upcoming upgrade. This proposal details specific improvements we would like to deliver, potential additions still under consideration, and ongoing development efforts that will continue beyond this upgrade.
Priority Improvements
Enhanced Upgrade Automation
Though perhaps the least exciting feature from a technical perspective, improved upgrade automation represents our highest priority. The manual, time-sensitive nature of the Berkeley upgrade created unnecessary complications that we refuse to repeat. Our solution ensures nodes will automatically switch to the new version, significantly streamlining the upgrade process while maintaining security and consensus integrity.
Reduced Slot Time
Slot time improvements stand as our headline feature for this upgrade. The current 180-second slots negatively impact finality, throughput, and zkApp responsiveness across the network. Our testing has already validated 90-second slots in private clusters under substantial load without issues. The performance team continues optimizing to determine how low we can safely reduce this parameter without compromising chain stability. The final proposed slot time will be specified in the upcoming formal MIP, balancing improved performance with our commitment to preventing missed blocks.
zkApp Account Update Limit Increases
During the Berkeley upgrade, we implemented a simplification where each zkApp transaction required its own snark work. While this approach served immediate needs, it created strict limits on zkApp transaction size and complexity. The upcoming upgrade will deploy our existing mechanism for splitting zkApp transactions across multiple snark works, effectively removing these constraints and enabling more sophisticated zkApp interactions.
*Ultimately we want to remove these limits entirely but we are not confident that this will be ready in time. At a minimum, we are confident we can deliver a 2x improvement. If we can deliver a better increase before that time then we will.
Potential Additional Improvements
Increased Network Throughput
Mina possesses tremendous throughput potential that remains largely untapped. This upgrade introduces the first iteration of throughput improvements, complementing the removal of zkApp limits by increasing available block space. These enhancements will allow zkApps to become more complex and powerful while also alleviating congestion during high-demand periods like staking payouts at epoch transitions.
Expanded Event and Action Limits
The Berkeley upgrade established conservative limits of approximately 16 field elements for actions and events in account updates. Our optimizations now enable a dramatic increase in this capacity, facilitating more sophisticated action queuing and enabling advanced features like full merkle paths in events for account updates.
Enhanced zkApp Application State
The original 8 field element app state size was somewhat arbitrary when Berkeley launched. Based on real-world developer feedback, we’re increasing this to 32 field elements—a more informed trade-off that maintains efficient transaction processing while removing race conditions from many use cases. This change also supports more elegant Protokit settlement to Mina, allowing applications to build with fewer compromises.
Historical Preconditions Support
While zkApps can currently access protocol state, they face challenges making assertions about certain state fields due to block timing uncertainties. To address this limitation and enable more interesting use cases—like leveraging chain-generated randomness—we’re extending the API to allow zkApps to “look back” at recent historical blocks. This feature also unlocks off-chain assertions about the Mina merkle tree in zkApps by tying merkle tree views to the chain’s recent past when an app executes.
On-Chain Governance Mechanisms
We’ve intentionally excluded on-chain voting mechanisms from our confirmed improvements as we believe community consultation is essential for designing effective governance systems. Similarly, the Mina Foundation’s vision for a decentralized treasury using on-chain governance requires further refinement. While we’re beginning to prototype these systems, we won’t delay the upgrade for these features—our priority remains delivering on previously established commitments.
Automated Staking Payouts
We’re approaching a satisfactory design for automated staking payouts and will seek direct feedback from node operators and stakers, as well as through the formal MIP process. We believe we can deliver a solution that significantly improves the staking experience for all participants. If the design achieves community consensus quickly, we’ll aim to include this feature in the upcoming upgrade.
Partial Release of the Rust Node
While fully auditing a new client implementation represents a substantial undertaking, our testing demonstrates that parts of the Rust node are approaching production readiness. Rather than waiting for the complete implementation, we’ll begin releasing well-tested, high-confidence components of the Rust codebase embedded within the existing OCaml node. This approach will deliver incremental performance gains, memory improvements, and overall node quality enhancements while we continue progressing toward the full Rust node implementation.
Ongoing Development Beyond the Upgrade
zkApps API Redesign
Developer feedback has highlighted that the current zkApps API, while flexible, sometimes lacks guardrails that ensure secure, composable contracts. We’re exploring a refined design that maintains composability while reducing complexity and potential security issues. Current efforts focus on improving state property assertions and enhancing communication mechanisms between account updates within transactions.
Consensus Layer Improvements
While Mina’s Ouroboros Samasika represents a groundbreaking fully zero-knowledge consensus layer, certain properties create suboptimal conditions for bridging and finality. Our ongoing research aims to preserve Mina’s unique succinct consensus while dramatically reducing the number of blocks required to achieve finality. As this design matures, we’ll publish a whitepaper and formal MIP for community review.
Project Untitled Integration
As we advance [Project Untitled], we’re designing optimal integration patterns with Mina to create an ideal system for shared mutable state in decentralized applications. This project directly addresses a fundamental challenge: Mina’s lightweight design requires complementary systems for state management that prevent race conditions in multi-user environments. Mina will maintain first-class citizenship in this project, furthering our path toward decentralized Protokit app chains and enabling larger-scale zero-knowledge collaborative applications without compromises.
MIP Process
In the next few weeks, we’ll publish formal MIPs detailing each planned change. Based on initial positive feedback, we anticipate moving efficiently through the design validation process with the community before opening these proposals for voting.
We also welcome community MIPs. Something that isn’t included in our current plans at all is tokenomics. We are not experts in this area but do welcome proposals from the community.
Following MIP finalization and approval, we’ll commence a comprehensive testing phase lasting up to three months to ensure protocol stability and allow exchanges adequate time to prepare for the upgrade. Our current timeline projects mainnet deployment of this upgrade during fall 2025.
Dependencies
Moving forward we want to make much more frequent upgrades, using the improved hard-fork mechanism to get improvements into the protocol quickly. To achieve this, we don’t want to repeat the mistakes of the Berkeley release and commit to a large number of features. Instead, we want to prepare things, promote them, and then ship them when ready and approved. This means that, for this upgrade and future upgrades, we will avoid delaying the release for any particular feature. This is also why we have broken down the features into different buckets: we want to be as transparent as possible and hope you will appreciate the approach. We will continue working and testing to see what other features could be included in the upgrade if they are ready and pass the MIPs process.
One area where we have less confidence is exchange readiness. We are very confident that the engineering will be ready: most of it has been done already and many features are already in testing. However, exchanges each have their own constraints and timelines, and there are no guarantees that they will be able to move ahead with these particular dates. We will start reaching out to exchanges now and will keep the community fully updated as things progress.
Conclusion
This upgrade represents a critical evolution for Mina, addressing immediate technical needs while laying groundwork for future innovations. We deeply appreciate everyone who has contributed to these improvements and the broader community supporting Mina’s continued development.
The changes outlined in this proposal—from automated upgrades and reduced slot times to expanded zkApp capabilities and throughput enhancements—collectively strengthen Mina’s foundation as a lightweight, scalable, and developer-friendly zero-knowledge platform. We look forward to working with the community to refine these proposals and deliver a successful upgrade in the coming months.
