Multi-chain sybil isolation: keeping wallets unlinked across L2s

the hardest part of multi-wallet operations is not generating wallets, funding them, or even running transactions at scale. the hardest part is keeping them separate in a world where every on-chain action leaves a permanent, public, cross-referenceable trace. chain analysis has gotten good. not just Chainalysis-and-TRM good, but also open-source-script-running-on-a-laptop good. if a protocol’s team can write a Python script to pull Dune data and run a common-input-ownership heuristic, your wallets are at risk.

this guide is for people who already know what a sybil attack is, already know why airdrop protocols screen for them, and already run multiple wallets. i’m not going to explain what MetaMask is. what i am going to explain is the specific, non-obvious ways that wallets get linked across Ethereum L2s, what the actual failure modes look like in production, and what mitigations are worth your time versus which ones are security theater.

the stakes here are not abstract. the Arbitrum airdrop in March 2023 excluded somewhere around 250,000 addresses flagged as sybil. Optimism’s OP1 and OP2 rounds had similar exclusions. zkSync’s 2024 airdrop famously clawed back allocations from wallets that cleared initial screening but got flagged post-distribution. if you are running 20 wallets and all 20 get linked, you may walk away with a single allocation, or zero, depending on the protocol’s penalty model. the cost of poor isolation compounds with scale.

background and prior art

the concept of address clustering predates L2s by years. bitcoin researchers published clustering techniques in the early 2010s based on the common-input-ownership heuristic: if two addresses appear as inputs in the same transaction, the same entity likely controls both. on UTXO chains this is clean and powerful. on EVM chains the equivalent is gas refueling: if a single address sends ETH to ten wallets in quick succession, those ten wallets share a common funder. that common funder link is often all a detection script needs.

what changed with L2s is that the surface area exploded. instead of one chain with one mempool, you now have Arbitrum One, Optimism, Base, Blast, Linea, Scroll, zkSync Era, Starknet, and a dozen more, each with its own sequencer, its own bridge contract on L1, and its own on-chain history. the naive assumption is that because chains are separate, wallets are automatically isolated. they are not. bridging transactions are public. the L1 bridge contract sees both the source address and the destination address. if you bridge from wallet A on mainnet to wallet B on Arbitrum, and both A and B appear in your cluster, you’ve just linked them at the L1 level. Nansen, Dune, and custom protocol-internal analytics all ingest this data.

academic work on EVM clustering has accelerated since 2022. the broad methodology: pull all bridge events for a protocol, build a bipartite graph of L1 sender to L2 receiver, then apply community detection algorithms (Louvain, Leiden) to find clusters. overlay gas funding patterns, transaction timing, and NFT transfer history. the output is a probabilistic cluster score. a score above 0.8 is usually enough for a protocol to reject an address.

the core mechanism

to isolate wallets properly, you need to understand exactly which data fields create links. there are five primary vectors.

common funding source. the most common failure. you have 30 wallets to fund with 0.05 ETH each for gas. you send from your main wallet to all 30. every on-chain analyst sees this immediately. the fix is obvious: never use the same funding wallet twice, and ideally never use an address that has any other activity. in practice, most operators use a CEX withdrawal per wallet, or a mixer output per wallet. CEX withdrawal works well because the CEX aggregates thousands of withdrawals, so the link from your KYC identity to your L2 wallet is off-chain. what you want to avoid is any on-chain hop that touches multiple target wallets in the same transaction or across a short time window.

bridge signature correlation. when you use an official bridge, your L1 address is in the event log. if wallet X on mainnet bridges to wallet Y on Arbitrum, and later wallet X also bridges to wallet Z on Arbitrum, Y and Z are linked through X. the solution is to never reuse an L1 intermediate address across multiple L2 wallets. each L2 wallet should have a dedicated, purpose-built L1 address used only once for that wallet’s bridging needs. this address is retired after use.

transaction timing clusters. even if funding and bridging are clean, if you run 30 wallets all executing the same sequence of actions within a 10-minute window, a timing correlation attack will group them. protocols look at the timestamp distribution of first interactions, swap times, and bridge times. the fix is randomized delays between wallets. not just random uniform delays, but delays sampled from realistic human distributions. a human using an app might interact daily for a few days, then disappear for a week, then come back. a bot runs every 6 hours with 0-10 minutes of jitter. the shape of the activity distribution matters, not just whether delays exist.

contract interaction fingerprinting. if all 30 wallets use the exact same sequence of contract calls in the exact same order with the exact same slippage parameters, even a simple frequency analysis will cluster them. humans use the same protocol in different ways. one person swaps ETH to USDC directly. another goes ETH to WBTC to USDC because they had a reason. your wallets need behavioral variance, not just timing variance.

