XRPL.to Token Analytics

Measured conclusion: Deep-tested. L2 outcome: tools_ok.

XRP Ledger tokens, AMM pools, NFTs, accounts and transactions: prices, holders, trades and history

Add to your agent

Copy this into your MCP client config:

{
  "mcpServers": {
    "XRPL.to Token Analytics": {
      "url": "https://api.xrpl.to/v1/mcp",
      "transport": "streamable-http"
    }
  }
}

Measured tools (88)

• search_tokens read-only

  Search XRPL tokens by name, symbol or issuer address. Returns matching tokens with md5 ids, price, volume and market cap. An r-address returns every token that account issued or created (a launchpad creator funds a separate issuer wallet; role says which), including the ones tagged Scam, which a name search leaves out; their tags say so. Returns: up to 15 matches with md5, name, issuer, currency, verified flag, price, 24h volume, market cap, holders, tags.

  Parameters:

  • query (required) — string — Token name, symbol or issuer r-address
  • oldest — boolean — Instead: every token with exactly this name, oldest first, with when each was created (the search ranks by activity, so an old or dormant token of a common name is not in its 15)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_token read-only

  Detail for one XRPL token: price, market cap, volume, TVL, holders, origin, risk fields. id = md5, slug, or "XRP". Compact by default (the ~55 essential fields); pass full=true for the entire document. Returns: token with exch (XRP price), usd, marketcap, vol24hxrp, tvl, holders, trustlines, pro5m/1h/24h/7d changes, origin, tags, creator, top10, creatorHoldingPercent, depthPlus2/Minus2, tvlChange24h, vol6h/7d (full adds description, social links, supply detail and pipeline fields).

  Parameters:

  • id (required) — string — Token md5 / slug / issuer-currency / XRP
  • full — boolean — Return the whole document instead of the compact essentials

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_trending_tokens read-only

  Top trending XRPL tokens right now. Returns: tokens ranked by trendingScore with lightweight market fields.

  Parameters:

  • limit — integer

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_new_launches read-only

  Most recently launched XRPL tokens, newest first. With by_origin, how many tokens each launchpad issued over a window. With creator true, what each token's creator received and what it sold, in total and within 24 hours of launch: the way to find launches whose creator dumped. Returns: tokens sorted by dateon desc with lightweight market fields; with creator, each token's creator {account, receivedTokens, soldTokens, soldPct, soldXrp, soldWithin24hTokens, soldWithin24hPct, firstSellMinutesAfterLaunch}.

  Parameters:

  • days — integer — With by_origin: the window, ending now
  • limit — integer
  • since — string — With by_origin: the window start instead, ISO date (e.g. the first of the month)
  • creator — boolean — Add each creator's allocation and sells
  • by_origin — boolean — Instead: how many tokens were first issued in a window, per launchpad (FirstLedger, xrp.fun, Horizon, xrpl.to, ...) and with no launchpad, each with how many are listed and still held

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_trades read-only

  DEX trades for a token (time, side, amounts, price, trader): the latest, or those inside a past window (since/until), optionally of one trader. by_account true answers "who sold into that dump": the whole window (up to 7 days) totalled per wallet — net XRP each one sold or bought, the price path (open, close, low, high, with the fill that printed the low) and, for windows up to 48 h, an hourly breakdown. Returns: trades[] with time, amounts paid/got, price, maker/taker, hash; with by_account: {window, fills, price {open, close, low {price, time, taker, hash}, high}, sellers[], buyers[] {account, name, xrpSold, xrpBought, net, fills}, byHour[]}.

  Parameters:

  • id (required) — string — Token md5 or slug
  • limit — integer
  • since — string — ISO date/time or Unix ms: trades at or after it
  • until — string — ISO date/time or Unix ms: trades at or before it
  • account — string — Only this trader's fills (r-address)
  • by_account — boolean — Total the window per wallet instead of listing fills (needs since; at most 7 days)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_holders read-only

  Top holders of a token with balances and share of supply, each with the wallet that activated it; offset pages past the first rows. id XRP gives the XRP rich list (get_xrp_distribution with list true adds each account's last activity). Holders only: a line the issuer froze after it was emptied is not listed (get_frozen_lines lists every frozen line). Returns: richList[] with account, balance, holding % of supply, isAMM/isCreator/freeze flags, funder, plus summary top10/top20/top50/top100 %, gini, hhi.

  Parameters:

  • id (required) — string — Token md5 or slug
  • limit — integer
  • offset — integer — Skip this many holders (rank order)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_top_traders read-only

  Top traders of a token ranked by P&L, volume or wash-trading score, with realized/unrealized PnL, ROI and balances. Returns: traders[] with account, realized/unrealized PnL (XRP), ROI, buy/sell volumes, trade counts, current balance, wash flag.

  Parameters:

  • id (required) — string — Token md5 or slug
  • limit — integer
  • sortBy — string
  • interval — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_creator_activity read-only

  On-chain activity of a token creator/dev wallet for that token: buys, sells, transfers, liquidity events. Returns: events[] of the creator wallet for this token: side (buy/sell/transfer/deposit/withdraw/burn...), amounts, XRP value, time, hash.

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_token_flow read-only

  Supply flow map: where the issued/dev supply went — held, sold, pooled, sent to exchanges, burned. Returns: summary with the split as percentages of supply (retainedPctOfSupply, tracedSoldPctOfSupply, lpDepositedPctOfSupply, placedToExchangePctOfSupply, creatorBurnedPctOfSupply, untracedPctOfSupply, unscannedPctOfSupply), flowSubject + flowSubjectRole (dev|issuer), XRP totals (totalSoldXrp, totalBoughtXrp, netFlowXrp, totalToExchanges), coverage flags (creatorScanComplete, preFloorLaunch); exchangeBreakdown[]; linkedAddresses[].

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• analyze_token_risk read-only

  Risk review for a token: an overall risk score, how many risk and positive signals fired, how much supply the creator controls, and linked prior launches by the same operator with their dead-token history. Returns: score (1-10, higher is riskier) and riskLevel, riskCount and positiveCount (how many signals fired; which ones is not published), supplyControl (creator wallet and escrow %), creatorFamily (prior launches, dead/verified counts, partial flag), creatorTokens, creatorService, creatorFundedBy. Holder concentration is in get_holders.

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_frozen_lines read-only

  Trust lines of a token that its ISSUER has frozen or deep-frozen right now, zero balances included (holder lists and gateway_balances leave those out), each with the transaction that switched the freeze on, found by walking the line's own history; plus the issuer's control flags (NoFreeze, GlobalFreeze, clawback, RequireAuth) and whether it can still sign at all: a blackholed issuer can never freeze, whatever its flags say. Answers "has this issuer ever frozen anyone": a line frozen now is proof. A freeze that was later lifted, and any clawback, leave nothing in ledger state: get_issuer_actions lists them as they happened, from the ledger its records start. Returns: {token, issuer, issuerFlags, frozen {count, deepFrozen, lines[] {holder, name (its label in the xrpl.to index, when known), balance, deepFrozen, frozenBy {hash, date, account, deepFreeze} | null, deepFrozenBy (when the deep freeze came later)}}, note}.

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_issuer_actions read-only

  What issuers did to their tokens and holders, as it happened on the ledger: freezes and deep freezes (and lifting them), trust-line authorizations, clawbacks (from a holder, or from an AMM pool with AMMClawback), MPT locks and authorizations, and the account flags that grant or give up those powers (RequireAuth, NoFreeze, GlobalFreeze, AllowTrustLineClawback, AllowTrustLineLocking), and who can sign for the account at all: the master key disabled or enabled (with the regular key left to sign), a regular key set or removed, a signer list set or removed. With blackholed, the accounts that became unable to sign anything in the window (master key off, no usable regular key, no signer list, checked on the ledger now) with the tokens they issue: "which issuers blackholed this week" in one call. Read from each successful transaction's metadata, so a request that changed nothing records nothing, and a clawback's amount is what the holder actually lost (requested is what was asked). A trust-line action carries role: issuer, or holder when an account set the flag on its own side as the line's holder, which leaves the issuer's token untouched (only the issuer's bit freezes a holder). Filter by the account that acted (the issuer), the account it acted on, and the action; omit both accounts to search every issuer on the ledger, with topAccounts ranking who did it most. Records start at coverage.fromLedger; before it, a freeze still in place shows in get_frozen_lines and anything undone leaves no trace in ledger state. Returns: {coverage {fromLedger, fromTime}, counts {action: n}, topAccounts[] {account, name?, n}, actions[] {time, ledger, tx, type, action, role?, account, accountName?, counterparty, counterpartyName?, currency?, mptIssuanceID?, amount?, requested?, counterpartyBalance?, ammAccount?, clawed?, regularKey?, previousRegularKey?, masterDisabled?, quorum?, signers?}}; with blackholed: {since, coverage, keyChanges, checked, blackholed, issuingTokens, canStillSign, accounts[] {account, name?, blackholedAt, ledger, tx, lastAction, regularKey, tokens[] {md5, name, currency, holders}}}. With supply and account (the issuer): every rise in what the issuer has outstanding over its whole life, each located to its ledger with that ledger's transactions of the issuer: the way to answer "was more of this token ever created after launch", without scanning the issuer's history; Returns then {account, fromLedger, toLedger, samples, currencies[] {currency, now, rises[] {ledger, time, before, after, increase, first?, txs[] {hash, type, account, destination?, delivered?, result}}}, note}.

  Parameters:

  • limit — integer
  • since — string — ISO date: only actions at or after it
  • action — string — Comma-separated: freeze, unfreeze, deep_freeze, deep_unfreeze, authorize, unauthorize, clawback, amm_clawback, require_auth_on, require_auth_off, no_freeze_on, no_freeze_off, global_freeze_on, global_freeze_off, clawback_enabled, clawback_disabled, trustline_locking_on, trustline_locking_off, mpt_lock, mpt_unlock, mpt_authorize, mpt_unauthorize, master_key_disabled, master_key_enabled, regular_key_set, regular_key_removed, signer_list_set, signer_list_removed
  • holder — string — The account acted on (holder, or the AMM account), r-address
  • supply — boolean — Instead, with account (the issuer): every rise in the supply it has outstanding, across its whole life, each with its ledger and transactions
  • account — string — The account that acted (the issuer), r-address
  • blackholed — boolean — Instead: accounts that became unable to sign anything since `since` (default the last 7 days), with the tokens they issue

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_wash_trading read-only

  Wash-trading check for a token: which wallets self-trade to fake volume, using the per-wallet wash score (0-100, from FIFO/self-trade analysis); or, with collection, for an NFT collection: sales of an NFT back to a wallet that owned it, and sales between wallets tied by creation (backToPreviousOwner, linkedSales, repeatPairs, flaggedVolumePct). Returns a token-level verdict plus the top offenders. Returns: {washTraders, highWashTraders, washVolumeXrp, tradersScanned, verdict, topWashers[] {account, washScore, suspicious, volumeXrp, trades}}.

  Parameters:

  • id — string — Token md5 or slug
  • days — integer — Collection mode: how many days of sales to read
  • interval — string — Window for the trader stats (default all)
  • collection — string — An NFT collection slug or id instead: wash trading in its sales

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• check_scam read-only

  Check an XRPL account against the scam blocklist (drainers, phishing, impersonation) plus account-freshness advisory. get_wallet_risk already runs this check — call check_scam alone for a quick yes/no, or on counterparties. Returns: is_scam, category, reason, source plus first_seen / age_seconds / new_account advisory.

  Parameters:

  • account (required) — string — r-address

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• check_domain read-only

  Is a website a known XRPL scam, how old is its domain, and which XRPL accounts does it claim? Without a domain, the newest entries of the phishing-domain list with what each impersonates. Checks the domain and each parent domain against xrpl.to's phishing-domain list (the list GET /v1/scams serves), reads the public registration record (RDAP), and reads the site's xrp-ledger.toml: the accounts it lists and the people it names. With `account`, it checks the link BOTH ways, the standard XRPL account verification: the site lists the account AND the account's own on-ledger Domain field names the site. Each half needs a key the other side cannot use (the site's to publish the file, the account's to set Domain), so a two-way match means one party controls both; either half alone is only a claim. Returns: {domain, listed, matched, status, since, registration {registered, ageDays, expires, registrar, status[], nameservers[]}, toml {url, found, accounts[] {address, network, desc}, principals[]}, accountCheck {account, listedInToml, accountDomain, domainMatches, verified}}.

  Parameters:

  • limit — integer — Without a domain: how many of the newest listed phishing domains
  • domain — string — A domain or a URL, e.g. xrpl-promotion.net or https://app.example.com/claim
  • account — string — Optional r-address: verify it and the domain claim each other

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_ohlc read-only

  OHLC candles for a token, or its price at a past moment. Quoted in XRP by default (the literal XRP in USD). vs_currency USD converts each candle at the XRP/USD rate of its own time; EUR/JPY/CNH then convert it at the ECB reference rate of its own day (the ECB publishes CNY, used for CNH; fx_basis says so). With `at` (a date/time) it returns the one candle containing that moment, at the finest resolution that reaches it (5-minute up to ~17 days back, hourly up to ~208 days, daily beyond), plus the previous close: the way to answer "what was X worth on <date>". Candles are gapless (each open is the previous close); a candle with volume 0 had no trade and carries the last traded price forward. XRP/USD is Binance XRP/USDT and starts 2018-05-04; nothing before a series starts is invented. With extremes true it reads the whole daily series once and returns the all-time high and low in XRP and in USD, each with its date: the way to answer "what was X's all-time high". Returns: ohlc [time, open, high, low, close, volume] (series), or {at, candle {start, end, open, high, low, close, volume, traded}, previousClose, resolution, vs_currency} (at), or {since, xrp {high {price, date, dayVolumeXrp}, highestClose, low, lowestClose, now, fromHighPct, fromHighestClosePct}, usd {…}} (extremes).

  Parameters:

  • id (required) — string — Token md5 or slug, or XRP
  • at — string — A past moment (ISO date/time, or Unix ms): returns the candle containing it instead of a series
  • count — integer
  • extremes — boolean — All-time high and low over the whole daily series, in XRP and USD, with dates
  • resolution — string
  • vs_currency — string — Quote currency (default XRP; USD for the literal XRP)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_orderbook read-only

  Live XRP order book for a token (bids/asks with sizes). Returns: bids[] and asks[] with price, amount, total, maker; spread.

  Parameters:

  • id (required) — string — Token md5 or slug
  • limit — integer

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_token_pairs read-only

  Trading pairs a token trades in, with per-pair volume. Returns: pairs[] the token trades in with counter asset and 24h volume.

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_account_info read-only

  XRPL account profile: balance, activation, name/labels, flags. Returns: balance, reserve/ownerCount, inception/parent (activator), name/domain labels, flags, blackholed, scam flags; for a deleted account {deleted, created, activatedBy, fundedXrp, deletedTo, deleteTx} instead of "not found".

  Parameters:

  • account (required) — string — r-address

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_account_ancestry read-only

  Who activated an account and who it activated (funding lineage), with tokens launched along the chain. Each child carries childrenCount (the wallets IT activated), and descendants totals two levels down, so a family tree needs one call, not one per child. Returns: ancestors[] (who funded whom, depth), children[] (accounts it activated, up to limit, each with childrenCount), descendants {children, grandchildren}, tokens launched along the chain.

  Parameters:

  • account (required) — string — r-address
  • limit — integer — Max children returned
  • direction — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_transaction read-only

  Look up an XRPL transaction by hash. Returns: decoded transaction: type, account, destination, amounts, fee, result code, ledger, date, affected balances.

  Parameters:

  • hash (required) — string — 64-char hex tx hash

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_global_stats read-only

  Platform-wide XRPL token market stats: totals, 24h volume, active tokens. Returns: platform totals: token count, 24h volume, active tokens, XRP price, fiat rates. Its transaction counts are DEX trades on tracked tokens, not every ledger transaction: for the whole network use get_network_activity.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_network_activity read-only

  The whole XRP Ledger's activity over the last N hours, or a calendar window with since/until (every transaction, not only token trades), all exact: xrpl.to counts each ledger's transactions by type and result as it applies the ledger. Other views of the same network: by app (transactions per wallet app by SourceTag), active_age (how old today's active accounts are), dex_traders_days (distinct DEX wallets over up to 30 days), daily (one row per day). Ledgers closed and their average close time, transactions by type with how many failed (a tec result: included in the ledger and charged its fee without doing what it asked), XRP destroyed by fees (the drop in total_coins), accounts created in the window, and accounts that sent a successful transaction (24h window). Returns: {window {hours, from, to, ledgerFrom, ledgerTo}, ledgers, avgCloseSeconds, xrpBurned, activeAccounts24h, newAccounts, deletedAccounts, topCreators[] {account, name, created}, transactions {total, perLedger, failed}, partialPayments {flagged, succeeded, deliveredLessThanAmount, ledgersCounted}, tickets {count, sharePct}, fees {medianDrops, p90Drops, p99Drops, maxDrops, meanDrops}, xrpPayments {count, withDestinationTag, destinationTagSharePct, deliveredXrp}, busiestLedgers[] {ledger, transactions}, types[] {type, count, sharePct, failed, failedPct}, hours[]? {start, ledgers, transactions, failed, partial?}}. Instead: top_senders (who paid the most fees or sent the most transactions), large_transfers (the largest single XRP transfers and the accounts that moved the most between each other), largest_trades (the largest DEX trades). failed_senders: the accounts that sent the most failed transactions, with the results they hit. exchange_flows: XRP into and out of each custodial service's labeled wallets over the window (exchanges, and the swap services and companies that also take tagged deposits), and the net.

  Parameters:

  • by — string — hour: also break the window into clock hours (UTC): transactions, failed and ledgers per hour. app: instead, the successful transactions of the last `hours` per wallet app or platform, by the SourceTag it stamps on them (kept 32 days), each with the distinct wallets that sent them
  • daily — integer — Instead: one row per day for the last N days from xrpl.to's daily network reports (DEX traders, trades and XRP volume, accounts activated, live and deleted accounts, new tokens, AMM liquidity), back to 2026-02-26
  • hours — integer — Window ending at the latest ledger (counts are kept 30 days, from when xrpl.to began recording them)
  • limit — integer — With by app: how many apps to list
  • since — string — Start of a calendar window instead, ISO date or Unix ms (e.g. 2026-09-26T00:00:00Z for yesterday, with until). Also for token_payments, top_senders, failed_senders, exchange_flows, drains and large_transfers; the hourly views snap it to the whole UTC hour
  • until — string — End of the window, ISO date or Unix ms (default: the latest ledger); a ledger closing exactly at until belongs to the next window. Hourly views round it up to the whole hour
  • census — boolean — Instead: how many ledger objects of each type exist, from xrpl.to's mirrors and from a daily walk of the whole ledger (ledgerState: every object type incl. tickets, signer lists, NFT pages, DIDs, credentials; accounts, the XRP held in reserves, accounts with a Domain and the most common domains, accounts that authorized an NFTokenMinter and the top minters, the largest owner counts, NFT offers past their expiration, escrows with a crypto-condition), the account flags counted over every account, checks, payment channels, and currency codes shared by the most issuers (currencyCodes: how many issuers issue USD, RLUSD's code and so on)
  • drains — boolean — Instead: wallet drains in the last `hours` (up to 720): payments out of victims' wallets to drainer accounts on xrpl.to's blocklist, recorded as they happened. How many, the XRP (and tokens) taken, from how many wallets, per drainer, and the largest
  • active_age — boolean — Instead: when the accounts that sent a successful transaction in the last 24 hours were created, by year, and how many in the last 30 days
  • created_by — string — Instead: the accounts created in the last `hours` by this account, or by every wallet carrying this label in xrpl.to's index (e.g. Coinbase), and which of them have sent a transaction since (known for windows of 24 hours or less)
  • dex_by_hour — integer — Instead: DEX trading volume (XRP) and fills by hour of the day (UTC), averaged over the last N days
  • top_senders — string — Instead: the accounts that paid the most in transaction fees, or sent the most transactions (failed ones included), over the last `hours` (up to 744)
  • cross_currency — boolean — Instead: the largest Payments of the last `hours` (up to 72) that delivered a different currency than they spent (converted through the DEX or an AMM on the way), with sender, recipient (or a swap to itself), what was delivered and the XRP value converted
  • exchange_flows — boolean — Instead: XRP received and sent by every wallet under each custodial label (xrpl.to's labels; custodial = its wallets take tagged deposits from many customers, as exchanges do, and some swap services and companies) over the last `hours` (default 168, up to 744), with the net: which exchange had the largest net outflow or inflow. Transfers between one label's own wallets cancel out of its net
  • failed_senders — boolean — Instead: the accounts that sent the most failed (tec) transactions in the last `hours` (up to 744), each with how many and which results, e.g. tecPATH_DRY
  • largest_trades — boolean — Instead: the largest DEX trades of the last `hours` (up to 72) by XRP value: every fill one transaction made across offers and AMM pools, summed on its XRP side, with the taker and the token
  • token_payments — string — Instead: a token's transfers in the last `hours` (up to 744): successful Payments and check cashes that sent the token itself to another account (not bought through the DEX), with the count, the amount, how many sent and received it, what its issuer paid out and took back, and the largest senders and receivers. A token md5, slug or name; "all" ranks the tokens paid most
  • large_transfers — boolean — Instead: the largest single XRP transfers over the last `hours` (up to 2,160): payments, check cashes and account deletions that delivered 1,000 XRP or more, with sender, receiver and hash; and corridors, the pairs of accounts that moved the most XRP between each other through such transfers
  • dex_traders_days — integer — Instead: how many distinct wallets traded on the DEX (order book or AMM) over the last N days, counted once each
  • most_transactions — boolean — Instead: the accounts that have sent the most transactions ever, from the highest Sequence numbers on the ledger (daily census) less each account's starting number, with when each was created

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_validators read-only

  The validators xrpl.to's Mainnet node trusts (its UNL, from the default validator list sites), each with the domain in its signed manifest, its server version and its last vote; and every amendment still being voted on, with rippled's own tally (votes for, the threshold, when majority was reached, whether this node's software knows the amendment). Votes come from the validators' own validations of each voting ledger (every 256th). Pass amendment (a name or id) for which validators support it and which do not. Use it to say whether a validator key is on the default UNL, who runs it (the domain is the operator's own claim unless the domain verifies it), and where an amendment stands. What an amendment changes is not in this tally: read it in the code with search_rippled_source for its switch (feature<Name>, or fix<Name> itself; e.g. featureBatchV1_1), and get_protocol_rules. A name the source does not hold was built outside rippled's public develop branch (3.4.1 knows fixBatchV1_2; develop does not), so say that rather than guess from the name. Returns: {count (every key this node trusts, its own validator included), onDefaultLists (the default UNL: keys on at least one list), thisNodesValidator?, votesInLatestRound, votesWithin24h, validators[] {key, domain, version, lastVote {ledger, time}, onLists[] (the default list sites carrying the key), thisNode?, feeVote?}, feeVotes {heard, baseFee|reserveBase|reserveInc: {currentDrops, votes[] {drops, validators, direction}, keepCurrent}, proposals[], changes} (the next flag ledger's fee vote, run as rippled runs it), amendments[] {id, name, count, threshold, validations, hasMajorityNow, majoritySince, knownToThisNode, supporters?, notSupporting?, noRecentVote?, heldByRippled? {validators, supporting, names?}}, lists[] {uri, expiration, count}, note}; for an amendment already enabled: {amendment {id, name, enabled, enabledAt {ledger, time}}} (when it went live, read from the ledger); with history, events[] {ledger, time, amendment, name, event (gotMajority, lostMajority, enabled), tx}: the way to answer which amendments were enabled most recently, and whether a majority was lost and regained (that restarts its two weeks). rippled keeps a silent validator's last votes for 24 hours, and so does this tally. With agreement_hours: per UNL validator, of the ledgers the network validated in the window, how many it validated too (agreed), signed a different ledger for (disagreed) and missed, scored ledger by ledger from the validations stream: which validators missed the most. Returns then {window, coverage, ledgersScored, validators[] {key, domain, version, agreed, disagreed, missed, agreementPct}}.

  Parameters:

  • history — integer — Optional: the last N amendment events on the ledger (gained majority, lost majority, enabled), newest first
  • releases — boolean — Instead: rippled's latest GitHub releases (tag, date, the start of the release notes) beside the versions the trusted validators run
  • amendment — string — Optional: an amendment name or 64-hex id, to list its supporters and the validators not supporting it; for an enabled one, when it went live
  • locations — boolean — Instead: where each trusted validator says it is: owner_country and server_country from its operator's own xrp-ledger.toml entry for its key (self-declared), with a count per server country
  • commits_days — integer — Instead (or with releases): rippled development over the last N days: commits on develop and the top contributors
  • agreement_hours — integer — Instead: each UNL validator's agreement over the last N hours (UTC clock hours): validated ledgers it validated too, signed differently, or missed

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_escrows read-only

  Escrows on the XRP Ledger, from xrpl.to's index of every Escrow object (kept current each ledger): totals (how many, how much XRP, how many owners) for the whole ledger or one account, and the escrows sorted by the next to unlock, the largest, or those that can be finished now. FinishAfter is the earliest an escrow can be finished; nothing moves until someone sends EscrowFinish (with the fulfillment, where the escrow has a condition), and once CancelAfter passes it can only be cancelled. sequence is what EscrowFinish and EscrowCancel take as OfferSequence (null where it could not be confirmed). Without an account it also ranks the owners holding the most (topOwners, with names). With within_days, what unlocks in the next N days per owner. With history_days, the XRP in escrow at each UTC midnight back through the record (today's total less what was created since, plus what ended since; with exclude_name, also without owners whose label contains it, e.g. Ripple): how escrowed XRP changed. The list shows `limit` at a time (page on with offset = list.nextOffset); totals and totals.xrpAmounts (smallest, largest, the most common amounts) always cover every escrow, so read the amounts there rather than from one page. Returns: {asOf {ledger}, totals {count, xrp, owners, withCondition, withCancelAfter {count, xrp} (only these can ever be cancelled), finishAfter {earliest, latest}, xrpAmounts {smallest, largest, mostCommon[] {xrp, escrows}}}, list {sort, matching, offset, returned, nextOffset?}, topOwners[] {owner, name?, escrows, xrp, nextFinish}, escrows[] {id, owner, ownerName?, destination, destinationName?, amount, currency, issuer?, mptIssuanceID?, finishAfter, cancelAfter, condition, sequence}}.

  Parameters:

  • role — string — With account: escrows it funded (owner), is paid by (destination), or either
  • sort — string — next: the soonest FinishAfter still ahead; amount: largest XRP first; ready: can be finished now
  • limit — integer
  • offset — integer — Skip this many of the sorted escrows: the next page of an account with more than limit (list.nextOffset says where it continues; totals always cover every escrow)
  • account — string — Optional r-address: its escrows
  • currency — string — XRP, a token currency code, or all
  • within_days — integer — Instead: every escrow that unlocks (FinishAfter) in the next N days, totalled per owner, largest first
  • exclude_name — string — With within_days or history_days: leave out owners whose label contains this text (e.g. Ripple)
  • history_days — integer — Instead: XRP in escrow at each UTC midnight over the last N days, as far back as the record of escrow creations and ends goes

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_xrp_distribution read-only

  How XRP is spread across accounts, from xrpl.to's index of every account balance (kept current each ledger): accounts and XRP in balance bands (over 1B, 100M-1B, 10M-100M, 1M-10M, 100k-1M, 10k-100k, 1k-10k, under 1k), each as a share of the total supply and of the XRP held in accounts (the supply less escrowed XRP); with min_xrp, the accounts and XRP above that line. Answers "how many accounts hold over 1M XRP, and what share". With list true, the accounts themselves, largest first, each with the last ledger any transaction touched it, and with inactive_years only the dormant ones. Also live and deleted account counts. Returns: {asOf {ledger}, supply, escrowed, inAccounts, accounts {live, deleted}, bands[] {minXrp, maxXrp, accounts, xrp, shareOfSupplyPct, shareOfXrpInAccountsPct}, above? {minXrp, accounts, xrp, shareOfSupplyPct, shareOfXrpInAccountsPct}}.

  Parameters:

  • list — boolean — Instead: the accounts above min_xrp themselves, largest first (the XRP rich list), each with the last ledger that touched it
  • limit — integer — With list: how many accounts
  • median — boolean — Also the median balance and the accounts under 1, 10 and 100 XRP (counts over every account, about a second)
  • min_xrp — number — Optional: accounts holding more than this many XRP (1,000 or more)
  • by_label — boolean — Also the XRP held under each account label in xrpl.to's index (an exchange, a company, a person), summed over EVERY wallet with that label: how much sits with exchanges
  • inactive_years — number — With list: only accounts no transaction has touched for this many years (dormant holders)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_oracle_prices read-only

  Prices written ON the XRP Ledger by price oracles (XLS-47 Oracle objects), read from the validated ledger: each publisher's price with its last update time and age, and the ledger's own aggregate (median, mean, standard deviation, from rippled get_aggregate_price). Reads every publisher on the ledger that carries the pair (xrpl.to records each Oracle object as it is set), or the oracles you pass. XRP/USD unless base/quote say otherwise; the publishers also carry BTC, ETH, RLUSD, USDC, USDT and more against USD (each publisher lists its pairs). Returns: {base, quote, publishers[] {provider, account, documentId, price, updated, ageSeconds, pairs[]}, aggregate {median, mean, standardDeviation, size, time}}.

  Parameters:

  • base — string — Base asset code, e.g. XRP, BTC, RLUSD
  • quote — string
  • oracles — array — Optional: other Oracle objects to read instead of the defaults

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_top_movers read-only

  Biggest gainers or losers over a timeframe. Returns: tokens[] sorted by the chosen timeframe change (pro5m/1h/24h/7d) with lightweight fields.

  Parameters:

  • limit — integer
  • direction — string
  • timeframe — string
  • min_holders — integer — Only tokens with at least this many holders (ranked over every such token, not a page of the overall list)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_tokens_by_category read-only

  Tokens in a category/tag (e.g. Memes, Stablecoin, Gaming, FirstLedger), or of one token type: token_type mpt lists the Multi-Purpose Token (MPT) issuances with each issuance's rules read from the ledger, lp the AMM LP tokens; with neither, every listed token. Sorted by 24h volume unless sort says otherwise (holders for the most-held). With group_by issuer, issuing accounts ranked by tokens issued. With issuer_setting, every token with at least min_holders holders whose issuer's account has that setting, read live from the ledger: clawback, transfer_fee (with the fee), no_freeze, global_freeze, require_auth, blackholed, or no_default_ripple (DefaultRipple not set, so holders cannot send it to each other). Returns: tokens[]; with issuer_setting {setting, minHolders, checked {tokens, issuers}, matched, tokens[] {md5, name, currency, issuer, issuerName, holders, transferFeePct?}}.

  Parameters:

  • sort — string — trades: the most trades (DEX fills) in the last 24 hours, whatever their size. turnover: 24h volume as a share of market cap, over every token with at least min_marketcap. trustlines_24h / holders_24h: the listed tokens whose trust lines or holders grew and shrank most over 24 hours (net). holders_7d: the same over 7 days, for tokens with at least min_holders. lp_burned: tokens with at least min_holders by the share of their AMM LP tokens burned (liquidity locked for good). creator_holding: tokens with at least min_holders by the share of supply their creator (or issuer) still holds, with how many hold over half, grouped by creator. inactive: tokens with at least min_holders whose last DEX trade is older than inactive_days (or that never traded), longest idle first
  • limit — integer
  • rank_by — string — With group_by issuer: the ranking
  • category — string — Tag, e.g. Memes, Stablecoin, FirstLedger (optional when token_type is given)
  • group_by — string — Instead: issuing accounts ranked by how many tokens each has issued (or by rank_by), with how many still have holders, their holders, trust lines and listed market cap, and each one's largest tokens
  • token_type — string
  • min_holders — integer — With issuer_setting: only tokens with at least this many holders
  • inactive_days — integer — With sort inactive: the idle period
  • min_marketcap — number — With sort turnover: only tokens with at least this market cap in XRP
  • issuer_setting — string — Tokens whose issuer has this setting on now (read from the validated ledger); no_default_ripple: the issuer has NOT set DefaultRipple, so holders cannot send the token to each other

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_exit_liquidity read-only

  Real exit-liquidity curve: how much XRP you actually receive selling several sizes of a token against live AMM+book, with price impact per size. Answers "can I get out at size". Returns: curve[] {xrpSize, tokensSold, xrpReceived, effectivePricePct, priceImpact}.

  Parameters:

  • id (required) — string — Token md5 or slug
  • xrp_sizes — array — XRP-value sell sizes to test (default 100, 1k, 10k, 50k)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_wallet_risk read-only

  Composite risk read for an XRPL wallet from on-chain signals — scam-list status, account age, funding source (exchange vs unlabeled), blackhole, balance. Transparent factor breakdown + an aggregate level (Low/Medium/Elevated/Critical), not a black-box score. Returns: {level, factors, activator, signals}.

  Parameters:

  • account (required) — string — r-address

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_offramp read-only

  Trace how a wallet's XRP exits to exchanges INCLUDING one hop downstream (funds → intermediary → exchange), which direct cex-cashout detection misses. Returns: direct[] and viaIntermediary[] {intermediary, exchange, xrp}.

  Parameters:

  • account (required) — string — r-address
  • limit — integer

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_payment_flows read-only

  Trace an XRPL wallet's payment flows: who funded it and where it sent XRP and tokens, aggregated by counterparty (XRP as xrp/txCount, tokens by asset as tokens/tokenTxCount) with named exchanges labeled. Reads its latest transactions (up to 200) by default; all_history reads its whole history (up to 10,000), for "everyone it ever paid or was paid by". For everything between specific wallets (tokens too), use get_account_transactions with counterparty. Dust probes (senders of a few drops, "has this wallet been probed") are flagged, with any sender whose address mimics a real counterparty's (address poisoning). Returns: inflows[]/outflows[] {counterparty, name, xrp, txCount, tokens? {<currency>.<issuer>: amount}, tokenTxCount?, isExchange (custodial: many wallets pay it under their own destination tags, as exchanges are paid), service (a named account that is not custodial: a fee wallet, a platform, a project), dust} (15 each, 40 with all_history; counterparties gives the full counts when more), dust {senders, payments, lookAlikes[]}, netXrp (XRP only), and scanned (tx count / hasMore).

  Parameters:

  • account (required) — string — r-address
  • limit — integer — latest transactions to scan
  • background — boolean — Run as a background job for up to 10 minutes, for more than 25 s of reading: answers at once with a job_id; get_job returns the result
  • all_history — boolean — Read the whole history instead (25 s of reading, about 25,000 transactions; with background, up to 200,000)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_cex_cashouts read-only

  Detect XRP a wallet sent to centralized exchanges and other custodial services (Binance, Coinbase, Uphold, Gate.io…): accounts that many wallets pay under their own destination tags, named from our account registry, not a hardcoded list. Its latest transactions (up to 200), or with all_history its whole history (up to 10,000 transactions), for "how much has it ever sent to exchanges". Named fee or platform accounts it paid are listed apart (otherServices) and not counted. Returns: cashouts[] {exchange, counterparty, xrp, txCount}, totalXrp, otherServices[], scanned, complete (all_history).

  Parameters:

  • account (required) — string — r-address
  • limit — integer — latest transactions to scan
  • background — boolean — Run as a background job for up to 10 minutes, for more than 25 s of reading: answers at once with a job_id; get_job returns the result
  • all_history — boolean — Read the whole history instead (25 s of reading, about 25,000 transactions; with background, up to 200,000)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• find_snipers read-only

  Find the earliest buyers of a token (snipers) — the first wallets to buy after launch, with how many seconds after the first trade and how much they took. Coordinated early buying is a manipulation signal. Returns: snipers[] {account, secsAfterFirst, tokensBought, xrpPaid (XRP legs only), paidOther {<currency>.<issuer>: amount} (buys paid in another token), ledger}, firstTradeTime, windowBuyers.

  Parameters:

  • id (required) — string — Token md5 or slug
  • window_secs — integer — Seconds after the first trade to count as a sniper (default 300)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• find_sandwich_attacks read-only

  Sandwich/MEV detection three ways. With victim (any account; add id to keep one token): every ledger in the last days (default 60) where another wallet sandwiched its trades, with each bot, the wallet that funded it (fleets) and what the bot made: "was I sandwiched, by whom". With account (a bot wallet, or the funder of a bot fleet; add id to keep one token): every sandwich that wallet or the wallets it activated ran over the last days (default 60): ledgers where one of them traded a token, another account's same-side trade filled next, and the same wallet traded back, by the ledger's own fill order; with victims, tokens and the XRP the bots netted. With id (a token), scan that token's fills (its latest, or with days every fill in that window) for the pattern, bracketers grouped by funder (byFunder): wallets that BUY and SELL it in one ledger (round-trips), and the subset where a third party traded the same side bracketed between the two legs by on-chain fill order. Because XRPL orders a ledger by canonical hash shuffle (not fee/time), a one-off bracket is mostly chance — the real signal is a REPEAT bracketer across many ledgers. Returns: token mode {sameLedgerRoundTrips, bracketedRoundTrips, repeatBracketers[], topBracketers[] {wallet, bracketedLedgers, distinctVictims, direction, funder}, byFunder[]}; account mode {sandwiches, botNetXrp, byWallet[], byToken[], victims[], recent[]}; victim mode {sandwiched, botsNetXrp, byBot[] {bot, funder, sandwiches, botNetXrp}, byFunder[], recent[]}.

  Parameters:

  • id — string — Token md5 or slug (token mode; with account or victim, the one token to check)
  • days — integer — How many days to look back from until (in token mode, reads every fill of the window instead of the latest)
  • limit — integer
  • until — string — The end of the window, ISO date or Unix ms (default now), to look at a past day
  • victim — string — An account to check as the VICTIM: who sandwiched its trades (victim mode)
  • account — string — A bot wallet or the funder of a bot fleet (wallet mode)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• describe_bot_activity read-only

  Characterize whether a wallet trades like a bot, from the transactions it SIGNED: send rate, interval regularity (bots fire at near-constant spacing), and transaction-type mix. The account history also lists every payment, trade or swap that merely touched the account; those are other accounts' activity, so an issuer, a pool or an exchange deposit address is not judged on them. Returns: {sentCount, touchedCount, spanHours, txPerDay, intervalRegularity 0-1, typeMix, verdict, signed {transactions, activeHours, byHourUtc[24], busiestHoursUtc, feesXrp, since}}. signed counts every transaction the account itself signed since the record began, per UTC hour of day: when an account acts.

  Parameters:

  • account (required) — string — r-address
  • limit — integer

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• find_arb_pairs read-only

  Check a token for an arbitrage gap between its AMM spot price and the live order book (buy cheap on one venue, sell dear on the other). Returns: {ammSpot, bestBid, bestAsk, arbGapPct, direction} or none.

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_wallet_pnl read-only

  Trading P&L profile of a wallet across all tokens: realized/unrealized PnL, ROI, win rate, volume, best/worst trades. realizedPnl counts tokens sold without a recorded purchase (transfers, airdrops, LP withdrawals) at zero cost; pnlSplit separates the trading result on positions it bought from those proceeds. Returns: aggregate trading profile: realized/unrealized PnL, pnlSplit {tradingPnlXrp, uncoveredProceedsXrp}, ROI, win rate, volumes, trade counts, topTokens[] (the 15 biggest by profit, each with the same split: tradingPnlXrp, uncoveredProceedsXrp, tokensSoldWithoutPurchase). 404 (isError) for wallets with no DEX trades.

  Parameters:

  • account (required) — string — r-address

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_token_analytics read-only

  Trader-side analytics for a token: unique traders, buyer/seller split, suspected wash volume, concentration. Returns: trader-side metrics: unique traders/makers/takers, buyer vs seller counts, suspected wash volume share, concentration of volume.

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_holder_graph read-only

  Holder-count history of a token over a range (growth/decline trend): counts only, not which wallets. Returns: time series of holder counts over the range.

  Parameters:

  • id (required) — string — Token md5 or slug
  • range — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_whale_activity read-only

  Recent large trades on a token with whale badges (smart money, named wallets, cross-token holders). Returns: events[] of large fills with side, xrpAmount, account, badges (smart money, named, cross-token holder, new wallet), time, hash.

  Parameters:

  • id (required) — string — Token md5 or slug
  • limit — integer

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_related_projects read-only

  Projects sharing an AUDIENCE with a token (co-holders, co-mentions) — shared audience, not shared operator. Returns: related[] tokens/NFT collections sharing holders or promoters, with shared-wallet counts and posts; empty when none.

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_social_mentions read-only

  Recent X/Twitter posts mentioning a token. Without an id, the tokens mentioned most over the last `hours`: posts, distinct authors, views, and the bullish/bearish/neutral reading of the posts rated so far. Returns: mentions[] posts with author, text, engagement, time; without id {window, tokens[] {md5, name, mentions, authors, views, sentiment {bullish, bearish, neutral, rated}}}.

  Parameters:

  • id — string — Token md5 or slug (omit to rank the most-mentioned tokens)
  • days — integer — With follower_growth: the window
  • hours — integer — Without an id: the window, ending now
  • limit — integer
  • follower_growth — boolean — Instead: the X accounts xrpl.to follows (project and token accounts) that gained the most followers over the last `days` (default 7), with the tokens that name them

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• search_x read-only

  Live X (Twitter) search on any topic, not only a token: an amendment, a project, a person, an address, a domain. X search operators work (from:user, "exact phrase", -word, since:YYYY-MM-DD). A sample of recent matching posts, not every post; each is its author's claim. 10 credits a call. Returns: {query, count, posts[] {author, name, text, likes, reposts, views, url, time}}.

  Parameters:

  • query (required) — string
  • limit — integer

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_amm_pools read-only

  AMM pools for a token, or the whole ledger's pools ranked when no token is given (by 24h volume, liquidity, APY, fees or creation). tradingFee is in units of 1/100,000: 197 = 0.197%, 1000 = 1%, the maximum. apy24h/apy7d carry the window's volume, fees, trades and liquidity in XRP. With flows, the pools with the largest net deposits and withdrawals over a window. With by_token, tokens ranked by how many pools they are in. With performance, what providing liquidity to one pool earned over N days: fees against impermanent loss, per LP token. Returns: pools[] with ammAccount, asset1/asset2, currentLiquidity, tradingFee, apy24h/7d {apy, volume, fees, trades, liquidity}, lpBurnedPercent, lpHolderCount, status.

  Parameters:

  • id — string — Token md5 or slug; omit to rank every pool
  • days — integer — With performance or tvl_change: the window, ending now (tvl_change defaults to 7)
  • sort — string — Ranking when no token is given (liquidity, apy and fees rank the 7-day figures)
  • flows — boolean — When no token is given: the pools with the largest net deposits and net withdrawals over the last `hours`, from every AMMDeposit, AMMWithdraw and AMMCreate
  • hours — integer — With flows: the window, ending now
  • limit — integer
  • closed — boolean — When no token is given: the pools that closed (their AMM left the ledger after the last liquidity was withdrawn) in the last `days`, largest final withdrawal first, and the pools emptied but still on the ledger
  • traders — boolean — With id (the token's XRP pool) or amm_account: how many distinct accounts swapped through that pool over the last `days` (default 7), with the largest by XRP volume
  • by_token — boolean — When no token is given: tokens ranked by how many active AMM pools they are in (either side), XRP counted apart
  • fee_tiers — boolean — When no token is given: how many active pools charge each trading fee, the 1% maximum and no fee at all included (optionally only pools with at least min_liquidity XRP)
  • tvl_change — boolean — When no token is given: the pools whose liquidity (TVL, in XRP) grew and shrank the most over the last `days`, from xrpl.to's pool snapshots (deposits, withdrawals and price moves together; flows gives the deposits and withdrawals alone)
  • amm_account — string — With performance: the pool's AMM account instead of a token
  • fee_changes — boolean — When no token is given: every change of a pool's trading fee by liquidity-provider votes (AMMVote) in the last `hours`: the pool, the voter, the fee it voted for, and the fee before and after
  • performance — boolean — With id (the token's XRP pool) or amm_account: what providing liquidity earned over the last `days`, per LP token: fee income, impermanent loss against holding the two assets, and the net
  • token_pairs — boolean — When no token is given: the pools that pair two tokens (no XRP), ranked by value in XRP, a token priced only where its own XRP pool holds 1,000 XRP or more
  • created_days — integer — When no token is given: how many pools were created in the last N days (still active or already emptied), with the largest of them by liquidity now
  • min_liquidity — number — When no token is given: only pools with at least this much liquidity, in XRP (7-day figure)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_lp_positions read-only

  An account's AMM liquidity positions, read live from the validated ledger: every LP token it holds (an LP token is a trust line issued by an AMM account), each pool's reserves and LP supply, the account's share, what it would get back by withdrawing everything, and a value in XRP (a pool with XRP: twice its XRP side, the pool's own spot; a token/token pool: each side at its current xrpl.to price). One call instead of reading every LP line and pool by hand. Returns: {account, positions[] {amm, asset, asset2, lpTokens, share, amount, amount2, valueXrp, tradingFee}, totalValueXrp}.

  Parameters:

  • account (required) — string — r-address

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_holder_overlap read-only

  Wallets that hold BOTH of two tokens (or, with collection_a and collection_b, two NFT collections; or a token and a collection: a with collection_b) right now, counted over every holder from xrpl.to's trust-line index (not a sample): how many, what share of each token's holders that is, and the largest shared holders with both balances. Returns: {a {name, holders}, b {name, holders}, both, shareOfA, shareOfB, top[] {account, balanceA, balanceB}}.

  Parameters:

  • a — string — First token: md5 or slug (search_tokens finds them)
  • b — string — Second token: md5 or slug
  • limit — integer — How many shared holders to list
  • collection_a — string — First NFT collection instead: slug, id or issuer:taxon
  • collection_b — string — Second NFT collection: slug, id or issuer:taxon

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_account_transactions read-only

  Transactions of an XRPL account (payments, trades, trust lines, NFT and AMM activity) from the full history, newest first or (order oldest) from its first transaction: how a wallet was funded and where its first tokens came from. Filter by transaction type and by date range. summary true counts the whole range by type and result instead of listing it. counterparty (one or more r-addresses) returns every transfer between this account and those wallets over the whole history, by asset, both directions, with dates and totals — "what did the creator send these wallets" in one call (it reads this account's transactions for 25 s, or 10 minutes with background: true; start from whichever side has the shorter history). Returns: txs[] with hasMore + marker for paging; with summary: {sentByAccount, sentByOthers, counts {<type>: {total, sent, results}}, scanned, complete, sentInRange (with since: exactly how many transactions the account sent in the range, of every type and result, from its Sequence and TicketCount at both ends, even when the scan stops early)} (sent: signed by this account; the rest were other accounts' transactions that touched it); with counterparty: {flows[] {counterparty, transfers, accountToCounterparty {<asset>: total}, counterpartyToAccount, other {<type>: n}, first, last, rows[] {date, from, to, type, amount, asset, hash}}, scanned, complete}.

  Parameters:

  • account (required) — string — r-address
  • limit — integer
  • order — string — oldest reads forward from the account's first transaction
  • since — string — ISO date or date-time: only transactions in ledgers closed at or after it
  • types — string — Comma-separated TransactionTypes, e.g. AMMDeposit,AMMWithdraw
  • until — string — ISO date or date-time: only transactions in ledgers closed before it (a day is since 2025-06-01, until 2025-06-02)
  • marker — Paging: the marker a previous call returned
  • min_xrp — number — Instead: only the XRP transfers of at least this many XRP into or out of the account (Payment, CheckCash, AccountDelete; what arrived), read for up to 25 s (tens of thousands of transactions; background: true reads for up to 10 minutes). The large payments of a busy wallet, e.g. an exchange's outflows on one day, without paging through its deposits
  • summary — boolean — Count the range by type and result instead of listing it (reads for up to 25 s, tens of thousands of transactions; past that the counts say they are a floor; with since, sentInRange is exact however many there are)
  • background — boolean — Run as a background job for up to 10 minutes, for more than 25 s of reading: answers at once with a job_id; get_job returns the result
  • counterparty — string — Comma-separated r-addresses (up to 25): only transfers and other transactions between this account and them, totalled

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_account_trustlines read-only

  Token holdings (trust lines with balances) of an XRPL account. With valued true: every holding priced in XRP (a token at its current price, an AMM LP token at its share of the pool), largest first, with the total. Returns: lines[] with currency, issuer, balance, limit, flags plus token names; valued: {xrp {total, spendable}, holdings, tokensValueXrp, lines[] {currency, issuer, name, md5, balance, valueXrp, lpPool?}}.

  Parameters:

  • account (required) — string — r-address
  • limit — integer
  • valued — boolean — Price every holding in XRP and total them (what the account's tokens and LP positions are worth)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_account_objects read-only

  Everything an XRPL account owns or is owed on the ledger, summarised by type in ONE call (with top_owners instead, the accounts owning the most objects or Tickets ledger-wide) — escrows (XRP locked, finishable now, next unlock, never-cancellable), checks (SendMax totals by asset, destinations, expired), payment channels (XRP remaining), offers, NFT offers (sell/buy, destination-locked, to whom), tickets, trust lines, signer list, deposit preauths, DID, oracles, MPT issuances/holdings, credentials, domains, vaults — each split into outgoing (this account created it) and incoming (this account is the destination). Reads the validated ledger, up to 4,000 objects (truncated flag beyond); with a type filter it walks up to 40,000 directory entries, and signer_list / did are read directly by their fixed ID. Use this instead of paging account_objects by hand. Returns: {account, ledger_index, total, truncated, byType{<LedgerEntryType>: {count, …totals}}, samples{<LedgerEntryType>: first 3, times as ISO dates}}.

  Parameters:

  • type — string — Optional filter, as account_objects takes it: escrow, check, payment_channel, offer, nft_offer, ticket, state, signer_list, deposit_preauth, did, oracle, mptoken, mpt_issuance, credential, permissioned_domain, vault, delegate, nft_page
  • limit — integer — With top_owners: how many accounts
  • account — string — r-address (or CAIP-10 xrpl:0:r…)
  • top_owners — boolean — Instead, no account needed: the accounts on the whole ledger that own the most objects (with type ticket, the most Tickets; with type nft_page, the most NFTs), read live; complete for every account owning 150 objects or more

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_account_nfts read-only

  NFTs owned by an XRPL account, and what they are worth: the ledger's own list (a first page) plus every held NFT grouped by collection, each valued at its collection's floor (the cheapest ask) and at what its sales have averaged. Returns: nfts[] (ledger entries), byCollection {nfts, collections, valueAtFloorXrp, valueAtAvgSaleXrp, unpricedNfts, neverSoldNfts, top[] {collection, slug, nfts, floorXrp, valueAtFloorXrp, sales, avgSaleXrp, valueAtAvgSaleXrp}}.

  Parameters:

  • account (required) — string — r-address

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_nft_offers read-only

  NFT offers touching an account, and whether any is a phishing lure: offers it made, offers others made on its NFTs, and sell offers ADDRESSED to it (the airdrop-phishing shape — a free NFT whose name or link lures the owner to a drainer site). Each incoming offer carries the NFT's scam verdict and whether the sender is blocklisted. Returns: {offers[], incomingBuyOffers[], incomingSellOffers[] {offer, NFTokenID, name, collection, sender, amountXrp, senderBlocklisted, nftScam, nftScamType}, flagged (count of incoming offers that are scam-flagged or from a blocklisted sender)}.

  Parameters:

  • account (required) — string — r-address

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_nft_activity read-only

  An account's NFT trading history: buys, sells, mints, burns, transfers and offers, newest first, with prices in XRP and the counterparty. Without an account, the whole ledger over the last `hours`: how many events of the given types happened and which collections had the most (e.g. types MINT for "how many NFTs were minted today and by which collection", SALE for sales and XRP volume). Returns: {events[] {time, type, NFTokenID, collectionId, priceXrp, buyer, seller, broker, royaltyXrp, hash}, totals {bought, boughtXrp, sold, soldXrp}}; network-wide: {window {hours, from}, total, byType {type: n}, collections[] {collectionId, name, slug, events, xrp?}}; with order oldest: {first[] {time, ledger, type, NFTokenID, account, collectionId, hash}} (the NFT history index starts at the first mint after XLS-20 went live); with top: {sales[] {time, priceXrp, NFTokenID, collection, issuer, taxon, buyer, seller, broker, royaltyXrp, hash}}; with by broker: {brokers[] {broker, name, direct?, sales, volumeXrp, sharePct, feeXrp, feePct}}.

  Parameters:

  • by — string — Without an account: broker (types SALE) = sales, volume and fees per marketplace broker; day = the counts per UTC calendar day (whole days, today marked partial); collection (types SALE) = collections ranked by unique buyers, with sales, sellers and volume; account = the accounts behind the most events of the types (e.g. CREATE_SELL_OFFER with max_price_xrp 0 for free offers), with how many distinct destinations and whether xrpl.to lists them as scams. hours up to 720
  • top — integer — Without an account, with types SALE: the N most expensive sales in the window (hours up to 720)
  • hours — integer — Without an account: the window, ending now
  • limit — integer
  • order — string — Without an account: the first events of these types ever recorded instead of a window (e.g. the first NFT minted)
  • since — string — With top and types SALE: a calendar window instead of hours, any length (e.g. 2025-01-01 with until 2026-01-01 for the most expensive sales of 2025); ISO date or Unix ms
  • types — string — Comma-separated filter: SALE, MINT, BURN, TRANSFER, CREATE_BUY_OFFER, CANCEL_BUY_OFFER, CREATE_SELL_OFFER, CANCEL_SELL_OFFER, ACCEPT_OFFER (default: all)
  • until — string — With since: the end of the window, exclusive (default now)
  • account — string — r-address (omit for the whole ledger)
  • all_time — boolean — With top and types SALE: rank every sale ever recorded instead of a window (the record sale). Sales paid in XRP; a sale paid in a token has no XRP price on record
  • mint_flags — boolean — Instead: of the NFTs minted in the last `hours` (up to 2,160), how many are transferable, burnable by their issuer, XRP-only or mutable, and their transfer fees
  • max_price_xrp — number — With by account: only offers (or sales) at or below this price in XRP; 0 = free offers

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_nft_collection read-only

  One NFT collection in one call (or, with rank and no id, collections ranked by floor, volume, owners or items, with sane filters): floor (with its 24h/7d/30d history, all-time high, and the floor day by day over the last 30 days), volume and sales over 24h/7d/30d/all time, items, owners, listings, top offer, and its largest holders with how many each holds (xrpl.to's ownership index, recomputed from the ledger). id is the collection slug or issuer:taxon; a bare issuer address gives everything that issuer minted: the ledger's own mint and burn counters for the account (every taxon) and each of its collections. Also the royalties its issuer has been paid, summed from every recorded sale. Returns: {collection, metrics {floor, floorATH, items, owners, listedCount, vol24h, vol7d, sales24h, …}, floorDaily[] {date, low, high, close}, issuerLedger {minted, burned}, royalties {xrp, salesPaying, sales, since}, owners {totalNFTs, totalOwners, topHolders[] {address, count, percentage}}}; for an issuer {issuer, minted, burned, inCirculation, authorizedMinter, holders, collections[] {slug, name, taxon, items, owners}}.

  Parameters:

  • id — string — Collection slug (fuzzybears), issuer:taxon (rw1R8cfHGMySmbj7gJ1HkiCqTY1xhLGYAs:1), or an issuer address for all its collections
  • days — integer — With hold_times: the window of sales
  • rank — string — Instead of id: collections ranked, e.g. floor for the highest floors (with how many items are listed at the floor); bid_over_floor = collections whose best standing buy offer on one of their NFTs is above the floor, by how far
  • limit — integer — With rank: how many collections
  • holders — integer — How many top holders to list
  • min_sales — integer — With rank floor: only collections with at least this many recorded sales
  • hold_times — boolean — With id: instead, how long buyers held the collection's NFTs before reselling them over the last `days` (default 30): median and spread of the hold, how many flipped within an hour, a day or a week, and the price change on resale
  • min_owners — integer — With rank: only collections with at least this many owners (a 1-item collection's floor is one person's asking price)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_holder_cohorts read-only

  Exact holder counts by position size for a token, over EVERY holder (not a sample): dust worth up to 0.01 XRP (airdrop-sized), then up to 1, 10, 100 and 1,000 XRP, and above, valued at the current price. With profit true, also how many holders are in profit or at a loss on what they bought (the trader service's FIFO marks), hold only tokens they never bought, or never traded it. Returns: {priceXrp, holders, bands[] {label, upToXrp, upToTokens, holders}, profit? {inProfit, atLoss, even, heldWithoutPurchase, neverTraded, unrealizedXrp}}.

  Parameters:

  • id (required) — string — Token md5 or slug
  • profit — boolean — Also count holders in profit, at a loss, and holding without a purchase on record
  • above_tokens — number — Also count the holders with more than this many tokens (e.g. 10000 for RLUSD over $10,000)
  • bought_within_days — integer — Instead: every wallet that bought the token with XRP on the DEX in the last N days, its average buy price there against the price now: how many are under water on those buys

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_holder_clusters read-only

  Are a token's top holders connected? Groups its top holders (up to 100, AMM pools left out) by shared activation ancestry, in one call: each holder's chain of activators is walked up to 4 wallets, stopping at service wallets (more than 100 activations: exchanges, launchpads), and holders whose chains meet at the same private wallet, or where one holder activated another, form a cluster. Per cluster: the holders, their combined share of supply, the shared wallets and how many hops up they sit, and the exchange each chain came out of. Also counts holders an exchange activated directly. Activation is an on-chain fact; a shared private funder is strong evidence of one operator, not proof. Direct transfers between wallets are a separate test (get_account_transactions counterparty). With all_holders, EVERY holder is also grouped by the account that created it (farms, sybil groups and scripted airdrops sit below the top 100). Returns: {token, analyzed, clusters[] {holders, supplyPct, ranks[], members[] {account, rank, holding, hops}, shared[] {account, name, holds, activated}, exchangeRoots[], includesCreator}, activatedByService {name: holders}, summary {inClusters, clusteredPct, independent}, wholeHolderBase? {holders, privateFunders[] {funder, holders, supplyPct, balanceSpread, medianBalance}, serviceFunders[]}}.

  Parameters:

  • id (required) — string — Token md5 or slug
  • top — integer — How many top holders to analyse
  • hops — integer — How far up each activation chain to walk
  • all_holders — boolean — Also group EVERY holder by the account that created it (farms and sybil groups below the top 100; tokens up to 150,000 trust lines)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• scan_tweet_addresses read-only

  XRPL addresses posted in the replies to an X (Twitter) post — for airdrops and giveaways. X search returns only part of a thread, so the result says how many replies it saw. Returns: {tweetId, repliesSeen, addresses[] {address, handle, snippet}}.

  Parameters:

  • tweet_url (required) — string — https://x.com/<user>/status/<id>

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• pick_giveaway_winners read-only

  Draw winners for an XRPL giveaway from the replies to an X post: the XRPL addresses posted, one entry per X account and per address, drawn with the hash of an XRP Ledger ledger as the public seed, so anyone can repeat the draw. Pass closes_at (when the giveaway closed) and the seed is the first ledger that closed after it: every caller gets the same winners and nobody can draw again for a different result; without it the newest ledger is the seed, so each call draws anew. X search returns only part of a thread (once 6 of 68 replies), so the result says how many replies it saw: check the post and add anyone missing before treating the draw as final. Returns: {tweetId, repliesSeen, entrants, winners[] {rank, handle, address}, seed {ledger, hash, closedAt, rule}, method, entrantList[], note}.

  Parameters:

  • tweet_url (required) — string — The giveaway post: an X link containing /status/<id>
  • winners — integer — How many winners
  • closes_at — string — When the giveaway closed, as a date and time (e.g. 2026-10-06T18:00:00Z): the seed is the first ledger that closed after it, the same for everyone. Refused while the giveaway is still open

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_testnet read-only

  xrpl.to's live XRP Ledger TESTNET: the tokens (stablecoin, deep and volatile pools, edge cases such as transfer fee, frozen, auth-only, blackholed), AMM pools, NFT collections and test accounts it keeps active, the faucet grant, node state and the endpoints to read, submit and stream through. Read the ids from here rather than inventing them — a Testnet reset changes them. Returns: {network, node, faucet, endpoints, tokens[], pools[], collections[]}.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• fund_testnet_account

  Send Testnet XRP (worthless, the XRP Ledger TESTNET only) from xrpl.to's faucet to an address: the faucet's standard grant, one per address every 24 hours. The one tool here that sends anything; it never touches Mainnet and signs nothing for the caller. Use it to activate or top up a Testnet account for building and testing (get_testnet lists the Testnet economy to try things against). Returns: {network: "testnet", destination, amount, hash, cooldownHours, explorer (testnet.xrpl.org), readBack (xrpl.to's API)} or {error, retryAfterSeconds?}.

  Parameters:

  • address (required) — string — The Testnet r-address to fund

  Hints: read-only no · destructive no · idempotent no · open-world yes

• get_fear_greed_index read-only

  xrpl.to's Fear & Greed index for the XRP Ledger market (0 = extreme fear, 100 = extreme greed), recomputed every minute over listed XRPL tokens with stablecoins excluded. It is the XRPL market's own index, not the crypto-wide one. With days: its history instead, one reading a day taken when xrpl.to's daily report is built (late evening UTC; each reading carries its time), from 5 October 2026 on (nothing older was kept). Returns: {value, label (Extreme Fear | Fear | Neutral | Greed | Extreme Greed), bands, method (the five weighted inputs), updated}.

  Parameters:

  • days — integer — History instead: one reading a day over this many days (oldest first); with history {days, from, readings[] {date, value, label, at}, bands, note}

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_trade_brief read-only

  One call for the market around XRP: XRP's price and 24h change (xrpl.to's own) and the crypto market (CoinGecko), xrpl.to's Fear & Greed for the XRP Ledger, perpetuals across six venues (the OI-weighted 8-hour funding rate, open interest, each venue's rate, long/short ratios, taker buy/sell over the last full hour), liquidations (OKX's latest orders, Gate's last 24 hours and 7 days, its heaviest hour, and the last 24 hours each venue streamed), US spot XRP ETF flows, the Coinbase and Korea premiums, and the latest US macro readings. Every figure is the answer of the tool named for it, cut to its headline, with sources and times and no verdict. Use it for "market overview", "what is the market doing", "how is XRP positioned"; get_funding_rates, get_liquidations, get_crypto_market and get_macro_indicators carry the detail. Returns: {asset, at, xrp {priceUsd, change24hPct, source}, market {totalMarketCapUsd, marketCapChange24hPct, btcDominancePct, xrpMarketCapUsd, xrpRank, at, source}, fearGreed {value, label, index}, derivatives {fundingRate8hWeighted, openInterestUsd, venues {venue: {fundingRate8h, openInterestUsd}}, longShort {measure: {venue: ratio}}, takerBuySell {hourStart, venue: ratio}}, liquidations {okxLatest {from, to, orders, longsUsd, shortsUsd}, gate24h, gate7d, gateHeaviestHour, streamed24h {venue: {longsUsd, shortsUsd, connected}}, streamsSince}, etf {latestDay, lastWeek, at}, premiums {coinbasePct, koreaPct}, macro[] {id, name, value, date, previous}, unavailable[] (sections that did not answer)}.

  Parameters:

  • asset — string — Whose perpetuals and liquidations; the rest is XRP's and the market's

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_funding_rates read-only

  Perpetual futures positioning for XRP, BTC or ETH on OKX, Binance, Bybit, Hyperliquid, Bitget and Gate: each venue's funding rate for its own period (intervalHours; Hyperliquid pays every hour) and the same rate over 8 hours (fundingRate8h, the one to compare across venues; positive = longs pay shorts, longs crowded), the next funding time, open interest in coins and USD, and the total open interest across the venues; long/short ratios (all accounts on OKX, Binance, Bybit and Gate; top traders by accounts and by position size on OKX and Binance); and taker buy and sell volume over the last full hour on Binance and OKX. With days (1-30): instead the funding settled per UTC day on Binance, OKX, Bybit and Hyperliquid, and daily open interest on Binance, OKX and Bybit. Returns: {asset, venues[] {venue, instrument, fundingRate, intervalHours, fundingRate8h, nextFundingTime, openInterest, openInterestUsd, at}, openInterestTotal {openInterest, openInterestUsd, fundingRate8hWeighted (the 8-hour rates weighted by USD open interest), venues[]}, longShortRatios[] {venue, measure, longShortRatio, longShare?, shortShare?, period, at}, takerVolume[] {venue, hourStart, buyVolume, sellVolume, buySellRatio}}; with days {asset, days, from, funding[] {date, venues {venue: {sum, payments}}}, openInterest {venue: [{at, openInterest, openInterestUsd?}]}}.

  Parameters:

  • days — integer — History instead: funding per UTC day and daily open interest over this many days (today included, still open)
  • asset — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_liquidations read-only

  Recent real liquidations of XRP, BTC or ETH perpetual positions; with levels true, instead the ESTIMATED liquidation levels (a heatmap): where positions opened in the last 7 days on Binance, Bybit and OKX would be liquidated, in 1% price bands up to 25% either side, longs below the price and shorts above, from hourly open-interest changes and an assumed leverage mix (stated in the result), each band's USD and the running total from the price ("how much would liquidate if XRP fell 5%"). OKX: its latest filled liquidation orders (up to 100): how many longs and shorts were forced out, their size and USD value, the window they cover and the largest ones. Gate (gate): hourly totals by side over the last 24 hours and the last 7 days, each UTC day of the week, and the week's three heaviest hours, so "how much was liquidated yesterday" has an answer beyond the latest orders. Streams (streams): every liquidation Binance, Bybit and OKX streamed, collected by xrpl.to (since 5 October 2026): last 24 hours and 7 days by venue and side, each UTC day, the largest of the day, and whether each venue's collector is connected (Binance streams at most one liquidation per symbol per second, so its figures are a floor). A long liquidated is a forced sell, a short a forced buy. Returns: {asset, window {from, to, events}, longsLiquidated {count, size, usd}, shortsLiquidated {count, size, usd}, largest[], gate {last24h, last7d {from, to, hours, longsLiquidated {size, usd}, shortsLiquidated {size, usd}}, days[] {date, hours, longsLiquidated, shortsLiquidated}, largestHours[] {hourStart, longsLiquidated, shortsLiquidated}}, streams {collectingSince, venues {venue: {connected, last24h, last7d {longs, shorts {count, size, usd}}}}, days[], largest24h[]}}; a source that did not answer carries unavailable: true. With levels: {asset, estimate: true, price, window, venues[], openInterestShare, assumptions, longs {totalUsd, levels[] {fromPct, toPct, priceLow, priceHigh, usd, cumulativeUsd}, largest[]}, shorts {…}, note}.

  Parameters:

  • asset — string
  • levels — boolean — Instead: estimated liquidation levels by price (a model, labelled as an estimate), not liquidations that happened

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_crypto_market read-only

  The crypto market as a whole, across all venues (centralized exchanges included): total market cap and 24h volume, BTC/ETH/XRP/USDT/USDC dominance, and XRP's global market cap, rank, volume and all-time high. With history (BTC, ETH, SOL, …): that asset's daily closes (Binance, USDT) and the correlation of its daily returns with XRP's. With token (an XRPL token): every market CoinGecko tracks for it outside xrpl.to (centralized exchanges and other DEXes), matched on the token's currency and issuer, each priced in USD against the token's XRPL DEX price: "SOLO on the DEX versus centralized exchanges". Returns: {totalMarketCapUsd, totalVolume24hUsd, marketCapChange24hPct, dominancePct, xrp {...}, at}; with history {asset, days, closes[] {date, close}, correlation {withXrp, dailyReturns, from, to}}; with token {token, xrplDex {priceXrp, priceUsd}, listed, coinId?, centralizedMarkets, unclassified?, markets[] {market, centralized (CoinGecko's flag on the exchange; null not known yet), pair, last, lastUsd, vsXrplDexPct, volume24hUsd, spreadPct, trust, stale, anomaly, lastTradedAt}}.

  Parameters:

  • days — integer — With history: how many days
  • token — string — An XRPL token (md5, slug or name): its markets on other venues, from CoinGecko, against its XRPL DEX price
  • history — string — Daily price history of this asset instead, with its correlation to XRP
  • etf_flows — boolean — Instead: US spot XRP ETFs: daily net inflow, net assets and cumulative inflow (last 20 trading days), the last week's total, each fund's latest day, and an estimate of the XRP they hold
  • korea_premium — boolean — Instead: XRP's price on Upbit (KRW) against Binance (USDT), and the premium or discount in Korea ("kimchi premium")
  • coinbase_premium — boolean — Instead: XRP's price on Coinbase (USD, at Coinbase's own USDT-USD) against Binance (USDT): the Coinbase premium or discount, how US spot buyers price XRP
  • xrpl_cex_ranking — boolean — Instead: XRPL-issued tokens ranked by how many centralized exchanges list them (every XRPL token CoinGecko tracks, its exchanges named; rebuilt daily)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_prediction_markets read-only

  Active Polymarket prediction markets on the Fed, crypto or the economy, busiest first, each outcome priced as a probability (0-1). Returns: {topic, events[] {title, url, endDate, volume24hUsd, markets[] {question, outcomes[] {name, probability}}}}.

  Parameters:

  • topic — string

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_macro_indicators read-only

  Latest US macro readings from FRED: effective fed funds rate, 10-year Treasury yield, CPI inflation and M2 year over year, unemployment rate, initial jobless claims, broad dollar index — each with its date, previous reading and FRED link. With id: that one series over the last months instead (every observation, oldest first). Returns: {series[] {id, name, units, value, date, previous {value, date}, url}}; with id {id, name, units, url, months, from, observations[] {date, value}}.

  Parameters:

  • id — string — One series' history instead: DFF fed funds, DGS10 10-year yield, CPIAUCSL CPI year over year, UNRATE unemployment, ICSA jobless claims, DTWEXBGS dollar index, M2SL M2 year over year
  • months — integer — With id: how many months back

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• find_wallets read-only

  Which XRPL wallets belong to a person, project or website — the reverse of identify_wallet_owner ("what is @JoelKatz's wallet?"). Give an X handle, a domain or an exact name; returns every account xrpl.to's index ties to it with WHERE each tie comes from, and reads the candidates' xrp-ledger.toml files. A wallet whose on-ledger Domain names a site that lists it back in [[ACCOUNTS]] is controlled by that site's operator (two keys agree), and the file's [[PRINCIPALS]] say whom the site names. A token or NFT collection whose metadata merely names a handle is the launcher's claim, not the handle owner's: famous handles collect dozens of tribute tokens, and launchpad TOMLs are generated from what the launcher typed. Returns: {query, xProfile, siteToml, candidates[] {account, name, balanceXrp, inception, tier, evidence, labelSource, domain, sharedHost, toml {listsAccount, principals[]}}, counts, note}.

  Parameters:

  • name — string — An exact name as the index labels it (case-sensitive)
  • limit — integer
  • domain — string — A website domain, e.g. distributedagreement.com
  • handle — string — X (Twitter) handle, with or without @

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• identify_wallet_owner read-only

  Who owns or runs an XRPL wallet, searched on the web and X — for the question the ledger cannot answer (on-chain tools prove links between wallets, never a name). Returns leads with the posts and pages behind them, not proof. Needs your own X-Api-Key (20,000 credits a call). Returns: {subject, answer, sources[] (links), searches {web, x}, asOf, note}.

  Parameters:

  • account (required) — string — r-address
  • context — string — Optional: what you already know (a token it issued, a handle), max 300 chars

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• identify_token_operator read-only

  Who runs an XRPL token, searched on the web and X using the token's issuer, name, X account and website. Returns leads with the posts and pages behind them, not proof. Needs your own X-Api-Key (20,000 credits a call). Returns: {subject, answer, sources[] (links), searches {web, x}, asOf, note}.

  Parameters:

  • id (required) — string — Token md5 or slug

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_news read-only

  XRPL/XRP news with sentiment, from xrpl.to's XRP-focused news feed (not a general crypto wire). Search it with query ("when was Bitget hacked?" → query "Bitget hack"), or list the latest, optionally from one source (the response lists the tracked sources) or one day. Returns: data[] with title, sourceName, sourceUrl, pubDate, sentiment, summary, newest first; sources[] when listing; with query, the words searched and pagination.total.

  Parameters:

  • date — string — YYYY-MM-DD: articles published that day
  • limit — integer
  • query — string — Keywords naming the event, company or token, e.g. "Bitget hack". Every story here is about XRP, so "xrp", "ripple" and "crypto" are dropped while a more specific word remains. Searches every source and day: not combined with source or date
  • source — string — One tracked source, e.g. CoinDesk

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• api_get read-only

  Call ANY documented public xrpl.to GET endpoint not covered by a dedicated tool (to tell a developer how to call the REST API from their own code, use get_api_docs) (the long tail: NFT collections, charts, platform stats, account balances/objects/offers, ledger, tx explain, pairs, richlists…). Read the resource xrplto://reference/api-endpoints for the full list with parameters. Only paths in the public docs are allowed; auth-gated and admin endpoints are refused. Returns: the endpoint's JSON response, arrays shrunk to fit.

  Parameters:

  • path (required) — string — Endpoint path with params filled in, e.g. /account/balance/rXXXX or /nft/collections/{slug}/holders
  • query — object — Optional query parameters as string values

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• xrpl_command read-only

  Call any READ-ONLY rippled JSON-RPC command directly against the XRPL node — the full ledger API for anything the higher-level tools do not cover: account_objects, account_offers, account_channels, ledger_entry, ledger_data, owner_info, noripple_check, deposit_authorized, nft_buy_offers, nft_sell_offers, ripple_path_find (engine-computed payment paths and cost), transaction_entry, get_aggregate_price (price oracles), vault_info (single-asset vaults), simulate (dry-run a tx, submits nothing), server_info, feature, plus the Clio reads mpt_holders (who holds an MPT issuance), nfts_by_issuer and nft_info, and more. Write/sign/admin commands are refused. Params follow xrpl.org for that command. To find the ledger at a date, do not bisect with ledger: api_get /ledger/at with time=<ISO date> returns the last ledger closed at or before it (the one after it is the first to close later). Returns: the raw rippled result.

  Parameters:

  • command (required) — string — rippled command name, e.g. "account_objects", "ledger_entry", "simulate", "vault_info"
  • params — object — Command parameters object as documented at xrpl.org (e.g. {account, ledger_index, limit})
  • network — string — testnet sends the command to xrpl.to's Testnet node (read commands only); an xrpl:1:r… account or a T… X-address selects it too. devnet sends it to Ripple's public Devnet server (s.devnet.rippletest.net), where amendments arrive before Testnet

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• run_script read-only

  Run a short read-only JavaScript program against the XRP Ledger, for what no other tool answers: a scan of every ledger in a past day (about 22,000 ledgers: split it over three calls and add the parts), a sample of ledgers across history, many accounts' histories, anything that needs a loop over rippled reads. When the question needs one, run it rather than offering to: the all-time transaction count, which no index stores, is a sample of ledgers across history (stratified by period, since a ledger held a few transactions in 2013 and over a hundred now) scaled up and given with its 95% interval. Write the body of an async function and return a JSON value. Inside the program: xrpl(method, params, {network}) returns rippled's result for any read-only command xrpl_command takes (current state comes from the local node; ledgers and transactions older than its ~3 days come from full-history nodes, about 200 ledgers a second; rippled errors such as actNotFound come back in the result); api(path, query) returns any documented public xrpl.to GET endpoint; pmap(items, fn, n) runs fn over items n at a time (use it: one call at a time is slow); log(...) keeps up to 60 lines; rippleTime(s) turns a close_time into an ISO date; ledgersBetween(since, until) returns {first, last, count}, the ledgers that closed in [since, until) (a ledger often closes exactly at midnight, and it belongs to the day it opens). No network, files, timers or modules. Limits per call: 50 s, 20,000 node calls (96 at a time), 300 api calls, 64 MB, 60,000 characters of result. Needs an API key. Ways that work: to go on with a paged read (account_tx) in the next call, return its marker and pass it back in; never restart from a ledger index, since one ledger can hold several of the account's transactions. How many transactions an account sent in a window: get_account_transactions with summary and since/until (sentInRange), or in a program the change in its Sequence less the change in its TicketCount (absent = 0) between ledgers first - 1 and last (account_info with ledger_index). A long account_tx range reads fastest as disjoint ledger sub-ranges paged in parallel, each with its own marker. A day is counted exactly (three calls); a total over weeks or more is best estimated from a uniform random sample of its ledgers (the mean per ledger times the number of ledgers), with its margin of error. Returns: {result} (what the program returned) or {error} (naming its line), with logs[] and stats {xrplCalls, apiCalls, failedCalls, byMethod, ms}, and unfinishedPaging[] {method, account, pagesRead} when a paged read stopped while the node still had more: its totals are then partial, so say so or read on. Example: const v = await xrpl("ledger", {ledger_index: "validated"}); const top = Number(v.ledger_index); const n = await pmap(Array.from({length: 1000}, (_, i) => top - i), async (li) => (await xrpl("ledger", {ledger_index: li, transactions: true})).ledger.transactions.length, 64); return {ledgers: n.length, transactions: n.reduce((a, b) => a + b, 0)};

  Parameters:

  • code (required) — string — The program: the body of an async function, ending in return
  • network — string — The network xrpl() reads; api() always reads xrpl.to's Mainnet data
  • background — boolean — Run as a background job for up to 10 minutes and 200,000 node calls, for a program that needs more than 50 s: answers at once with a job_id; get_job returns the result

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_job read-only

  Read a background job: a tool started with background: true (run_script, get_account_transactions, get_payment_flows, get_cex_cashouts), which can run up to 10 minutes. Waits up to wait_s seconds for it to finish, then returns its status, and the tool's own result once it is done. Jobs are kept 1 hour and only the API key that started one can read it. Returns: {job_id, job_tool, job_status (working | completed | failed | cancelled), job_message, createdAt, lastUpdatedAt, next while working; once completed, the tool's own result fields beside these}.

  Parameters:

  • job_id (required) — string — The job_id the background call returned
  • wait_s — integer — Seconds to wait for the job to finish before answering (25 at most)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• cancel_job read-only

  Stop a background job started with background: true. Returns: {job_id, job_status: cancelled}, or the status it had already ended with and note: already ended.

  Parameters:

  • job_id (required) — string — The job_id the background call returned

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• decode_xrpl read-only

  Decode XRPL encodings exactly as the protocol defines them, without guessing: a transaction blob (hex) to its JSON, flags and memo text, plus its hash to look up with get_transaction; an NFTokenID to its flags, transfer fee, issuer, taxon and sequence; an X-address to its classic address and destination tag, or a classic address and tag to its X-address; a currency code between its 40-hex form and its text; an MPTokenIssuanceID to its issuer and sequence; a CTID to its ledger, transaction index and network; a public key to the address it derives. Returns: {kind, ...the decoded fields}.

  Parameters:

  • value (required) — string — The thing to decode: hex blob, NFTokenID, X-address or classic address, currency code or text, MPTokenIssuanceID, CTID, public key (to its address)
  • tag — integer — With a classic address: the destination tag to put in the X-address
  • kind — string — Optional; read from the value when omitted (64 hex characters are read as an NFTokenID, 66 starting 02, 03 or ED as a public key)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_protocol_rules read-only

  XRP Ledger protocol rules checked against the rippled source this server runs: what the ledger allows and refuses and what things cost. Covers freezes and deep freeze, clawback, authorization, trust lines and their limits, payments and partial payments, Deposit Authorization, DisallowXRP, escrows, expiry of offers, checks and NFT offers, self-crossing offers, checks, AMM fees, votes, auction slot, LP tokens, one-sided withdrawals and deletion, NFT transfer fees and mutability, keys and the free key reset, AccountDelete, multisigning, tickets, Batch fees, ordering inside a ledger, sequence errors, amendment majority, close times, oracles and node operations. Each rule carries its evidence (file, current line, permalink), found again on every call; verified:false means the source changed and the rule needs re-checking. Check here BEFORE answering a protocol question from memory; search_rippled_source for anything it does not cover. Returns: {commit, rules[] {id, topics, rule, verified, evidence[] {file, line, url, snippet}}}.

  Parameters:

  • topic — string — A topic or keywords, e.g. "deep freeze", "escrow", "amm", "partial payments", "account deletion". Omit to list every rule without evidence.

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• explain_result_code read-only

  What an XRPL transaction result code means, read from the rippled source this server runs: its class (tes, tec, tef, tel, tem, ter) with what the class implies, quoted from TER.h (applied or not, fee claimed or not, forwarded, whether it can still succeed); its number (tec numbers are stored in metadata); rippled's one-line description (TER.cpp); and every place the engine returns it, each with its function, the section and the conditions it sits in, which say WHEN the code fires (tecUNFUNDED_PAYMENT, for one, is returned only for a direct XRP payment). Use it for "my transaction failed with X" before search_rippled_source. Returns: {code, number, class {prefix, meaning[], url}, description, url, returnedAt[] {file, line, function, section?, conditions[], comments[], at, url}, more, testFiles {count, sample[]}, commit}.

  Parameters:

  • code (required) — string — The result code, e.g. tecPATH_DRY, tefPAST_SEQ, telINSUF_FEE_P, terQUEUED

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• search_rippled_source read-only

  Search the actual rippled C++ source code (the XRPL server implementation) for engine-internals questions the docs and node cannot answer: exact constants, flag bit values, fee/reserve/AMM math, transaction apply/retry logic, canonical tx ordering, error-code meanings. It also reads the repository's own documents, first: API-CHANGELOG.md (which xrpld version added or changed each API method), API-VERSION-2.md / API-VERSION-3.md, cfg/xrpld-example.cfg (every config section and key with its limits) and docs/. Returns matching file:line excerpts pinned to the checked-out commit, each citable as a GitHub permalink. Use this for "what is the exact value/behaviour in rippled" questions; get_protocol_rules holds the rules already checked against it, and explain_result_code reads a result code with its branches. Returns: {commit, permalinkBase, count, matches[] {file, line, text, section (the heading a document match sits under)}}.

  Parameters:

  • query (required) — string — What to find — a symbol, constant, string, or (with regex:true) a POSIX ERE. e.g. "kTradingFeeThreshold", "tecPATH_DRY", "canonical"
  • regex — boolean — Treat query as a regular expression (default false = literal string)
  • context — integer — Lines of surrounding context per match (0-3, default 0)
  • path_glob — string — Restrict to files matching this glob, e.g. "*.h", "AMM*.cpp" or "*.cfg" (default: .h/.cpp/.ipp/.macro and the .md/.cfg/.txt documents)
  • max_results — integer — Max matches to return (default 25, max 50)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• search_forum_posts read-only

  Search the scraped early-XRP / Ripple forum corpus for historical context on-chain tools cannot give: BitcoinTalk ripple threads (e.g. "Pizza for ripples?", "Ripple Giveaway!", "Selling XRP for FRC", "A foundation with 80% of the coins can never work"), bitcoin-otc web-of-trust ratings (the fuzzybear OTC trader), and archived forum.ripple.com. Use for provenance / "who said what in early XRP" / founding-era questions. Returns matching passages with the source site and original thread URL, citable. Returns: {count, matches[] {site, url, title, snippet}}.

  Parameters:

  • query (required) — string — Word, phrase, wallet address, or (with regex:true) a POSIX ERE. e.g. "pizza", "fuzzybear", "rHb3LGN"
  • regex — boolean — Treat query as a regular expression (default false = literal)
  • max_results — integer — Max matches to return (default 20, max 50)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• search_xrpl_docs read-only

  Search the XRP Ledger documentation at xrpl.build (xrpl.org's docs, lighter and improved, at the same paths): how the ledger works and how to build on it. Transaction types with their fields, flags and error cases, API methods, concepts (reserves, tickets, rippling, AMM, escrow, multi-signing ...), tutorials and code samples. Use it for any "how do I / what does field X mean / which flag" question and link the xrpl.build page it returns (url). Pass page (a path or URL it returned) to read a whole page. Returns: {query, count, results[] {title, section, url, description, excerpt}}, or with page {page, title, url, sections[] {heading, text}}.

  Parameters:

  • page — string — Read one whole page instead: a path or URL a search returned, e.g. "docs/concepts/accounts/tickets"
  • limit — integer — Results (default 5, max 10)
  • query — string — A few words, a transaction type, a field or a flag name, e.g. "AMMDeposit flags", "TicketSequence", "partial payments delivered_amount"

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• get_api_docs read-only

  xrpl.to's own REST and WebSocket API from its published docs (the same as GET https://api.xrpl.to/v1/docs and https://xrpl.to/docs), for a developer calling xrpl.to from their own code: an endpoint's exact URL, method and parameters, the key header and rate limits, the WebSocket streams and their messages, error codes. The tools on this server are not the REST API: answer "how do I call xrpl.to for X" with what this returns. Returns: {query, baseUrl, keyHeader, keyNotes, count, endpoints[] {method, url, section, description, params, body, auth, messages, response}, topics[] {name, content}}.

  Parameters:

  • query (required) — string — What to call or know, e.g. "ohlc candles", "websocket prices", "rate limits", "submit transaction", "api key"
  • limit — integer — Endpoints (default 8, max 20)

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• save_note

  Save a finding under a subject (a wallet, a token, a topic) so it can be recalled in later sessions. Notes belong to the X-Api-Key making the call; without a key this tool explains how to get one. Returns: the stored note {id, subject, text, at}.

  Parameters:

  • subject (required) — string — What the note is about — an r-address, token md5/name, or a topic (max 64 chars)
  • text (required) — string — The finding (max 1000 chars)

  Hints: read-only no · destructive no · idempotent no · open-world no

• recall_notes read-only

  Recall notes saved earlier under this X-Api-Key, optionally filtered by subject (exact or prefix match). Returns: notes[] newest first.

  Parameters:

  • subject — string — Optional subject filter

  Hints: read-only yes · destructive no · idempotent yes · open-world no

• delete_note destructive

  Delete one saved note by id. Returns: {deleted: true|false}.

  Parameters:

  • id (required) — string

  Hints: read-only no · destructive yes · idempotent yes · open-world no

• get_swap_quote read-only

  Exact swap quote between two tokens on the XRPL DEX (AMM + order book routed). Token ids: md5, or the literal "XRP". Give source_value (amount to spend) OR destination_value (amount to receive). Returns: quote {source_amount, destination_amount (XRP drops string or {currency,issuer,value}), execution_rate, spot_price, price_impact, amm_price_change, suggested_slippage, minimum_received, paths, warnings, route}, alternatives, requiresTrustline.

  Parameters:

  • source_token (required) — string
  • destination_token (required) — string
  • source_value — string — Amount of source_token to spend
  • source_account — string — Optional r-address the quote is computed for (reserve/spendable checks)
  • destination_value — string — Amount of destination_token to receive

  Hints: read-only yes · destructive no · idempotent yes · open-world no

Publisher website

Measured by MCPYP probing. Untested fields are omitted, never estimated. Listing is always free; MCPYP never proxies calls or stores user tokens.