Delegation is the most popular way to participate in staking, because it lets you earn rewards without running a server. But "I do not run a node" is not the same as "I take no risk". When you delegate, you hand your stake's voting power to an operator, and that operator's uptime, fees, security, and honesty become your problem. This post covers the risks that actually cost delegators money or rewards, and a short checklist to run before you delegate to anyone, including us.
First, the reassuring part, stated precisely. On most proof-of-stake chains, delegating does not transfer custody of your coins: your tokens stay in your wallet or staking contract, and the validator cannot spend them. What you hand over is the right to vote and validate on your behalf, and with it, exposure to that validator's behaviour. If the validator performs badly, your rewards fall. On chains with slashing, your stake can be penalised for the validator's faults. That distinction, custody versus exposure, is the foundation of every risk below.
Commission: the fee that can change
Validators charge a commission on rewards, and that commission is not always fixed. Some validators raise it after attracting a large delegation, which quietly reduces your returns without any action from you. Before delegating, check the current commission, whether the chain allows the validator to change it, and whether changes have a notice period or a cap. A validator with a transparent commission history is worth more than one with a temporarily low rate and no track record. If a rate looks too good to be sustainable, ask how the operator pays for servers, monitoring, and staff at that rate, because an operator who cannot cover costs will either raise fees or cut corners on operations.
Uptime and missed duties
A validator that is offline does not earn, and neither do its delegators. Occasional missed attestations are normal on every chain, but a pattern of downtime is a red flag: it usually means weak monitoring, no redundancy, or an operator who treats the node as a side project. Before delegating, look at the validator's recent uptime and missed-duty record on a block explorer. A few percent of missed duties over a long window is ordinary; a validator that disappears for hours at a time is not. Also check whether the operator runs a single node or a redundant setup, and whether they publish any status or incident history. Silence about past outages is itself information.
Slashing exposure
Slashing is the penalty for serious validator faults, most commonly double-signing, where a validator signs two conflicting blocks, and in some chains, extended downtime. As a delegator, your stake can be reduced when your validator is slashed, even though you did nothing wrong. The practical defences are boring and effective: choose validators with a long clean record, avoid validators that run experimental or duplicate setups, and spread larger stakes across more than one validator instead of putting everything with a single operator. The slashing explainer on this blog covers the mechanics in detail, including why double-signing usually happens during a badly handled failover, not from malice.
Operator risk: the human behind the node
A validator is a business run by people, and people risk is real. An operator can shut down, lose interest, or get compromised. Key compromise is the sharpest version: if an attacker gains control of a validator's signing keys, they can double-sign and get the validator slashed, or simply take it offline. You cannot audit an operator's key management directly, but you can look for proxies: a public team or company behind the validator, a track record across upgrades and incidents, and a history of communicating with delegators. Anonymous validators are not automatically bad, but they offer no recourse if things go wrong, so size your delegation accordingly.
Lock-ups and unbonding: the exit cost
The risk delegators forget most often is time. Many chains lock delegated stake for an unbonding period after you ask to withdraw, during which you earn nothing and cannot sell or move the funds. Unbonding periods vary widely by chain, from days to weeks, and they apply exactly when you most want out, during volatility or a validator incident. Before delegating, write down three numbers for your chain: the lock-up length, the unbonding length, and whether rewards continue during unbonding. If you cannot find them in the chain's official docs, do not delegate yet. A position you cannot exit is a different risk from a position that merely falls in value.
Concentration: the risk nobody prices
There is one more risk, and it belongs to the network, not just to you. When too many delegators pile into the same few large validators, the chain becomes more centralised, and a failure or compromise at one operator affects a larger share of stake. Delegating to a smaller, competent validator is not just a nice gesture toward decentralisation; it is diversification for you, because your stake is not tied to the same single point of failure as everyone else's. Check a validator's share of total stake before delegating, and be cautious about adding to an operator that already controls a large share.
A 5-minute checklist before you delegate
- Commission: current rate, change rules, and history - is it stable and sustainable?
- Performance: recent uptime and missed duties on a block explorer - any long outages?
- Slashing record: clean history, and no duplicate or experimental setups visible?
- Operator: public identity or company, incident communication, and a real operations setup?
- Exit terms: lock-up and unbonding periods from the official docs, written down before you commit?
- Concentration: share of total stake, and are you diversifying across more than one validator?
Delegation done well is genuinely low-effort staking: pick a competent operator, check in occasionally, and let the infrastructure do its job. Delegation done carelessly is how people lose rewards to fee hikes, downtime, and lock-ups they never read. If you run a project and want your own validator operated to a standard your delegators can check, that is what DevOpsBy's node operations service is for, and the free infra audit is a good first conversation: bring the validator you are considering, and we will walk the checklist with you.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-11-03 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.