rippled/docs/telemetry-glossary.md

Telemetry Glossary

Plain-language definitions of the XRP Ledger and xrpld terms used in the Grafana dashboard panel descriptions. Each Grafana panel already carries a short Keywords gloss inline; this page is the deeper reference for going further, and most terms link out to the canonical xrpl.org documentation.

Related docs: docs/telemetry-runbook.md (operator runbook).

Contents

• Ledger Lifecycle
• Consensus
• Transaction Pipeline
• Fees & Queue
• Node State & Sync
• Peer & Overlay Networking
• Storage Internals
• Validator Health
• RPC & Pathfinding

Ledger Lifecycle

Ledger build

Building a ledger means applying the agreed transaction set, in canonical order, onto the previous ledger to produce the new closed ledger and its hash. Build time is a large component of the overall close time.

Scope: per node — measured on and specific to this individual server.

See also: Ledger build on xrpl.org

Ledger close

The XRP Ledger never converts an open ledger into a closed one; instead the server discards the open ledger and builds a new closed ledger by applying the consensus-agreed transaction set (in canonical order) on top of the previous closed ledger. Consensus triggers the close; the close completes when the new ledger is built.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Ledger close on xrpl.org

Ledger close interval

The XRP Ledger closes a new ledger at a roughly steady cadence (about every 3-5 seconds on Mainnet). Close times are rounded to a shared resolution so validators can agree on them. A node that closes far slower or faster than the network cadence is not keeping up or is misbehaving.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Ledger close interval on xrpl.org

Ledger index

The ledger index (or ledger sequence) is the position of a ledger version in the chain, incremented by one for each new ledger. The current/open ledger index is one or two ahead of the latest validated sequence on a synced node.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Ledger index on xrpl.org

Ledger store

After a ledger is built and validated, the node persists it into its ledger history (the object store). The store rate should track the build rate on a healthy, in-sync node.

Scope: per node — measured on and specific to this individual server.

Ledger validation

Validation is the stage after transaction-set agreement: each server independently computes the ledger from the agreed set, then compares results. When enough trusted validators agree on the same ledger, it is declared validated (final and immutable). A validating node issues one validation per ledger it fully validates.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Ledger validation on xrpl.org

Open ledger

A server has exactly one open ledger: a temporary workspace where it provisionally applies transactions in the order received. Its results are tentative and can differ from the final validated result, because the closed ledger applies transactions in canonical order instead.

Scope: per node — measured on and specific to this individual server.

See also: Open ledger on xrpl.org

Published ledger

After a ledger is validated the node publishes it to internal subscribers and clients. The published ledger normally tracks the validated ledger closely; a growing gap means the publish pipeline is backing up and subscribers may see stale data.

Scope: per node — measured on and specific to this individual server.

Transaction apply phase

