Live XRPL macro telemetry
Supply, regional flows, AMM depth, and a modeled Active Float showing how much XRP can clear inside a single ledger close, all from on-chain data. No price predictions. No investment advice. No black-box math.
Free from this page. No wallet, no payment, no inputs. The same payload agents pay for over the
x402 API at telemetry.xrpl-utilities.io.
Total Circulating Supply is how much XRP exists outside Ripple's escrow. Modeled Active Float is how much of that can actually clear inside a single 3-5 second ledger close. Most XRP held at exchanges is sitting in customer balances, not posted on the order book, so the active slice is much smaller than the headline number.
When an exchange holds ~6.5B XRP across its labeled wallets, most of that is user balances backing trades and withdrawals, not depth a market sweep can hit inside a few seconds. Counting full exchange holdings as "available" overstates how much can clear in a settlement burst.
Active Float applies an 10% multiplier on exchange holdings as an estimate of what's genuinely on the book at any moment, then adds XRP committed to liquidity pools (swappable inside a single ledger close) and XRP resting in open offers on XRPL's native order book. The paid /scan response includes every input number and the multiplier so anyone receiving the data can recompute under their own assumptions.
The Equation of Exchange (M · V = P · Q) says supply available for trade times turnover rate equals the per-unit price times annual dollar volume. Plug in three values, solve for the fourth.
M is anchored at Modeled Active Float (the supply that can clear inside a single ledger close). Set Q (your assumption about annual settlement volume on XRPL) and V (how often that supply turns over per year), and the math returns P: the per-XRP price the identity requires under those specific assumptions. Not a forecast. Read P as "what the math requires."
What fraction of custodial exchange holdings is genuinely posted on the book at any given moment, available to be hit by a market sweep within a few seconds. The midpoint (10%) is the default; drag the slider to see how M (and the equilibrium price P below) responds across the defensible range.
M · Modeled Active Float. The supply that can clear inside a single 3-5 second ledger close. Computed as 10% of exchange holdings + XRP committed to liquidity pools + XRP resting in open offers on XRPL's native order book.
V · Annual velocity. How many times each unit of M is reused for settlement per year. Your assumption. The default of 6 reflects what a mature settlement network looks like with ODL-style cross-border flows recycling supply. Today's real velocity is much lower since most XRP is held, not transacted.
Q · Total annual settlement volume in USD. Your assumption. Must share V's time window (both are annual).
P · The per-XRP USD price the identity requires given M, V, and Q. Not a forecast.
P usually comes out far below market price. That's the point: pure settlement math is a floor, not a forecast. The gap is everything else XRP is priced for (adoption bets, scarcity, store-of-value), and none of that is in this calculation by design.
What would push P up
The Floor Matrix below compounds either dynamic forward 24 months.
The /scan response also carries an algebraic_p_at_assumed_qv_usd_flows_biased field next to the canonical P. It applies a bounded nudge (±10% max) to Q based on how tightly ETF AUM moves with XRPL exchange flow over the trailing window: tighter alignment nudges Q up, decoupling nudges down. The canonical P stays operator-controlled so the headline doesn't move with weekly noise; the biased value is a side-by-side comparator only.
XRP or RLUSD Payments on validated mainnet ledgers, USD-anchored at each ledger's close-time price. Other IOU tokens are excluded. Per-token oracle pricing would distort the figure.
XLS-81 (Permissioned DEX) is live on mainnet. Permissioned settlement classifies a Payment when the tx body or affected Offer/AMM node carries a DomainID. The metric is at or near 0% today as institutional venues come online; the trajectory becomes the signal as adoption ramps.
The Q field above (in Burst Math) is your assumption about annual XRPL settlement that uses XRP as the medium. The annualized run-rate here is what the network actually transacted this week, projected to a year. If your Q is far above measured Q, you're betting on growth; if it's below, your model is conservative relative to current activity. Click Use measured next to Q to load the live number into the floor calculation.
Why XRP-only feeds Q. RLUSD↔RLUSD payments on XRPL clear through the issuer's stablecoin and don't consume XRP supply, so including them would inflate the demand on Active Float and overstate the equilibrium-price floor. Use measured prefills Q with the XRP-denominated portion of the annualized run-rate. The full XRP+RLUSD figure is shown above for context but isn't what feeds the floor math.
XRP↔RLUSD order-book fills on validated mainnet ledgers. A taker offer crossing one maker offer counts as one fill; multi-leg crosses contribute one fill per consumed maker leg. AMM swaps and pathfinder-routed legs are not in this number yet.
The settlement-volume number above counts gross Payment deliveries: a $100 RLUSD payment that routes through an XRP↔RLUSD offer contributes $100 to that headline. This DEX pair-volume number counts order-book fills: the same Payment also consumed one maker-side offer, and that fill is what shows up here. Both figures can describe the same on-chain transaction in different lenses.
Each fill is recorded with both legs (XRP value at hourly close-time price + RLUSD at $1), so the headline matches the conventional "pair volume" figure that XRPL explorers publish. The XRP-side and RLUSD-side subtotals are shown in the small print for flow-direction views.
Burst Math gives you a price today. Real networks compound: supply tightens, settlement grows. Pick monthly rates below and the math projects forward 24 months. Shaded band is a ±15% visual envelope, not a confidence interval. Grey dashed line is today's market price.
% of liquid M that exits circulation each month (vault locks, escrow relock, dormancy growth, AMM TVL). Range capped at 1.5%/month; sustained constriction above that is not historically observed on XRPL.
% monthly increase in annual settlement Q (new ODL corridors, B2B adoption, RLUSD scale). Range capped at 2%/month; sustained growth above that compounds into headline-grabbing numbers that the underlying math cannot honestly defend.
Small monthly rates compound aggressively. 1% per month of supply constriction works out to ~21% of supply gone in 24 months; 2% monthly volume growth compounds to ~1.6× Q. Watch where the baseline crosses the dashed market line. Sensitivity, not forecast.
Starting price · today's implied floor. Copied live from Burst Math. Re-anchor by tweaking Q or V there.
Monthly supply constriction · how fast liquid M shrinks each month. 1% per month means 1% of M exits each month into AMM pools, cold custody, escrow, or dormancy.
Monthly volume growth · how fast annual settlement Q grows each month. Compounds geometrically.
±15% band · visual reminder that the baseline is a point estimate. Not a statistical confidence interval. The slider ranges (constriction max 1.5%, growth max 2%) are intentionally narrow: wider ranges produce numbers the model cannot honestly defend.
XR-Telemetry implements x402 v2 with the
exact scheme on XRPL mainnet.
Verification and settlement are delegated to the
t54 XRPL facilitator.
POST /quote returns an invoice with amount in drops, recipient, deep link, and QR code.
GET /status/{invoice_id} until paid: true.
GET /results/{invoice_id} returns the full TelemetryPayload: supply, liquidity, AMM, utility floor.
xrpl_telemetry_settlement_totalsxrpl_telemetry_settlement_seriesxrpl_telemetry_dex_pair_volumexrpl_telemetry_snapshot · $0.10 (inline x402)xrpl_telemetry_get_quote · $0.10 (invoice flow step 1)xrpl_telemetry_get_status · no extra (step 2)xrpl_telemetry_get_results · no extra (step 3)
Or skip the integration: call any tool above from an
MCP client (Claude Desktop etc.) via
@xrpl-utilities/mcp
or the hosted endpoint at mcp.xrpl-utilities.io/mcp. Free tools work without a payment header; paid tools use the same x402 model wrapped as MCP arguments.
import requests quote = requests.post( "https://telemetry.xrpl-utilities.io/quote", json={}, ).json() # Sign & submit XRPL Payment from your wallet using quote["deep_link"] # Then poll until paid: while not requests.get( f"https://telemetry.xrpl-utilities.io/status/{quote['invoice_id']}" ).json()["paid"]: time.sleep(5) payload = requests.get( f"https://telemetry.xrpl-utilities.io/results/{quote['invoice_id']}" ).json() print(payload["supply"]) print(payload["utility_floor"])
supply: total / circulating / escrowed / dormant XRP, AMM-locked, exchange omnibus + venue/address counts, DEX orderbook depth, HODL wave %, 24h exchange outflow, escrow release÷relock ratioliquidity: per-region inflow / outflow / net flow over 24h, with a list of top venuesamm: top pairs (TVL USD, 1% depth XRP, APR%); vault metrics (TVL XRP-equivalent, utilization%, supply APY%) ship once the XLS-Vaults amendment activates on mainnetderived_models.active_float: value_xrp (modeled supply available for 3-second settlement), delta_24h_xrp, proxy_ratio, and the full mathematical_bridge with each additive component and its sourceutility_floor: baseline (= P at the assumed Q, V, and Active Float as M), current spot, premium ratio, plus an ETF-flow-biased secondary P with provenance blockgenerated_at: ISO timestamp the snapshot was computed
Full field-level details at /schema. Live manifest at /agents.json.
XR-Telemetry produces on-chain telemetry and an algebraic implied-floor computation. Not a price prediction, investment recommendation, or financial advice. Burst Math and Floor Matrix are sensitivity tools. They show what the math implies under explicit assumptions, not what XRP will or should be priced at.
Users are responsible for complying with local digital asset and AI regulations, including the California Digital Financial Assets Law and the Colorado AI Act where applicable.
Live aggregate from /sla?days=30. The recorder probes our upstream dependencies on a recurring cadence and counts each sample as healthy only if all succeed. Same liveness assertion /healthz returns. No external monitoring; data is what we see from inside the service.
Covered: backend liveness of the XRPL RPC dependency and the x402 facilitator. If either probe fails at sample time, that sample counts as unhealthy and is attributed to its component.
Not covered: external network latency between you and the service, individual endpoint correctness (only liveness), and data freshness inside the snapshot cache. For data freshness, see /healthz checks.slow_tasks.