Honeypot XRPL

What this dashboard is for

Bait-independent real-time analysis of the public ledger

Honeypot XRPL is an open real-time threat dashboard for the XRPL community. Every validated block of the XRP Ledger mainnet is checked in real time for fraud, phishing and draining patterns; detected actors are connected into clusters by their money flow and assigned roles (source, drainer, collector, relay).

The analysis is bait-independent: no own honeypot or decoy accounts are operated for detection anymore. The data comes exclusively from the public ledger — in live mode through a direct WSS connection to honeycluster.io (one ledger command per block, no sampling), in archive mode through the persisted server window (24 hours to 7 days). Account names and exchange attributions come from xrpscan.com (CC BY-NC-SA 4.0).

The same analysis module (lib/detector.mjs) runs in the browser and on the server — the live analysis in the browser produces the same findings as the server walk that fills the window in the background.

Every address shown is an actor address publicly visible in the ledger and is displayed in full. The protective layers around the historical bait accounts (hash deny-list, server-side sanitization) remain active regardless.

What is detected

Roles and patterns of the detector engine — heuristics, not proof of guilt

Roles in the cluster graph

Drainer: An account funded by at least two different senders that forwards at least 90 % of its inflow to a single target in one payment — the typical pattern of a victim account being swept.
Collector: A collection account with at least three inflows from different senders (at least one of them flagged), at most two outflows and clear accumulation — where the money gets bundled.
Source: An account with at least three small outgoing payments (at most 0.1 XRP each) to flagged targets — a typical sender of dust and lure payments.
Relay: A pass-through account with balanced inflow and outflow (difference at most 50 % of the larger value) — a waypoint for the money, not an offender by itself.

Patterns and connections

Draining (drainer sweep): A freshly funded account is swept immediately: at least 90 % of the balance leaves to a single target in one payment. Only with ledger proof of account creation — or with an entity-snapshot proof of fresh account activity across ticks — is the finding classified as malicious; without it, it stays suspect.
Fresh-activity proof (verifiedFresh): The malicious classification of a drainer sweep rests on a second proof of freshness: a ledger proof of account creation, or an entity-snapshot proof of fresh account activity within the last 21,600 ledgers (about 24 hours). verifiedFresh is a second evidence path — never a finding source by itself and never a downgrade; the threshold is published as verifiedFreshGapLedgers in the dashboard's machine-readable rules catalog.
Cross-ledger sweep: Funding and sweeping across block boundaries: when an account is funded in ledger N and only swept in ledger N+1, the cross-ledger memory of the engine keeps the sweep visible. Stretched dusting campaigns are caught the same way, via the union of their tiny destinations over the window.
Peeling chains: Staged forwarding of 60 to 95 % of the inflow across unflagged 1:1 relays, from three hops onwards. Detection runs on the transaction view and follows inconspicuous intermediate accounts without assigning them a role.
Wash trading (self-transfers): At least three self-payments of the same account within one ledger (sender and destination are identical) — volume generation without a real counterparty, a typical washing pattern.
Wash cycle (cross-account): At least two payments in each direction between the same two accounts (A→B and B→A) with at least 80 % volume conservation within one hour — volume generated across two identities. Single payment pairs stay exempt (normal refunds and market moves), exchanges never take part as cycle members; the finding class is suspect.
Motif counters (gather-scatter): Deterministic counters over the accumulated flow edges — no learning architecture, zero extra requests. Gather-scatter (fan-in and fan-out of at least 3 different counterparties at one node) is recorded as a purely informative note; the wash-cycle thresholds above come from the same machinery. A cluster carries the motifs field only when a qualified pattern exists — no field means no motif. All counters and caps appear in the dashboard's machine-readable rules catalog.
Hub connections: Unflagged nodes with more than 20 finding edges (exchange, faucet or aggregation accounts) are cut out of the cluster union: two independent scenes never merge through a shared exchange. Connections that run through a shared exchange account (transit) are marked as pass-through, not as direct adjacency.
Known-bad contact: When a transaction touches an address from the threat list (curated and derived from the honeypot history), this is reported as a hit — direct account or payment contact as malicious, mere trustline or NFT positions only as suspect.

