
Monad Validator Delegation Program - What It Takes to Stay Eligible
Overview
Written on April 2, 2026. Monad's Validator Delegation Program (VDP) defines a clear contract between the Foundation and validator operators: if you want to receive and keep delegation, you need to demonstrate consistent performance, strong observability, and operational discipline. The requirements are not abstract. They are measurable, enforced, and revisited continuously. That turns validator participation into an auditable service rather than just infrastructure deployment. Weekly uptime, timely upgrades, testnet participation, KYC/KYB, metrics exposure, and architecture choices such as RPC separation all become part of the eligibility story.
Operational Baseline

At the core of the program are a few non-negotiables. Operators are expected to maintain at least 98% uptime on a weekly basis, remain active on testnet while enrolled, complete KYC/KYB, expose required metrics to the Foundation, avoid serving external RPC from validator nodes, and stay current on network upgrades within Monad's expected response windows. These are eligibility rules, not aspirational best practices.
Observability Is Part of the Job
Context
Monad treats monitoring as part of validator participation, not as optional tooling. The node stack integrates with an OTEL collector and exposes metrics locally, which means operators are expected to route telemetry into Prometheus, Grafana, or an equivalent system. The practical implication is simple: if you cannot observe your node, you cannot prove compliance.
A good operator setup therefore includes a compact proof bundle:
7-day uptimecharts- block proposal performance and missed-slot tracking
- metrics endpoint and scrape configuration
- upgrade logs showing timestamp and version applied
- a human escalation path for incidents
Alerts and Architecture Rules
Operational Impact
At minimum, operators should alert on weekly uptime drifting toward the threshold, process failures across monad-bft, monad-execution, and monad-rpc, storage or latency spikes, missed proposals, and sync drift. These signals all sit on the same chain of accountability: OTEL to Prometheus to real-time alerting.
The architecture rule that validators must not serve external RPC is just as important. Monad is effectively forcing a clean separation of concerns: validator nodes focus on consensus and block production, while full nodes handle RPC and indexing workloads. That separation reduces the chance that public traffic interferes with validator performance.
Why This Matters
Operator Actions
The VDP signals a different model of validator participation. Rather than treating stake alone as the gate, the program emphasizes operational quality, continuous verification, and standardized visibility across the validator set. For operators, the work does not stop at deployment. It becomes an ongoing loop of monitoring, proving, and maintaining performance every week.
Sources
- VDP eligibility is performance-driven: uptime, monitoring, and operational discipline are evaluated continuously.
- The 98 percent weekly uptime threshold is a hard baseline, and repeated misses can put delegation at risk.
- Metrics exposure through OTEL into Prometheus, Grafana, or equivalent tooling is a core requirement, not optional polish.
- Validators should separate consensus infrastructure from public RPC workloads and maintain a reviewable proof bundle.
