{"schema_version":"2.24.0","provider":"XRPL-Utilities™","metric":"Activity Score","scale":"0-100","window_days":90,"interpretation":"Describes how automated/high-frequency the wallet's on-ledger behavior appears within the last 90 days. This is NOT a risk, compliance, or sanctions score.","levels":{"Low":"Low-frequency, human-paced activity","Medium":"Mixed or moderate automation","High":"High-frequency automation typical of services, exchanges, bots, or market makers","Dormant":"Wallet exists on-ledger but has had no activity in the last 90 days","Unknown":"Node returned no history for this address (likely unactivated)"},"confidence":{"low":"<10 in-window txs, or Unknown classification. Do not branch on this alone","medium":"10-49 in-window txs, or Dormant classification","high":"50+ in-window txs"},"signals":{"DUST_ONLY_ON_QUIET_WALLET":"All in-window payments are dust (<$0.01 USD at current XRP spot) on a Low or Dormant wallet. Possible address-poisoning or beacon attempts.","NET_OUTBOUND_SWEEP":"OUT/IN ratio > 1.5 on a High-activity wallet, consistent with a hot wallet distributing funds.","NET_INBOUND_ACCUMULATION":"IN/OUT ratio > 1.5 on a Medium or High wallet, consistent with accumulation or aggregation.","OFFER_HEAVY_BOT":"Offer churn ratio > 0.5: majority of activity is order placement/cancellation, typical of DEX market-making bots.","MULTI_CURRENCY_GATEWAY":"4+ unique currencies touched, typical of gateways, issuers, or multi-asset services.","BURST_ACTIVITY":"20+ transactions packed into less than 1 hour. Dense short-window cluster typical of automated bursts.","TRUSTLINE_ONLY":"More than half of in-window txs are TrustSet, typical of issuer setup, token-registration, or trustline-management wallets.","HIGH_DUST_RATIO":"Dust payments exceed 20% of 10+ in-window payments. Beacon/poisoning amid otherwise active usage.","DUST_ON_FRESH_WALLET":"Low-activity wallet (5 or fewer in-window payments) has at least one dust payment (<$0.01 USD at current XRP spot). Common pattern of address-poisoning bots targeting newly-activated wallets.","LABELED_EXCHANGE_COUNTERPARTY":"Wallet transacts with a counterparty labeled as a known exchange (via XRPScan). Descriptive flag; does not imply any compliance status.","COUNTERPARTY_ADVISORY":"A top counterparty has a public advisory on XRPScan (e.g., community-flagged as hacked/scam/sanctioned). Always worth surfacing to a human reviewer.","COUNTERPARTY_ADVISORY_TRUSTED":"A top counterparty has a XRPScan advisory whose underlying report is marked trusted by the provider. High-confidence subset of COUNTERPARTY_ADVISORY. Note: as of the latest XRPScan data sweep, no advisories carry trusted: true - this signal is kept for forward compatibility and would only fire if XRPScan begins issuing trusted advisories.","TARGET_ADVISORY":"The scanned address itself has a public advisory on XRPScan. Higher-priority signal than COUNTERPARTY_ADVISORY since it concerns the wallet under review directly.","TARGET_ADVISORY_TRUSTED":"The scanned address has a XRPScan advisory whose underlying report is marked trusted by the provider. High-confidence subset of TARGET_ADVISORY. Note: as of the latest XRPScan data sweep, no advisories carry trusted: true - this signal is kept for forward compatibility and would only fire if XRPScan begins issuing trusted advisories.","SINGLE_COUNTERPARTY_HEAVY":"At least 80% of in-window Payments (10+ minimum) are with the same counterparty, typical of broker/dealer relationships, dedicated settlement wallets, or merchant-to-acquirer flows.","DORMANT_REAWAKENING":"Wallet was silent for 30+ days before the oldest in-window transaction. Activity has resumed after a significant gap.","PASSIVE_COUNTERPARTY":"Target is acting as a passive counterparty rather than an active actor - issuer, AMM pool, or gateway. NET_INBOUND_ACCUMULATION (and, for AMMs, MULTI_CURRENCY_GATEWAY) are suppressed when this signal fires because they describe behavior that doesn't apply to passive roles.","SCORE_TRAJECTORY_BOT_ONBOARDING":"Activity score climbed by 30+ points within the last 30 days vs the most-recent prior scan, crossing into the High-automation range. Consistent with a wallet transitioning from human/idle to bot/service operation. Requires a prior scan to fire; null on first observation of an address.","CADENCE_TIGHTENING":"median_seconds_between_tx dropped by 50% or more vs the prior scan, with prior cadence at least 30 seconds. Captures a wallet whose tempo is accelerating toward bot-typical timings even if the activity level label hasn't crossed a threshold yet.","COUNTERPARTY_BURST":"10+ counterparties present in the current top_counterparties list that were absent from the prior scan's. Useful for detecting freshly-onboarded payout fanouts or new market-making relationships.","COUNTERPARTY_INSTITUTIONAL":"At least one top counterparty has an XRPScan label matching the institutional watchlist (exchanges, issuers, treasuries, market makers, custody). Broader than LABELED_EXCHANGE_COUNTERPARTY: catches Ripple-treasury transfers, MM-routed flow, custodial movements, and known issuer interactions in addition to plain exchange custody. Descriptive flag; does not imply any compliance status.","INSTITUTIONAL_SCALE_FLOW":"At least one top counterparty has an aggregate XRP+RLUSD Payment volume of $10M+ USD with the scanned wallet within the scan window. XRP is valued at current spot; RLUSD is added at $1.00 (issuer-pegged stablecoin). Identity-independent: fires regardless of whether the counterparty is on the curated watchlist - captures the size-based institutional signature even when the entity is unlabeled. Sibling to COUNTERPARTY_INSTITUTIONAL (which is identity-based, watchlist-only); both can fire on the same scan when a watchlisted entity moves at scale. Other IOU Payments (SOLO, CSC, USD-Bitstamp, etc.) are still excluded from the aggregate because they lack a $1-peg and would require per-currency oracle lookups. Behavioral context, not a risk verdict.","BRIDGE_INTERACTION":"At least one top counterparty is a labeled cross-chain bridge wallet (Wanchain, Allbridge, Axelar, Coreum Bridge, Wrapped XRP, XPR Bridge). Indicates the wallet operates cross-chain - XRP value is leaving or entering the XRPL ecosystem via the bridge. Behavioral context, not a risk verdict.","PERMISSIONED_ISSUER_GOVERNANCE":"Target wallet has both lsfRequireAuth (every holder must be issuer-authorized before they can hold the IOU) AND lsfAllowTrustLineClawback (issuer can claw back outstanding IOU balances) set on its AccountRoot flags. Together these are the structural pattern of a permissioned RWA / institutional-stablecoin issuance: the issuer retains operator control over who holds the token and can reverse a holding if needed. Behavioral context, not a risk verdict; permissioned governance is a normal posture for tokenized treasuries, regulated stablecoins, and institutional pilots.","FRESH_WALLET":"Target wallet was activated within the last 30 days. Fresh wallets paired with high-value flow or rapidly-developing activity patterns warrant closer attention than the same patterns on aged wallets. Behavioral context, not a risk verdict.","WHALE_GENESIS":"Target wallet was funded at activation with 50,000+ XRP (~$125k+ at typical spot). Initial funding at this scale is institutional setup rather than retail dispense. Combined with the activator label (when present) gives provenance — known venues seeding institutional users vs. unlabeled large-scale provisioning.","INSTITUTIONAL_PROVENANCE":"The genesis chain (target wallet -> activator -> activator's activator -> ...) terminates at a labeled venue (XRPScan well-known) within 3 hops. The wallet's lineage traces back to a known exchange or institution. Stronger provenance signal than just the immediate activator since intermediate operational wallets get walked past.","LAYERED_PROVENANCE":"The genesis chain has 2+ unlabeled hops in a row before resolving (or hits max_depth without resolving), and every hop is fresh (each activator's own activation < 90 days before its outbound dispense). Pattern consistent with layered routing through fresh intermediate wallets rather than direct dispense from a labeled venue. Behavioral context only — legitimate setup pipelines can also produce this shape.","ESCROW_LIFE_HEAVY":"30%+ of in-window transactions are Escrow operations (EscrowCreate, EscrowFinish, or EscrowCancel combined). Wallet's activity is escrow-dominated — consistent with a vesting/grants vehicle, an institutional settlement counterparty, or a programmatic escrow pipeline. Behavioral context, not a risk verdict. Requires at least 3 in-window txs to fire (avoids over-firing on dormant wallets with one escrow).","PERMISSIONED_DEX_PARTICIPANT":"Wallet currently owns at least one XLS-81 permissioned Offer (Offer ledger object with a DomainID field). The wallet is actively participating in a permissioned-DEX venue — placing trades that are gated on the venue's accepted_credentials list. Detected from on-chain owner-side object state today; the owning domain_id is included on the response so callers can drill through to the Trust /domain/{id} record. Behavioral context — permissioned-DEX participation is normal posture for credentialed institutional traders.","DEEP_FROZEN_BY_ISSUER":"At least one of the wallet's trustlines has been deep-frozen by the issuer (lsfHighDeepFreeze or lsfLowDeepFreeze set on the RippleState ledger entry). Deep-freeze is strictly stronger than the regular freeze flag: the holder can neither send NOR receive the IOU. Sanctions-grade compliance state — read directly from the on-chain trustline. Behavioral context, not a risk verdict (issuers freeze for many reasons: court order, KYC failure, suspected fraud, internal compliance review).","INSTITUTIONAL_BY_CONFIGURATION":"Wallet configuration matches institutional governance posture, fired by ANY of: (a) SignerList with 8 or more entries; (b) SignerList where at least one signer entry carries WalletLocator metadata (multi-sig key custody/HSM pattern); (c) lsfDepositAuth flag set AND DepositPreauth object count >= 1 (explicit allowlist of senders). Read from a single on-chain account-objects lookup. High-confidence one-pass classifier for treasury/institutional wallets — these configurations carry meaningful setup cost (signer coordination, on-chain reserve per object) so they don't appear on retail wallets by accident. Behavioral context, not a risk verdict.","ESCROW_COUNTERPARTY_INSTITUTIONAL":"At least one top counterparty's aggregate XRP+RLUSD escrow USD value with the scanned wallet clears the institutional floor (default $10M). Sums EscrowCreate Amount when the scanned wallet is the creator plus the underlying Escrow ledger object's Amount on EscrowFinish where the scanned wallet is owner or finisher. Other-IOU escrows are excluded (no oracle, same discipline as INSTITUTIONAL_SCALE_FLOW for Payments). Identity-independent: fires regardless of whether the counterparty is on the curated watchlist — captures the size-based institutional escrow signature even when the entity is unlabeled. Sibling of INSTITUTIONAL_SCALE_FLOW (Payments) and ESCROW_LIFE_HEAVY (activity-mix-based); all three can fire on the same scan. Behavioral context, not a risk verdict.","OPERATES_PERMISSIONED_DOMAIN":"Scanned wallet appears in XR-Trust's XLS-70/80 permissioned-domain operator directory. The wallet has owned at least one PermissionedDomain object on mainnet and has issued credentials under it. Captured via cross-product enrichment from XR-Trust rather than on-chain probe; the full operator drill-down (domain count, credentials issued/outstanding, identity markers) lands on the top-level `permissioned_domain` block of the same /scan response. Strong institutional-side signal: running an XLS-80 domain requires sustained operational setup (signer coordination, credential issuance pipeline, identity attestation). Behavioral context, not a risk verdict; many regulated stablecoin issuers and institutional liquidity venues operate permissioned domains as their normal posture.","WHALE_RECENT_ACTIVITY":"Scanned wallet has been sender or receiver of at least one XRPL Payment large enough to clear the WHALE_MOVE or INSTITUTIONAL_FLOW tier threshold within the last 30 days. Captured via cross-product enrichment from XR-Pulse's deterministic on-chain whale watcher; the full event list with counterparties, tiers, directions, and USD values lands on the top-level `whale_context` block of the same /scan response. Trajectory signal, not a risk verdict; many institutional treasuries, market makers, and exchange omnibus wallets show whale activity as their normal posture. Compare with INSTITUTIONAL_SCALE_FLOW (which fires from this wallet's own /scan in-window ledger evidence) for cross-confirmation."},"features":{"tx_types":"Map of TransactionType -> count within the window","direction_in_out":"String 'IN/OUT' count of transactions (target account perspective)","unique_currencies":"Sorted list of currency codes touched","dust_payments_under_usd_0p01":"Count of XRP Payment txs whose value is below $0.01 USD at current XRP/USD spot. USD-anchored so address-poisoning detection stays calibrated as XRP price moves.","offer_churn_ratio":"(OfferCreate + OfferCancel) / total in-window txs, rounded to 0.01","approx_time_span_hours":"Elapsed hours between oldest and newest in-window tx","total_txs_fetched":"Raw txs returned by the node before window filtering","top_counterparties":"List (top-20 by total interaction count) of {address, count, payment_count, usd_payment_total, usd_escrow_total, direction IN|OUT|MIXED, label | null}. 'count' includes Payments, OfferCreate fills, and Escrow tx; 'payment_count' is Payment-only interactions. 'usd_payment_total' (added schema 2.8.0; expanded schema 2.10.0 to include RLUSD) sums XRP-denominated Payments (valued at current XRP spot) plus RLUSD-denominated Payments (added at $1.00 per unit - issuer-pegged stablecoin) with this counterparty within the scan window — feeds INSTITUTIONAL_SCALE_FLOW. 'usd_escrow_total' (added schema 2.16.0) is the sibling for escrow flow: EscrowCreate Amount when scanned wallet is creator + Escrow ledger object's Amount (recovered from meta.AffectedNodes) on EscrowFinish where scanned wallet is owner or finisher. Same XRP+RLUSD-only valuation rules. Feeds the ESCROW_COUNTERPARTY_INSTITUTIONAL signal. Other IOUs (SOLO, CSC, USD-Bitstamp, etc.) are excluded from both aggregates because they lack a $1-peg and would require per-currency oracle lookups. Labels sourced from XRPScan when available.","target_label":"XRPScan label for the scanned address itself (name, domain, verified, twitter, advisory) when available; null otherwise.","pre_window_gap_days":"Days of silence between the most-recent pre-window transaction and the oldest in-window transaction. null if there are no pre-window transactions (no prior history fetched) or no in-window ones.","trustset_count":"Number of TrustSet transactions in the window. Useful for identifying token-launch wallets, drainage events, and trustline-management hubs.","amm_ops_count":"Sum of AMMDeposit, AMMWithdraw, AMMBid, AMMVote, AMMCreate, and AMMDelete transactions in the window. Identifies AMM liquidity providers and voters.","nft_ops_count":"Sum of NFTokenMint, NFTokenBurn, NFTokenCreateOffer, NFTokenCancelOffer, and NFTokenAcceptOffer transactions in the window. Identifies NFT collectors, minters, and marketplace activity.","failed_tx_ratio":"Share of in-window transactions whose meta.TransactionResult is not tesSUCCESS, rounded to 0.01. Elevated values can indicate poorly-coded bots, contention, or oracle-style retry behavior.","median_seconds_between_tx":"Median elapsed seconds between consecutive in-window transactions. null when fewer than 2 in-window txs. Tight medians (single-digit seconds) are bot-typical; day-scale medians are human-paced.","currency_net_flows":"Map of asset key -> {in, out, net, _overflow?} (target perspective). Asset key is 'XRP' for native, or 'CURRENCY-ISSUER' for IOUs. Values are summed Payment amounts in the asset's native units. OfferCreate fills are not aggregated here (use offer_churn_ratio for that signal). When in/out/net exceeds 1e15, an `_overflow: true` sibling is added to flag XRPL issuer-side accounting artifacts (issuer's 'obligation' leg is the negation of all outstanding tokens and can land at values like 9.99e+94). Raw value preserved; consumers should treat _overflow buckets as not-meaningful-flow when rendering.","issuer_summary":"Compact issuer-obligations snapshot when the target wallet appears to be an IOU issuer (label tokens contain issuer/stablecoin/gateway, or the target was observed emitting an IOU Payment in window). null otherwise. Shape: {tokens_issued: [...], obligations: {currency: amount_str}, frozen: bool}.","account_flags":"Compact account-state snapshot. Populated for issuer-likely wallets (same gate as issuer_summary) AND for any wallet whose wallet_config block surfaced configuration footprints (so the deposit_auth bit is available to the INSTITUTIONAL_BY_CONFIGURATION signal). null otherwise. Shape: {blackholed: bool, master_disabled: bool, regular_key_set: bool, require_auth: bool, clawback_enabled: bool, deposit_auth: bool, owner_count: int}. `blackholed` is true when lsfDisableMaster is set AND the RegularKey is absent or set to a known burn address (no further mint possible). `require_auth` reflects lsfRequireAuth - every holder must be issuer-authorized before they can hold the IOU. `clawback_enabled` reflects lsfAllowTrustLineClawback - the issuer can claw back outstanding IOU balances. `deposit_auth` reflects lsfDepositAuth - the wallet requires explicit preauthorization of any sender before receiving payments. Combined with the wallet_config.deposit_preauth_count, this drives the INSTITUTIONAL_BY_CONFIGURATION signal. `owner_count` is the OwnerCount field on AccountRoot - rough proxy for trustlines + open offers + escrows.","wallet_config":"Configuration footprint of the scanned wallet, read from one on-chain account-objects lookup (no type filter, first 200 entries). Surfaces four orthogonal patterns used by Sentinel signals: institutional governance posture (SignerList + DepositPreauth), XLS-81 permissioned-DEX participation, and issuer-side deep-freeze state. Shape: {signer_count: int, signers_with_wallet_locator: int, deposit_preauth_count: int, permissioned_offer_count: int, permissioned_offer_domain_ids: list[str] (capped at 5), deep_frozen_trustline_count: int, deep_frozen_currencies: list[str] (capped at 5, ASCII-decoded), truncated: bool (true if the wallet has 200+ owned objects and we paginated past v1's cap)}. Always fetched; null on lookup error."},"issuer_profile":"OPTIONAL top-level string. Present only when the target wallet is an IOU issuer. Short narrative (2-3 sentences) covering tokens issued and outstanding supply, blackhole/master-key state, owner-object count, and the domain on file (XRPScan). Sourced exclusively from on-chain data (live XRPL ledger reads) and the external domain attribution. Does NOT include market cap, exchange listings, project history, or other off-ledger context. Omitted entirely for non-issuer wallets.","identity_block":{"description":"Top-level `identity` key surfacing the scanned wallet's XRPScan label and watchlist role. Always present (labeled=false when XRPScan has no label).","shape":{"labeled":"true when XRPScan has a label.name for the address","display_name":"label.name plus #desc when desc exists, e.g. 'Binance #11'","name":"raw label.name (e.g., 'Binance')","desc":"raw label.desc (e.g., '11')","role":"exchange | issuer | treasury | mm | bridge | custody | null. Resolved against the same 62-entry watchlist used for COUNTERPARTY_INSTITUTIONAL/BRIDGE_INTERACTION signals.","verified":"XRPScan's verified flag. true means the label is operator-attested by XRPScan, not user-suggested","domain":"label.domain (e.g., 'binance.com')","twitter":"label.twitter handle","source":"'xrpscan' when labeled=true, null otherwise","advisory":"XRPScan advisory object when present (also drives TARGET_ADVISORY signal)"}},"did_brief":{"description":"Top-level `did_brief` key on /scan responses. Compact summary of the wallet's on-chain XLS-40 DID + linked .well-known/xrp-ledger.toml manifest. Always present in stable shape: when the wallet has not published a DID, has_did_document is false and the other fields are null/empty. Independent of XRPScan labeling — sourced directly from the validated XRPL ledger and the operator-published TOML.","shape":{"has_did_document":"true when the address owns an XLS-40 DID ledger object on validated mainnet.","org_name":"Organization name from the linked TOML's [METADATA] block. null when no DID, when the DID does not point at a parseable TOML, or when METADATA omits org_name.","org_url":"Organization URL from the same [METADATA] block.","description":"Free-text description from [METADATA].","source_toml_url":"The exact https URL the DID's URI/DIDDocument/Data field pointed at, used to fetch the manifest. Lets a consumer audit identity provenance independently.","principals_count":"Number of [[PRINCIPALS]] entries in the TOML.","principal_names":"First three principal names from the TOML (preserves TOML order). Empty when no principals are listed.","did_uri":"The decoded XRPL `URI` field on the DID ledger object (often a separate IPFS or self-hosted URL distinct from the TOML manifest)."},"caching":"24h positive cache (DID + TOML metadata change rarely), 6h negative cache (so a wallet that just published a DID surfaces within 6h of the next scan).","feeds_into_reasoning":"When org_name is present, the AI narrative names the organization and listed principals. When the wallet has no DID or only a thin DID without TOML metadata, the narrative does not invent identity."},"permissioned_domain":{"description":"Top-level `permissioned_domain` key on /scan responses. Compact summary of the wallet's role as a permissioned-domain operator (XLS-70/80) when applicable, sourced from XR-Trust's operator drill-down. Null when the address is not in Trust's operator directory OR when cross-product enrichment is not configured on this Sentinel deploy.","shape":{"operator_address":"Echo of the scanned address.","domain_count":"Number of live PermissionedDomain ledger objects this wallet currently owns.","credentials_issued":"CredentialCreate count attributed to this issuer.","credentials_outstanding":"Issued minus revoked (still on-chain and acceptable).","credentials_revoked":"CredentialDelete count attributed to this issuer.","unique_subjects_count":"Distinct addresses that hold at least one credential issued by this operator.","credential_types":"List of credential_type strings this operator has ever issued.","first_seen_unix":"Earliest lifecycle event observed for this operator (PermissionedDomainSet OR CredentialCreate).","last_active_unix":"Most recent lifecycle event observed.","owner_label":"XRPScan label resolved from the matching domain record (when present).","has_did":"True when at least one of this operator's domains has a linked XLS-40 DID document.","org_name":"Organization name from the [METADATA] block of the linked TOML, when discoverable via the DID.","trust_url":"Direct link to XR-Trust's operator drill-down for forensic audit."},"caching":"6h positive + negative cache. Most addresses scanned through Sentinel are not domain operators; the negative cache prevents re-hitting Trust on every /scan of a non-operator address.","feeds_into_reasoning":"Future revisions of the AI narrative may reference this block. Currently informational: the field is surfaced for agent consumers and for the marketing-site Sentinel report card."},"delta_block":{"description":"Top-level `_delta` key on /scan responses, present only when XR-Sentinel has a recorded prior paid scan for the same address. Lets agents track wallet trajectory without scanning N times themselves.","shape":{"prior_scan_at":"Unix timestamp of the prior recorded scan.","hours_since_prior_scan":"Integer hours between prior_scan_at and now.","score_delta":"current activity_score minus prior activity_score. Positive means more automated.","level_change":"String 'PRIOR->CURRENT' (e.g., 'Medium->High') when the level changed, null otherwise.","tx_count_delta":"current transaction_count minus prior transaction_count.","median_seconds_between_tx_delta":"current median_seconds_between_tx minus prior. Negative means cadence tightened.","prior_schema_version":"schema_version under which the prior scan was recorded - useful when comparing fields whose meaning changed across versions."}},"scan_history_endpoint":{"path":"/scan/history","method":"POST","body":{"address":"rXXX...","limit":"1-25, default 25"},"price":"$0.10 USD via x402 (same protocol as /scan)","description":"Returns recorded scan history for an address as `{address, row_count, limit, scans: [...]}`. Each row contains scan_id, scanned_at, activity_score, activity_level, transaction_count, signals, features, schema_version. Empty list when no paid scans have been recorded for the address yet (recording began with schema 2.1.0)."}}