---
title: "Validator Nodes"
url: "https://radix-wiki.miow.me/contents/tech/core-concepts/validator-nodes"
updated: 2026-10-03
description: "Validator nodes secure the Radix network by participating in Cerberus consensus. They process transactions, propose state changes, and earn staking rewards…"
---

# Validator Nodes

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

# Validator Nodes

## 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](/contents/tech/core-protocols/xrd-token) 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](/contents/tech/core-concepts/components) 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](/contents/tech/core-concepts/badges), an [LSU](/contents/tech/core-concepts/liquid-stake-units) [resource](/contents/tech/core-concepts/resources) 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 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](/contents/tech/core-protocols/nfts-on-radix) 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.

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.

The [Gateway](https://docs.radixdlt.com/docs/network-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](https://github.com/radixdlt/babylon-gateway/blob/main/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml) 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](/ecosystem/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](/contents/tech/core-concepts/buckets-proofs-and-vaults) 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.

## 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](https://docs.radixdlt.com/docs/metadata-for-wallet-display), and the Radix Wallet presents it to anyone looking at the validator. Only the account holding the [owner badge](/contents/tech/core-concepts/badges) 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](https://docs.radixdlt.com/docs/network-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.

| What the link does | Links |
| --- | --- |
| The name does not resolve | 50 |
| TLS fails, so a browser refuses the page | 12 |
| The server answers 404 | 6 |
| The server answers an error, or a CDN reports it cannot reach the origin | 6 |
| The host resolves and never answers | 5 |
| The link returns a page | 76 |

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](/ecosystem/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](/ecosystem/apollo-pool) publishes `apollopool.io`, which a new owner [registered on 23 August 2026](https://rdap.identitydigital.services/rdap/domain/apollopool.io); [XIDAR](/ecosystem/xidar) publishes `xidar.io`, [registered again on 4 August 2026](https://rdap.identitydigital.services/rdap/domain/xidar.io), 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)](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)