XRPL.to Token Analytics

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.

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.

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.

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

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.

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

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

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.

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

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.

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

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.

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

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

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

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.

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

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

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

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

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

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.

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

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, acc…

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[…

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

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 service…

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.

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

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