{"schema_version":"2.33.2","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 (activity_score 0-33)","Medium":"Mixed or moderate automation (activity_score 34-66)","High":"High-frequency automation typical of services, exchanges, bots, or market makers (activity_score 67-100)","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)"},"level_derivation":"For classified wallets the band is derived deterministically from activity_score (Low 0-33, Medium 34-66, High 67-100), so the label can never contradict the number and is reproducible given it. The AI returns only the score; Dormant and Unknown are separate non-classified states.","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).","VERIFIED_INSTITUTIONAL_ENTITY":"The target wallet is a positively identified institution, by either of two independent sources: a verified XRPScan label (XRPScan reserves the verified flag for identified businesses and services such as exchanges, issuers, custodians, gateways, and infrastructure operators), or membership in the operator-curated registry of known RWA / institutional issuer wallets (which covers genuine issuers XRPScan does not mark verified). Keystone institutional marker: it fires on the wallet's identified-entity status itself, independent of which on-ledger primitives the wallet happens to use. Behavioral context, not a risk verdict; identification confirms identity, not conduct.","FIXED_SUPPLY_ISSUER":"The wallet is 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 supply commitment that serious token issuers make to assure holders the supply cannot be inflated. Read from the account-flags snapshot resolved for issuer-likely wallets. Behavioral context, not a risk verdict.","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.","ISSUES_MPT":"Wallet owns at least one MPTokenIssuance ledger object — it is the issuer of a Multi-Purpose Token (XLS-33). MPTs are the newer fixed-metadata token primitive favored for stablecoins, tokenized RWAs, and institutional instruments, distinct from classic IOU/trustline issuance. Read from the wallet's account_objects. Behavioral context, not a risk verdict.","HOLDS_MPT":"Wallet holds at least one MPToken ledger object — it is a holder/distribution endpoint for a Multi-Purpose Token (XLS-33), as opposed to its issuer. Read from account_objects. Behavioral context, not a risk verdict.","OPERATES_PRICE_ORACLE":"Wallet owns at least one Oracle ledger object (XLS-47) — it publishes on-chain price-feed data. An infrastructure/data-provider role (market maker, DeFi venue, oracle operator) rather than a trading or holding wallet. Read from account_objects; the object's LastUpdateTime indicates whether the feed is live or stale. Behavioral context, not a risk verdict.","BRIDGE_OPERATOR":"Wallet owns at least one Bridge ledger object (XLS-38 cross-chain bridge) — it operates a door/witness side of a cross-chain bridge, not merely transacts with one. Strictly distinct from BRIDGE_INTERACTION, which fires when a labeled bridge is a counterparty; this fires on the bridge operator itself. Read from account_objects. Behavioral context, not a risk verdict.","HAS_DID":"Wallet owns a DID ledger object (XLS-40) — it has anchored a W3C Decentralized Identifier on-chain. Signals a named/regulated/dApp entity that has published verifiable identity, often paired with a .well-known/xrp-ledger.toml. Read from account_objects; the resolved identity (when present) lands on the response `did_brief` block. Behavioral context, not a risk verdict.","CREDENTIAL_HOLDER":"Wallet holds at least one Credential ledger object (XLS-70) — it is the subject of an issued credential, i.e. KYC'd / whitelisted to participate in permissioned domains and permissioned-DEX venues. Complements PERMISSIONED_DEX_PARTICIPANT (the trading side) and OPERATES_PERMISSIONED_DOMAIN (the issuer side) by capturing the credentialed-holder side. Read from account_objects. Behavioral context, not a risk verdict.","HOLDS_CHECKS":"Wallet owns at least one Check ledger object — it is party to a deferred / pull-payment settlement (the XRPL Check primitive), a pattern more typical of invoice or B2B settlement flows than of spot transfers. Read from account_objects. Behavioral context, not a risk verdict.","PAYMENT_CHANNEL_OPERATOR":"Wallet owns at least one PayChannel ledger object — it runs an XRPL Payment Channel, the primitive behind high-frequency streaming and agent-native micropayments (the same rail x402-style metering uses). Signals a streaming/automated-payments posture. Read from account_objects. Behavioral context, not a risk verdict.","TOKEN_ESCROW_USER":"Wallet owns at least one Escrow ledger object whose locked Amount is a token (IOU or MPT) rather than XRP — i.e. it uses XLS-85 token escrow for OTC settlement, vesting, or RWA delivery-versus-payment. Distinct from ESCROW_LIFE_HEAVY, which is XRP-blind and activity-mix-based. Read from account_objects. Behavioral context, not a risk verdict.","GLOBAL_FREEZE_ACTIVE":"Issuer wallet has lsfGlobalFreeze set on its AccountRoot — every trustline to this issuer is frozen at once. An emergency / wind-down / incident posture, strictly broader than the per-line DEEP_FROZEN_BY_ISSUER. Read from account_info flags. Behavioral context, not a risk verdict (issuers global-freeze for incident response, regulatory order, or migration).","NO_FREEZE_COMMITTED":"Issuer wallet has lsfNoFreeze set on its AccountRoot — it has permanently and irreversibly surrendered its ability to freeze trustlines or set global freeze. A credibly-trust-minimizing 'cannot rug-freeze' commitment, common on assets that market decentralization. Read from account_info flags. Behavioral context, not a risk verdict.","PUNITIVE_TRANSFER_RATE":"Issuer wallet sets a TransferRate above 0.5% (i.e. holders pay a >0.5% fee when transferring the IOU between each other). Signals a fee-extracting or deliberately friction-laden token economic posture, distinct from the typical zero-fee issuer. Read from account_info TransferRate. Behavioral context, not a risk verdict.","DIRECT_CLAWBACK_ACTOR":"Wallet has executed at least one Clawback or AMMClawback transaction in the scan window — it has actively reversed a holder's balance, an enforcement ACT rather than the mere capability flagged by PERMISSIONED_ISSUER_GOVERNANCE. Read from the in-window transaction-type mix. Behavioral context, not a risk verdict (clawback is exercised for court orders, KYC failures, fraud response, and contractual redemption).","HIGH_FAILURE_RATE":"More than 30% of the wallet's in-window transactions failed (TransactionResult != tesSUCCESS), on a wallet with at least 10 in-window transactions. Consistent with a testing/debugging wallet, a misconfigured automation, or aggressive order placement that repeatedly hits rejection thresholds (DEX slippage, insufficient reserve, path failures). Read from the in-window failed-transaction ratio. Behavioral context, not a risk verdict.","AMM_LIQUIDITY_PROVIDER":"AMM operations (AMMDeposit / AMMWithdraw / AMMVote / AMMBid) make up at least 30% of the wallet's in-window activity, with a floor of 3 such operations — an active automated-market-maker liquidity provider. Distinct from being an AMM pool pseudo-account (which suppresses behavioral signals via the passive-counterparty heuristic); this is a wallet that provisions liquidity into pools. Read from the in-window transaction-type mix. Behavioral context, not a risk verdict.","NFT_MARKETPLACE_ACTIVE":"NFT operations (NFTokenMint / NFTokenBurn / NFTokenCreateOffer / NFTokenCancelOffer / NFTokenAcceptOffer) number at least 10 and make up at least 20% of the wallet's in-window activity — a regular NFT minter, trader, or marketplace-automation wallet. Read from the in-window transaction-type mix. Behavioral context, not a risk verdict.","MULTI_ASSET_ISSUER":"Wallet issues at least 3 distinct currencies (it is the issuer-of-record on 3+ IOU codes with outstanding obligations). Consistent with an RWA tokenizer, a multi-stablecoin operator, or an institutional treasury running parallel asset classes, as opposed to a single-asset issuer. Read from the issuer obligation summary already resolved for issuer-likely wallets. Behavioral context, not a risk verdict.","WHALE_ACCUMULATOR":"Of the wallet's whale-tier events in the last 30 days (5+ total), at least 80% are inbound — it is net-accumulating at whale scale. Sourced from the cross-product whale_context block (XR-Pulse). Sharpens WHALE_RECENT_ACTIVITY with a direction read: building a position rather than offloading. Behavioral context, not a risk verdict; exchange omnibus and custody wallets accumulate as normal posture.","WHALE_DISTRIBUTOR":"Of the wallet's whale-tier events in the last 30 days (5+ total), at least 80% are outbound — it is net-distributing at whale scale. Sourced from the whale_context block (XR-Pulse). The outbound counterpart to WHALE_ACCUMULATOR: paying out / offloading rather than building. Behavioral context, not a risk verdict; treasuries and market-maker hubs distribute as normal posture.","WHALE_INSTITUTIONAL_TIER":"The wallet has at least 2 INSTITUTIONAL_FLOW-tier events in the last 30 days — sustained activity at the higher of the two whale tiers (institutional-scale, above plain whale-move). Sourced from the whale_context tier rollup (XR-Pulse). Distinguishes wallets operating at institutional ticket sizes from those merely clearing the whale floor. Behavioral context, not a risk verdict.","IDENTITY_ATTESTED_INSTITUTION":"The wallet has published an on-chain XLS-40 DID with an organization name and at least 2 named principals, resolved via its linked .well-known/xrp-ledger.toml — a multi-principal, self-attested institutional identity. Sourced from the did_brief block; identity-based, orthogonal to the configuration-based INSTITUTIONAL_BY_CONFIGURATION. Behavioral context, not a risk verdict; the attestation is operator-published and not independently verified."},"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.","registry_institutional_issuer":"Identity {name, token, note?} when the scanned address is a known RWA / institutional issuer wallet in the operator-curated registry, else null. Second identity source for the VERIFIED_INSTITUTIONAL_ENTITY keystone, covering genuine issuers XRPScan does not mark verified.","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."},"institutional_posture":{"description":"Top-level `institutional_posture` key on /scan responses. A SECOND scoring axis, orthogonal to activity_score: activity_score measures how automated / service-like the wallet's activity is (0-100), while institutional_posture measures how much institutional sophistication its signal set reveals. Deterministic and fully traceable — the score is the capped sum of institutional-marker signal weights, and `contributors` lists exactly which signals drove it. Behavioral posture, NOT a risk, compliance, or sanctions determination.","shape":{"score":"0-100. Capped sum of the weights of the institutional-marker signals that fired. 0 when no marker fired (retail / unclassified).","tier":"Band label for the score: none (0), minimal (1-19), moderate (20-39), institutional (40-59), core-institutional (60-100).","contributors":"List of {signal, weight} for every institutional-marker signal that fired, descending by weight. Makes every point auditable back to a signal.","methodology":"Stable human-readable note on how the score is computed."},"note":"Only institutional-marker signals carry weight. Retail / automation / abuse signals (dust, offer-churn, net-flow, fresh-wallet, advisories) contribute 0 — they belong to the activity_score axis, not this one."},"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)."}}