XRPL-Utilities
XR-Sentinel

XR-Sentinel

XRPL Activity Pattern Classifier

XR-Sentinel reads an XRPL wallet's recent on-ledger behavior and tells you how automated it looks. Quiet human-paced activity, mixed traffic, or the high-frequency pattern of an exchange, market maker, or bot. Behavioral classification, not a risk score.

Try a known address

Click an address above or paste your own. Free from this page. Agents pay $0.10 per scan over the x402 API at sentinel.xrpl-utilities.io.

Bulk scan
Scan up to 50 wallets in one payment
Paste a list, get one quote, pay once, download all reports as JSON.

Understanding wallet classification

What it does

Sentinel reads a wallet's last 90 days of on-chain activity and tells you what kind of actor it looks like. Bots, retail wallets, exchanges, AMM pools, issuers, and market makers each leave a distinct signature.

You get back two separate 0–100 scores: an activity level (Low / Medium / High / Dormant / Unknown) for how automated the wallet is, and an institutional-posture score for how much institutional sophistication its signals reveal. Plus structured signal flags and a short AI narrative tying it together.

The two scores are independent: a busy retail wallet can score high on activity and zero on posture, while a quiet issuer does the reverse. Posture is deterministic and fully traceable, the score is the sum of the institutional-marker signal weights, each shown next to the signal that earned it.

Who reads the output

Agents pricing OTC trades. Market makers vetting counterparties before quoting. Researchers writing about XRPL flows. Treasuries deciding whether a wallet is shaped like a service they'd integrate with. Anyone who's about to send funds to an address they don't fully recognize and wants 90 seconds of due diligence before clicking send. Not compliance officers; see the panel to the right for what this isn't.

What it isn't

Neither score is a risk score, sanctions screen, AML determination, or credit rating. A "High" activity level usually means an exchange, market maker, or bot, not a warning; a high institutional posture means the wallet is configured like an institution, not that it is safe or unsafe. The full signal catalog is at /schema; consumers set their own thresholds.

For developers & AI agents

Pay $0.10 per scan, no API key

XR-Sentinel implements x402 v2 with the exact scheme on XRPL mainnet. Verification and settlement are delegated to the t54 XRPL facilitator.

  1. 1. POST /scan returns 402 Payment Required with two options: XRP (dynamic, ≈ $0.10 spot) or RLUSD (flat 0.10).
  2. 2. Sign an XRPL Payment matching one option, base64-JSON-encode it, send as PAYMENT-SIGNATURE.
  3. 3. Server verifies, runs the classification, then settles. Returns 200 with the report and a PAYMENT-RESPONSE header.

POST /scan/history uses the same x402 flow and price. It returns up to 25 prior recorded scans for an address so agents can read trajectory without scanning the wallet N times themselves. Recording began with schema 2.1.0; older paid scans were not persisted.

Paid MCP tools (2)
  • xrpl_sentinel_scan · $0.10
  • xrpl_sentinel_scan_history · $0.10

Or skip the integration: call either tool above from an MCP client (Claude Desktop etc.) via @xrpl-utilities/mcp or the hosted endpoint at mcp.xrpl-utilities.io/mcp. Same x402 model, just wrapped as MCP arguments.

# pip install x402-xrpl
from x402_xrpl import X402RequestsSession
from xrpl.wallet import Wallet

session = X402RequestsSession(
    wallet=Wallet.from_seed(seed),
    rpc_url="https://YOUR_XRPL_RPC",
    payment_requirements_selector="XRP",
)

report = session.post(
    "https://sentinel.xrpl-utilities.io/scan",
    json={"address": "r..."},
).json()

print(report["activity_level"])
print(report["signals"])
print(report["reasoning"])

Output shape

What you get back

Full field-level details at /schema. Live manifest at /agents.json.

Signal glossary

What do these signal flags mean?

Click to expand. 35 flags in plain English.

XR-Sentinel reports include a signals array. Short flags drawn from a versioned catalog that describe what kind of behavior the on-chain history looks like. None of these are risk, compliance, or sanctions assessments.

Behavioral pattern