The engine rule catalog holds fifteen rules — besides the ones above, among others memo phishing (URLs and seed patterns in payment memos), dusting (mini XRP to fresh accounts), fake NFT fraud, airdrop TrustSet spam, payment bursts, offer spam, AMM washing, thin-pool exploits and spoof offer cycles. Every rule carries a severity; all assignments are heuristics, not proof of guilt.

Every threshold of the rules with numeric thresholds is machine-readable in the dashboard's rules catalog (thresholds per rule), and the deployed commit is reported in the x-deploy-commit response header of the same endpoint.

Glossary

The terms of the interface — short and precise

Cluster: A group of addresses connected through money-flow edges (transactions with at least one flagged endpoint). Clusters form via union-find, carry labels such as “Cluster A” and track members, roles, volume and first/last sighting.
Severity: The engine assigns the levels malicious, suspect and info. The account check reports its verdict as known malicious, risk-associated (contact to listed addresses), clean or unknown, plus an off-ramp assessment (likely unproblematic, worth reviewing, not assessable). Addresses on whitelists (known gateways, exchanges) count as benign — exemption from the broad rules as false-positive protection, not a value judgment.
Destination tag and transit: Exchange accounts are hosted accounts: many users share one r-address and are told apart by the 32-bit destination tag. If inflows at the same exchange account show at least two different tag identities, the connection counts as transit — it runs through a shared exchange account and is not a direct adjacency.
Entity resolution: Control clusters from cryptographic signals instead of money flow: regular key, signer-list fingerprint, email hash and a shared sponsor address (funding source) unite accounts into one entity. Domains only count after two-way verification via xrp-ledger.toml; join keys carried by more than 20 addresses (hubs) are excluded.
Block window vs. persistent cluster stock: The block window is the rolling persisted stock behind the archive view (24 hours / 3 days / 7 days): hourly rollups plus details of flagged transactions only, seven days of retention. The persistent cluster stock (flow state) is independent of it: it accumulates clusters across the run of a server walk with a cursor, keeps them at most seven days after their last sighting (then the top 200 by volume) and feeds the flow host.
History vs. archive: The history permanently collects every cluster classified as malicious — independent of the live feed, among others through visitor reports. The dashboard archive only shows the persisted block window (24 hours to 7 days). For the backwards search per address there is a separate archive of daily chunks: registry-linked clusters stay retrievable for 180 days, malicious ones for 30 days.

Honest limits

What this dashboard can do — and what it cannot

All roles and patterns are heuristics from in/out degree and money flow. They name anomalies, not offenders — no proof of guilt, no legal statement or liability.
There is no 100 % promise: not every scheme matches a rule, and rules can misfire without context. Cross-checking the transactions on the public ledger is explicitly encouraged.
The account check assesses at most the last 300 transactions of the queried address — older contacts and patterns are not covered. The queried address is not stored.
The analysis runs against public endpoints with rate limits (honeycluster.io). The server walk fills the window every five minutes; live mode and endpoints throttle and cache (60 s) — under load, views may briefly lag or drop out (fail-closed instead of pretending success).
The archive backwards search reads day blocks on a limited read budget (62 days by default): the 180-day retention of registry-linked clusters exceeds what is queryable — old windows may be cut short (marked as truncated).
The off-ramp assessment of the account check is a heuristic — the decision about payouts rests with the respective provider.

Data sources

Ledger data: XRP Ledger mainnet via honeycluster.io (WSS/JSON-RPC). Account names and exchange attribution: xrpscan.com (CC BY-NC-SA 4.0). Country borders on the globe: Natural Earth (TopoJSON). Every finding address can be verified directly on the public ledger.