Cold-wallet sybil patterns and how teams detect them

When LayerZero announced their ZRO token distribution in mid-2024, they did something unusual: they published a sybil self-report window before snapshot finalization, giving wallet operators a chance to come forward and accept a reduced allocation rather than zero. The result was a public dataset of hundreds of thousands of flagged addresses that exposed, in granular detail, exactly which on-chain patterns their detection pipeline had flagged. i’ve spent a lot of time with that data, and with equivalent datasets from Arbitrum, Optimism, and a handful of smaller protocols. what follows is an honest account of the techniques teams actually use, the patterns that get wallets flagged, and where the real edges and limits are in 2026.

this piece is written for operators who already understand the basics: you know what a cold wallet is, you’ve run multi-wallet setups, and you’re not here for a definition of “sybil attack.” what you probably want is a more precise mental model of how detection actually works at the infrastructure level, which failure modes matter, and what the teams on the other side are actually capable of. i’ll be honest about what i’ve seen work and what i’ve watched get burned.

the stakes are material. a single flagged sybil cluster can wipe out months of farming work across dozens of wallets. more importantly, protocols have started coordinating, sharing flagged address lists between teams, and some are beginning to submit data to analytics firms whose commercial products feed back into future projects. getting flagged isn’t just a one-time loss anymore. understanding the detection surface is now basic operational hygiene.

background and prior art

the academic literature on sybil resistance goes back to John Douceur’s 2002 Microsoft Research paper, which established the foundational argument: without a trusted certification authority, sybil attacks are always possible in distributed systems. the blockchain context adds a twist: all activity is public and permanently recorded, which makes post-hoc forensic analysis far more powerful than real-time detection. a team that launches a token today can run their sybil analysis three months later with better tooling than existed at snapshot time.

the first serious on-chain sybil analysis i saw documented at scale was around the Uniswap UNI airdrop in September 2020, where community members identified clusters of wallets that had been funded from the same sources to meet the minimum swap threshold. that work was informal, posted on governance forums, and mostly anecdotal. by the time Arbitrum distributed ARB in March 2023, distributing 1.275 billion tokens across roughly 625,000 eligible addresses, the tooling had professionalized significantly. Nansen, Chainalysis, and a cohort of newer firms had built commercial clustering products that protocols could license directly. the 2024-2025 cycle saw several major distributions run detection pipelines before finalization rather than after, which changed the incentives for operators significantly.

the core mechanism

at the most fundamental level, sybil detection is a graph clustering problem. the inputs are: transaction history, funding sources, timing data, contract interaction sequences, and gas behavior. the output is a probability score that a given address is part of a controlled cluster rather than an independent user. here’s how each input layer works in practice.

funding graph analysis is the entry point. every wallet was funded from somewhere. a centralized exchange withdrawal, a bridge deposit, a transfer from another wallet. detection systems build a directed graph of these funding relationships and look for hub-and-spoke patterns: one source address that funded fifteen wallets, or a CEX withdrawal address that appeared in the funding chain of dozens of flagged wallets. the naive pattern, funding multiple wallets directly from a single hot wallet, gets caught in every serious pipeline. but the less obvious pattern, using intermediary hops to obscure the source, also leaves traces because the timing and amounts of those hops often follow machine-generated patterns rather than human behavior.

behavioral fingerprinting is where detection has gotten genuinely sophisticated. when you script wallet interactions, the resulting on-chain behavior has statistical properties that differ from organic user activity. transaction timing follows distributions: human users interact with protocols across varied intervals, often clustering around evenings and weekends in their timezone. automated wallets tend to show much more uniform spacing, or burst patterns tied to when scripts ran. protocols that have been farming targets for long enough have transaction history going back months, and forensic analysis of that full history often reveals scripting artifacts that weren’t visible at snapshot time.

contract interaction sequences are another signal. if forty wallets all interacted with the same set of contracts in the same order, on the same days, that’s a clustering signal regardless of whether those wallets share a funding source. this is why the “checklist” approach to activity farming, where you follow a published guide and do exactly what it says in exactly the order it says, creates correlation patterns in the dataset. your wallet’s activity profile ends up looking statistically identical to every other wallet that followed the same guide.

gas behavior leaks information in subtle ways. gas price selection, timing of transactions relative to block space conditions, whether transactions are submitted via MEV-protected endpoints like Flashbots Protect, whether fee escalation patterns match human retry behavior or automated retry loops. i’ve seen analysis that clusters wallets based purely on gas bidding behavior, with no reference to funding sources or contract interactions at all.

