I’m George Agapov, Technical Lead at o1Labs, and I’m excited to introduce o1Labs’ first MIP towards the Mina Protocol upgrade this fall!
This MIP aims to reduce the slot time for Mina’s block production, thereby improving chain throughput and transaction responsiveness and marking our first step on the path toward achieving fast finality. We’ll also address the impact on vesting schedules and our proposed risk mitigation plan, along with the technical specifics.
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 propose the following changes:
Reduce slot times from 180s to 90s.
Update the coin base constant from 720 to 360 MINA.
Update the account vesting schedule logic.
Remove the zkApp soft limit.
Why Does This Matter?
The Mina Protocol has been carefully designed to scale without compromising on decentralization. So far, much of the work has been focused on developing the protocol and ensuring that the cryptography and security are robust.
Now, we must start to showcase how Mina’s design will allow it to scale quickly while maintaining Mina’s unique, succinct design.
The specific value of 90 seconds was chosen as:
Doubles the potential throughput of the network
Remains safely within the performance capabilities of the improved system
How YOU Can Get Involved:
We are eager to hear your thoughts, feedback, and suggestions on this MIP.
Hi everyone, our team has collected some FAQs which we would like to share:
General
Will the current networking layer be able to handle the increase in performance?
Yes, the networking layer will handle the 2x increase in frequency of blocks. We don’t expect it to be a bottleneck in any meaningful way.
What changes in tooling for archive nodes, explorers, wallets and other services (eg, Mina Time Machine & epoch calculator, staking pools, etc) would the MIP necessitate?
Archive nodes - no changes required.
Slot times will be halved, so any interface displaying “time of block created” or something similar may need an update. Coinbase will change, but this will be read from new blocks without any issues. There are no other changes anticipated aside from this factor.
Vesting accounts
What are vesting accounts and locked accounts?
Firstly, they are the same thing. Most of them were created at Mina’s mainnet launch in 2021. These vesting accounts have now been paid out. However, they can also be used as part of zkApp functionality.
Who is using this?
The accounts are baked into the protocol as a feature, but they are rarely used by builders. Still, we can’t just assume they aren’t used, because someone may create a transaction that will initiate usage of such type of accounts, and it’s a bad practice to just leave these accounts unaccounted for in the migration procedure.
Who else might be affected?
We anticipate that nobody else will be affected.
Snarkwork
Re: require at least some of the community members running the SNARK workers to run multiple (at least 4) SNARK workers per coordinator to ensure timely processing of SNARK work for the heaviest transactions.
What will be the incentive to provide SNARK work? Are snark fees expected to increase?
The Snarketplace is backed by market forces. We can only speculate about it.
However, if transactions on Mina increase or become much more sophisticated, we may need more snark work. If there is a higher demand for the snark work, the fee will naturally start reflecting that so that demand and supply meet.
What would a snark coordinator and 4 or more workers require in terms of server specs and cost?
For the most sophisticated transactions to be sent at maximum scale, we need at least some snark work operators to run more than 4 workers per coordinator. If they were running one coordinator and 1 worker, and now they’ll be running 4 workers, the server costs will rise proportionally to the number of extra CPUs that need to be allocated. At least one snark work operator already runs many tens of workers on a single coordinator; for them, the cost won’t change.
Great and much needed proposal, and I like new SNARK worker optimization scheme allowing for parallel proving.
If the coordinator uses many SNARK workers to calculate proofs in parallel, and one of those workers produces an invalid proof that cannot be merged because it cannot be verified, how will this edge case be handled? Will the entire proof‐creation process fail, or will there be a mechanism to reject and re‐calculate just the invalid proof?
Would the coordinator be able to start SNARK workers on demand (for example, by sending a POST request to a webhook provided via command‐line arguments) to obtain as many workers as needed for parallel proof calculation, and then send to them shutdown command as soon as the work is done?
In our design, the coordinator and its SNARK workers are assumed to be operated by the same entity and are launched from the same package/executable. This assumption simplifies trust boundaries and configuration expectations across the system.
Proof Validity Assumptions
Under this model:
Invalid proofs are not expected to be produced in normal operation.
If the same executable is used across coordinator and workers, the only realistic cause of invalid proofs would be a misconfiguration or a bug.
Therefore, proof verification by the coordinator serves as a redundant sanity check, not as a primary defense mechanism.
The coordinator verifies the proof for the full transaction, not for individual account updates or sub-proofs. This decision reflects the underlying assumption that all components are operating within the same trusted system.
If, in the unlikely event, an invalid proof is generated:
The coordinator will reject the full transaction and not forward it to the network.
This will be treated as a critical bug or a configuration issue, not a routine error.
Handling this failure at the account-update level is considered unnecessary, as such failures are not expected to happen in practice.
Dynamic Worker Scaling
We haven’t yet implemented a mechanism to launch SNARK workers on-demand via API, but in principle, this is feasible. Currently:
The coordinator is designed to accept any number of worker connections, without needing reconfiguration.
This allows infrastructure-level logic (e.g., a watchdog or autoscaler) to deploy additional workers as needed.
For example, if CPU usage of existing workers is saturated, a monitoring service could spin up more workers to distribute the load.
This means no changes to the coordinator or Mina node code are needed to support dynamic scaling—only infrastructure scripting (e.g., Kubernetes, Docker, systemd) is required.
While this kind of dynamic worker dispatch hasn’t been the focus so far, it remains a viable direction if operational needs evolve.
I fully support this proposal. One thing that concerns me is propagation, which has always been an issue on MINA. Will there be significant networking improvements bundled into the hardfork?
Given “heavier” blocks and the potential for more missed slots, this encourages BPs to add even more redundancy and more block-producing nodes to increase their chances of any block being propagated. This further increases the level of gossip of blocks from the same producer, exacerbating the issue. As seen previously, these effects have been very hard to reproduce in any testing environment.
Limiting the number of nodes that a BP can run other than via social consensus seems problematic, given the lack of slashing.
While this release does not include networking-related updates, the issue you’re referring to is being addressed through significant protocol-level improvements.
Problem in Previous Versions
In earlier releases, block creation took over 100 seconds roughly every 10th block, and under load, block creation times were significantly longer than 100 seconds. This created a cascade of issues:
Blocks were propagated only to the creator’s immediate peers
Those peers often lacked sufficient time to verify and propagate the block before the next slot
Consequently, only a portion of the network could reliably include and build on that block, leading to inconsistencies or missed blocks
Improvements in This Release
The upcoming hard fork delivers substantial optimizations to block creation and processing:
Block creation time: under 45 seconds (preliminary numbers from pre-release versions)
These are preliminary performance metrics—we will confirm final numbers from late-stage cluster testing when all hard fork protocol changes are tested together
Expected final performance: consistently under 30 seconds for creation and processing
With the new 90-second slot time, this means:
Block creators can propagate blocks to their peers with ample time for:
Full block verification
Further propagation to their peers
Second-degree peers (neighbors of neighbors) will definitely receive blocks within the slot time and most likely will be able to verify them before their own block production turn
Compared to the previous state (180-second slots with 100+ second block times), the network now has significantly higher likelihood that:
Every block reaches relevant block producers in time
Block production remains coherent across the network
Future Networking Improvements
To completely solve the issue—particularly in large or high-diameter networks—we plan to implement header-based block synchronization:
Distribute block headers first
Require nodes to validate and forward only headers (computationally cheap) without waiting for full block verification—the full block will still be verified by every node, but nodes won’t wait for complete verification before propagating to peers
This allows the network to rapidly propagate block references, ensuring all potential block producers know the latest block in time
We explored this approach before Berkeley. While that effort was paused, we’re now considering reviving it or implementing a similar architecture.
The advantage: this doesn’t require a hard fork. Berkeley’s upgrade introduced a body_reference field in the header format, allowing us to implement the new networking protocol entirely through a soft fork when prioritized.
Conclusion
While this release doesn’t include networking changes, the protocol improvements significantly reduce block creation and verification time, improving network behavior under the new 90-second slot time.
Key points:
We are maintaining network stability while reducing slot time from 180 to 90 seconds
Despite the reduced slot time, the system is more robust due to protocol optimizations
A complete solution will come with future networking updates, but we’ve already substantially improved the status quo
I’d also like to follow up on one important point. Based on our observations, the networking protocol itself—specifically the challenge of transmitting large blocks (tens of megabytes)—has not been a bottleneck in our experiments. In other words, simply sending block bytes from one node to another has not posed a significant issue.
Instead, we consistently found that block verification time is the primary limiting factor. This is why our current focus has been on protocol-level improvements that reduce verification time, rather than networking-layer optimizations.
That said, if you’ve observed cases where block propagation of large payloads is noticeably delayed or degraded, please let us know. We haven’t encountered such issues in our testing, but if there’s evidence suggesting otherwise, we’d be happy to investigate further to ensure that this release does not introduce additional risk on that front.
The 90-second slot time was chosen deliberately based on network propagation requirements. Specifically, in order for a block created by one block producer to reliably reach all other producers across the network, the slot time should be at least three times the maximum block processing delay. This is not a fundamental protocol constraint, but rather a practical one, given the current state of our networking stack.
With future upgrades to the networking layer, we expect to relax this constraint. Ideally, the slot time could then approach the actual block production time plus a small delta, significantly improving latency. However, doing so without networking improvements would likely result in network instability due to missed or late blocks.
To give more context:
30 seconds is not feasible today—it’s too short for reliable propagation under current conditions.
60 seconds might work, but introduces a non-negligible risk of increased orphan rates or missed blocks, similar to one Gareth mentioned above.
Therefore, we chose 90 seconds as a conservative and safe default for the upcoming hard fork.
Reducing the slot time further (e.g., to 30 seconds or lower) is something we plan to revisit in a future hard fork, once we’ve introduced improvements to the networking protocol to support lower-latency, higher-reliability block dissemination.
A lot of fruitful work has been done. I fully support all the directions of modernization developed by the o1Labs team. I would like to note their thoughtfulness: the slot time will be halved, while the inflation issue will not be overlooked (from 720 to 360 MINA).
Yes, the delays are mainly driven by verification, but I want to point out a few details here.
We were creating blocks in under 30 seconds, yet they still weren’t able to make it into the 3 minute block slots. There have been significant improvements at many levels, but they still don’t address the biggest underlying issue networking.
The reason I say networking is the core issue is that during verification, block size handling, SNARKs, mempool behavior, and peer behaviours, none of these components perform well under load. The delays and issues from each of these areas compound the limited network capacity. This results in blocks not propagating, transactions not being included in blocks, and various other problems.
As two of the biggest SNARK producers Gareth’s and our SNARK coordinator, one using sequential and the other using random selection improved network performance somewhat by reducing duplicated SNARKs. But in a public mainnet environment, there are many different actors, all behaving differently. Running a snark worker which creates bunch of duplicate snarks or sending a lot of transactions is not that actor’s fault. Network not able to handle the load is networks problem. Decentralized networks doesn’t operate efficiently. The limits at networking layer just cause issues on other things I mentioned before. We can’t have all sorter because of networking limitations. From my opinion that should be a priority.
From what you’ve written, I can see that blocks are getting high priority on the node side, but the issue of transactions making it into blocks will likely persist. Even though the verification time of large blocks with many transactions have somewhat an affects on this issue because of big blocks not getting verified in time and getting orphaned while empty ones getting verified and become canonical. We shouldn’t be choosing getting transactions in to block or block propagating consistently.
From everything I’ve seen since genesis, I don’t believe the chain can function with strong performance without actual improvements at the networking layer. I hope I’m wrong about this, but I haven’t seen any data to support the opposite across multiple updates and improvements since genesis.
Exactly - this aligns with our observations. The key insight is that block creation time is only part of the equation. What really matters is the end-to-end process: block creation plus block application across all nodes that receive the block.
We observed that while block creation was taking 30 seconds on the block producer, block application on receiving nodes was taking over 100 seconds. In a network requiring at least two hops for blocks to reach every block producer, this creates a cascading delay problem. Even with 30-second block creation, you get 100 seconds for the first hop plus another 100 seconds for the second hop - totaling over 180 seconds, which exceeds our current limits.
This is why the improvements preceding this MIP focus on the complete pipeline. We’ve implemented changes to ensure that both block production and block application are constrained to 30-45 seconds maximum, providing the necessary buffer to stay well under new 90-second threshold even with multi-hop propagation.
I agree that networking presents significant challenges across those components. However, I believe block application time remains the primary bottleneck. While we’ll certainly encounter mempool and networking issues under load, these are likely to be secondary factors when evaluating the 90-second slot reduction proposal. These networking challenges, though real, aren’t directly tied to the slot timing change and won’t be materially worsened by implementing this improvement.
I agree, and we also recently implemented a random offset selection, which (if adopted by the majority of snark work producers) we expect to yield results that are significantly better than the current combination of some snark work pools running in sequential mode and others in random mode.
Agreed. We have several networking improvements in mind to tackle these performance issues.
Exactly. Solving the transaction inclusion problem will require redesigning our transaction pool architecture. This is on our radar for post Fall 2025 hard fork work. It’s a complex challenge, but addressing it is one of the high priority items.
We believe we’ve addressed this issue during our MIP preparation work.
I fully agree with you. However, we’re prioritizing block application issues over networking layer issues because our investigations consistently reveal that apparent networking problems are often caused by extremely slow block processing. This processing was unnecessarily slow and somewhat unpredictable.
We believe the preparatory work for this MIP has resolved the block application issue, though future networking improvements remain necessary. For this MIP our goal is to both reduce block propagation latency and address the networking consistency problems we’ve identified on the existing network.
: