Ask most staking providers how their validators are performing and the answer arrives as a single number: uptime. Ninety-nine point something percent, usually presented without a time window, a methodology or a comparison point. For a retail delegator, that may be enough. For an institution with fiduciary obligations, it is closer to a marketing claim than a control.
Institutions do not stake assets in a vacuum. They answer to investment committees, auditors, risk officers and, increasingly, regulators. Each of those stakeholders will eventually ask the same question: how do you know the validator is doing its job? “The provider told us” is not an answer that survives an audit.
This is why validator monitoring has moved from a back-office engineering topic to a governance one. The relevant question is no longer whether a provider monitors its validators. Every serious operator does. The question is what the institution itself can see, how often, in what format, and whether that information is precise enough to support decisions about risk, allocation and reporting.
This article sets out what that visibility should look like in practice. It covers the metrics that matter, the alerts and incident disclosures institutions should expect, and the questions worth asking a provider before capital is delegated. Most examples reference Ethereum, where the protocol mechanics are well documented, but the principles apply across Proof-of-Stake networks.
Why Validator Monitoring Is a Governance Issue
In traditional finance, an institution that outsources a critical function keeps responsibility for overseeing it. A fund that uses a third-party administrator still reviews its controls. A bank that relies on a cloud provider still monitors service levels and incident reports. Staking is no different: delegating validator operations to a provider transfers the work, not the accountability.
Three factors make visibility especially important in staking.
Losses are often silent. On Ethereum, a validator that misses an attestation does not trigger an obvious failure. According to ethereum.org, missing the source and target votes costs the validator the reward it would have earned and an equal penalty on top. Missing a block proposal carries no explicit penalty, only the forgone rewards. Individually, these amounts are small. Across thousands of validators and a full year, they compound into a measurable gap between expected and realized yield, and nobody notices unless someone is measuring it.
Severe losses are rare but correlated. Slashing is uncommon, but the protocol is designed to punish coordinated failures harder than isolated ones. A single slashed validator on Ethereum loses a small initial amount (0.0078125 ETH for a 32 ETH validator) and is removed over 36 days. At the midpoint, a correlation penalty applies that scales with how much stake was slashed around the same time. In a mass slashing event, validators can lose their entire effective balance. The risk is less about one bad day and more about shared dependencies: the same client, the same failover script, the same data center. Monitoring is how those dependencies become visible.
Performance is relative. A validator’s yield depends partly on network conditions the operator does not control. A drop in rewards may reflect a provider problem or a network-wide event. Without benchmarking against the broader network, an institution cannot tell the difference, and cannot fairly assess its provider.
For these reasons, the transparency institutions expect from their staking providers has to go beyond published uptime figures. It needs to reach the level of data the institution can verify, store and present to its own stakeholders.
The Five Layers Institutions Should Be Able to See
Useful validator monitoring is layered. Each layer answers a different question, and a gap in any one of them leaves the institution relying on trust rather than evidence.
1. Duty performance: is the validator doing its job?
This is the foundation. On Ethereum, an active validator is asked to attest once per epoch (every 6.4 minutes, or roughly 225 times a day). Each attestation includes three votes: source, target and head. Each must be correct and timely to earn the full reward. Validators are also occasionally selected to propose blocks or join a sync committee.
At this layer, an institution should be able to see:
- Attestation participation: the share of assigned attestations that were included on-chain.
- Vote accuracy and timeliness: correct and timely source, target and head votes, reported separately. A validator can be online and still vote late or on the wrong head.
- Inclusion distance: how many slots passed before an attestation was included. Persistent delays usually point to latency or peering issues.
- Proposals: assigned, proposed and missed blocks, with the reason for each miss.
- Sync committee participation: when applicable, the share of duties completed.
The important shift is from “uptime” to duty completion. A server can be reachable 100% of the time while its validator underperforms. What the protocol rewards is completed duties, so that is what the institution should measure.
4. Alerts and incidents: what happens when something goes wrong?
Every operator has incidents. What separates institutional-grade operations is how quickly incidents are detected, how they are communicated and what changes afterward.
Institutions should expect clarity on:
- Detection: which conditions trigger internal alerts, such as missed attestations above a threshold, peer count drops, sync lag, disk pressure or client errors.
- Notification: which events are escalated to the client, through what channel and within what time frame.
- Recovery: typical time to detect and time to recover, measured and reported over time rather than stated as an aspiration.
- Post-incident reporting: a written account of what happened, the impact in missed duties and rewards, the root cause and the remediation.
One principle deserves emphasis. On Ethereum, the penalties for brief downtime are small compared with the penalties for double-signing. A provider whose incident response is built to restore service at any cost may be taking the wrong risk. Institutions should hear that their provider prioritizes safety over liveness, and see it in how incidents are handled.
5. Change management: how is the setup maintained over time?
Proof-of-Stake networks evolve continuously. Ethereum alone has gone through several hard forks since the Merge, each requiring coordinated client upgrades. Every upgrade, configuration change or migration is a moment of elevated risk.
Visibility at this layer includes:
- Upgrade readiness: confirmation that validators are running client versions compatible with upcoming network upgrades, well ahead of activation.
- Staged rollouts: changes deployed to a small share of validators first, monitored, then expanded.
- Lifecycle operations: the status of deposits, activations, exits and withdrawals, including queue positions when queues are long.
- Configuration changes: advance notice of migrations between data centers, clients or hosting setups that affect the institution’s validators.
What Good Reporting Looks Like
Visibility only helps if it reaches the people who need it, in a form they can use. In practice, institutional-grade validator reporting tends to share a few characteristics.
It is verifiable. Ethereum duty performance is recorded on-chain. An institution, or an independent analytics provider, should be able to reconcile a provider’s reported figures with public data at the validator-index level. Reports that cannot be checked against the chain should be treated with caution.
It is granular, then aggregated. Executives need a summary; risk and operations teams need detail. Good reporting starts at the level of the individual validator and rolls up into totals, so a portfolio-level figure can always be traced back to its source.
It is delivered in usable formats. A dashboard is convenient, but institutions also need exports and API access that feed their own systems: risk platforms, accounting tools, fund administrators. Reporting that only lives on a provider’s website is difficult to audit.
It is consistent over time. Metric definitions should not change silently from one period to the next. When a methodology changes, the change should be documented.
It covers more than performance. Reward reporting needs to support accounting and tax workflows, with rewards attributed by period, by source and by validator. For many institutions, this is the part of staking reporting that gets the most scrutiny from auditors.
Questions to Ask a Staking Provider
The following questions translate the five layers into due diligence. They work as part of a broader process for choosing an institutional staking partner, and they are equally useful for periodic reviews of existing providers.
Area | Question | What a strong answer includes |
|---|---|---|
Duty performance | Which duty-level metrics do you report, and at what frequency? | Attestation participation, vote timeliness by type, proposals and misses, per validator |
Benchmarking | How do you compare our performance with the network? | A named methodology, a network baseline and reward sources reported separately |
Data access | Can we verify your figures independently? | Validator indices disclosed, exports and API access, reconciliation with on-chain data |
Client risk | Which clients run our validators, and how do you handle supermajority risk? | Client mix disclosed; a stated policy on minority clients |
Infrastructure | Where do our validators run, and on what kind of hosting? | Facilities, regions and hardware model disclosed; no single point of failure |
Slashing protection | How do you prevent a key from signing in two places? | Slashing protection databases, single-active-signer policy, documented failover procedure |
Incidents | What do you notify us about, and how quickly? | Defined escalation thresholds, notification windows and written post-incident reports |
Change management | How do you handle network upgrades and migrations? | Staged rollouts, advance notice and upgrade readiness confirmed ahead of activation |
Assurance | Which independent audits cover your operations? | Recognized attestations such as SOC 2 Type II, with reports available under NDA |
Contingency | What happens to our stake if you suffer a major outage or a slashing event? | A tested recovery plan and clear terms on slashing coverage |
A provider does not need to have the perfect answer to every question. But it should be able to answer all of them clearly and in writing. Hesitation on basic disclosure, such as which clients are running or where validators are hosted, is itself useful information.
From Trust to Evidence
Institutional staking is maturing quickly. As more capital moves into Proof-of-Stake networks, the expectations placed on validator operators are converging with those applied to any other critical outsourced function: defined service levels, measurable performance, timely incident disclosure and independent assurance.
Validator monitoring sits at the center of that shift. The institutions best placed to scale their staking programs will be the ones that can see, verify and explain how their validators are performing, rather than relying on a headline uptime figure.
At GlobalStake, this thinking shapes how we operate. We run validators on directly owned bare-metal infrastructure across multiple locations, and we treat reporting as part of the product, including direct reporting integration into clients’ own systems. The economics behind that choice are covered in our analysis of staking infrastructure costs. Whichever provider an institution works with, the standard should be the same: if it matters to your risk, you should be able to see it.
FAQ
What is validator monitoring? Validator monitoring is the continuous tracking of a validator’s duties, rewards, infrastructure health and risk exposure. For institutions, it also covers how that information is reported, verified and escalated.
Is uptime a good measure of validator performance? Uptime is a starting point, not a complete measure. A validator can be online and still miss rewards because of late or incorrect votes. Duty completion and benchmarked rewards give a more accurate picture.
What causes slashing on Ethereum? Slashing on Ethereum is triggered by proposing two different blocks for the same slot, or by making contradictory attestations. In practice, it most often results from operational errors, such as the same key running on two machines at once.
How often should institutions review validator performance? Operational metrics should be available continuously, with alerts for material events. A formal review, covering performance against benchmark, incidents and changes to risk posture, is typically done monthly or quarterly.
Can institutions verify a provider’s reported performance? Yes, on networks such as Ethereum, where duty performance is recorded on-chain. With validator indices disclosed, figures can be reconciled using public data or independent analytics providers.