cross-chain correlation is now standard. if your EVM wallets all bridged from Solana, and your Solana wallets share a common funding source, that cross-chain link closes the attribution loop. with bridge protocols publishing full transaction history and firms like Nansen maintaining labeled address databases across dozens of chains, the assumption that activity on chain A is invisible to analysis of chain B is no longer safe.

the actual detection pipeline at a serious protocol typically looks like this:

1. pull all eligible addresses from snapshot
2. build funding graph: trace each address back 3-5 hops
3. cluster by shared funding sources at each hop depth
4. run behavioral fingerprint scoring on each cluster
5. apply cross-chain correlation for addresses above threshold activity
6. score each cluster: high / medium / low confidence sybil
7. human review of edge cases near allocation thresholds
8. finalize exclusion list or apply tiered allocation penalties

the specific thresholds and scoring weights vary by team and tooling vendor, but this structure is consistent across the cases i’ve reviewed.

worked examples

the LayerZero ZRO distribution, 2024. LayerZero’s approach was notable because they published their methodology publicly and ran a self-report window before finalizing the exclusion list. their detection was run in partnership with Chaos Labs, using a combination of funding graph analysis and behavioral clustering. the self-report mechanism was economically clever: wallets that self-reported received 15% of their calculated allocation rather than zero. this created a financial incentive that caused a large fraction of operators to voluntarily reveal the scope of their operations, providing LayerZero with ground-truth data about cluster sizes and operational patterns. the result was one of the most detailed public sybil datasets in the industry. analysis of the self-reported data showed median cluster sizes of around 8-12 wallets, with a long tail of operations running hundreds of wallets per cluster, and the dominant detection signal was funding source correlation rather than behavioral fingerprinting. this suggests that at the time of the snapshot, many operators had solved the behavioral layer but not the funding graph layer.

the Arbitrum ARB airdrop, March 2023. Arbitrum allocated tokens based on a points system tied to bridge activity, transaction count, and contract diversity. post-distribution community analysis identified several patterns that would have been caught by a stricter detection pipeline. one documented case involved a cluster of approximately 1,800 wallets that had all been funded through the same sequence of Hop Protocol bridge transactions over a 72-hour window, with nearly identical transaction timing profiles and contract interaction sequences. the wallets received ARB allocations totaling several hundred thousand tokens at the time worth roughly six figures USD. Arbitrum did not run a pre-distribution sybil filter at the sophistication level that later protocols adopted, partly because the tooling wasn’t as mature in early 2023. this case is now used as a teaching example inside several detection firms.

a smaller DeFi protocol, 2025 (name withheld). i was peripherally involved in reviewing the sybil analysis for a mid-tier protocol that distributed approximately $8 million in tokens in Q1 2025. their detection pipeline, built on top of Chainalysis Reactor data, flagged 23% of initially eligible addresses as high-confidence sybil clusters. the dominant pattern was not the funding graph but rather what the team called “activity mirroring”: groups of wallets that had interacted with an identical set of 14 contracts in a window of three weeks, with timing gaps between interactions that were statistically too uniform to be human. the wallets had been funded through mixers and multi-hop transfers that successfully obscured direct funding links, but the behavioral correlation remained visible in the raw transaction data. the protocol ultimately excluded 19% of addresses after human review of edge cases, which saved approximately $1.5 million in token allocation from being distributed to what were almost certainly controlled clusters.

edge cases and failure modes

the organic correlation problem. not all correlated behavior is sybil. if a popular farming guide gets published and 40,000 people follow it, their wallets will show statistical correlation in contract interaction sequences that looks like clustering. detection systems handle this by applying population-level baselines: if 30% of all eligible addresses interacted with the same contracts in the same window, that’s not a clustering signal, it’s a popular protocol. the failure mode for operators is accidentally replicating rare or unusual interaction patterns that have high distinctiveness even if the behavior was technically organic. following niche guides with low readership creates higher correlation risk than following well-known ones, counterintuitively.

the dust attack surface. some operators have been burned by receiving small unsolicited transfers from known-flagged addresses, creating a funding graph link that appears to connect their wallets to a flagged cluster. this is largely noise in serious detection systems, which filter for meaningful funding relationships rather than dust, but it’s worth being aware of as a potential false positive vector. if you receive unexpected small transfers from unfamiliar sources, most detection pipelines will not penalize you for it, but you should document the fact that the transfer was inbound and unsolicited if you’re ever in a dispute process.

