A validator can have a low commission and still perform poorly. Another can have a solid record but change its fee in a way that affects your expected rewards. Delegators need to check both operational performance and the share of rewards a validator keeps, using the network’s own records rather than relying only on a ranking page.
There is no universal on-chain field called “uptime.” Networks define validator performance differently: a chain may expose missed-block counters, signed-block windows, proposal participation, attestations, or voting credits. The useful question is not simply whether a validator appears online now. It is whether it has continued to perform its assigned duties over a relevant period, and how the fee changed during that same period.
Solana provides a concrete example of a primary-data workflow. The same principles apply elsewhere, but the queries and interpretation must match that chain’s consensus and staking rules.
| Source | Best for | Main trade-off |
|---|---|---|
| Direct node or RPC queries | Checking the chain’s current state and retrieving underlying records | Requires the right validator address, a suitable endpoint, and interpretation of protocol fields |
| Validator operator statements | Understanding a planned fee change, maintenance event, or service policy | Useful context, but not proof that the change was executed or that performance matched the claim |
| Community dashboards | Fast comparisons across many validators | Metrics can be aggregated, delayed, or defined differently; check the source and measurement window |
For a decision that depends on a recent change, use a dashboard to find the relevant validator, then verify the public key and underlying data against a node or RPC endpoint. An explorer can be a convenient viewer of chain records, but its presentation is still an interpretation layer.
Start with the validator’s vote account address, not just its brand name or node identity. Solana’s official getVoteAccounts RPC reference documents a response divided into current and delinquent vote accounts. Each record can include fields such as commission, epochCredits, lastVote, rootSlot, and the vote-account public key. Query the address you actually delegated to and use a consistent commitment level when comparing snapshots.
The current/delinquent grouping is a useful alert, not a complete historical uptime report. If a validator appears delinquent, check again after a short interval and inspect the underlying recent voting history before making a decision. A single snapshot can reflect a temporary issue, endpoint lag, or a transition around an epoch boundary.
For a longer view, record the epochCredits history across several epochs. The RPC example presents entries as an epoch number and cumulative credit values. Compare the validator’s credit change across epochs, rather than treating the cumulative total as a score. Review the timeline for a sudden slowdown or a sustained drop. Credits are evidence of voting performance, but they are not a universal uptime percentage: opportunity, network conditions, vote timing, and epoch context matter. Do not compare validators using a percentage unless you know exactly how its denominator and sampling window were calculated.
Solana’s CLI reference also documents solana validators for a summary including stake, commission, skip rate, and software version, and solana vote-account for vote-account details. These commands are convenient for a quick check. If a result would change your delegation decision, query the documented RPC fields directly or cross-check them with a second independent endpoint.
First, read the current commission value in the vote-account record. That answers what the chain reports now. It does not show when the value changed or what the prior value was.
To establish history, request confirmed transaction signatures for the vote-account address using Solana’s getSignaturesForAddress RPC, then retrieve relevant transactions with getTransaction. Inspect the transaction instructions to identify a vote-account commission update, confirm the transaction succeeded, and note its slot. Compare the instruction’s new value with the current on-chain commission. Solana’s CLI reference lists vote-update-commission as the command that changes a vote account’s commission.
This is more work than reading a validator profile, but the evidence is stronger: the transaction signature, slot, instruction, and current account state are independently inspectable. A provider may limit older transaction history, so missing results from one RPC endpoint do not prove that no older change occurred. Use an archival-capable endpoint or a second provider when you need deeper history, and disclose the limits of the data you reviewed.
On Solana, staking rewards are distributed between delegated stake and vote accounts according to the validator commission rate, as described on the official staking overview. Still, do not assume the advertised rate alone predicts your realized reward. Confirm that you have the correct vote account, that your stake is active, and that the reward period you compare covers the same epochs. Other chains may define commission scopes, activation periods, fee-change limits, and penalties differently.
If you only need a quick routine check, use a reputable dashboard to spot a change, then verify the current commission and status through primary data. If you are choosing among validators, compare several completed epochs of performance alongside fee history and the operator’s public explanation. If a commission recently changed, or a performance metric suddenly fell, review the transaction or underlying votes and cross-check the record before acting.
For recurring monitoring, keep a small record with the validator’s public key, the network and endpoint, observation date or slot, current commission, current/delinquent state, and epoch-credit changes. Recheck on a regular schedule that fits your delegation, and after a material on-chain event. A written record helps distinguish a genuine trend from a one-time snapshot.
Public chain data can show protocol-recognized activity, account settings, and transactions. It cannot by itself explain every cause of missed work, guarantee future performance, or establish the quality of an operator’s support and security practices. A high historical performance record is not a promise. A commission value is not a complete forecast of net yield. Review the protocol’s own documentation for how it defines performance and rewards, and treat operator explanations as context to test against the record.
The practical standard is straightforward: identify the exact validator key, measure performance over comparable periods, confirm the current fee, and inspect the transaction history when a change matters. That combines a useful overview with verifiable evidence while keeping the limitations of each metric in view.
A successful blockchain transaction does not always mean a wallet will display the tokens. Learn how to verify the network, recipient, token contract, explorer balance, bridge status, and exchange deposit details safely.
Why liquid staking tokens can trade below redemption value, how withdrawal queues, liquidity, risk and time affect the discount, and when swapping or redeeming may make more sense.
Use this practical airdrop safety checklist to verify official claim contracts, inspect wallet permissions, spot malicious signatures, and respond to suspicious approvals.
Learn how to monitor validator performance and commission changes from primary blockchain data, compare the trade-offs, and build a reliable delegator check routine.
Learn how to match crypto transfers across exchange and wallet exports, preserve cost basis, separate fees, and review Form 1099-DA before calculating gains.
Learn how MEV protection works for retail DEX swaps, how private transactions reduce sandwich risk, how slippage affects exposure, and what trade-offs to check before you trade.
Understand how account abstraction wallets use session keys, paymasters, and recovery rules, plus the permissions and risks to check before signing.
Avoid crypto withdrawal mistakes by checking the receiving chain, token contract, address, and memo or destination tag before you send funds.
Before delegating restaked assets, verify an operator’s AVS exposure, slash conditions, loss limits, redistribution rules, and exit delays with this practical checklist.
Learn what crypto proof of reserves can verify, what liabilities it may omit, and how to check an exchange’s snapshot, customer balances, and audit scope.
