When validators go offline
4 minDifficulty Checked 2026-11-10- With fewer than about 20% of trusted validators failing, the ledger keeps going.
- Past that, it stops validating new ledgers and waits. It does not confirm bad ones.
- The Negative UNL sets aside validators that are offline so the rest can reach a quorum.
Servers break. Cables get cut. A validator can be down for an upgrade. The XRP Ledger is built to expect that.
The rule of thumb has three zones.
- A few validators fail. If fewer than about 20% of the trusted validators are down or misbehaving, nothing changes. Ledgers keep closing.
- Many fail. If more than about 20% are gone, the rest cannot gather enough votes. No new ledger becomes final. The network waits.
- Nearly all cheat. To confirm something false, at least 80% of trusted validators would have to cheat together, in the same way.
The middle zone is a choice. The ledger would rather stop than be wrong. A pause is obvious and people can step in. A wrong final answer cannot be taken back.
Stopping has a cost, though. With dozens of trusted validators, a handful going offline together could stall everything. The Negative UNL softens that.
It works like a team sheet. When a validator has been silent for a while, the others agree to mark it "out sick." The vote count then uses only the validators still playing. When the absent one returns and behaves well, it comes off the sick list.
The sick list changes slowly, one validator at a time, about every 15 minutes. It also has a cap. However many are out, a ledger still needs agreement from 60% of the full list.
The Negative UNL never changes what a transaction does. It only helps the network keep declaring results final.
Thresholds, from xrpl.org:
| Faulty share of trusted validators | Effect |
|---|---|
| Under about 20% | Consensus continues |
| Over about 20% | No new ledgers are validated. Transactions are processed tentatively |
| 80% or more, colluding | Needed to confirm an invalid transaction |
Reliability score. Each server scores each trusted validator over the last 256 ledgers:
reliability = matching validations ÷ 256
Below 50%, the validator is a candidate for the Negative UNL. Above 80%, it is a candidate for removal.
Changes happen on flag ledgers, where the ledger index is divisible by 256.
- A change scheduled in the previous flag ledger takes effect.
- Each server may propose adding up to 1 validator, if the list is not full.
- Each server may propose removing up to 1 validator.
- A proposal that reaches consensus is scheduled for the next flag ledger.
Proposals are UNLModify pseudo-transactions. When several validators qualify, servers pick the one whose public key XORed with the parent ledger hash is lowest. Most servers then propose the same candidate.
Limits. The list is full at 25% of the configured UNL, rounded down. The quorum is always at least 80% of the effective UNL and at least 60% of the configured UNL.
Scope. Validators on the Negative UNL are ignored only in the validation step. They can still take part in choosing the transaction set. Their validations are still tracked for scoring.
On the ledger. State lives in one NegativeUNL entry:
DisabledValidators: each withPublicKeyandFirstLedgerSequence.ValidatorToDisableandValidatorToReEnable: changes scheduled for the next flag ledger.
The entry does not exist when no validator is disabled or scheduled. Read it with ledger_entry and "nunl": true.
Sudden large outages. If more than 20% drop at once, validation stops. Servers keep making tentative progress and keep adjusting the Negative UNL in those tentative ledgers. If the outage lasts, full validation can resume from there.
Live status: Amendments page.
Related: Validators and the UNL, Running a node: xrpld and Clio.
- Negative UNLRead 2026-11-10
- Consensus Protections Against Attacks and Failure ModesRead 2026-11-10
- Consensus ProtocolRead 2026-11-10
- NegativeUNLRead 2026-11-10
- ledger_entryRead 2026-11-10