NFT and token transfer trails. this is the one people forget. if you mint an NFT on Arbitrum to wallet A and then transfer it to wallet B “for safekeeping,” you’ve linked A and B. same with ERC-20 consolidation: sweeping funds from 10 wallets into 1 at the end of a campaign creates an obvious cluster. never transfer assets between wallets you want isolated, and never consolidate to a shared exit address without passing through a clean intermediary.

worked examples

example 1: arbitrum airdrop post-mortem, 2023.

the Arbitrum airdrop in march 2023 used several documented criteria. wallets needed at least 2 months of activity, transactions across at least 2 distinct months, minimum 4 transactions, and some interaction with arbitrum’s ecosystem contracts. the team also ran sybil screening that eliminated addresses sharing a common funder within 1 hop on-chain.

a common failure pattern i saw firsthand: operators funded wallets through a single CEX withdrawal address that was reused. the operator would withdraw 2 ETH from Binance to address X, then send 0.1 ETH from X to each of 20 wallets. address X was the common link. the Arbitrum sybil filter explicitly checked for this pattern, and all 20 wallets in such a cluster were excluded. operators who used per-wallet CEX withdrawals (one withdrawal per wallet, directly to the wallet) fared much better.

another failure: timing. wallets funded on the same day, bridged on the same day, first transaction on the same day. even with distinct funding addresses, the timing cluster was obvious. the remedy is simple but operationally painful: stagger wallet creation and initial activity over weeks, not hours.

example 2: zkSync era airdrop, 2024.

zkSync’s airdrop in june 2024 was more aggressive. they published their eligibility criteria at distribution time, but the sybil exclusion methodology was partly reverse-engineered by the community. wallets flagged as sybil had several common properties: they shared on-chain funding sources within 2 hops, they had identical transaction sequences (often the same three protocols in the same order), and their gas spending patterns were machine-like in regularity.

the hop-2 analysis is the part that catches people who think they’re clean. if wallet A funded wallet B, and wallet B funded wallet C, wallets A, B, and C form a cluster even if A never directly touched C. operators who used a dedicated intermediary wallet (funded by CEX, used to fund target wallets) thought they were isolated. they were not, because the intermediary itself was the link. the correct approach is CEX withdrawal directly to the target wallet, with no on-chain intermediate.

the behavioral fingerprinting in zkSync was particularly effective against scripted operators. the protocol could see that 10,000 wallets had made a transaction to protocol X, then protocol Y, then protocol Z, in exactly that order, within the same 30-minute window. that’s not 10,000 humans. the addresses were bulk-excluded.

numbers: zkSync distributed approximately 3.6 billion ZK tokens. the community estimated that somewhere between 15-20% of eligible addresses were excluded for sybil patterns. at distribution price, that exclusion cost some operators tens of thousands of dollars in aggregate.

example 3: optimism op3 and delegated governance, 2025.

Optimism has run multiple airdrop rounds with increasingly sophisticated criteria. by OP3, the eligibility requirements included governance participation: voting with delegated OP, participating in proposal discussions, and having a history of meaningful on-chain governance actions across the ecosystem.

the governance layer creates a new linking vector that pure on-chain analysts often miss. if wallet A and wallet B both delegate voting power to the same third-party delegate address, and both vote identically on the same proposals at nearly the same time, they’re behaviorally linked even without a financial transaction between them. one operator i spoke to had 15 wallets all delegating to a single delegate they controlled, thinking governance activity would look legitimate. the delegate address was the cluster anchor. all 15 wallets were grouped.

the fix for governance-layer isolation is to use different delegates per wallet, vote at different times, and occasionally abstain or vote differently on lower-stakes proposals to simulate genuine opinion variance.

edge cases and failure modes

1. ENS and onchain identity registration.

if you register an ENS name from wallet A and then interact with any protocol from wallet A in a way that exposes the name, you’ve created a persistent identity anchor. more dangerously: if you look up your ENS name from wallet B (for example, by signing a message that includes the ENS resolution), you’ve linked B to the identity attached to A. similar issues exist with Lens Protocol, Farcaster custody addresses, and any on-chain attestation system like EAS. the rule is: identity systems and airdrop wallets do not mix. keep them on completely separate addresses that share no transaction history.

2. gas price anomalies.

EVM transactions include a gas price field. if all your wallets consistently set gas to the exact same value at the exact same time, that’s a signal. more subtly: if you use a script that reads the current base fee and adds a fixed tip, all your wallets will have identical priority fees in the same block or adjacent blocks. this is a low-weight signal on its own but combines badly with other signals. use randomized gas parameters within a reasonable range, and don’t transact all wallets in the same block.

