Skip to article
XRPAuthority
Network governance · Verified concept guide

Inside an XRP Ledger Consensus Round

Follow candidate transactions through proposal rounds, canonical ordering, and validation.

Published 2026-08-23Reviewed 2026-08-237 minute readBy Matt Barlow
SIMPLE EXPLANATION

Definition and scope

Inside an XRP Ledger Consensus Round addresses a distinct part of validators and network governance. Follow candidate transactions through proposal rounds, canonical ordering, and validation.

XRPL governance is distributed across deterministic software rules, server operators, validator choices, amendment voting, and the consensus process. These topics clarify what validators can do, what they cannot do, and how protocol changes become active. No single validator or list publisher controls the ledger. Consensus claims must distinguish local trust configuration from network-wide results.

TECHNICAL DEPTH

How it works

During a consensus round, servers share candidate transactions, exchange proposals, converge on a set, apply canonical ordering, build a ledger, and publish validations for the resulting hash.

  • proposal: verify this field, object, or component against the cited protocol documentation.
  • candidate set: verify this field, object, or component against the cited protocol documentation.
  • canonical order: verify this field, object, or component against the cited protocol documentation.
  • validation: verify this field, object, or component against the cited protocol documentation.
PRACTICAL EXAMPLE

Practical example and checks

A transaction can be observed during proposal rounds but becomes authoritative only when included in a ledger that the server reports as validated with sufficient trusted agreement.

For production use, preserve the exact signed or queried data, record the network and validated ledger reference, and compare the result with the current primary documentation before changing off-ledger state.

Open the related live demo or evidence lab →

Limits, risks, and common confusion

Consensus is iterative and network-dependent, not an instant vote by a fixed committee. Provisional candidate inclusion should never trigger irreversible off-ledger credit.

No single validator or list publisher controls the ledger. Consensus claims must distinguish local trust configuration from network-wide results.

Current network status

Enabled on XRPL Mainnet. The underlying protocol capability is available on XRPL Mainnet. Individual services can still impose additional rules, limits, or trust assumptions.

Status reviewed 2026-08-23. Amendment-dependent behavior must be rechecked against the network's live feature state before operational use.