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

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