3. RPC endpoint leakage.

this is a network-layer issue, not a chain-level one, but it matters. if all 30 wallets connect through the same RPC endpoint and that endpoint logs IP addresses (most do), the endpoint operator sees all 30 addresses originating from the same IP. if that endpoint is a third party, they have the data. if you’re running your own node, you’re fine. if you’re using Infura, Alchemy, or QuickNode with a shared API key, your addresses are grouped at the infrastructure level. use separate API keys per wallet cluster, or better, per wallet. for proxy setups, this is where residential proxy rotation matters. the antidetect and proxy ops community has written extensively on this, and proxyscraping.org/blog/ has useful material on RPC-layer isolation using rotating residential endpoints.

4. hardware wallet reuse for signing.

ledger and trezor users sometimes sign transactions for multiple addresses from the same device. the device itself doesn’t leak on-chain, but the derivation path does in some edge cases. more practically: if you use a hardware wallet to occasionally “check in” on a cluster of software wallets by signing a test transaction, and if you do this from the same machine that also runs your main wallet, the risk is in software, not hardware. your browser, your clipboard history, your local node cache. keep signing environments physically separate where feasible.

5. consolidated exit addresses.

after a successful airdrop claim, the natural impulse is to sweep everything to one address for convenience. doing this on-chain immediately retroactively links all your claiming wallets. even if the airdrop team does not rescan post-distribution, future protocols that do cross-protocol analysis will see the consolidation and flag all those wallets as a cluster. exit through a CEX or through multiple independent paths, not through a single on-chain consolidation transaction. this also applies to NFT protocol rewards, liquidity mining claims, and any other on-chain income that might be considered in future snapshot criteria.

what we learned in production

running multi-wallet campaigns across five different L2 protocols over the past two years, the single biggest lesson is that isolation discipline decays over time. the first batch of wallets might be set up perfectly: clean funding, distinct bridge paths, staggered activity, behavioral variance. but six months in, you’re tired, you need to top up gas quickly, and you send from a hot wallet you’ve used before. that one shortcut links wallets that were clean for six months.

the solution is process, not willpower. every wallet management operation should go through a checklist that includes: funding source verification (is this source clean and unused?), bridge path review (does this bridge path reuse any L1 address?), timing check (am i transacting too close in time to another wallet in this cluster?). this sounds bureaucratic for small operations. at 50+ wallets it’s the only way to avoid drift. i use a simple spreadsheet that tracks the funding address, bridge date, first interaction date, and last gas top-up source for every wallet. checking it takes 30 seconds and has saved allocations multiple times.

the second lesson is that browser and network isolation matters more than most people admit. for the browser side, i’d point to the reviews at antidetectreview.org/blog/ as a starting point for anti-detect browser setups. for network, each wallet cluster needs its own residential IP that does not overlap with any other cluster. the goal is that if someone subpoenas your RPC provider or your browser fingerprint leaks, the blast radius is contained to one cluster. the multi-account operations community has documented this operational model in detail at multiaccountops.com/blog/, particularly around the question of how many wallets can safely share a single network identity.

one more thing worth saying: the protocols are getting better faster than most operators realize. zkSync 2024 was notably more sophisticated than Arbitrum 2023. the gap between “good enough” isolation and “actually clean” isolation is closing. techniques that worked 18 months ago, specifically shared-hop funding and timing jitter alone, are no longer sufficient. the floor has moved up. if your current workflow was designed in 2022, it needs a review.

references and further reading

• Ethereum Foundation: Layer 2 rollups overview – the canonical reference for how L2s work at a technical level, including sequencer architecture and bridge mechanics that underpin the linking risks described here.
• Arbitrum documentation: introduction to Arbitrum One – covers the bridge contract structure and how L1-to-L2 message passing works, relevant to understanding why bridge events are publicly queryable.
• Optimism documentation – includes the OP Stack bridge architecture, useful for understanding how cross-chain message verification creates permanent on-chain records.
• zkSync Era developer documentation – details on zkSync’s account abstraction model and how native AA changes some assumptions about address derivation and wallet behavior that affect isolation strategy.

for further reading on this site: the wallet generation and key management guide covers the upstream steps before isolation becomes relevant. the gas optimization across L2s deep-dive explains how gas parameters affect both cost and detectability. for a broader view of how protocols detect and penalize cluster behavior, see the sybil detection methods and scoring guide. for protocol-specific criteria, see the airdrop eligibility tracker on the main index.

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.