Overview#
A compliance team investigating a suspected structuring scheme found that a cluster of wallets had been active for two and a half years. The wallets had changed composition over time, some addresses going dormant, new ones appearing, but the core behavioural fingerprint remained consistent. Persistent cluster tracking had been recording those changes all along, providing a timeline of entity evolution that became central to the case narrative. That kind of long-term, continuously updated intelligence is what distinguishes persistent clusters from snapshot-based analysis.
The Blockchain Persistent Clusters system transforms transient blockchain activity patterns into durable, evolving entity intelligence. It maintains historical cluster relationships across millions of addresses while tracking confidence decay, entity attribution, and cluster evolution over multi-year timeframes. Compliance teams, financial intelligence units, and blockchain forensics investigators rely on persistent clusters for the long-term context that snapshot analysis cannot provide.
Key Features#
- Long-Term Cluster Storage: Maintains multi-year cluster histories with full member tracking, confidence evolution, and relationship metadata, accumulating intelligence over time
- Confidence Scoring System: Probabilistic scores (0.0-1.0) representing cluster validity and member relationship strength, enabling risk-based decision-making with configurable thresholds
- Temporal Decay Model: Confidence naturally declines without confirming activity, ensuring stale intelligence does not dominate current risk assessments while maintaining historical context
- Cluster Evolution Tracking: Records every structural change including formation, growth, splits, merges, dormancy, and reactivation with complete audit trails
- Entity Attribution Persistence: When a cluster is attributed to a real-world entity, that intelligence becomes permanent cluster metadata, propagating across all members and persisting through structural changes
- Cluster Merge and Split Detection: Identifies when clusters should combine (same underlying entity) or divide (distinct sub-entities), maintaining integrity as blockchain intelligence evolves
- Dynamic Member Management: Tracks core, probable, and peripheral members with rich contextual data including first seen, last activity, transaction count, and confidence trajectory
Supported Networks#
- Major Blockchains: Bitcoin, Ethereum, Tron, BNB Chain, Solana, Cardano, Polkadot, Avalanche
- Layer 2 Solutions: Polygon, Arbitrum, Optimism, Base, zkSync Era, Starknet, Linea
- EVM-Compatible Chains: Cronos, Moonbeam, Fantom, Gnosis Chain, Aurora, Celo, and more
- Cross-Chain: Multi-blockchain cluster relationships with chain-specific metadata
Cluster Lifecycle#
Clusters progress through five lifecycle states:
- Emerging: New patterns requiring validation with developing confidence
- Active: Established clusters with ongoing transactional activity
- Confirmed: High-certainty clusters with verified entity attribution
- Dormant: Inactive clusters undergoing confidence decay
- Archived: Historical records maintained for reference but excluded from active queries
Each state transition generates audit events enabling compliance teams to understand why classifications changed over time, which is critical for regulatory inquiries and legal proceedings.
Confidence Thresholds#
Different operational contexts require different confidence levels:
- High-Risk Screening (0.85+): Sanctions checks, law enforcement referrals
- Compliance Monitoring (0.70+): Transaction monitoring, enhanced due diligence
- Intelligence Development (0.50+): Investigative leads, pattern detection
- Research and Exploration (0.30+): Early warning, emerging threat identification
Investigation Use Cases#
Sanctions Screening#
- Screen against attributed sanctioned clusters for broader coverage than individual address lists
- Catch indirect sanctioned fund flows through cluster propagation that address-only screening would miss
- Automated blocking with audit trail documentation and complete evidence chains
Investigation Case Development#
- Instant access to pre-computed cluster relationships removes the need for manual graph traversal
- Historical evolution reveals entity operational patterns and changes over time
- Attributed exchange deposits identify potential cash-out venues for rapid response
Customer Due Diligence#
- Historical analysis shows customer counterparty exposure across attributed entities
- Confidence-scored risk assessment based on cluster attributions for consistent evaluation
- Automated enhanced due diligence triggering for mixer, darknet, or sanctioned entity exposure
Forensic Analysis#
- Reconstruct entity development timelines through complete cluster evolution history
- Build evidence chains showing how entity identification occurred and evolved
- Support algorithm validation by comparing current clustering against historical ground truth
Entity Attribution#
Attribution types cover the full spectrum of blockchain entities:
- Exchange Attribution: Centralized exchange wallets identified through multiple intelligence sources
- Service Attribution: DeFi protocols, payment processors, custody services
- Illicit Attribution: Darknet markets, ransomware operations, scam campaigns
- Sanctions Attribution: OFAC, UN, EU sanctioned entities with regulatory cross-reference via OpenSanctions
- Mixer Attribution: Tumblers, privacy services, and obfuscation tools
Attributions include entity name, type, confidence level, evidence source, attribution date, and jurisdictional context. When any cluster member receives attribution, it propagates to all cluster members with historical backfill of past transactions.
Open Standards#
- FATF Recommendation 16 (Travel Rule): Cluster attribution and entity propagation support Virtual Asset Service Provider (VASP) obligations under the FATF Travel Rule by identifying the beneficial owner behind a cluster of addresses, enabling originator and beneficiary due diligence.
- OFAC SDN List / OpenSanctions: Sanctions screening integrates directly with the OFAC Specially Designated Nationals list and the OpenSanctions aggregated dataset, matching attributed cluster identities against both sources to surface sanctioned-entity exposure.
- Common Input Ownership Heuristic (CIOH): The primary address-clustering method implements the CIOH, a well-established forensic methodology in blockchain analysis whereby addresses co-signing a transaction are inferred to share a common controller.
- Ethereum Improvement Proposals ERC-20, ERC-721, ERC-1155: Token transfer events conforming to the ERC-20 (fungible), ERC-721 (non-fungible), and ERC-1155 (multi-token) standards are tracked across all cluster members, ensuring token-layer activity is reflected in cluster confidence and attribution.
- Ethereum JSON-RPC (EIP-1474): On-chain transaction and state data is ingested from self-hosted and third-party nodes via the Ethereum JSON-RPC interface, which defines the canonical method set for querying blockchain state across EVM-compatible networks.
- GraphQL (June 2018 Specification): All cluster queries, mutations, and attribution operations are exposed through a GraphQL API, providing typed, introspectable access to cluster lifecycle state and member data.
- SHA-256 (FIPS 180-4): Forensic evidence packages generated from cluster investigations are integrity-sealed with a SHA-256 hash of the canonical JSON report, enabling independent verification for court and regulatory submissions.
- TLS 1.3 (RFC 8446): All cluster data in transit, including API calls to blockchain nodes and client-facing GraphQL endpoints, is encrypted using TLS 1.3.
Compliance#
- Complete audit trail documenting all cluster changes, attribution decisions, and confidence score evolution
- Supports Bank Secrecy Act, AML/CTF, and FATF Travel Rule compliance workflows
- Configurable data retention policies meeting jurisdictional requirements
- Role-based access control with elevated privileges required for attribution modifications
- GDPR considerations addressed through pseudonymous data handling without PII storage
- Encryption at rest and in transit (TLS 1.3) for all cluster data
- Regular penetration testing and security assessments
- SOC 2 Type II certified infrastructure
Last Reviewed: 2026-02-05 Last Updated: 2026-04-14