I’m Florian, Technical Lead at o1Labs, and I’m happy to introduce a new o1Labs MIP for the Mesa Upgrade!
This MIP proposes increasing the current limit on the number of on-chain state fields that a zkApp account can store on-chain. The change aims to give developers greater flexibility to store and manage larger amounts of application data directly on-chain, enabling more sophisticated zkApp designs while preserving Mina’s succinctness guarantees.
You can read and comment on the full technical MIP on Github and we’ll be engaging here with any questions or comments you have about the proposal and the process.
What’s Changing?
We are increasing the maximum number of on-chain state fields per zkApp account from 8 to 32.
Why Does This Matter?
Currently, Mina restricts each zkApp account to store a fixed number of on-chain state (currently 8 field elements). These registers hold application-specific data that can be read and modified by smart contracts. As zkApp complexity grows, this requires developers to use workarounds to pack multiple values into a single field element, splitting state across multiple accounts or falling back to off-chain account storage and only storing the data root on-chain, complicating code and zkApp design. Advanced zkApps such as on-chain order books, multi-step protocols, or rich metadata storage become cumbersome or even infeasible.
By raising the state-size limit, we can support more advanced applications without sacrificing Mina’s succinctness.
How YOU Can Get Involved:
We are eager to hear your thoughts, feedback, and suggestions on this MIP.
provedState, a boolean which is true if the entire on-chain state
of this account was last modified by a proof
Does it mean that the SmartContract will see provedState set to true only if ALL 8 Fields are changed by proof before the hardfork and ALL 32 Fields set by proof after hardfork, leading to the change of the SmartContract behavior in case the contract relies on provedState and uses only 8 Fields?
What is the recommended upgrade path, and will o1js issue the warning during compilation for such cases?
As of right now, we didn’t plan any changes to how provedState is handled on the protocol side - this, however, could also be a part of the migration process if you (and others) think that’s important.
Currently, after the HF a zkApp developer will need to re-deploy their zkApp with the new verification key (which is generated by compiling your zkApp with the new o1js version). The state of the zkApp account (existing state, balances, flags, etc) will remain after the HF. Deploying the new verification key to the network behaves the same way as redeploying a zkApp to the same account.
If you think we should migrate the accounts to provedState = false after the HF and consider special cases for that, let me know!
Great work on this proposal, it addresses a fundamental need for developers.
The 8-field limit has long been a bottleneck for building truly powerful zkApps on Mina. Increasing it to 32 fields unlocks the ability to design more ambitious apps: on-chain order books, multi-step protocols, games, identity layers, and more. This is a concrete and impactful improvement, fully aligned with Mina’s core promise: enabling private and verifiable programmability.
I also appreciate the careful approach to preserve the protocol’s succinctness.
A few questions/considerations:
What is the expected impact on system performance (proving/verifying time, account size, etc.)?
Will there be public benchmarks or examples of zkApps leveraging the 32-field capacity?
Will this change come with new tools or guidance to help developers adopt it more easily?
Overall, this proposal sends a strong and encouraging signal to the builder community. Thanks for the great work
What is the expected impact on system performance (proving/verifying time, account size, etc.)?
We don’t expect any significant changes in proving speeds, the only change we expect is an increased ledger size (form roughly 256 bytes per account to 1024 bytes per account) - which is more than manageable and expected.
Will there be public benchmarks or examples of zkApps leveraging the 32-field capacity?
Yes, part of the work in o1js to support the new 32 state fields will include examples of zkApps using all the new state fields.
Will this change come with new tools or guidance to help developers adopt it more easily?
Luckily, there won’t be a need for new tools! The documentation will be adjusted to reflect the increased on chain state, o1js will natively handle that change which will make it very easy for developers.
