XRPL.to MCP Server
One endpoint gives Claude, Cursor or any MCP client live XRPL token analytics — prices, risk reviews, supply flows, holders, traders, order books, AMM pools, whale activity, accounts and exact DEX swap quotes. Read-only: nothing here signs or submits — the only writes are your own notes, scoped to your API key.
POST https://api.xrpl.to/v1/mcpConnect in 30 seconds
claude mcp add xrplto --transport http https://api.xrpl.to/v1/mcp --header "X-Api-Key: YOUR_KEY"
{
"mcpServers": {
"xrplto": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://api.xrpl.to/v1/mcp",
"--header",
"X-Api-Key: YOUR_KEY"
]
}
}
}{
"mcpServers": {
"xrplto": {
"url": "https://api.xrpl.to/v1/mcp",
"headers": {
"X-Api-Key": "YOUR_KEY"
}
}
}
}Beyond the dedicated tools, api_get reaches every documented public GET endpoint — the catalog with parameters is the xrplto://reference/api-endpoints resource. Tool calls need an API key on a paid plan, sent as X-Api-Key: get one on the dashboard. Listing tools, prompts and resources needs no key. Stateless Streamable HTTP, JSON-RPC 2.0 — initialize, tools/list, tools/call, prompts/*, resources/*.
Tool catalog · 88
search_tokensSearch 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.
query string requiredoldest booleanReturns up to 15 matches with md5, name, issuer, currency, verified flag, price, 24h volume, market cap, holders, tags.
get_tokenDetail 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.
id string requiredfull boolean = falseReturns 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).
get_creator_activityOn-chain activity of a token creator/dev wallet for that token: buys, sells, transfers, liquidity events.
id string requiredReturns events[] of the creator wallet for this token: side (buy/sell/transfer/deposit/withdraw/burn...), amounts, XRP value, time, hash.
get_token_flowSupply flow map: where the issued/dev supply went — held, sold, pooled, sent to exchanges, burned.
id string requiredReturns summary with the split as percentages of supply (retainedPctOfSupply, tracedSoldPctOfSupply, lpDepositedPctOfSupply, placedToExchangePctOfSupply, creatorBurnedPctOfSupply, untracedPctOfSupply, unscannedPctOfSupply), flowSubject + flowSubjectRole (dev|issuer), XRP totals (totalSoldXrp, totalBoughtXrp, netFlowXrp, totalToExchanges), coverage flags (creatorScanComplete, preFloorLaunch); exchangeBreakdown[]; linkedAddresses[].
analyze_token_riskRisk 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.
id string requiredReturns 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.
get_frozen_linesTrust 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.
id string requiredReturns {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}.
get_issuer_actionsWhat 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.
blackholed booleansupply booleanaccount stringholder stringaction stringsince stringlimit integer = 50Returns {coverage {fromLedger, fromTime}, counts {action: n}, topAccounts[] {account, name?, n}, actions[] {time, ledger, tx, type, action, role?, account, accountName?, counterparty, counterpartyName?, currency?, mptIssuanceID?, amount?, requested?, counterpartyBalance?, ammAccount?, clawed?, regularKey?, previousRegularKey?, masterDisabled?, quorum?, signers?}}; with blackholed: {since, coverage, keyChanges, checked, blackholed, issuingTokens, canStillSign, accounts[] {account, name?, blackholedAt, ledger, tx, lastAction, regularKey, tokens[] {md5, name, currency, holders}}}. With supply and account (the issuer): every rise in what the issuer has outstanding over its whole life, each located to its ledger with that ledger's transactions of the issuer: the way to answer "was more of this token ever created after launch", without scanning the issuer's history; Returns then {account, fromLedger, toLedger, samples, currencies[] {currency, now, rises[] {ledger, time, before, after, increase, first?, txs[] {hash, type, account, destination?, delivered?, result}}}, note}.
get_wash_tradingWash-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.
id stringcollection stringdays integer = 90interval 24h|7d|30d|allReturns {washTraders, highWashTraders, washVolumeXrp, tradersScanned, verdict, topWashers[] {account, washScore, suspicious, volumeXrp, trades}}.
find_snipersFind 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.
id string requiredwindow_secs integer = 300Returns snipers[] {account, secsAfterFirst, tokensBought, xrpPaid (XRP legs only), paidOther {<currency>.<issuer>: amount} (buys paid in another token), ledger}, firstTradeTime, windowBuyers.
find_sandwich_attacksSandwich/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.
id stringvictim stringaccount stringdays integer = 60until stringlimit integer = 200Returns 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[]}.
get_token_analyticsTrader-side analytics for a token: unique traders, buyer/seller split, suspected wash volume, concentration.
id string requiredReturns trader-side metrics: unique traders/makers/takers, buyer vs seller counts, suspected wash volume share, concentration of volume.
get_related_projectsProjects sharing an AUDIENCE with a token (co-holders, co-mentions) — shared audience, not shared operator.
id string requiredReturns related[] tokens/NFT collections sharing holders or promoters, with shared-wallet counts and posts; empty when none.
get_trending_tokensTop trending XRPL tokens right now.
limit integer = 10Returns tokens ranked by trendingScore with lightweight market fields.
get_new_launchesMost 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.
limit integer = 10creator booleanby_origin booleandays integer = 30since stringReturns tokens sorted by dateon desc with lightweight market fields; with creator, each token's creator {account, receivedTokens, soldTokens, soldPct, soldXrp, soldWithin24hTokens, soldWithin24hPct, firstSellMinutesAfterLaunch}.
get_global_statsPlatform-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_activityThe whole XRP Ledger's activity over the last N hours, or a calendar window with since/until (every transaction, not only token trades), all exact: xrpl.to counts each ledger's transactions by type and result as it applies the ledger. Other views of the same network: by app (transactions per wallet app by SourceTag), active_age (how old today's active accounts are), dex_traders_days (distinct DEX wallets over up to 30 days), daily (one row per day). Ledgers closed and their average close time, transactions by type with how many failed (a tec result: included in the ledger and charged its fee without doing what it asked), XRP destroyed by fees (the drop in total_coins), accounts created in the window, and accounts that sent a successful transaction (24h window).
hours integer = 24since stringuntil stringby hour|appactive_age booleandex_by_hour integercross_currency booleancensus booleancreated_by stringdaily integerdex_traders_days integerfailed_senders booleanmost_transactions booleantoken_payments stringdrains booleantop_senders fees|transactionslarge_transfers booleanlargest_trades booleanexchange_flows booleanlimit integer = 15Returns {window {hours, from, to, ledgerFrom, ledgerTo}, ledgers, avgCloseSeconds, xrpBurned, activeAccounts24h, newAccounts, deletedAccounts, topCreators[] {account, name, created}, transactions {total, perLedger, failed}, partialPayments {flagged, succeeded, deliveredLessThanAmount, ledgersCounted}, tickets {count, sharePct}, fees {medianDrops, p90Drops, p99Drops, maxDrops, meanDrops}, xrpPayments {count, withDestinationTag, destinationTagSharePct, deliveredXrp}, busiestLedgers[] {ledger, transactions}, types[] {type, count, sharePct, failed, failedPct}, hours[]? {start, ledgers, transactions, failed, partial?}}. Instead: top_senders (who paid the most fees or sent the most transactions), large_transfers (the largest single XRP transfers and the accounts that moved the most between each other), largest_trades (the largest DEX trades). failed_senders: the accounts that sent the most failed transactions, with the results they hit. exchange_flows: XRP into and out of each custodial service's labeled wallets over the window (exchanges, and the swap services and companies that also take tagged deposits), and the net.
get_validatorsThe validators xrpl.to's Mainnet node trusts (its UNL, from the default validator list sites), each with the domain in its signed manifest, its server version and its last vote; and every amendment still being voted on, with rippled's own tally (votes for, the threshold, when majority was reached, whether this node's software knows the amendment). Votes come from the validators' own validations of each voting ledger (every 256th). Pass amendment (a name or id) for which validators support it and which do not. Use it to say whether a validator key is on the default UNL, who runs it (the domain is the operator's own claim unless the domain verifies it), and where an amendment stands. What an amendment changes is not in this tally: read it in the code with search_rippled_source for its switch (feature<Name>, or fix<Name> itself; e.g. featureBatchV1_1), and get_protocol_rules. A name the source does not hold was built outside rippled's public develop branch (3.4.1 knows fixBatchV1_2; develop does not), so say that rather than guess from the name.
amendment stringhistory integerreleases booleancommits_days integeragreement_hours integerlocations booleanReturns {count (every key this node trusts, its own validator included), onDefaultLists (the default UNL: keys on at least one list), thisNodesValidator?, votesInLatestRound, votesWithin24h, validators[] {key, domain, version, lastVote {ledger, time}, onLists[] (the default list sites carrying the key), thisNode?, feeVote?}, feeVotes {heard, baseFee|reserveBase|reserveInc: {currentDrops, votes[] {drops, validators, direction}, keepCurrent}, proposals[], changes} (the next flag ledger's fee vote, run as rippled runs it), amendments[] {id, name, count, threshold, validations, hasMajorityNow, majoritySince, knownToThisNode, supporters?, notSupporting?, noRecentVote?, heldByRippled? {validators, supporting, names?}}, lists[] {uri, expiration, count}, note}; for an amendment already enabled: {amendment {id, name, enabled, enabledAt {ledger, time}}} (when it went live, read from the ledger); with history, events[] {ledger, time, amendment, name, event (gotMajority, lostMajority, enabled), tx}: the way to answer which amendments were enabled most recently, and whether a majority was lost and regained (that restarts its two weeks). rippled keeps a silent validator's last votes for 24 hours, and so does this tally. With agreement_hours: per UNL validator, of the ledgers the network validated in the window, how many it validated too (agreed), signed a different ledger for (disagreed) and missed, scored ledger by ledger from the validations stream: which validators missed the most. Returns then {window, coverage, ledgersScored, validators[] {key, domain, version, agreed, disagreed, missed, agreementPct}}.
get_escrowsEscrows 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.
account stringrole either|owner|destination = eithercurrency string = XRPsort next|amount|ready = nextwithin_days integerexclude_name stringhistory_days integerlimit integer = 20offset integer = 0Returns {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}}.
get_xrp_distributionHow 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.
min_xrp numberby_label booleanmedian booleanlist booleaninactive_years numberlimit integer = 25Returns {asOf {ledger}, supply, escrowed, inAccounts, accounts {live, deleted}, bands[] {minXrp, maxXrp, accounts, xrp, shareOfSupplyPct, shareOfXrpInAccountsPct}, above? {minXrp, accounts, xrp, shareOfSupplyPct, shareOfXrpInAccountsPct}}.
get_oracle_pricesPrices 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).
base string = XRPquote string = USDoracles arrayReturns {base, quote, publishers[] {provider, account, documentId, price, updated, ageSeconds, pairs[]}, aggregate {median, mean, standardDeviation, size, time}}.
get_top_moversBiggest gainers or losers over a timeframe.
timeframe 5m|1h|24h|7d = 24hdirection gainers|losers = gainersmin_holders integerlimit integer = 10Returns tokens[] sorted by the chosen timeframe change (pro5m/1h/24h/7d) with lightweight fields.
get_tokens_by_categoryTokens 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).
category stringtoken_type trustline|lp|mpt|xls14|demurrage|nonstandardsort vol24hxrp|holders|marketcap|tvl|trendingScore|dateon|turnover|trustlines_24h|holders_24h|holders_7d|lp_burned|creator_holding|inactive|trades = vol24hxrpinactive_days integer = 90min_marketcap number = 100000limit integer = 20issuer_setting clawback|transfer_fee|no_freeze|global_freeze|require_auth|blackholed|no_default_ripplegroup_by issuerrank_by tokens|trustlines|holders|marketcap = tokensmin_holders integer = 1000Returns tokens[]; with issuer_setting {setting, minHolders, checked {tokens, issuers}, matched, tokens[] {md5, name, currency, issuer, issuerName, holders, transferFeePct?}}.
get_fear_greed_indexxrpl.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).
days integerReturns {value, label (Extreme Fear | Fear | Neutral | Greed | Extreme Greed), bands, method (the five weighted inputs), updated}.
get_newsXRPL/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.
query stringlimit integer = 15source stringdate stringReturns data[] with title, sourceName, sourceUrl, pubDate, sentiment, summary, newest first; sources[] when listing; with query, the words searched and pagination.total.
get_tradesDEX 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.
id string requiredlimit integer = 20since stringuntil stringaccount stringby_account boolean = falseReturns 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[]}.
get_ohlcOHLC candles for a token, or its price at a past moment. Quoted in XRP by default (the literal XRP in USD). vs_currency USD converts each candle at the XRP/USD rate of its own time; EUR/JPY/CNH then convert it at the ECB reference rate of its own day (the ECB publishes CNY, used for CNH; fx_basis says so). With `at` (a date/time) it returns the one candle containing that moment, at the finest resolution that reaches it (5-minute up to ~17 days back, hourly up to ~208 days, daily beyond), plus the previous close: the way to answer "what was X worth on <date>". Candles are gapless (each open is the previous close); a candle with volume 0 had no trade and carries the last traded price forward. XRP/USD is Binance XRP/USDT and starts 2018-05-04; nothing before a series starts is invented. With extremes true it reads the whole daily series once and returns the all-time high and low in XRP and in USD, each with its date: the way to answer "what was X's all-time high".
id string requiredresolution 1|5|15|60|240|D = Dcount integer = 100vs_currency XRP|USD|EUR|JPY|CNHat stringextremes booleanReturns 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).
get_orderbookLive XRP order book for a token (bids/asks with sizes).
id string requiredlimit integer = 30Returns bids[] and asks[] with price, amount, total, maker; spread.
get_token_pairsTrading pairs a token trades in, with per-pair volume.
id string requiredReturns pairs[] the token trades in with counter asset and 24h volume.
find_arb_pairsCheck 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).
id string requiredReturns {ammSpot, bestBid, bestAsk, arbGapPct, direction} or none.
get_whale_activityRecent large trades on a token with whale badges (smart money, named wallets, cross-token holders).
id string requiredlimit integer = 25Returns events[] of large fills with side, xrpAmount, account, badges (smart money, named, cross-token holder, new wallet), time, hash.
get_amm_poolsAMM pools for a token, or the whole ledger's pools ranked when no token is given (by 24h volume, liquidity, APY, fees or creation). tradingFee is in units of 1/100,000: 197 = 0.197%, 1000 = 1%, the maximum. apy24h/apy7d carry the window's volume, fees, trades and liquidity in XRP. With flows, the pools with the largest net deposits and withdrawals over a window. With by_token, tokens ranked by how many pools they are in. With performance, what providing liquidity to one pool earned over N days: fees against impermanent loss, per LP token.
id stringsort volume24h|volume7d|liquidity|apy|fees|created = volume24hmin_liquidity numberflows booleanhours integer = 168by_token booleantvl_change booleantoken_pairs booleanfee_tiers booleantraders booleancreated_days integerclosed booleanfee_changes booleanperformance booleanamm_account stringdays integer = 30limit integer = 10Returns pools[] with ammAccount, asset1/asset2, currentLiquidity, tradingFee, apy24h/7d {apy, volume, fees, trades, liquidity}, lpBurnedPercent, lpHolderCount, status.
get_lp_positionsAn 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.
account string requiredReturns {account, positions[] {amm, asset, asset2, lpTokens, share, amount, amount2, valueXrp, tradingFee}, totalValueXrp}.
get_swap_quoteExact 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).
source_token string requireddestination_token string requiredsource_value stringdestination_value stringsource_account stringReturns 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.
get_holdersTop 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).
id string requiredlimit integer = 20offset integer = 0Returns richList[] with account, balance, holding % of supply, isAMM/isCreator/freeze flags, funder, plus summary top10/top20/top50/top100 %, gini, hhi.
get_top_tradersTop traders of a token ranked by P&L, volume or wash-trading score, with realized/unrealized PnL, ROI and balances.
id string requiredsortBy pnl|volume|wash = pnlinterval 24h|7d|30d|all = 30dlimit integer = 20Returns traders[] with account, realized/unrealized PnL (XRP), ROI, buy/sell volumes, trade counts, current balance, wash flag.
get_exit_liquidityReal 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".
id string requiredxrp_sizes arrayReturns curve[] {xrpSize, tokensSold, xrpReceived, effectivePricePct, priceImpact}.
get_wallet_pnlTrading 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.
account string requiredReturns 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.
get_holder_graphHolder-count history of a token over a range (growth/decline trend): counts only, not which wallets.
id string requiredrange 1d|7d|30d|90d|1y|5y|all = 30dReturns time series of holder counts over the range.
get_holder_overlapWallets 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.
a stringb stringcollection_a stringcollection_b stringlimit integer = 20Returns {a {name, holders}, b {name, holders}, both, shareOfA, shareOfB, top[] {account, balanceA, balanceB}}.
get_holder_cohortsExact 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.
id string requiredprofit booleanbought_within_days integerabove_tokens numberReturns {priceXrp, holders, bands[] {label, upToXrp, upToTokens, holders}, profit? {inProfit, atLoss, even, heldWithoutPurchase, neverTraded, unrealizedXrp}}.
get_holder_clustersAre 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).
id string requiredtop integer = 100hops integer = 4all_holders boolean = falseReturns {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[]}}.
check_scamCheck 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.
account string requiredReturns is_scam, category, reason, source plus first_seen / age_seconds / new_account advisory.
check_domainIs 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.
domain stringlimit integer = 20account stringReturns {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}}.
get_account_infoXRPL account profile: balance, activation, name/labels, flags.
account string requiredReturns 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".
get_account_ancestryWho activated an account and who it activated (funding lineage), with tokens launched along the chain. Each child carries childrenCount (the wallets IT activated), and descendants totals two levels down, so a family tree needs one call, not one per child.
account string requireddirection up|down|both = bothlimit integer = 200Returns ancestors[] (who funded whom, depth), children[] (accounts it activated, up to limit, each with childrenCount), descendants {children, grandchildren}, tokens launched along the chain.
get_transactionLook up an XRPL transaction by hash.
hash string requiredReturns decoded transaction: type, account, destination, amounts, fee, result code, ledger, date, affected balances.
get_wallet_riskComposite 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.
account string requiredReturns {level, factors, activator, signals}.
get_offrampTrace how a wallet's XRP exits to exchanges INCLUDING one hop downstream (funds → intermediary → exchange), which direct cex-cashout detection misses.
account string requiredlimit integer = 200Returns direct[] and viaIntermediary[] {intermediary, exchange, xrp}.
get_payment_flowsTrace an XRPL wallet's payment flows: who funded it and where it sent XRP and tokens, aggregated by counterparty (XRP as xrp/txCount, tokens by asset as tokens/tokenTxCount) with named exchanges labeled. Reads its latest transactions (up to 200) by default; all_history reads its whole history (up to 10,000), for "everyone it ever paid or was paid by". For everything between specific wallets (tokens too), use get_account_transactions with counterparty. Dust probes (senders of a few drops, "has this wallet been probed") are flagged, with any sender whose address mimics a real counterparty's (address poisoning).
account string requiredlimit integer = 200all_history boolean = falsebackground boolean = falseReturns inflows[]/outflows[] {counterparty, name, xrp, txCount, tokens? {<currency>.<issuer>: amount}, tokenTxCount?, isExchange (custodial: many wallets pay it under their own destination tags, as exchanges are paid), service (a named account that is not custodial: a fee wallet, a platform, a project), dust} (15 each, 40 with all_history; counterparties gives the full counts when more), dust {senders, payments, lookAlikes[]}, netXrp (XRP only), and scanned (tx count / hasMore).
get_cex_cashoutsDetect 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.
account string requiredlimit integer = 200all_history boolean = falsebackground boolean = falseReturns cashouts[] {exchange, counterparty, xrp, txCount}, totalXrp, otherServices[], scanned, complete (all_history).
describe_bot_activityCharacterize 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.
account string requiredlimit integer = 200Returns {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.
get_account_transactionsTransactions of an XRPL account (payments, trades, trust lines, NFT and AMM activity) from the full history, newest first or (order oldest) from its first transaction: how a wallet was funded and where its first tokens came from. Filter by transaction type and by date range. summary true counts the whole range by type and result instead of listing it. counterparty (one or more r-addresses) returns every transfer between this account and those wallets over the whole history, by asset, both directions, with dates and totals — "what did the creator send these wallets" in one call (it reads this account's transactions for 25 s, or 10 minutes with background: true; start from whichever side has the shorter history).
account string requiredlimit integer = 50types stringsince stringuntil stringorder newest|oldest = newestcounterparty stringsummary boolean = falsemin_xrp numbermarker background boolean = falseReturns txs[] with hasMore + marker for paging; with summary: {sentByAccount, sentByOthers, counts {<type>: {total, sent, results}}, scanned, complete, sentInRange (with since: exactly how many transactions the account sent in the range, of every type and result, from its Sequence and TicketCount at both ends, even when the scan stops early)} (sent: signed by this account; the rest were other accounts' transactions that touched it); with counterparty: {flows[] {counterparty, transfers, accountToCounterparty {<asset>: total}, counterpartyToAccount, other {<type>: n}, first, last, rows[] {date, from, to, type, amount, asset, hash}}, scanned, complete}.
get_account_trustlinesToken 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.
account string requiredlimit integer = 100valued booleanReturns lines[] with currency, issuer, balance, limit, flags plus token names; valued: {xrp {total, spendable}, holdings, tokensValueXrp, lines[] {currency, issuer, name, md5, balance, valueXrp, lpPool?}}.
get_account_objectsEverything 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.
account stringtype stringtop_owners booleanlimit integer = 20Returns {account, ledger_index, total, truncated, byType{<LedgerEntryType>: {count, …totals}}, samples{<LedgerEntryType>: first 3, times as ISO dates}}.
get_account_nftsNFTs 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.
account string requiredReturns nfts[] (ledger entries), byCollection {nfts, collections, valueAtFloorXrp, valueAtAvgSaleXrp, unpricedNfts, neverSoldNfts, top[] {collection, slug, nfts, floorXrp, valueAtFloorXrp, sales, avgSaleXrp, valueAtAvgSaleXrp}}.
get_nft_offersNFT 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.
account string requiredReturns {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)}.
get_nft_activityAn 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).
account stringhours integer = 24order oldesttop integerall_time booleansince stringuntil stringby broker|day|collection|accountmax_price_xrp numbermint_flags booleantypes stringlimit integer = 100Returns {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}}.
get_nft_collectionOne NFT collection in one call (or, with rank and no id, collections ranked by floor, volume, owners or items, with sane filters): floor (with its 24h/7d/30d history, all-time high, and the floor day by day over the last 30 days), volume and sales over 24h/7d/30d/all time, items, owners, listings, top offer, and its largest holders with how many each holds (xrpl.to's ownership index, recomputed from the ledger). id is the collection slug or issuer:taxon; a bare issuer address gives everything that issuer minted: the ledger's own mint and burn counters for the account (every taxon) and each of its collections. Also the royalties its issuer has been paid, summed from every recorded sale.
id stringholders integer = 20hold_times booleandays integer = 30rank floor|volume_24h|volume_7d|volume_30d|volume_all|owners|items|bid_over_floormin_owners integer = 20min_sales integer = 1limit integer = 15Returns {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}}.
find_walletsWhich 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.
handle stringdomain stringname stringlimit integer = 20Returns {query, xProfile, siteToml, candidates[] {account, name, balanceXrp, inception, tier, evidence, labelSource, domain, sharedHost, toml {listsAccount, principals[]}}, counts, note}.
get_social_mentionsRecent 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.
id stringhours integer = 24follower_growth booleandays integer = 7limit integer = 20Returns mentions[] posts with author, text, engagement, time; without id {window, tokens[] {md5, name, mentions, authors, views, sentiment {bullish, bearish, neutral, rated}}}.
search_xLive 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.
query string requiredlimit integer = 20Returns {query, count, posts[] {author, name, text, likes, reposts, views, url, time}}.
scan_tweet_addressesXRPL 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.
tweet_url string requiredReturns {tweetId, repliesSeen, addresses[] {address, handle, snippet}}.
pick_giveaway_winnersDraw 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.
tweet_url string requiredwinners integer = 1closes_at stringReturns {tweetId, repliesSeen, entrants, winners[] {rank, handle, address}, seed {ledger, hash, closedAt, rule}, method, entrantList[], note}.
identify_wallet_ownerWho 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).
account string requiredcontext stringReturns {subject, answer, sources[] (links), searches {web, x}, asOf, note}.
identify_token_operatorWho 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).
id string requiredReturns {subject, answer, sources[] (links), searches {web, x}, asOf, note}.
get_testnetxrpl.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_accountSend 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).
address string requiredReturns {network: "testnet", destination, amount, hash, cooldownHours, explorer (testnet.xrpl.org), readBack (xrpl.to's API)} or {error, retryAfterSeconds?}.
get_trade_briefOne 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.
asset XRP|BTC|ETH = XRPReturns {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)}.
get_funding_ratesPerpetual 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.
asset XRP|BTC|ETH = XRPdays integerReturns {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?}]}}.
get_liquidationsRecent 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.
asset XRP|BTC|ETH = XRPlevels booleanReturns {asset, window {from, to, events}, longsLiquidated {count, size, usd}, shortsLiquidated {count, size, usd}, largest[], gate {last24h, last7d {from, to, hours, longsLiquidated {size, usd}, shortsLiquidated {size, usd}}, days[] {date, hours, longsLiquidated, shortsLiquidated}, largestHours[] {hourStart, longsLiquidated, shortsLiquidated}}, streams {collectingSince, venues {venue: {connected, last24h, last7d {longs, shorts {count, size, usd}}}}, days[], largest24h[]}}; a source that did not answer carries unavailable: true. With levels: {asset, estimate: true, price, window, venues[], openInterestShare, assumptions, longs {totalUsd, levels[] {fromPct, toPct, priceLow, priceHigh, usd, cumulativeUsd}, largest[]}, shorts {…}, note}.
get_crypto_marketThe 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".
token stringhistory BTC|ETH|XRP|SOL|BNB|DOGE|ADA|LTC|XLM|HBARkorea_premium booleancoinbase_premium booleanxrpl_cex_ranking booleanetf_flows booleandays integer = 30Returns {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}}.
get_prediction_marketsActive Polymarket prediction markets on the Fed, crypto or the economy, busiest first, each outcome priced as a probability (0-1).
topic fed|crypto|economy = fedReturns {topic, events[] {title, url, endDate, volume24hUsd, markets[] {question, outcomes[] {name, probability}}}}.
get_macro_indicatorsLatest 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).
id DFF|DGS10|CPIAUCSL|UNRATE|ICSA|DTWEXBGS|M2SLmonths integer = 12Returns {series[] {id, name, units, value, date, previous {value, date}, url}}; with id {id, name, units, url, months, from, observations[] {date, value}}.
api_getCall 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.
path string requiredquery objectReturns the endpoint's JSON response, arrays shrunk to fit.
xrpl_commandCall any READ-ONLY rippled JSON-RPC command directly against the XRPL node — the full ledger API for anything the higher-level tools do not cover: account_objects, account_offers, account_channels, ledger_entry, ledger_data, owner_info, noripple_check, deposit_authorized, nft_buy_offers, nft_sell_offers, ripple_path_find (engine-computed payment paths and cost), transaction_entry, get_aggregate_price (price oracles), vault_info (single-asset vaults), simulate (dry-run a tx, submits nothing), server_info, feature, plus the Clio reads mpt_holders (who holds an MPT issuance), nfts_by_issuer and nft_info, and more. Write/sign/admin commands are refused. Params follow xrpl.org for that command. To find the ledger at a date, do not bisect with ledger: api_get /ledger/at with time=<ISO date> returns the last ledger closed at or before it (the one after it is the first to close later).
command string requiredparams objectnetwork mainnet|testnet|devnet = mainnetReturns the raw rippled result.
run_scriptRun a short read-only JavaScript program against the XRP Ledger, for what no other tool answers: a scan of every ledger in a past day (about 22,000 ledgers: split it over three calls and add the parts), a sample of ledgers across history, many accounts' histories, anything that needs a loop over rippled reads. When the question needs one, run it rather than offering to: the all-time transaction count, which no index stores, is a sample of ledgers across history (stratified by period, since a ledger held a few transactions in 2013 and over a hundred now) scaled up and given with its 95% interval. Write the body of an async function and return a JSON value. Inside the program: xrpl(method, params, {network}) returns rippled's result for any read-only command xrpl_command takes (current state comes from the local node; ledgers and transactions older than its ~3 days come from full-history nodes, about 200 ledgers a second; rippled errors such as actNotFound come back in the result); api(path, query) returns any documented public xrpl.to GET endpoint; pmap(items, fn, n) runs fn over items n at a time (use it: one call at a time is slow); log(...) keeps up to 60 lines; rippleTime(s) turns a close_time into an ISO date; ledgersBetween(since, until) returns {first, last, count}, the ledgers that closed in [since, until) (a ledger often closes exactly at midnight, and it belongs to the day it opens). No network, files, timers or modules. Limits per call: 50 s, 20,000 node calls (96 at a time), 300 api calls, 64 MB, 60,000 characters of result. Needs an API key. Ways that work: to go on with a paged read (account_tx) in the next call, return its marker and pass it back in; never restart from a ledger index, since one ledger can hold several of the account's transactions. How many transactions an account sent in a window: get_account_transactions with summary and since/until (sentInRange), or in a program the change in its Sequence less the change in its TicketCount (absent = 0) between ledgers first - 1 and last (account_info with ledger_index). A long account_tx range reads fastest as disjoint ledger sub-ranges paged in parallel, each with its own marker. A day is counted exactly (three calls); a total over weeks or more is best estimated from a uniform random sample of its ledgers (the mean per ledger times the number of ledgers), with its margin of error.
code string requirednetwork mainnet|testnet|devnet = mainnetbackground boolean = falseReturns {result} (what the program returned) or {error} (naming its line), with logs[] and stats {xrplCalls, apiCalls, failedCalls, byMethod, ms}, and unfinishedPaging[] {method, account, pagesRead} when a paged read stopped while the node still had more: its totals are then partial, so say so or read on. Example: const v = await xrpl("ledger", {ledger_index: "validated"}); const top = Number(v.ledger_index); const n = await pmap(Array.from({length: 1000}, (_, i) => top - i), async (li) => (await xrpl("ledger", {ledger_index: li, transactions: true})).ledger.transactions.length, 64); return {ledgers: n.length, transactions: n.reduce((a, b) => a + b, 0)};
get_jobRead 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.
job_id string requiredwait_s integer = 20Returns {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}.
cancel_jobStop a background job started with background: true.
job_id string requiredReturns {job_id, job_status: cancelled}, or the status it had already ended with and note: already ended.
decode_xrplDecode 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.
value string requiredkind tx_blob|nft_id|x_address|currency|mpt_issuance_id|ctid|public_keytag integerReturns {kind, ...the decoded fields}.
get_protocol_rulesXRP 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.
topic stringReturns {commit, rules[] {id, topics, rule, verified, evidence[] {file, line, url, snippet}}}.
explain_result_codeWhat 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.
code string requiredReturns {code, number, class {prefix, meaning[], url}, description, url, returnedAt[] {file, line, function, section?, conditions[], comments[], at, url}, more, testFiles {count, sample[]}, commit}.
search_rippled_sourceSearch 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.
query string requiredregex boolean = falsepath_glob stringcontext integer = 0max_results integer = 25Returns {commit, permalinkBase, count, matches[] {file, line, text, section (the heading a document match sits under)}}.
search_forum_postsSearch 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.
query string requiredregex boolean = falsemax_results integer = 20Returns {count, matches[] {site, url, title, snippet}}.
search_xrpl_docsSearch 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.
query stringpage stringlimit integer = 5Returns {query, count, results[] {title, section, url, description, excerpt}}, or with page {page, title, url, sections[] {heading, text}}.
get_api_docsxrpl.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.
query string requiredlimit integer = 8Returns {query, baseUrl, keyHeader, keyNotes, count, endpoints[] {method, url, section, description, params, body, auth, messages, response}, topics[] {name, content}}.
save_noteSave 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.
subject string requiredtext string requiredReturns the stored note {id, subject, text, at}.
recall_notesRecall notes saved earlier under this X-Api-Key, optionally filtered by subject (exact or prefix match).
subject stringReturns notes[] newest first.
delete_noteDelete one saved note by id.
id string requiredReturns {deleted: true|false}.
Prompts · 8
token-audit(token*)Full due diligence on a token: identity, risk review, supply flow, holders, wash check, creator activity, liquidity.
investigate-wallet(account*)Who is this wallet: profile, funding lineage, scam status, trading P&L, holdings, recent activity.
trace-funds(account*)Trace where a wallet's funds came from and went: activation chain, payment history, exchange touchpoints.
market-briefCurrent XRPL token market snapshot: totals, trending, movers, new launches, news.
swap-check(token*, xrp_amount*)Pre-swap due diligence: verify the token, risk, live quote, price impact and liquidity for a given size.
new-launch-scan(count)Screen the newest launches for red flags in one pass.
whale-watch(token*)What large players are doing on a token right now.
compare-tokens(a*, b*)Side-by-side comparison of two tokens on fundamentals and risk.
Resources · 9
xrplto://token/{id}Full token document by md5, slug, issuer-currency or XRP
xrplto://account/{address}XRPL account profile by r-address
xrplto://reference/token-identityToken identity on xrpl.to
xrplto://reference/xrpl-basicsXRPL fees, reserves and settlement facts
xrplto://reference/risk-reviewHow to read analyze_token_risk
xrplto://reference/supply-flowHow to read get_token_flow
xrplto://reference/linksDeep links into xrpl.to
xrplto://reference/amm-mathAMM pricing and depth
xrplto://reference/api-endpointsPublic API endpoint catalog for api_get (182 endpoints)
Catalog fetched live from the server · 2026-10-11 23:50 UTC. Everything the page lists is what tools/list returns.