MIP Proposal: Validator Self-Declaration for Improved Block Production and Network Health

MIPs (Mina Improvement Proposals)
1

Summary

This proposal introduces an opt-in mechanism for block production on the Mina Protocol. Validators would be required to explicitly declare themselves as active participants, making them eligible for block production.

The aim is to improve slot fill rate, network liveness, and overall protocol efficiency, while minimizing disruption to Mina’s lightweight and zk-friendly design.

Motivation

Currently, any account with sufficient stake is eligible to produce blocks. However, many large stakeholders (especially custodians or exchanges) do not actively participate in validation. This results in:

  • Low slot fill rate (often ~60% on mainnet, and worse on devnet)
  • Degraded throughput and responsiveness
  • Inefficient use of the VRF-based leader election

On the devnet, this problem is particularly acute. Block production is so sporadic that developers frequently wait up to 30 minutes for transactions to be included. This hampers zkApp development and discourages experimentation.

Proposal

We propose:

1. Validator Self-Declaration

Introduce a lightweight, explicit transaction (e.g. register_validator) that a node must submit to be considered for block production.

  • This transaction could be required once per epoch (or every N epochs)
  • Only accounts that have declared themselves as validators would be included in the VRF slot lottery
  • The logic for leader selection remains unchanged; the only difference is limiting the eligible set

2. Automatic Expiry of Validator Status

If a declared validator fails to produce any block (canonical or orphaned) over a defined period:

  • Their validator status automatically expires
  • They must re-submit the self-declaration transaction to regain eligibility

This prevents the accumulation of “dead” or inactive validators

3. Fallback Mechanism

To preserve network liveness and decentralization:

If the number of declared validators falls below a threshold (e.g. set via consensus variable), the protocol reverts to the current behavior, where all stake is eligible

4. Wallet Integration Benefits

Validator self-declaration allows wallet providers (e.g. Auro) to:

  • Display only self-declared, active validators in delegation lists
  • Warn users delegating to inactive validators
  • Encourage redelegation when a validator’s status expires

This improves the delegator experience and helps prevent loss of rewards.

Security Considerations

Benefits

  • Improved liveness and throughput
  • Reduction in missed slots and wasted VRF computation
  • More predictable network performance, especially for developers

:warning: Risks

  • If too few validators declare, there is a risk of centralization
  • Can be mitigated via fallback logic and minimum thresholds

No additional slashing mechanisms are proposed, maintaining safety and simplicity

Stake Analysis Examples

  • Binance holds >1% of total MINA and does not run a validator
  • B62qrQKS9…ny9 owns over 7% of circulating supply, never produced a block, and doesn’t delegate

These are just two among many passive large stakeholders impacting network performance.

Rejected Alternatives

Forced Delegation

Some proposed forcibly reassigning inactive stake to “well-performing” validators. This is rejected because:

  • It breaks ownership autonomy
  • It introduces subjectivity and centralization risk
  • Some institutions cannot legally delegate due to regulatory or tax constraints

Compatibility

  • Maintains Mina’s use of Ouroboros Samisika
  • Keeps the VRF-based block lottery intact
  • Can be zk-friendly and state-efficient (e.g., store declaration status in account state)

Conclusion

Validator self-declaration is a minimal, protocol-compatible improvement that:

  • Increases block fill rate
  • Enhances developer experience
  • Preserves decentralization and zk-compatibility

It strikes a balance between network health, stakeholder control, and implementation simplicity.

We encourage further discussion and welcome feedback from the community. If this direction gains traction, the next step will be to formalize this into a full MIP draft with technical specifications and implementation pathways.

Author: Naamah
Status: Draft
Last updated: June 7, 2025

2 Likes
2

Interesting idea, please explore further and create a MIP that can be voted on.

2 Likes
3

Hey Pete,
Thanks for your feedback and interest!

I’m not exactly sure how you’d like me to develop the proposal further, or what level of detail you’d expect in the MIP.

Also, could you clarify what you mean by “create a MIP that can be voted on”? :sweat_smile:

4

Hey! Maybe @Cris-F can help with the MIP proposal. Its just puts the idea in a standard format so it’s easy to see what changes it makes, what the positive / negative effects will be etc.

Mina has on chain voting so if it’s feasible then wallet holders can vote yes or no on the proposal to be implemented.

5