OFFER_HEAVY_BOT
Most of what this wallet does is place and cancel DEX orders. Typical of a market-making bot. Fires when: order placement and cancellation make up more than half of in-window activity.
MULTI_CURRENCY_GATEWAY
The wallet handles four or more different tokens. Typical of a gateway, issuer, or multi-asset service. Fires when: 4+ unique currencies touched in the window.
BURST_ACTIVITY
A flurry of transactions packed into less than an hour. Automation territory. Fires when: 20+ in-window transactions span less than one hour.
TRUSTLINE_ONLY
Most of what this wallet does is set up trustlines for tokens, not move money. Typical of issuer setup or token-registration wallets. Fires when: more than half of in-window transactions are TrustSet operations.
NET_OUTBOUND_SWEEP
Money is leaving this wallet much faster than it's coming in. Looks like a hot wallet distributing funds. Fires when: outgoing transactions exceed incoming by 1.5× or more on a High-activity wallet.
NET_INBOUND_ACCUMULATION
Money is piling in faster than it's going out. Accumulation or aggregation pattern. Fires when: incoming transactions exceed outgoing by 1.5× or more on a Medium- or High-activity wallet.
PASSIVE_COUNTERPARTY
The wallet behaves like an issuer or AMM pool. It sits there receiving from others rather than initiating activity. Suppresses some other signals that don't make sense for passive roles. Fires when: label or transaction mix indicates issuer / stablecoin / gateway / AMM-pool role.

Cadence & trajectory

DORMANT_REAWAKENING
The wallet sat silent for at least a month before its recent activity. Just woke up. Fires when: 30+ days of silence between the most-recent prior transaction and the oldest in-window transaction.
SCORE_TRAJECTORY_BOT_ONBOARDING
The automation score jumped sharply over the last 30 days. Looks like a wallet that was hand-operated or idle and is now running like a bot or service. Fires when: score climbed 30+ points within 30 days vs the prior recorded scan and the wallet is now classified High. Requires a prior recorded scan.
CADENCE_TIGHTENING
The time between transactions has dropped sharply since the last scan. The wallet is speeding up toward bot-typical timings. Fires when: median seconds-between-tx halved or more since the prior scan, with the prior cadence at least 30 seconds. Requires a prior recorded scan.

Counterparties

LABELED_EXCHANGE_COUNTERPARTY
The wallet transacts with a known exchange (per public XRPL label sources). Descriptive flag; says nothing about compliance status. Fires when: at least one top counterparty matches an exchange label or domain.
COUNTERPARTY_INSTITUTIONAL
Broader than the exchange-only flag above. The wallet transacts with any labeled institutional entity: exchange, IOU issuer, corporate or foundation treasury, market maker, cross-chain bridge, or institutional custodian. Descriptive context, not a risk verdict. Fires when: at least one top counterparty's public label matches a 60+ entry institutional watchlist (covers all six roles).
INSTITUTIONAL_SCALE_FLOW
Size-based companion to COUNTERPARTY_INSTITUTIONAL. Catches institutional-scale relationships when the counterparty isn't on the curated watchlist but the volume signature is unmistakable. Behavioral context, not a risk verdict. Fires when: aggregate XRP + RLUSD Payment volume with at least one top counterparty clears $10M USD within the scan window. XRP is valued at current spot; RLUSD is added at $1.00 (issuer-pegged stablecoin). Other (non-RLUSD) IOU Payments are excluded.
ESCROW_COUNTERPARTY_INSTITUTIONAL
Escrow-flow sibling of INSTITUTIONAL_SCALE_FLOW. Captures institutional-scale escrow relationships rather than direct Payments; useful for catching the vesting / settlement / DvP pattern where value moves through Escrow ledger entries rather than Payment txs. Behavioral context, not a risk verdict. The two signals can co-occur, and that's meaningful: mixed Payment + escrow flow with one counterparty is a stronger institutional signature than either alone. Fires when: aggregate XRP + RLUSD escrow value with at least one top counterparty clears $10M USD within the scan window. Sums EscrowCreate Amount (when the scanned wallet is creator) plus the underlying Escrow ledger object's Amount on EscrowFinish (recovered from meta.AffectedNodes). Other-IOU escrows excluded; no oracle.
BRIDGE_INTERACTION
The wallet has sent to or received from a labeled cross-chain bridge wallet (Wanchain, Allbridge, Axelar, Coreum Bridge, Wrapped XRP, XPR Bridge). Indicates the wallet routes XRP value cross-chain. Behavioral context, not a risk verdict. Fires when: at least one top counterparty is on the bridge sub-list of the institutional watchlist.
SINGLE_COUNTERPARTY_HEAVY
Almost all payments go to or come from a single address. Typical of broker/dealer relationships, dedicated settlement wallets, or merchant-to-acquirer flows. Fires when: 80%+ of in-window payments (10+ minimum) flow through one counterparty.
COUNTERPARTY_BURST
Ten or more counterparties showed up in this scan that weren't there last time. Could be a payout fanout, new market-making relationships, or a distribution event. Fires when: 10+ new addresses in the top counterparties list vs the prior recorded scan. Requires a prior recorded scan.
COUNTERPARTY_ADVISORY
A counterparty has been publicly flagged in advisory data (community-reported as hacked, scam, or sanctioned). Worth a closer look. Fires when: at least one top counterparty carries a public advisory flag.
COUNTERPARTY_ADVISORY_TRUSTED
A counterparty's advisory is provider-verified, not just community-reported. Fires when: an advisory's trusted flag is true. Not currently observable in upstream advisory data; reserved for forward compatibility.

