# XRPL.to Token Analytics (remote · api.xrpl.to) XRP Ledger tokens, AMM pools, NFTs, accounts and transactions: prices, holders, trades and history - Trust score: 70/100 (medium) - Change this week: +4 - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-11-04 ## Components - remote · `api.xrpl.to`: 70/100 (this document), [markdown](https://verifymcp.io/servers/xrplto-xrpl-to/v1-mcp.md), [page](https://verifymcp.io/servers/xrplto-xrpl-to/v1-mcp) ## Channel facts - Endpoint: `https://api.xrpl.to/v1/mcp` - Transports: `streamable-http` - Auth: `none` - Version: `1.20.0` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-11-04. - **Endpoint Security**: 63/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (delete_note). - HTTPS is enforced; there's no plaintext access path. - The HSTS (Strict-Transport-Security) header is present. - DNSSEC check failed: this domain isn't protected by DNSSEC. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 55/100 - 53% of prompts and resources have a non-trivial description (not blank, and not just the item's name). - AI-judged instruction clarity (good). - Context-footprint check failed: tool/resource definitions use about 28792 tokens (~299/item across 96 items; 89 tools + 7 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 50/100 - Stability observed for 15 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 96/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 87% of tool parameters carry a description. - **Tool Safety**: 100/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation. - An AI judge read all 91 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### How do I install the XRPL.to Token Analytics MCP server? XRPL.to Token Analytics is a hosted endpoint at https://api.xrpl.to/v1/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add --transport http xrplto-xrpl-to 'https://api.xrpl.to/v1/mcp' ``` ### Cursor ```json { "mcpServers": { "xrplto-xrpl-to": { "url": "https://api.xrpl.to/v1/mcp" } } } ``` ### VS Code ```json { "servers": { "xrplto-xrpl-to": { "type": "http", "url": "https://api.xrpl.to/v1/mcp" } } } ``` ### Codex ```toml [mcp_servers.xrplto-xrpl-to] url = "https://api.xrpl.to/v1/mcp" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "xrplto-xrpl-to": { "type": "remote", "url": "https://api.xrpl.to/v1/mcp", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add xrplto-xrpl-to --url 'https://api.xrpl.to/v1/mcp' --transport streamable-http ``` ### Hermes ```yaml mcp_servers: xrplto-xrpl-to: url: "https://api.xrpl.to/v1/mcp" ``` ### Netclaw ```json { "McpServers": { "xrplto-xrpl-to": { "Transport": "http", "Url": "https://api.xrpl.to/v1/mcp" } } } ``` ### Vellum ```bash assistant mcp add xrplto-xrpl-to -t streamable-http -u 'https://api.xrpl.to/v1/mcp' ``` ### Other ```json { "mcpServers": { "xrplto-xrpl-to": { "type": "http", "url": "https://api.xrpl.to/v1/mcp" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-11-04 (score 70, +1) No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-11-02 (score 69, +1) - [security] The server rewrote its instructions, which are the text every model session reads - [security] Tool “get_account_ancestry” rewrote its description, which is the text the model reads - [security] Tool “get_account_transactions” rewrote its description, which is the text the model reads - [security] Tool “get_amm_pools” rewrote its description, which is the text the model reads - [security] Tool “get_network_activity” rewrote its description, which is the text the model reads - [security] Tool “get_nft_collection” rewrote its description, which is the text the model reads - [security] Tool “get_payment_flows” rewrote its description, which is the text the model reads - [security] Tool “get_token_flow” rewrote its description, which is the text the model reads - [cosmetic] “get_amm_pools” added an optional parameter “history” - [cosmetic] “get_amm_pools” added an optional parameter “since” - [cosmetic] “get_amm_pools” added an optional parameter “until” - [cosmetic] “get_network_activity” added an optional parameter “accounts_by_day” - [cosmetic] “get_network_activity” added an optional parameter “type” - [cosmetic] “get_nft_collection” added an optional parameter “since” - [cosmetic] “get_nft_collection” added an optional parameter “until” - [cosmetic] “get_tokens_by_category” added an optional parameter “days” - [cosmetic] “get_tokens_by_category” added an optional parameter “since” - [cosmetic] “get_tokens_by_category” added an optional parameter “until” - [cosmetic] “get_account_transactions” reworded the description of “summary” - [cosmetic] “get_amm_pools” reworded the description of “amm_account” - [cosmetic] “get_network_activity” reworded the description of “by” - [cosmetic] “get_network_activity” reworded the description of “daily” - [cosmetic] “get_network_activity” reworded the description of “hours” - [cosmetic] “get_nft_collection” reworded the description of “rank” - [cosmetic] “get_tokens_by_category” reworded the description of “min_holders” - [cosmetic] “get_tokens_by_category” reworded the description of “sort” ### 2026-10-31 (score 68, +1) No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-30 (score 67, 0) - [functional regression] Resource “Public API endpoint catalog for api_get (192 endpoints)” was removed - [functional] New resource “Public API endpoint catalog for api_get (193 endpoints)” ### 2026-10-29 (score 67, +1) No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-27 (score 66, 0) - [security] Tool “get_account_objects” rewrote its description, which is the text the model reads - [security] Tool “get_account_transactions” rewrote its description, which is the text the model reads - [security] Tool “get_holders” rewrote its description, which is the text the model reads - [functional] New tool “get_trader_rotations” ### 2026-10-26 (score 66, +1) No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes. ### 2026-10-24 (score 65, +1) - [functional regression] Resource “Public API endpoint catalog for api_get (187 endpoints)” was removed - [functional] New resource “Public API endpoint catalog for api_get (192 endpoints)” ## MCP tools (89) ### `search_tokens` (~175 tokens) 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. Input parameters: - `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) - `query` (string, required): Token name, symbol or issuer r-address ### `get_token` (~184 tokens) 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). Input parameters: - `full` (boolean): Return the whole document instead of the compact essentials - `id` (string, required): Token md5 / slug / issuer-currency / XRP ### `get_trending_tokens` (~37 tokens) Top trending XRPL tokens right now. Returns: tokens ranked by trendingScore with lightweight market fields. Input parameters: - `limit` (integer) ### `get_new_launches` (~240 tokens) 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}. Input parameters: - `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 - `creator` (boolean): Add each creator's allocation and sells - `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) ### `get_trades` (~284 tokens) 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[]}. Input parameters: - `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) - `id` (string, required): 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 ### `get_holders` (~191 tokens) 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. An MPT (id mpt-) lists the wallets holding its units (MPToken objects, balance scaled by AssetScale). Input parameters: - `id` (string, required): Token md5 or slug - `limit` (integer) - `offset` (integer): Skip this many holders (rank order) ### `get_top_traders` (~109 tokens) 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. Input parameters: - `id` (string, required): Token md5 or slug - `interval` (string) - `limit` (integer) - `sortBy` (string) ### `get_creator_activity` (~78 tokens) 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. Input parameters: - `id` (string, required): Token md5 or slug ### `get_token_flow` (~166 tokens) Supply flow map: where the issued/dev supply went — held, locked in escrow, sold, pooled, sent to exchanges, burned. Returns: summary with the split as percentages of supply (retainedPctOfSupply, placedLockedPctOfSupply, tracedSoldPctOfSupply, lpDepositedPctOfSupply, placedToExchangePctOfSupply, creatorBurnedPctOfSupply, untracedPctOfSupply, unscannedPctOfSupply), flowSubject + flowSubjectRole (dev|issuer), XRP totals (totalSoldXrp, totalBoughtXrp, netFlowXrp, totalToExchanges), coverage flags (creatorScanComplete, preFloorLaunch); exchangeBreakdown[]; linkedAddresses[]. Input parameters: - `id` (string, required): Token md5 or slug ### `analyze_token_risk` (~138 tokens) 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. Input parameters: - `id` (string, required): Token md5 or slug ### `get_frozen_lines` (~236 tokens) 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}. Input parameters: - `id` (string, required): Token md5 or slug ### `get_issuer_actions` (~875 tokens) 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, acc… Input parameters: - `account` (string): The account that acted (the issuer), r-address - `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… - `blackholed` (boolean): Instead: accounts that became unable to sign anything since `since` (default the last 7 days), with the tokens they issue - `holder` (string): The account acted on (holder, or the AMM account), r-address - `limit` (integer) - `since` (string): ISO date: only actions at or after it - `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 ### `get_wash_trading` (~207 tokens) 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}}. Input parameters: - `collection` (string): An NFT collection slug or id instead: wash trading in its sales - `days` (integer): Collection mode: how many days of sales to read - `id` (string): Token md5 or slug - `interval` (string): Window for the trader stats (default all) ### `check_scam` (~91 tokens) 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. Input parameters: - `account` (string, required): r-address ### `check_domain` (~322 tokens) 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}}. Input parameters: - `account` (string): Optional r-address: verify it and the domain claim each other - `domain` (string): A domain or a URL, e.g. xrpl-promotion.net or https://app.example.com/claim - `limit` (integer): Without a domain: how many of the newest listed phishing domains ### `get_ohlc` (~450 tokens) 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 ". 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). Input parameters: - `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 - `id` (string, required): Token md5 or slug, or XRP - `resolution` (string) - `vs_currency` (string): Quote currency (default XRP; USD for the literal XRP) ### `get_orderbook` (~61 tokens) Live XRP order book for a token (bids/asks with sizes). Returns: bids[] and asks[] with price, amount, total, maker; spread. Input parameters: - `id` (string, required): Token md5 or slug - `limit` (integer) ### `get_token_pairs` (~51 tokens) Trading pairs a token trades in, with per-pair volume. Returns: pairs[] the token trades in with counter asset and 24h volume. Input parameters: - `id` (string, required): Token md5 or slug ### `get_account_info` (~90 tokens) 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". Input parameters: - `account` (string, required): r-address ### `get_account_ancestry` (~154 tokens) Who activated an account and who it activated (funding lineage), with tokens launched along the chain. An API key reads the upward path: who an account activated (direction down or both) is for xrpl.to's own surfaces. 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. Input parameters: - `account` (string, required): r-address - `direction` (string) - `limit` (integer): Max children returned ### `get_transaction` (~55 tokens) Look up an XRPL transaction by hash. Returns: decoded transaction: type, account, destination, amounts, fee, result code, ledger, date, affected balances. Input parameters: - `hash` (string, required): 64-char hex tx hash ### `get_global_stats` (~74 tokens) 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. ### `get_network_activity` (~1873 tokens) 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 day (one transaction type per UTC day, e.g. payments each day of the last 30 days), accounts_by_day (accounts created per UTC day at any date), 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 daily report). 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 service… Input parameters: - `accounts_by_day` (boolean): Instead: how many accounts were created per UTC day, at any date, with the total and the busiest day (since/until, default the last 30 days, at most 400 days at a time) - `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 - `by` (string): hour: also break the window into clock hours (UTC): transactions, failed and ledgers per hour. day: instead, one row per UTC day (default the last 30 days, since/until for up to 400; counts start 202… - `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, cre… - `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 fo… - `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… - `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… - `dex_by_hour` (integer): Instead: DEX trading volume (XRP) and fills by hour of the day (UTC), averaged over the last N days - `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 - `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, f… - `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… - `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 - `hours` (integer): Window ending at the latest ledger (xrpl.to's counts start 2026-10-02) - `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 corri… - `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 - `limit` (integer): With by app: how many apps to list - `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 - `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_t… - `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 amou… - `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) - `type` (string): With by day: the transaction type to count, e.g. Payment, OfferCreate, NFTokenAcceptOffer (default Payment) - `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 ### `get_validators` (~860 tokens) 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, or fix 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, am… Input parameters: - `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 - `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 - `commits_days` (integer): Instead (or with releases): rippled development over the last N days: commits on develop and the top contributors - `history` (integer): Optional: the last N amendment events on the ledger (gained majority, lost majority, enabled), newest first - `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 - `releases` (boolean): Instead: rippled's latest GitHub releases (tag, date, the start of the release notes) beside the versions the trusted validators run ### `get_escrows` (~644 tokens) 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}}. Input parameters: - `account` (string): Optional r-address: its escrows - `currency` (string): XRP, a token currency code, or all - `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 - `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) - `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 - `within_days` (integer): Instead: every escrow that unlocks (FinishAfter) in the next N days, totalled per owner, largest first ### `get_xrp_distribution` (~435 tokens) 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}}. Input parameters: - `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) - `limit` (integer): With list: how many accounts - `list` (boolean): Instead: the accounts above min_xrp themselves, largest first (the XRP rich list), each with the last ledger that touched it - `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) ### `get_oracle_prices` (~221 tokens) 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}}. Input parameters: - `base` (string): Base asset code, e.g. XRP, BTC, RLUSD - `oracles` (array): Optional: other Oracle objects to read instead of the defaults - `quote` (string) ### `get_top_movers` (~100 tokens) Biggest gainers or losers over a timeframe. Returns: tokens[] sorted by the chosen timeframe change (pro5m/1h/24h/7d) with lightweight fields. Input parameters: - `direction` (string) - `limit` (integer) - `min_holders` (integer): Only tokens with at least this many holders (ranked over every such token, not a page of the overall list) - `timeframe` (string) ### `get_tokens_by_category` (~741 tokens) 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?}}. Input parameters: - `category` (string): Tag, e.g. Memes, Stablecoin, FirstLedger (optional when token_type is given) - `days` (integer): With sort holders_change and no since: the window is the last N days (default 7) - `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 - `inactive_days` (integer): With sort inactive: the idle period - `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 - `limit` (integer) - `min_holders` (integer): With issuer_setting or sort holders_7d, holders_change, lp_burned, creator_holding or inactive: only tokens with at least this many holders today - `min_marketcap` (number): With sort turnover: only tokens with at least this market cap in XRP - `rank_by` (string): With group_by issuer: the ranking - `since` (string): With sort holders_change: start of the window, ISO date or Unix ms - `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_24… - `token_type` (string) - `until` (string): With sort holders_change: end of the window, ISO date or Unix ms (default now) ### `get_exit_liquidity` (~118 tokens) 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}. Input parameters: - `id` (string, required): Token md5 or slug - `xrp_sizes` (array): XRP-value sell sizes to test (default 100, 1k, 10k, 50k) ### `get_wallet_risk` (~87 tokens) 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}. Input parameters: - `account` (string, required): r-address ### `get_offramp` (~77 tokens) 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}. Input parameters: - `account` (string, required): r-address - `limit` (integer) ### `get_payment_flows` (~392 tokens) 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; for totals over a date range, get_account_transactions with since, until and summary. 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? {.: 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). Input parameters: - `account` (string, required): r-address - `all_history` (boolean): Read the whole history instead (25 s of reading, about 25,000 transactions; with background, up to 200,000) - `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 - `limit` (integer): latest transactions to scan ### `get_cex_cashouts` (~241 tokens) 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). Input parameters: - `account` (string, required): r-address - `all_history` (boolean): Read the whole history instead (25 s of reading, about 25,000 transactions; with background, up to 200,000) - `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 - `limit` (integer): latest transactions to scan ### `find_snipers` (~139 tokens) 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 {.: amount} (buys paid in another token), ledger}, firstTradeTime, windowBuyers. Input parameters: - `id` (string, required): Token md5 or slug - `window_secs` (integer): Seconds after the first trade to count as a sniper (default 300) ### `find_sandwich_attacks` (~529 tokens) 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[]}. Input parameters: - `account` (string): A bot wallet or the funder of a bot fleet (wallet mode) - `days` (integer): How many days to look back from until (in token mode, reads every fill of the window instead of the latest) - `id` (string): Token md5 or slug (token mode; with account or victim, the one token to check) - `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) ### `describe_bot_activity` (~180 tokens) 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. Input parameters: - `account` (string, required): r-address - `limit` (integer) ### `find_arb_pairs` (~75 tokens) 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. Input parameters: - `id` (string, required): Token md5 or slug ### `get_wallet_pnl` (~178 tokens) 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. Input parameters: - `account` (string, required): r-address ### `get_token_analytics` (~70 tokens) 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. Input parameters: - `id` (string, required): Token md5 or slug ### `get_holder_graph` (~62 tokens) 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. Input parameters: - `id` (string, required): Token md5 or slug - `range` (string) ### `get_whale_activity` (~83 tokens) 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. Input parameters: - `id` (string, required): Token md5 or slug - `limit` (integer) ### `get_trader_rotations` (~331 tokens) Where active DEX traders are moving XRP between tokens. A rotator is an account that both bought and sold tokens in the window; the window counts whole UTC days (24h = yesterday and today). Without id, the whole market: the tokens rotators traded most, with rotateInXrp (XRP they spent buying it), rotateOutXrp (XRP they got selling it), netFlow (in minus out) and trader counts, plus the 20 biggest rotators with their top buys and sells. With id, one token: which other tokens its sellers bought in the same window (rotatedTo), which tokens its buyers sold (rotatedFrom), each capped at the trader's own volume in this token, and freshCapital, its buyers who sold nothing else. Same window, not proven order. Returns: market {period, totalRotators, totalTokensInvolved, tokens[] {md5, name, rotateInXrp, rotateOutXrp, netFlow, rotateInTraders, rotateOutTraders}, topRotators[] {account, totalVolume, tokenCount, topTokens[]}}; token {period, sellers, buyers, sellVolume, buyVolume, rotatedTo[] {md5, name, xrp, traders, topTraders[]}, rotatedFrom[], freshCapital[] {account, xrp}, freshCapitalTotal, freshCapitalCount}. Input parameters: - `id` (string): Token md5 or slug; omit for the whole market - `limit` (integer): Tokens in the market view - `period` (string) ### `get_related_projects` (~71 tokens) 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. Input parameters: - `id` (string, required): Token md5 or slug ### `get_social_mentions` (~201 tokens) 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}}}. Input parameters: - `days` (integer): With follower_growth: the window - `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 - `hours` (integer): Without an id: the window, ending now - `id` (string): Token md5 or slug (omit to rank the most-mentioned tokens) - `limit` (integer) ### `search_x` (~124 tokens) 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}}. Input parameters: - `limit` (integer) - `query` (string, required) ### `get_amm_pools` (~951 tokens) 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 history, one pool's liquidity over time, month by month (since/until). 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. Input parameters: - `amm_account` (string): With performance, traders or history: the pool's AMM account instead of a token - `by_token` (boolean): When no token is given: tokens ranked by how many active AMM pools they are in (either side), XRP counted apart - `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… - `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 - `days` (integer): With performance or tvl_change: the window, ending now (tvl_change defaults to 7) - `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 - `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) - `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 - `history` (boolean): With id (the token's XRP pool) or amm_account: the pool's reserves and value in XRP over time, month by month with the change, and day by day for a window of up to 92 days. since/until pick the windo… - `hours` (integer): With flows: the window, ending now - `id` (string): Token md5 or slug; omit to rank every pool - `limit` (integer) - `min_liquidity` (number): When no token is given: only pools with at least this much liquidity, in XRP (7-day figure) - `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 - `since` (string): With history: start of the window, ISO date - `sort` (string): Ranking when no token is given (liquidity, apy and fees rank the 7-day figures) - `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 - `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 - `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 giv… - `until` (string): With history: end of the window, ISO date (default now) ### `get_lp_positions` (~162 tokens) 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}. Input parameters: - `account` (string, required): r-address ### `get_holder_overlap` (~209 tokens) 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}}. Input parameters: - `a` (string): First token: md5 or slug (search_tokens finds them) - `b` (string): Second token: md5 or slug - `collection_a` (string): First NFT collection instead: slug, id or issuer:taxon - `collection_b` (string): Second NFT collection: slug, id or issuer:taxon - `limit` (integer): How many shared holders to list ### `get_account_transactions` (~771 tokens) 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, and adds up what the account received and sent by asset ("what did it send and receive in October"). 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 (an MPT payment carries deliveredMpt {units, ticker, mptIssuanceId}, already scaled by the token's AssetScale, and the page mpts {: {ticker, name, scale, issuer, slug}}); with summary: {sentByAccount, sentByOthers, counts {: {total, sent, results}}, received[] and sent[] {asset, transfers, total}, toSelf[]?, 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 {: total}, counterpartyToAccount, other {: n}, first, last, rows[] {date, from, to, type, amount, asset, hash}}, scanned, complete}. Input parameters: - `account` (string, required): r-address - `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 - `limit` (integer) - `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; backgro… - `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 - `summary` (boolean): Count the range by type and result, and total what it received and sent by asset, instead of listing it (reads for up to 25 s, tens of thousands of transactions; past that the counts say they are a f… - `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) ### `get_account_trustlines` (~162 tokens) 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?}}. Input parameters: - `account` (string, required): r-address - `limit` (integer) - `valued` (boolean): Price every holding in XRP and total them (what the account's tokens and LP positions are worth) ### `get_account_objects` (~499 tokens) 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{: {count, …totals}}, samples{: first 3, times as ISO dates}}; MPTokenIssuance carries issuances[] {mptIssuanceId, ticker, name, issuerName, description (metadata decoded), assetScale, outstanding, maximum, transferFee, flags (requireAuth, canTransfer, canTrade, canClawback, canLock, canEscrow, locked)} and MPToken carries holdings[] {mptIssuanceId, units, flags (authorized, locked)}. Input parameters: - `account` (string): r-address (or CAIP-10 xrpl:0:r…) - `limit` (integer): With top_owners: how many accounts - `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 o… - `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, permission… ### `get_account_nfts` (~146 tokens) 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}}. Input parameters: - `account` (string, required): r-address ### `get_nft_offers` (~158 tokens) 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)}. Input parameters: - `account` (string, required): r-address ### `get_nft_activity` (~759 tokens) 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}}. Input parameters: - `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 - `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) = collection… - `hours` (integer): Without an account: the window, ending now - `limit` (integer) - `max_price_xrp` (number): With by account: only offers (or sales) at or below this price in XRP; 0 = free offers - `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 - `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 - `top` (integer): Without an account, with types SALE: the N most expensive sales in the window (hours up to 720) - `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) ### `get_nft_collection` (~659 tokens) One NFT collection in one call (or, with rank and no id, collections ranked by floor, volume, owners or items, or by sales or volume over any date range, 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}}. Input parameters: - `days` (integer): With hold_times: the window of 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,… - `holders` (integer): How many top holders to list - `id` (string): Collection slug (fuzzybears), issuer:taxon (rw1R8cfHGMySmbj7gJ1HkiCqTY1xhLGYAs:1), or an issuer address for all its collections - `limit` (integer): With rank: how many collections - `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) - `min_sales` (integer): With rank floor: only collections with at least this many recorded sales - `rank` (string): Instead of id: collections ranked, e.g. floor for the highest floors (with how many items are listed at the floor); sales_range and volume_range by sales or XRP volume between since and until; bid_ov… - `since` (string): With rank sales_range or volume_range: start of the window, ISO date or Unix ms (default 30 days before until, at most 400 days) - `until` (string): With rank sales_range or volume_range: end of the window, ISO date or Unix ms (default now) ### `get_holder_cohorts` (~276 tokens) 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}}. Input parameters: - `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 - `id` (string, required): Token md5 or slug - `profit` (boolean): Also count holders in profit, at a loss, and holding without a purchase on record ### `get_holder_clusters` (~384 tokens) 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[]}}. Input parameters: - `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) - `hops` (integer): How far up each activation chain to walk - `id` (string, required): Token md5 or slug - `top` (integer): How many top holders to analyse ### `scan_tweet_addresses` (~88 tokens) 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}}. Input parameters: - `tweet_url` (string, required): https://x.com//status/ ### `pick_giveaway_winners` (~285 tokens) 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}. Input parameters: - `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 - `tweet_url` (string, required): The giveaway post: an X link containing /status/ - `winners` (integer): How many winners ### `get_testnet` (~112 tokens) 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[]}. ### `fund_testnet_account` (~156 tokens) 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?}. Input parameters: - `address` (string, required): The Testnet r-address to fund ### `get_fear_greed_index` (~190 tokens) 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}. Input 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} ### `get_trade_brief` (~448 tokens) 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)}. Input parameters: - `asset` (string): Whose perpetuals and liquidations; the rest is XRP's and the market's ### `get_funding_rates` (~390 tokens) 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?}]}}. Input parameters: - `asset` (string) - `days` (integer): History instead: funding per UTC day and daily open interest over this many days (today included, still open) ### `get_liquidations` (~549 tokens) 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[… Input parameters: - `asset` (string) - `levels` (boolean): Instead: estimated liquidation levels by price (a model, labelled as an estimate), not liquidations that happened ### `get_crypto_market` (~551 tokens) 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}}. Input parameters: - `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 - `days` (integer): With history: how many days - `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 - `history` (string): Daily price history of this asset instead, with its correlation to XRP - `korea_premium` (boolean): Instead: XRP's price on Upbit (KRW) against Binance (USDT), and the premium or discount in Korea ("kimchi premium") - `token` (string): An XRPL token (md5, slug or name): its markets on other venues, from CoinGecko, against its XRPL DEX price - `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) ### `get_prediction_markets` (~80 tokens) 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}}}}. Input parameters: - `topic` (string) ### `get_macro_indicators` (~203 tokens) 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}}. Input 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 ### `find_wallets` (~281 tokens) 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}. Input parameters: - `domain` (string): A website domain, e.g. distributedagreement.com - `handle` (string): X (Twitter) handle, with or without @ - `limit` (integer) - `name` (string): An exact name as the index labels it (case-sensitive) ### `identify_wallet_owner` (~131 tokens) 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}. Input parameters: - `account` (string, required): r-address - `context` (string): Optional: what you already know (a token it issued, a handle), max 300 chars ### `identify_token_operator` (~98 tokens) 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}. Input parameters: - `id` (string, required): Token md5 or slug ### `get_news` (~212 tokens) 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. Input 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 a… - `source` (string): One tracked source, e.g. CoinDesk ### `api_get` (~170 tokens) 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. Input parameters: - `path` (string, required): Endpoint path with params filled in, e.g. /account/balance/rXXXX or /nft/collections/{slug}/holders - `query` (object): Optional query parameters as string values ### `xrpl_command` (~352 tokens) 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= returns the last ledger closed at or before it (the one after it is the first to close later). Returns: the raw rippled result. Input parameters: - `command` (string, required): rippled command name, e.g. "account_objects", "ledger_entry", "simulate", "vault_info" - `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.… - `params` (object): Command parameters object as documented at xrpl.org (e.g. {account, ledger_index, limit}) ### `run_script` (~857 tokens) 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… Input parameters: - `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 - `code` (string, required): 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 ### `get_job` (~177 tokens) 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}. Input parameters: - `job_id` (string, required): The job_id the background call returned - `wait_s` (integer): Seconds to wait for the job to finish before answering (25 at most) ### `cancel_job` (~58 tokens) 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. Input parameters: - `job_id` (string, required): The job_id the background call returned ### `decode_xrpl` (~256 tokens) 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}. Input parameters: - `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) - `tag` (integer): With a classic address: the destination tag to put in the X-address - `value` (string, required): The thing to decode: hex blob, NFTokenID, X-address or classic address, currency code or text, MPTokenIssuanceID, CTID, public key (to its address) ### `get_protocol_rules` (~271 tokens) 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}}}. Input parameters: - `topic` (string): A topic or keywords, e.g. "deep freeze", "escrow", "amm", "partial payments", "account deletion". Omit to list every rule without evidence. ### `explain_result_code` (~246 tokens) 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}. Input parameters: - `code` (string, required): The result code, e.g. tecPATH_DRY, tefPAST_SEQ, telINSUF_FEE_P, terQUEUED ### `search_rippled_source` (~384 tokens) 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)}}. Input parameters: - `context` (integer): Lines of surrounding context per match (0-3, default 0) - `max_results` (integer): Max matches to return (default 25, max 50) - `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) - `query` (string, required): 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) ### `search_forum_posts` (~221 tokens) 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}}. Input parameters: - `max_results` (integer): Max matches to return (default 20, max 50) - `query` (string, required): 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) ### `search_xrpl_docs` (~258 tokens) 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}}. Input parameters: - `limit` (integer): Results (default 5, max 10) - `page` (string): Read one whole page instead: a path or URL a search returned, e.g. "docs/concepts/accounts/tickets" - `query` (string): A few words, a transaction type, a field or a flag name, e.g. "AMMDeposit flags", "TicketSequence", "partial payments delivered_amount" ### `get_api_docs` (~212 tokens) 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}}. Input parameters: - `limit` (integer): Endpoints (default 8, max 20) - `query` (string, required): What to call or know, e.g. "ohlc candles", "websocket prices", "rate limits", "submit transaction", "api key" ### `save_note` (~115 tokens) 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}. Input parameters: - `subject` (string, required): What the note is about — an r-address, token md5/name, or a topic (max 64 chars) - `text` (string, required): The finding (max 1000 chars) ### `recall_notes` (~46 tokens) Recall notes saved earlier under this X-Api-Key, optionally filtered by subject (exact or prefix match). Returns: notes[] newest first. Input parameters: - `subject` (string): Optional subject filter ### `delete_note` (~31 tokens) Delete one saved note by id. Returns: {deleted: true|false}. Input parameters: - `id` (string, required) ### `get_swap_quote` (~178 tokens) 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. Input parameters: - `destination_token` (string, required) - `destination_value` (string): Amount of destination_token to receive - `source_account` (string): Optional r-address the quote is computed for (reserve/spendable checks) - `source_token` (string, required) - `source_value` (string): Amount of source_token to spend ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/xrplto-xrpl-to/v1-mcp#diagnostics ## Score history - 2026-11-04: 70 - 2026-11-03: 69 - 2026-11-02: 69 - 2026-11-01: 68 - 2026-10-31: 68 - 2026-10-30: 67 - 2026-10-29: 67 - 2026-10-28: 66 - 2026-10-27: 66 - 2026-10-26: 66 - 2026-10-25: 65 - 2026-10-24: 65 - 2026-10-23: 64 - 2026-10-22: 64 - 2026-10-21: 63 - 2026-10-20: 63 ## Common questions ### What is the XRPL.to Token Analytics MCP server? XRPL.to Token Analytics is an MCP server listed in the public MCP registry as io.github.xrplto/xrpl-to. XRP Ledger tokens, AMM pools, NFTs, accounts and transactions: prices, holders, trades and history. This page covers its hosted endpoint (https://api.xrpl.to/v1/mcp). ### Is the XRPL.to Token Analytics MCP server safe to use? XRPL.to Token Analytics scores 70 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm. ### What tools does the XRPL.to Token Analytics MCP server expose? XRPL.to Token Analytics exposes 89 tools: search_tokens, get_token, get_trending_tokens, get_new_launches, get_trades, and 84 more. Their descriptions and schemas cost roughly 24,842 tokens of context every time the server is loaded. ### Does the XRPL.to Token Analytics MCP server require authentication? No. We connected to XRPL.to Token Analytics without credentials and it answered, so anything it exposes is reachable by anyone who knows the address. ### Is the XRPL.to Token Analytics MCP server still maintained? XRPL.to Token Analytics is still listed as active in the MCP registry. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced. ## Links - Remote endpoint: https://api.xrpl.to/v1/mcp - Authorisation metadata: https://api.xrpl.to/.well-known/oauth-protected-resource/v1/mcp - Website: https://xrpl.to/mcp - Changelog RSS feed: https://verifymcp.io/servers/xrplto-xrpl-to/v1-mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/xrplto-xrpl-to/v1-mcp.json - HTML version of this page: https://verifymcp.io/servers/xrplto-xrpl-to/v1-mcp