---
title: "Validator Nodes"
url: "https://radix.wiki/contents/tech/core-concepts/validator-nodes"
version: "2.0.0"
updated: 2026-08-07
last_verified: 2026-08-07
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Validator Nodes

|  |  |
| --- | --- |
| **Role** | Transaction processing, consensus participation |
| **Consensus** | [Cerberus BFT](/contents/tech/core-protocols/cerberus-consensus-protocol) |
| **Rewards** | Share of 300M XRD annual [emissions](/contents/tech/core-concepts/network-emissions) |
| **Minimum Stake** | 100 XRD to delegate |
| **Registered validators** | 188 of 287 (mainnet, epoch 332767) |
| **Active set** | Top 100 by stake |
| **Fee range** | 0–100%, increases delayed ~4,032 epochs |
| **Unstaking delay** | 2,016 epochs (~1 week) |

## Overview

**Validator nodes** secure the [Radix network](https://www.radixdlt.com) by participating in [Cerberus consensus](/contents/tech/core-protocols/cerberus-consensus-protocol). They process transactions, propose state changes, and earn [staking rewards](/contents/tech/core-concepts/network-emissions) distributed to their delegators.

### Staking

XRD holders can delegate to any validator with a minimum of 100 XRD. Delegation creates [Liquid Stake Units (LSUs)](/contents/tech/core-concepts/liquid-stake-units) that represent the staked position and continue accruing value. The [Radix Dashboard](https://dashboard.radixdlt.com) and [ShardSpace](/ecosystem/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](/contents/history/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](https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs) — 1,000 USD-equivalent in the mainnet genesis configuration — and creates a component together with an owner badge, an [LSU](/contents/tech/core-concepts/liquid-stake-units) 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](https://docs.radixdlt.com/docs/network-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](/contents/tech/core-concepts/network-emissions) it keeps before the rest accrues to delegators. The engine [bounds it to between 0 and 1](https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/consensus_manager/validator.rs) — 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](https://docs.radixdlt.com/docs/network-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](/ecosystem/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](https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/consensus_manager/validator.rs); 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)](https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/consensus_manager/validator.rs)
- [ConsensusManagerConfig::mainnet_genesis — the network's staking constants](https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs)
- [Radix Gateway API — /state/validators/list](https://docs.radixdlt.com/docs/network-gateway)
- [Radix Dashboard: the validator register](https://dashboard.radixdlt.com/network-staking)