Thank you for this thoughtful proposal, Naamah. The validator self-declaration mechanism addresses a real pain point with Mina’s current slot fill rates. While the approach has merit, there are several technical and design considerations worth examining more closely.

On the Core Mechanism

The opt-in validator registration concept could potentially help with the slot fill issue. Though there’s a critical technical issue with the automatic expiry mechanism:

“If a declared validator fails to produce any block (canonical or orphaned) over a defined period: Their validator status automatically expires”

This is problematic because Mina uses secret VRF for leader selection. The protocol cannot reliably determine whether a validator “failed” to produce a block versus simply wasn’t selected by the VRF lottery during that period. Removing this automatic expiry component would still preserve the core benefit—giving stakeholders an opt-out mechanism by not reconfirming their active status each epoch.

Implementation Considerations

On the consensus layer, this would involve:

  • Discarding blocks from accounts that haven’t marked themselves as active block producers
  • Adjusting the total stake calculation to exclude inactive participants

While technically feasible, there are some governance concerns. The mechanism could theoretically allow existing block producers to influence who can join the active validator set, creating potential censorship vectors that warrant careful consideration.

Alternative Approaches

Your mention of tax/regulatory constraints for exchanges and custodians is particularly relevant. Rather than complex protocol changes, we might consider:

  1. Default delegation pools: Establish foundation-backed pools where inactive stake rewards flow directly to ecosystem grants (or are burned to ensure block production continues)
  2. Semi-manual ledger adjustments: Implement changes through hard forks rather than dynamic protocol rules, providing more predictable and auditable transitions

Data-Driven Decision Making

Before proceeding, we should quantify the scope of the problem. If inactive stake represents only ~10% of the network, the complexity may not justify the solution. If it’s closer to 30%, then active intervention becomes more compelling.

The examples you cited (Binance’s >1% stake, the 7% holder at B62qrQKS9…ny9) suggest this could be substantial, but comprehensive stake analysis would help prioritize this against other protocol improvements.

Recommendation

The proposal raises important questions about network health, but I’d suggest:

  1. Remove the automatic expiry mechanism due to VRF secrecy constraints
  2. Conduct thorough stake analysis to quantify inactive participation
  3. Consider whether simpler alternatives (default pools, periodic manual adjustments) might achieve similar outcomes with less protocol complexity

The core insight—that explicit validator participation could improve network health—is worth exploring, though we should carefully weigh the tradeoffs against Mina’s permissionless design principles.

4 Likes
6

Many thanks for your feedback. I’ll need some time to gather relevant stats — I believe @garethtdavies might already have valuable data to share on this — and to respond to your points.
I’ll try to do it asap.

7

Auto opt-out

Regarding the challenge posed by the VRF-based leader selection. I now see that without visibility into whether a validator was actually selected for a slot, we can’t reliably distinguish inactivity from bad luck.
My initial goal with the expiry idea was to gently nudge validators who opt in but silently disappear — not to penalize those who simply weren’t chosen. I agree that removing or rethinking this part makes sense, and that we could preserve the core benefits of the opt-in mechanism without it. A regular reconfirmation each epoch (or similar period) could serve the same purpose in a less error-prone way.

Governance

On the governance concerns — thanks for raising that. Just to clarify, in my proposal, validator self-declaration is fully permissionless and self-initiated. It’s not about vetting or approving validators, but simply requiring an on-chain signal (e.g. an account flag or a tx) to indicate active participation.

The idea is that only validators who voluntarily mark themselves as active will have their stake counted in the VRF, and thus be eligible for block production.

There’s no censorship or external control mechanism — the eligibility set is simply reduced to those who actively opt in. That said, I agree we should ensure this mechanism remains as lightweight, spam-resistant, and decentralized as possible.

Alternatives

Default delegation pools do sound pragmatic in theory, especially if they ensure block production continues and help redirect value to the ecosystem (via grants or burning to reduce inflation).

That said, I’m not sure this approach is actually simpler in practice.

It would require wallets to delegate to a specific pool or address by default, which introduces a new set of governance and UX questions:

  • Which pool is chosen by default?
  • Who controls that pool’s keys or manages the rewards?
  • Is it the Foundation, a DAO / Smart contract, …

These are non-trivial decisions, and the centralization risk here might actually be greater than with a lightweight, permissionless validator opt-in mechanism. So while I see merit in the idea, I think its implementation would need just as much scrutiny — especially to avoid the perception of favoring any single validator or institution

2 Likes
8

