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.

3 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