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.