Validator Nodes

Overview

Validator nodes secure the Radix network by participating in Cerberus consensus. They process transactions, propose state changes, and earn staking rewards distributed to their delegators.

Staking

XRD holders can delegate to any validator with a minimum of 100 XRD. Delegation creates Liquid Stake Units (LSUs) that represent the staked position and continue accruing value. The Radix Dashboard and ShardSpace provide interfaces for staking.

Subsidy Transition

The Validator Subsidy, which topped up validator income independently of delegator fees, was wound down through 2026 — see Validator Subsidy Sunset. What remains is the fee a validator sets for itself.

Registration and the active set

A validator is a component on the ledger, not a slot granted by anyone. Creating one costs a fee denominated in USD rather than XRD — 1,000 USD-equivalent in the mainnet genesis configuration — and creates a component together with an owner badge, an LSU resource and a claim-NFT resource that are unique to it. Existing is not the same as participating: a validator only enters consensus once its owner registers it, and only the top 100 registered validators by stake — max_validators in the same configuration — form the active set that proposes and validates rounds.

Read live from the Gateway at epoch 332767 on 7 August 2026, mainnet carries 287 validator components, of which 188 are registered. The tail is long and mostly nominal — dozens of registered validators hold single-digit XRD and will never enter the active set — so the register is better read as a list of who has stood a node up than as a picture of who is securing the network.

Unstaking is deliberately slow: num_unstake_epochs is 2,016, roughly a week at the ledger's recent pace of about 288 epochs a day, during which the position is a claim NFT rather than XRD. A validator's own fee income is slower still — see below.

The fee a validator charges is not always the fee it stores

Every validator has a fee factor: the share of that validator's emissions it keeps before the rest accrues to delegators. The engine bounds it to between 0 and 1 — 0% to 100% — and it is the single number that decides what delegating to one validator rather than another is worth.

Changing it is asymmetric, and deliberately so. A validator that raises its fee must wait num_fee_increase_delay_epochs — 4,032 epochs in the mainnet genesis configuration, about two weeks — before the new fee applies, which is the window delegators have to leave. A validator that lowers its fee has it apply at the beginning of the very next epoch. Nobody is protected from a fee cut.

The subtlety is what happens when the delay expires. The engine does not rewrite the stored validator_fee_factor at that moment. It leaves the request sitting in validator_fee_change_request and, every time it pays emissions, resolves the fee it actually charges as "the request, if its epoch has passed; otherwise the stored field". The stored field is only brought up to date later, as a side effect of the owner requesting the next change. A validator can therefore charge one fee for months while the field an explorer reads still shows the old one — the two are reconciled lazily, and nothing on the ledger is wrong about it.

That is not a corner case. Of the 188 registered validators read at epoch 332767, 62 are charging something other than their stored fee factor, and 50 of those are charging more. Between them they hold 2,900,410,156 of the 4,727,137,240 XRD staked to registered validators — 61% of all delegated stake sits with a validator whose stored fee is stale. The gaps are not rounding: one validator stores 1.49% and charges 14.9%, another stores 0% and charges 100%, a third stores 25% and charges 1%.

The practical rule for anyone reading a validator's fee — in a dashboard, in a directory, or through the Gateway — is to read both validator_fee_factor and validator_fee_change_request and compare the request's epoch_effective against the current epoch. A tool that reads only the first is wrong about a third of the register. This wiki was one of those tools until this pass: RadixStake's page carried the stored 1.49% while its delegators paid 14.9%.

Where the fee goes

A validator's fee is not paid out to it in XRD. When emissions are applied, the fee is taken from the emission bucket and then staked straight back to the same validator; the stake units minted against it are placed in the validator's locked owner stake-unit vault, where they are visible on-ledger and cannot be moved for num_owner_stake_units_unlock_epochs — 8,064 epochs in the genesis configuration, roughly a month.

So a validator's income arrives as its own delegated stake, under a lock longer than the one its delegators face. Fee income compounds into the same pool it was taken from, and the operator's visible stake grows with it — one reason a high-fee validator's rank can drift upward without any new delegator arriving.

External Links

• Validator blueprint: update_fee and apply_emission (radixdlt-scrypto)
• ConsensusManagerConfig::mainnet_genesis — the network's staking constants
• Radix Gateway API — /state/validators/list
• Radix Dashboard: the validator register