the shared infrastructure fingerprint. if multiple wallets in a cluster submit transactions through the same RPC endpoint or node provider, and that provider’s transaction metadata leaks timing or routing information, that’s a detection surface that exists outside the on-chain record. most serious detection pipelines work only with on-chain data because off-chain metadata is unreliable and inadmissible in any public justification. but some newer approaches are starting to incorporate mempool observation data, which can reveal submission timing and routing patterns before transactions confirm. this is still relatively rare but worth tracking. the team at antidetectreview.org/blog/ has some useful write-ups on the infrastructure layer specifically.

the long history problem. protocols that weight activity over long time periods create a verification asymmetry that’s hard to overcome after the fact. if a farming campaign starts eight months before snapshot, wallets that begin activity two months before snapshot will have shorter, denser histories that look statistically different from wallets with genuinely organic multi-year histories. detection systems can flag wallets based on history length and density patterns even without identifying specific sybil signals. this is one of the strongest arguments for maintaining wallets with genuine, varied activity over extended periods rather than spinning up fresh wallets for each campaign.

the cross-protocol coordination gap. the emerging threat for operators is cross-protocol sybil list sharing. if your wallets are flagged on protocol A, and protocol A shares its exclusion list with protocol B, your wallets start each new campaign with a prior probability of being sybil that skews detection scoring against you. this is happening informally through community channels and formally through commercial arrangements with analytics firms whose databases accumulate flagged addresses over time. a wallet that has been publicly flagged in a documented sybil case has a meaningful persistent liability that doesn’t go away when you move to a new campaign. the Gitcoin Passport system and similar identity staking approaches are partly a response to this, giving protocols a way to require positive identity attestations rather than just relying on negative flagging.

what we learned in production

the most consistent observation from reviewing multiple detection datasets is that most operators get caught at the funding graph layer, not the behavioral layer. the behavioral mimicry problem is hard but solvable with enough automation sophistication. the funding graph problem is structurally harder because the on-chain record of value flows is permanent and complete. a wallet that was funded with ETH that can be traced back to a single CEX withdrawal that also funded twenty other wallets is going to show that link regardless of how sophisticated the subsequent behavior was. this is why the operational focus in 2025-2026 has shifted toward funding chain architecture rather than behavioral scripting.

the second observation is about scale economics. detection sensitivity scales with the size of the operation. a two-wallet operation that shares a funding source might not meet any detection threshold because the cluster is too small to be statistically significant. a 200-wallet operation sharing any common funding chain is almost certainly going to be flagged by any competent pipeline. this creates a nonlinear risk function where the marginal risk of adding wallets to a cluster accelerates faster than the marginal reward. the practical implication is that operators who are running large-scale coordinated operations are taking on substantially more detection risk per wallet than operators running smaller, more isolated setups. this isn’t a license to run two wallets and think you’re safe, but it is a meaningful risk calibration consideration.

one thing i’ve noticed working with operators across the Singapore and broader Southeast Asia scene is a persistent underestimation of the time horizon for detection. the common mental model is that if you make it through the snapshot date, you’re safe. this is wrong. protocols frequently run their sybil analysis weeks or months after snapshot, with tooling that continues to improve. i’ve seen wallets get flagged in retroactive analysis eight months after the original snapshot date. treating snapshot as the finish line is a mistake. the actual risk window extends until token distribution is complete and, in some cases, beyond that if the protocol conducts post-distribution audits for governance eligibility or future allocation rounds.

for a deeper look at the infrastructure and tooling side of multi-account operations, the multiaccountops.com/blog/ covers some of the operational security considerations that are adjacent to what i’ve described here. and if you’re looking at the proxy infrastructure layer specifically, proxyscraping.org/blog/ has relevant technical content on residential versus datacenter traffic patterns and how they interact with RPC submission.

references and further reading

• Gitcoin Passport documentation - the primary reference for decentralized identity attestation used in sybil resistance, including the scoring model and stamp architecture

• Nansen analytics platform - the commercial product most commonly referenced in protocol detection pipelines; their wallet labeling database covers most major EVM chains and several non-EVM networks

• Chainalysis blog on address clustering - Chainalysis publishes methodological notes on their reactor clustering approach and has documented several major sybil cases in their public writing

• Microsoft Research: The Sybil Attack (Douceur, 2002) - the foundational academic paper establishing why sybil attacks are structurally unavoidable without trusted certification; still the best starting point for understanding the theoretical framework

• LayerZero documentation and protocol specs - primary source for understanding the LayerZero protocol architecture, relevant for interpreting their 2024 sybil detection methodology in the context of their cross-chain messaging system

for more context on the broader airdrop farming ecosystem, the /blog/ index has related deep-dives on snapshot methodology, points systems, and allocation mechanics that are relevant background for the detection material covered here. the write-ups on wallet management and on-chain activity patterns cover the operational side of what i’ve described here from the detection perspective.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.