During a ledger close the server executes each transaction in the agreed set, in canonical order, updating ledger state. This apply phase (xrpld's doAccept path) is typically the largest single component of ledger-build time and scales with the number and cost of transactions in the ledger.

Scope: per node — measured on and specific to this individual server.

See also: Transaction apply phase on xrpl.org

Validated ledger

A validated ledger is one that a quorum of trusted validators has agreed on. It is immutable and forms part of the permanent ledger history. Each ledger index has exactly one validated ledger.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Validated ledger on xrpl.org

Consensus

Clock drift

Because each validator stamps its own observed close time, differences between validator clocks (drift) spread the proposed close times, forcing coarser close-time resolution and more distinct positions.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Clock drift on xrpl.org

Close time

Each validator proposes the wall-clock time it saw the ledger close; validators then agree on a common close time, rounded to a shared resolution so their ledgers match. Disagreement on close time forces the rounding resolution coarser and can cause extra rounds.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Close time on xrpl.org

Close-time resolution

Close times are rounded to a shared resolution (a number of seconds) so validators can agree on a single value. When validators disagree on close time the resolution moves coarser (up toward 120s); when they agree tightly it moves finer. Repeated coarsening signals persistent close-time disagreement.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Close-time resolution on xrpl.org

Consensus

XRP Ledger consensus is an iterative agreement protocol: each server listens to its trusted validators and, when a supermajority agree on the same transaction set and close time, declares consensus and builds the ledger. If they disagree, validators revise proposals over successive rounds until they converge.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Consensus on xrpl.org

Consensus mode

Consensus mode reflects how a node is participating: Proposing (a validator advancing its own proposal), Observing (following without proposing), Wrong Ledger (working from a ledger the network disagrees with), or Switched Ledger (just changed to match the network). Sustained time in Wrong/Switched Ledger indicates the node is out of sync or flapping.

Scope: per node — measured on and specific to this individual server.

See also: Consensus mode on xrpl.org

Consensus outcome

The result of a consensus round. Agreed is the healthy outcome. Moved On means the node proceeded without full agreement; Expired means the round timed out; No Consensus means agreement was not reached. A growing share of non-Agreed outcomes signals network stress or connectivity loss.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Consensus outcome on xrpl.org

Consensus round

A consensus round is one iteration in which validators relay and revise proposals. Multiple rounds (the establish count) may be needed within a single ledger before validators converge. Longer or more numerous rounds indicate disagreement, load, or poor connectivity.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Consensus round on xrpl.org

Consensus stall

A stalled condition is flagged when consensus health checks detect that rounds are not progressing. A nonzero stall rate is an early warning that can precede ledger stalls or forks, surfacing before validated-ledger-age alarms fire.

Scope: per node — measured on and specific to this individual server.

See also: Consensus stall on xrpl.org

Convergence time

How long consensus took to converge on the agreed transaction set and close time, typically a few seconds. A rising convergence time indicates the network is taking longer to agree, often from load or connectivity problems.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Convergence time on xrpl.org

Distinct positions

A count of how many different close-time positions validators held in a round. Weight on a single distinct position means everyone agreed; weight on two or more means proposals split, indicating clock drift or latency spread across the validator set.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Distinct positions on xrpl.org

Establish phase

The establish phase is the part of consensus where validators exchange and revise proposals until they converge. The establish (iteration) count per ledger is normally low (a few iterations); a growing share of ledgers needing many iterations signals disagreement or network stress.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Establish phase on xrpl.org

Fork

A fork occurs when parts of the network validate different ledger chains. Sustained history mismatches or nodes stuck on the Wrong Ledger are fork indicators; the network is designed to avoid forks by requiring a trusted-validator quorum.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Fork on xrpl.org

Ledger history mismatch

A mismatch is recorded when the ledger this node built does not hash-match the ledger the network validated. Any sustained rate indicates consensus divergence or database corruption and warrants immediate investigation; the reason label distinguishes close-time, sync-drift, and transaction-processing causes.

Scope: per node — measured on and specific to this individual server.

Position update

Each round a node tallies disputed transactions and updates its own proposed position to move toward its trusted peers. Sustained high position-update durations point to heavy dispute resolution or slow convergence.

Scope: per node — measured on and specific to this individual server.

See also: Position update on xrpl.org

Proposal

During consensus each validator broadcasts a proposal: the set of candidate transactions it thinks should be in the next ledger. Validators revise proposals over rounds to match their trusted peers until a supermajority agree.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Proposal on xrpl.org

Proposers

The number of distinct validators that proposed in the last consensus round. A falling proposer count (alongside rising convergence time) signals degrading consensus conditions, such as lost validator connectivity.

Scope: network event — a network-wide consensus process; this metric is one node's view of it.

See also: Proposers on xrpl.org

Transaction Pipeline

Apply pipeline stages

A transaction is processed in stages: preflight validates it without ledger state (signature, format), preclaim checks it against current ledger state, and apply executes it and commits state changes. A failure spike concentrated in one stage pinpoints where transactions are being rejected.

Scope: per node — measured on and specific to this individual server.

See also: Apply pipeline stages on xrpl.org

Direct apply vs enqueue

When a transaction arrives, the node either applies it directly to the open ledger (if it meets the open-ledger cost) or enqueues it for a future ledger. The bypass ratio is the share applied directly; it falls as congestion pushes more transactions into the queue.

Scope: per node — measured on and specific to this individual server.

See also: Direct apply vs enqueue on xrpl.org

Local vs relayed transactions

Transactions either originate from a client submitting to this node (local) or are relayed from peers. Most traffic on a network node is peer-relayed; local dominates on a submission node. An unexpected surge in local submissions can indicate a client flooding the node.

Scope: per node — measured on and specific to this individual server.

Queue accept (drain)

When a ledger closes, the node drains eligible queued transactions into it. The accept/applied ratio is the share of drained transactions that were included versus removed on failure. A healthy drain applies most of them; a low ratio means accepts are mostly failing.

Scope: per node — measured on and specific to this individual server.

See also: Queue accept (drain) on xrpl.org

Transaction result codes

Every transaction returns a result code grouped by prefix: tes (success), tec (failed but cost claimed, included in ledger), tef (cannot apply to this ledger or a later one), tem (malformed, cannot succeed in any ledger), ter (retry later), tel (local error). A steady background of tef/tec results is normal; a surge of one code for one type indicates a systemic issue or abusive submissions.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Transaction result codes on xrpl.org

Transaction suppression

The same transaction reaches a node from many peers; the node suppresses (discards) copies it has already seen so they are not reprocessed. A large suppressed share is normal on a well-connected node; a collapse in suppression means duplicate filtering is failing.

Scope: per node — measured on and specific to this individual server.

Transaction type

Each transaction has a type that determines its logic and cost, such as Payment, OfferCreate, TrustSet, or the AMM and NFToken families. Panels break down rate, latency, and failures by type; a single type spiking far above baseline can indicate a spam campaign of that type.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Transaction type on xrpl.org

Transactor

A transactor is the code that applies a single transaction of a given type, running its type-specific checks and state changes. The transactor stage is the innermost apply step; its result is a transaction result code such as tesSUCCESS (the tes success class).

Scope: per node — measured on and specific to this individual server.

See also: Transactor on xrpl.org

Fees & Queue

Base fee

The base fee is the transaction cost a reference (cheapest) transaction must destroy under minimum load, currently 10 drops on Mainnet. The actual required fee is the base fee scaled by the load factor and, when the open ledger is busy, by fee escalation.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Base fee on xrpl.org

drops

A drop is the smallest denomination of XRP: 1 XRP = 1,000,000 drops. Fees, reserves, and costs are often reported in drops.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: drops on xrpl.org

Fee escalation

Once the open ledger holds more than its soft target number of transactions, the cost to add further transactions rises exponentially (fee escalation). Transactions that cannot pay the escalated cost are queued instead. A large gap of the open-ledger level above the reference level means escalation is active.

Scope: per node — measured on and specific to this individual server.

See also: Fee escalation on xrpl.org

Fee levels

Fee levels express the transaction cost relative to a transaction's own minimum, so they compare across transaction types. Key levels are reference (baseline, 256), minimum (to queue), median (of the last ledger), and open-ledger (to enter the current open ledger). The open-ledger level spiking far above reference is the hallmark of congestion.

Scope: per node — measured on and specific to this individual server.

See also: Fee levels on xrpl.org

In-ledger vs target count

The node sets a soft target for how many transactions belong in a ledger, based on the previous ledger. While the in-ledger count stays at or below target, the open-ledger cost is minimal; exceeding it triggers exponential fee escalation.

Scope: per node — measured on and specific to this individual server.

See also: In-ledger vs target count on xrpl.org

Load factor

The load factor is a multiplier applied to the base transaction cost; 1.0 means no load. It combines local server load, network load, and cluster load. A rising factor means the node is charging premium fees due to congestion or overload; the components identify where the pressure originates.

Scope: per node — measured on and specific to this individual server.

See also: Load factor on xrpl.org

Queue admission rejection

When the queue is at capacity or a transaction is unlikely to be included, the node refuses it entry (a drop), applying backpressure. A burst of queue_full rejections, distinct from expiry, means the node is being flooded faster than it can drain.

Scope: per node — measured on and specific to this individual server.

See also: Queue admission rejection on xrpl.org

Queue expiry / abandonment

A queued transaction carrying a LastLedgerSequence is dropped once that deadline passes without inclusion. A sustained expiry rate is a demand-frustration signal: submitters under-bid the escalating fee and their transactions timed out, often coinciding with spam.

Scope: per node — measured on and specific to this individual server.

See also: Queue expiry / abandonment on xrpl.org

Reserve (base & owner)

Reserves protect the ledger from spam by requiring accounts to hold XRP. The base reserve is the minimum per account; the owner (incremental) reserve adds a further requirement per object the account owns (offers, trust lines, escrows, etc.). Both are set by validator fee voting and reported in drops.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Reserve (base & owner) on xrpl.org

Transaction cost

Every transaction must destroy a small amount of XRP (the transaction cost) to be relayed and included, which deters spam. The cost is the base fee scaled by the current load factor, and rises further under fee escalation when the open ledger is congested.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Transaction cost on xrpl.org

Transaction queue (TxQ)

The transaction queue (TxQ) holds transactions that pay enough for local relay but not the current open-ledger cost, so the node can include them in a future ledger instead of discarding them. Depth pinned at capacity for sustained periods signals demand exceeding throughput or a fee-spam burst.

Scope: per node — measured on and specific to this individual server.

See also: Transaction queue (TxQ) on xrpl.org

Node State & Sync

Back-fill / catch-up

When a node is missing ledgers (at startup, after an outage, or to extend history) it back-fills by fetching them from peers. Elevated back-fill activity is normal while catching up and should fall to near zero once history is complete and the node is synced.

Scope: per node — measured on and specific to this individual server.

Complete ledger ranges

A node stores ledger history as one or more contiguous ranges. One continuous range means an unbroken history; many fragmented ranges indicate gaps from missed or failed fetches that the node is still back-filling.

Scope: per node — measured on and specific to this individual server.

Historical fetch rate

The rate at which the node fetches older ledgers to extend or repair its stored history. Elevated while back-filling; near zero once history is complete.

Scope: per node — measured on and specific to this individual server.

Ledger acquire (inbound fetch)

Acquiring a ledger means requesting it and its contents from peers when the node lacks it. Acquire outcomes split into complete and failed; a rising failed rate means the node cannot fetch needed ledgers from its peers.

Scope: per node — measured on and specific to this individual server.

Operating mode / server state

The server state describes how fully the node is participating, in ascending order: disconnected, connected, syncing, tracking, full (caught up), and for validators validating and proposing. A healthy non-validator sits in Full; frequent transitions out of Full indicate instability.

Scope: per node — measured on and specific to this individual server.

See also: Operating mode / server state on xrpl.org

Peer & Overlay Networking

Cluster

A cluster is a set of servers run by the same operator that trust each other, exchanging load and status directly and skipping some redundant checks. Cluster overhead is routine; sustained high cluster overhead suggests frequent cluster-state churn.

Scope: cluster-wide — shared across a co-operated cluster of nodes run by one operator.

See also: Cluster on xrpl.org

Fetch-pack

A fetch-pack is a bulk transfer of ledger data used to accelerate catch-up across a range of ledgers. Fetch-pack traffic rises sharply while catching up and is near zero when fully synced; continuous fetch-pack traffic means the node never fully catches up.

Scope: per node — measured on and specific to this individual server.

GetObject / object fetch

GetObject messages fetch individual pieces of ledger data from peers, broken down by object type: ledger headers, individual transactions, transaction-tree nodes, and state-tree nodes. Many messages carrying few bytes means small piecemeal fetches; few large messages means batch transfers.

Scope: per node — measured on and specific to this individual server.

Have / requested transactions

Have-transaction messages advertise that a peer holds particular transactions; requested-transaction messages ask for them. Comparing requested versus have gauges how well transactions are propagating; requested far exceeding have means peers are behind on propagation.

Scope: per node — measured on and specific to this individual server.

Insane / diverged peers

Diverged (insane) peers are connected peers whose reported ledger state does not match the network's. Zero is healthy; a persistent nonzero count can indicate peers on a fork or misbehaving peers.

Scope: per node — measured on and specific to this individual server.

Ledger tree nodes

A ledger's contents are stored as Merkle trees (SHAMaps): a transaction tree and an account-state tree, each built from tree nodes. Peers fetch individual tree nodes (tx-node, account-state-node) to reconstruct a ledger. Account-state-node traffic dominates during state sync; transaction-set-candidate traffic dominates during consensus catch-up.

Scope: network-wide — a protocol-shared value, the same across all nodes.

Manifest

A manifest is a validator's signed statement linking its long-term master key to its current ephemeral signing key, letting it rotate keys without losing trust. Manifest overhead rises around key rotations; sustained high manifest traffic suggests frequent reissue.

Scope: network-wide — a protocol-shared value, the same across all nodes.

Overlay

The overlay is xrpld's peer-to-peer messaging layer connecting nodes. All inter-node traffic (transactions, proposals, validations, ledger data, control messages) flows over it, grouped into traffic categories for accounting.

Scope: per node — measured on and specific to this individual server.

See also: Overlay on xrpl.org

Proof path

Proof-path request/response messages let a peer verify an individual ledger entry via its Merkle proof, without downloading the entire ledger. Volume rises when peers verify specific state, often during catch-up.

Scope: per node — measured on and specific to this individual server.

Reduce-relay

Reduce-relay lowers overlay bandwidth by forwarding proposals/validations through a chosen subset of peers (selected), suppressing the rest, while some older peers have the feature not-enabled. When suppression hides a message a peer needed, it fetches it on demand; a rising missing-tx rate means suppression is too aggressive.

Scope: per node — measured on and specific to this individual server.

Replay delta

Replay-delta request/response messages transfer only the state changes between ledgers so a peer can efficiently replay them during catch-up, rather than refetching whole ledgers. Continuous replay traffic means the node is repeatedly replaying rather than staying current.

Scope: per node — measured on and specific to this individual server.

Resource disconnect

The resource manager tracks each peer's load and disconnects those exceeding limits. A rising resource-disconnect count is consistent with abusive or misbehaving peers being shed as backpressure; a flat line is healthy.

Scope: per node — measured on and specific to this individual server.

Set get/share

Set-get (fetch) and set-share messages exchange transaction-set data between peers as they reconcile which transactions belong in the closing ledger. Some exchange each ledger is normal; high set-get means peers are frequently missing transaction sets.

Scope: per node — measured on and specific to this individual server.

Squelch

Squelching is a relay-control mechanism: a node tells peers to stop sending it a particular validator's messages when it already has a good source, reducing redundant forwarding. High suppressed counts mean squelch is saving bandwidth; ignored directives (peers not honoring squelch) should stay low.

Scope: per node — measured on and specific to this individual server.

Trusted / untrusted / duplicate

Proposals and validations are trusted if they come from validators on this node's UNL, untrusted otherwise; duplicates are messages the node already received and discarded. High untrusted volume can indicate trusted-list misconfiguration or spam; high duplicates indicate inefficient relay.

Scope: per node — measured on and specific to this individual server.

See also: Trusted / untrusted / duplicate on xrpl.org

Validator list

Validator lists are the signed, published sets of recommended validators (the basis for a node's UNL). Peers exchange them so nodes stay configured with a current trusted set. Traffic bursts when lists update or new peers connect and is otherwise quiet.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Validator list on xrpl.org

Storage Internals

Caches (SLE / Ledger / TreeNode / FullBelow / AcceptedLedger)

xrpld keeps several caches: SLE (ledger entries), Ledger, AcceptedLedger, TreeNode, and the FullBelowCache (subtrees known to be fully present locally). A high hit rate means lookups are served from memory; low or falling hit rates indicate cache thrashing and extra back-end reads.

Scope: per node — measured on and specific to this individual server.

NodeStore

The NodeStore is xrpld's content-addressed object database holding all ledger tree nodes, keyed by hash. It is the main on-disk store read during queries and sync and written as new ledgers are stored; NuDB is the default backend.

Scope: per node — measured on and specific to this individual server.

NuDB

NuDB is a fast append-only key-value store used as the NodeStore backend. Its on-disk size grows steadily with retained ledger history; the growth slope is the data growth rate.

Scope: per node — measured on and specific to this individual server.

Read threads / read queue / write load

The NodeStore serves reads through a pool of read threads (optionally bundling reads) fronted by a read queue, while writes are scored as write load. Read threads pinned at the maximum, or a high read queue, mean read I/O is saturated; high write load means back-end write pressure.

Scope: per node — measured on and specific to this individual server.

Validator Health

Amendment blocked

Amendments are protocol changes activated by validator voting. If the network enables an amendment a node's build does not understand, the node becomes amendment-blocked: it stops processing to avoid diverging, and requires a software upgrade. OK is healthy; BLOCKED means an upgrade is needed.

Scope: per node — measured on and specific to this individual server.

See also: Amendment blocked on xrpl.org

Ledgers closed rate

The rate at which this node closes ledgers, roughly 12-20 per minute on Mainnet (one per ~3-5s close). It should match the network's steady cadence; a drop toward zero means the node stopped participating.

Scope: per node — measured on and specific to this individual server.

See also: Ledgers closed rate on xrpl.org

UNL (Unique Node List)

A node's Unique Node List is the set of validators it trusts not to collude. The node reaches consensus by listening to its UNL and declaring a ledger validated when a quorum of them agree. UNL expiry (days left) matters because an expired list leaves the node without a trusted set.

Scope: per node — measured on and specific to this individual server.

See also: UNL (Unique Node List) on xrpl.org

UNL blocked

UNL-blocked means the node could not establish a valid trusted validator list (for example, all configured lists expired or failed to load), so validator trust cannot be established. OK is healthy; BLOCKED halts safe participation.

Scope: per node — measured on and specific to this individual server.

See also: UNL blocked on xrpl.org

Validation agreement

Validation agreement is the fraction of recent ledgers where this validator issued a validation matching the consensus outcome (agreed) rather than missing or disagreeing (missed). A sustained dip signals configuration drift, unreliability, or a network partition.

Scope: per node — measured on and specific to this individual server.

See also: Validation agreement on xrpl.org

Validation quorum

The quorum is the minimum count of trusted-validator validations that must agree before a server declares a ledger validated (by default about 80% of the UNL). It is derived from the active validator list and changes when that list changes.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Validation quorum on xrpl.org

Validations checked vs sent

Checked validations are those received from other validators and verified by this node (reflecting network validation traffic reaching it); sent validations are those this node issues (roughly one per closed ledger for a validator).

Scope: per node — measured on and specific to this individual server.

See also: Validations checked vs sent on xrpl.org

RPC & Pathfinding

Batch vs single RPC

A single request carries one command; a batch request bundles several. Single requests usually dominate; a batch rate climbing sharply is consistent with bulk automation or amplification attempts.

Scope: per node — measured on and specific to this individual server.

Clio / reporting client

Clio is a separate reporting server that offloads historical and API queries from xrpld, fetching data via the gRPC interface. gRPC panels are nonzero mainly when reporting/Clio-style clients are connected.

Scope: per node — measured on and specific to this individual server.

gRPC

gRPC is a high-performance binary RPC protocol the node exposes for specific consumers, chiefly reporting-mode (Clio) clients. gRPC traffic is zero on nodes without such clients; its status is only ever success or error.

Scope: per node — measured on and specific to this individual server.

Order book

An order book holds the standing offers to exchange a given currency pair in the XRP Ledger's decentralized exchange. Pathfinding and some RPC queries walk order books; cost grows with order-book depth and request complexity.

Scope: network-wide — a protocol-shared value, the same across all nodes.

See also: Order book on xrpl.org

Path request / discovery

A path request is a client subscription for payment paths; discovery passes are the periodic refreshes the node runs to keep those paths current as ledgers close. Discovery cost tracks request demand and is a cost driver for subscription-heavy nodes.

Scope: per node — measured on and specific to this individual server.

See also: Path request / discovery on xrpl.org

Pathfinding (fast / full)

Pathfinding searches for routes along which a cross-currency payment can flow through order books and AMMs. A fast search trades accuracy for speed; a full search is exhaustive and much more expensive. Sustained high durations indicate pathfinding-heavy clients straining the node.

Scope: per node — measured on and specific to this individual server.

See also: Pathfinding (fast / full) on xrpl.org

Resource drops / warnings

The resource manager meters each peer and client; it first warns endpoints for excessive usage and then drops or blocks them. Nonzero rates mean the node is actively rejecting abusive connections; zero is expected when no abusive consumers are present.

Scope: per node — measured on and specific to this individual server.

RPC command / method

Clients call the node via named RPC commands (also called methods), such as account_info, ledger, or submit, over HTTP, WebSocket, or gRPC. Panels break rate, latency, and errors down by command; heavy commands (ledger/account queries) cost far more than status calls.

Scope: per node — measured on and specific to this individual server.

See also: RPC command / method on xrpl.org

WebSocket

WebSocket is a long-lived connection transport for the node's API, used by clients that subscribe to streams or send many requests. WebSocket message rate is nonzero only when clients use WebSocket; HTTP-only nodes read zero.

Scope: per node — measured on and specific to this individual server.

See also: WebSocket on xrpl.org