XRPL.to Token Analytics MCP Server

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.

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".

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}}.

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

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 {<id>: {ticker, name, scale, issuer, slug}}); with summary: {sentByAccount, sentByOthers, counts {<type>: {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 {<asset>: total}, counterpartyToAccount, other {<type>: n}, first, last, rows[] {date, from, to, type, amount, asset, hash}}, scanned, complete}.

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?}}.

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[]}}.

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}}.

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.

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}}.

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).

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.

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[].

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

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}}.

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}}.

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)}.

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.

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}}.

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}.

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}.

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?}}.

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.

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

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.

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.

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}.

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}}.

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

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.

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.

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.

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.

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).

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.

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}}.

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}.

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.

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}}.

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}}.

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}.

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}.

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}.

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}}.

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}.

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?}.

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?}]}}.

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.

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-<issuance id>) lists the wallets holding its units (MPToken objects, balance scaled by AssetScale).

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

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}.

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

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}}.

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 services and companies that also take tagged deposits), and the net.

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}.

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.

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

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}.

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

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}}.

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

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? {<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).

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}.

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}.

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}}}}.

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}}}.

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

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.

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)}}.

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[]}.

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}.

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.

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}}.

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

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}}.

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

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}}}.

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.

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[]}.

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)}.

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}.

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[]}.

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

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

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

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}.

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}}.

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.

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}}.