This problem has been getting worse, but the discussion has fizzled out. @garethtdavies raised on discord that last epoch there was only a 46% fill rate.

We know that any hard fork solution would only be possible after Mesa, but could we consider the default delegation pool idea as an immediate stopgap? My suggestion would be for o1Labs to operate the block producer and for the rewards to be burned or distributed to delegation program nodes in good standing. I know that who gets to control this validator is a contentious decision, but in the mean time, more and more stake is sitting undelegated.

@georgeee @naamah WDYT?

1 Like
9

How would default delegation staking work? It’s not possible to know which stake is inactive (other than probabilistically), so would have to be an action from the wallet holder to delegate to the new address - given they are inactive for a reason, what’s to suggest they would make such an action?

If any rewards were burned I don’t think this would be contentious - it would likely mean a significant decrease in existing block producer rewards as the number of slots with multiple blocks from different producers would increase substantially. We’d also have a large and increasing inactive stake on the burn address that can’t perform any action to actively delegate…

Practically, simply getting the top 2 wallet holders who control x% to delegate to a burn validator (or anyone) would be the simplest. Currently these 6 addresses control >50% of the stake.

Has there been any modelling done to changes in f assuming the current stake distribution levels?

CleanShot 2025-10-24 at 08.06.27@2x
CleanShot 2025-10-24 at 08.06.27@2x2502×698 41 KB

10

I totally agree with Gareth.

In any case, we would need a hard fork to identify pools holding a massive amount of MINA that do not run a validator or produce blocks — a kind of soft slashing, actually.
Alternatively, there could be a manual action from those pools to delegate their stake to a default validator that could burn or do whatever they decide with the block rewards.

I’m still convinced that validator self-declaration is a really good solution to address this issue with minimal impact, while also benefiting the validator community — since it would effectively double their chances of producing a block compared to the current situation.

2 Likes
11

This is the trend of it since genesis. I don’t think there is much we can do till any fork.

This will not work because we cannot know with 100% certainty which stakes are active and which are not. The problem isn’t most wallets, but rather large wallets, exchanges, and custodians. We had an exchange active years ago due to this problem, and that stake has grown to around 35 million now, considering their 10 million starting point. Since inactive amounts grow significantly faster, this wouldn’t make much of an impact.

I agree, but wouldn’t this require adjustments to the ledger? I don’t think we should go there. That would be a mess but I am most concerned about legal implications.

12

I meant just contacting and discussing with them and perform a manual transaction. They must be known to the team.

13

o1Labs is doing exchange outreach, but we have to prepare for the worst and assume that all large holders will reject to run a node or delegate their stake.

I like Naamah’s idea for BP self-identification, but going through the standard HF procedure for this sounds excruciating. I will propose taking a more active course on this if we can’t get a reasonable amount of stake participating via outreach.

1 Like
14

Yeah that make sense my bad understanding other way around but afaik foundation was also trying to do that. I don’t know the details but it can be very hard to get them onboard.

15

This was a good idea. Is anyone moving forward with it? @naamah

16

Hey Pete,

The issue has been raised again for the latest epochs on Discord (Gareth mentioned a slot fill rate of under 40% for epoch 39).

I don’t know what solution will be chosen, but I think this should be the top priority after the Mesa upgrade.

Regards,

1 Like
17

Thanks for the update. IMO I think it needs prompt action. Can we do anything to address things at the same time as the Mesa upgrade? Seems like a good idea with very little downsides from what I can see.

Anyway let me know if i can help in any way.

18

Unfortunately, this is not my decision but O(1)’s.
I feel this is an urgent issue that needs to be addressed, but I’m not sure it can be done as part of the Mesa upgrade — it may require a full MIP and a community vote.

1 Like
19

This unfortunately cannot be part of MESA and will be a priority post-upgrade.

20

Hey ya’ll, I am putting together a draft for changes that would at least allow for a solution to this problem in the event that we can get these large inactive stakers on board (we’re cautiously optimistic we can worth Binance on this point). In the event that we get them on board, this change would be the fastest way to return to a tolerable fill rate.

More robust solutions can come on top – there are many ideas floating around here and internal discussions at o1, and as I understand it they would factor through something like this anyway.

I have organized the draft as PR against my own fork of the MIP repo, and I would encourage anyone with a github account to comment there because IMO the UI is much more suited for that. Of course this is still the main thread, so up to you!

3 Likes