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 342675 on 21 September 2026, mainnet carries 288 validator components, of which 185 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%.

The Gateway will do that reconciliation for you, but only on one of the two endpoints that return a validator. /state/validators/list gives every item an effective_fee_factor object whose current is the fee actually being charged and whose pending appears only while a request is genuinely queued; the Gateway API schema declares it required on ValidatorCollectionItem, with current required and pending nullable, and declares it nowhere else. /state/entity/details, the endpoint you reach for when you have one validator's address, returns no resolved fee at all: its state object carries the raw validator_fee_factor and validator_fee_change_request and stops there. The natural single-validator lookup is the one that cannot answer the question, and the field it hands you instead is a fossil, because validator_fee_change_request is never cleared once its epoch has passed.

A non-null request does not mean a change is coming. Read at epoch 338190 on 25 August 2026, CaviarNine-1 stored 1.75% and charged nothing, its request field still holding the cut to zero that took effect at epoch 282893; Cadwynbloc stored 50% and charged 75%; Radstakes stored 15% and charged 25%. None of the three had a change pending. The only field that says one is coming is effective_fee_factor.pending.

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.

The website a validator publishes

A validator carries metadata on the ledger beside its stake, and one of those keys is info_url. The metadata standard defines it as a direct link to an informational webpage, and the Radix Wallet presents it to anyone looking at the validator. Only the account holding the owner badge can set it, so the field is as current as its operator keeps it, and nothing on the ledger checks that it still goes anywhere.

Read from the Gateway at epoch 342,675 on 21 September 2026, 155 of the 185 registered validators publish an info_url and 30 publish none. Fetching each of the 155 once, following redirects, 79 do not reach a working page. That is 51% of the published links, and the validators behind them hold 959,831,411 of the 4,518,815,466 XRD staked to registered validators, 21%. Within the top 100 by stake, the active set that proposes and validates rounds, 34 of the links fail and a further nine validators publish none.

The 50 names that do not resolve are 48 distinct domains, three validators naming www.radixnft.art between them, and one entry that was never a domain at all, coming.soon. Each returned NXDOMAIN from both 1.1.1.1 and 8.8.8.8 on a second, serial pass. Among them is Cobra Stakes, rank 21 with 84,579,935 XRD delegated, whose cobrastakes.com entered the .com redemption period on 18 September. The 12 TLS failures are three self-signed certificates, two expired ones, one certificate issued for a different name, and six servers that abandon the connection at or just after the handshake; each was inspected with openssl s_client rather than taken from the fetch.

Two of the 76 links that do return a page return a site the operator does not run. Apollo Pool publishes apollopool.io, which a new owner registered on 23 August 2026; XIDAR publishes xidar.io, registered again on 4 August 2026, and its validator holds 61,327,775 XRD. Both names now sit on Cloudflare nameservers and redirect to businesses with no connection to Radix. Those two links answer HTTP 200; the other 77 failures do not load at all.

Correcting one of these is the operator’s to do, because only the owner badge can write the field. Nothing else can: a wallet showing a validator’s website has no way to tell that the name behind it changed hands.

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