Issuer governance & configuration

PERMISSIONED_ISSUER_GOVERNANCE
The wallet is configured as a permissioned IOU issuer: every holder must be operator-authorized before they can hold the token, and the issuer can claw back outstanding balances. Structural pattern of a tokenized treasury, regulated stablecoin, or institutional pilot. Behavioral context, not a risk verdict. Fires when: the scanned address has both lsfRequireAuth and lsfAllowTrustLineClawback set on its AccountRoot flags. Surfaced in the response's features.account_flags.
VERIFIED_INSTITUTIONAL_ENTITY
The wallet is a positively identified institution, by either of two independent sources: a verified XRPScan label (reserved for identified businesses and services such as exchanges, issuers, custodians, gateways, and infrastructure), or membership in our curated registry of known real-world-asset and institutional issuer wallets. The registry covers genuine issuers that public label sources do not mark verified, so a real institution is not missed just because it lacks a verified tag. This is the keystone institutional-posture marker: it fires on the wallet's identified-entity status itself, not on any specific on-ledger primitive. Identification confirms identity, not conduct.
FIXED_SUPPLY_ISSUER
An issuer whose master key is disabled with no usable regular key (blackholed), so no further units of its token can ever be minted. An irreversible, on-chain commitment that the supply cannot be inflated, which serious token issuers make to assure holders. Read from the account-flags snapshot resolved for issuer-likely wallets.
INSTITUTIONAL_BY_CONFIGURATION
The wallet's on-chain configuration matches institutional governance posture: large multi-sig signer set, hardware-keyed signers, or an explicit deposit allowlist. These setups carry real cost (signer coordination, reserve per object) so they don't appear on retail wallets by accident. Fires when any of: 8 or more entries in the wallet's SignerList; at least one signer entry carries WalletLocator metadata (multi-sig key custody / HSM pattern); or lsfDepositAuth is set AND at least one DepositPreauth object exists. Surfaced in features.wallet_config.
DEEP_FROZEN_BY_ISSUER
At least one of the wallet's trustlines has been deep-frozen by its issuer. Deep-freeze is strictly stronger than the regular freeze flag; the holder can neither send nor receive the IOU. Issuers deep-freeze for many reasons (court order, KYC failure, suspected fraud, internal compliance review); descriptive flag, not a risk verdict. Fires when at least one RippleState (trustline) entry owned by the scanned wallet carries lsfHighDeepFreeze or lsfLowDeepFreeze. Detected from the same on-chain object scan as the configuration classifier above.
PERMISSIONED_DEX_PARTICIPANT
The wallet currently has at least one active offer placed inside an XLS-81 permissioned trading venue; i.e. an Offer ledger object that carries a DomainID. The wallet is participating in credentialed institutional liquidity rather than the open DEX. Behavioral context: permissioned-DEX participation is a normal posture for credentialed institutional traders. Fires when wallet_config.permissioned_offer_count is at least 1. The owning domain_id(s) are returned alongside so consumers can drill through to the XR-Trust directory.
OPERATES_PERMISSIONED_DOMAIN
The scanned wallet operates one or more XLS-70/80 permissioned domains and has issued credentials under them. Detected via cross-product enrichment against XR-Trust's operator directory rather than a direct on-chain probe. Running a permissioned domain requires sustained operational setup (signer coordination, credential issuance pipeline, identity attestation), so this is a strong institutional-posture flag. Fires when the scanned address appears in XR-Trust's operator drill-down. The full block (domain count, credentials issued/outstanding, identity markers, deep link to the operator's Trust page) lands on the top-level permissioned_domain field of the same /scan response.
WHALE_RECENT_ACTIVITY
The scanned wallet has been sender or receiver of at least one whale-tier XRPL Payment in the last 30 days. Detected via cross-product enrichment against XR-Pulse's deterministic on-chain whale watcher. Trajectory signal complementing INSTITUTIONAL_SCALE_FLOW: the latter fires from this wallet's own scan window, this one captures whale activity Pulse already saw network-wide. Fires when the wallet has at least one event in Pulse's whale stream above the WHALE_MOVE floor ($1M USD) within the last 30 days. The full block (event count, tier counts, direction counts, total USD volume, last-event timestamp, per-event counterparty list) lands on the top-level whale_context field of the same /scan response.
ESCROW_LIFE_HEAVY
The wallet's recent activity is escrow-dominated rather than transactional; consistent with a vesting or grants vehicle, an institutional settlement counterparty, or a programmatic escrow pipeline. Says nothing about who the wallet's escrow counterparties are; just describes the activity mix. Fires when the in-window count of EscrowCreate + EscrowFinish + EscrowCancel transactions is at least 30% of total in-window activity, with a floor of 3 total transactions (avoids over-firing on dormant wallets with one escrow).

Provenance & lineage

FRESH_WALLET
The wallet was created in the last 30 days. Fresh wallets paired with high-value flow or rapidly-developing patterns deserve closer attention than the same patterns on aged wallets. Fires when: the genesis block's hop-0 age_days is less than 30.
WHALE_GENESIS
The wallet was funded at activation with 50,000+ XRP; institutional-scale setup, not retail dispense. Combined with the activator label (when present) gives clean provenance: known venues seeding institutional users vs. unlabeled large-scale provisioning. Fires when: the genesis block's hop-0 initial funding is at least 50,000 XRP.
INSTITUTIONAL_PROVENANCE
The wallet's lineage traces back to a known exchange or institution within 3 hops. Stronger than just the immediate activator; intermediate operational wallets get walked past so the chain resolves to the original venue. Fires when: the genesis chain terminates at a publicly labeled well-known wallet within 3 hops.
LAYERED_PROVENANCE
The wallet's activator chain runs through 2 or more unlabeled wallets in a row, and every wallet in the chain was itself fresh when it dispensed downstream. Pattern of layered routing through fresh intermediates rather than direct dispense from a known venue. Behavioral context only; legitimate setup pipelines can also produce this shape. Fires when: 2+ consecutive unlabeled hops in the chain, every hop's age_days is below 90, and the chain does not terminate at a labeled venue.

Address-specific flags

TARGET_ADVISORY
The address you scanned has been publicly flagged in advisory data. Look up the address in any public XRPL advisory source before transacting. Fires when: the scanned address itself carries a public advisory flag. Higher-priority than COUNTERPARTY_ADVISORY since it concerns the wallet under review directly.
TARGET_ADVISORY_TRUSTED
The advisory on the scanned address is provider-verified, the strongest tier. Fires when: the target's advisory has trusted set to true. Not currently observable; reserved for forward compatibility.
DUST_ONLY_ON_QUIET_WALLET
Every payment in the window is sub-cent dust on a wallet that's otherwise quiet. Likely an address-poisoning beacon. Fires when: all in-window payments are below $0.01 USD on a Low- or Dormant-level wallet.
DUST_ON_FRESH_WALLET
A nearly-new wallet has at least one sub-cent payment. A common address-poisoning move targeting freshly-activated wallets. Fires when: 5 or fewer in-window payments and at least one is below $0.01 USD.
HIGH_DUST_RATIO
More than one in five payments are sub-cent dust amid otherwise active usage. Beacon or poisoning signals mixed into legitimate activity. Fires when: dust payments exceed 20% of 10+ in-window payments.
ISSUES_MPT
The wallet issues a Multi-Purpose Token (XLS-33), the newer fixed-metadata token type used for stablecoins, tokenized real-world assets, and institutional instruments. A different issuance model from classic trustline IOUs. Fires when: the wallet owns at least one MPTokenIssuance object.
HOLDS_MPT
The wallet holds a Multi-Purpose Token, placing it as a holder or distribution endpoint rather than the issuer. Fires when: the wallet owns at least one MPToken object.
OPERATES_PRICE_ORACLE
The wallet publishes on-chain price-feed data (XLS-47). An infrastructure and data-provider role rather than a trading or holding wallet. Fires when: the wallet owns at least one Oracle object.
BRIDGE_OPERATOR
The wallet operates a side of a cross-chain bridge (XLS-38), not just transacts with one. This is the bridge itself, distinct from BRIDGE_INTERACTION which flags a bridge counterparty. Fires when: the wallet owns at least one Bridge object.
HAS_DID
The wallet has anchored a decentralized identifier on-chain (XLS-40), often a named or regulated entity that has published verifiable identity. Fires when: the wallet owns a DID object.
CREDENTIAL_HOLDER
The wallet holds an issued credential (XLS-70), meaning it has been verified or whitelisted to participate in permissioned domains and venues. This is the credentialed-holder side of the permissioning stack. Fires when: the wallet owns at least one Credential object.
HOLDS_CHECKS
The wallet is party to a deferred or pull-payment settlement using the XRPL Check primitive, a pattern closer to invoicing than spot transfers. Fires when: the wallet owns at least one Check object.
PAYMENT_CHANNEL_OPERATOR
The wallet runs an XRPL Payment Channel, the rail behind streaming and agent-native micropayments. Fires when: the wallet owns at least one PayChannel object.
TOKEN_ESCROW_USER
The wallet locks a token (IOU or MPT) in escrow rather than XRP (XLS-85), a pattern used for over-the-counter settlement, vesting, and asset delivery. Fires when: the wallet owns an Escrow object whose locked amount is a token rather than XRP.
GLOBAL_FREEZE_ACTIVE
The issuer has frozen every trustline to its token at once. An incident, wind-down, or migration posture, broader than a single deep-frozen line. Fires when: the account has the global-freeze flag set.
NO_FREEZE_COMMITTED
The issuer has permanently given up its ability to freeze holdings, a credible commitment common on tokens that market decentralization. Fires when: the account has the no-freeze flag set.
PUNITIVE_TRANSFER_RATE
The issuer charges holders more than 0.5% to transfer its token between each other, a fee-extracting or deliberately illiquid posture. Fires when: the account's transfer rate is above 0.5%.
DIRECT_CLAWBACK_ACTOR
The wallet has actually reversed a holder's balance with a clawback, an enforcement action rather than just the capability. Fires when: the scan window contains at least one Clawback or AMMClawback transaction.
HIGH_FAILURE_RATE
More than a third of the wallet's recent transactions failed. Consistent with a testing wallet, a misconfigured automation, or aggressive order placement that keeps hitting rejection thresholds. Fires when: failed transactions exceed 30% of the in-window total, with a floor of 10 transactions.
AMM_LIQUIDITY_PROVIDER
The wallet actively provisions automated-market-maker liquidity (deposits, withdrawals, votes, bids). Different from being an AMM pool account itself, which the scan treats as a passive counterparty. Fires when: AMM operations are at least 30% of in-window activity, with a floor of 3 such operations, and the wallet is not itself an AMM pool.
NFT_MARKETPLACE_ACTIVE
Regular NFT minting or trading activity, consistent with a creator, a marketplace, or NFT automation. Fires when: NFT operations number at least 10 and make up at least 20% of in-window activity.
MULTI_ASSET_ISSUER
The wallet issues three or more distinct currencies, consistent with a real-world-asset tokenizer, a multi-stablecoin operator, or an institutional treasury running parallel asset classes. Fires when: the wallet is the issuer of record on at least 3 distinct currency codes with outstanding obligations.
WHALE_ACCUMULATOR
Most of the wallet's recent whale-scale activity is inbound, so it is building a position at whale scale rather than offloading. Sharpens WHALE_RECENT_ACTIVITY with a direction read. Fires when: at least 80% of the wallet's whale-tier events in the last 30 days are inbound, with a floor of 5 events.
WHALE_DISTRIBUTOR
Most of the wallet's recent whale-scale activity is outbound, so it is paying out or offloading at whale scale rather than building. The outbound counterpart to WHALE_ACCUMULATOR. Fires when: at least 80% of the wallet's whale-tier events in the last 30 days are outbound, with a floor of 5 events.
WHALE_INSTITUTIONAL_TIER
The wallet has been moving money at the higher institutional tier, not just clearing the whale floor. Distinguishes institutional ticket sizes from plain whale moves. Fires when: the wallet has at least 2 institutional-flow-tier events in the last 30 days.
IDENTITY_ATTESTED_INSTITUTION
The wallet has published an on-chain identity (a decentralized identifier) naming an organization and two or more principals, resolved through its linked domain manifest. A self-attested institutional identity. Note: the attestation is operator-published, not independently verified. Fires when: the wallet has a published DID document with an organization name and at least 2 named principals.

Sister products

Also part of the XRPL-Utilities Portfolio

Safe harbor & compliance

XR-Sentinel produces behavioral pattern classification, not risk assessment. It is not a compliance, AML, sanctions, or forensic service. A "High" activity level is not a risk signal. It typically indicates an exchange, market maker, AMM, validator, or trading bot.

Users are responsible for complying with local digital asset and AI regulations, including the California Digital Financial Assets Law and the Colorado AI Act where applicable.