Wallet isolation: the proxy plus anti-detect stack that survived LayerZero

the LayerZero airdrop in june 2024 was the most aggressive Sybil-detection exercise the space had seen at that point. the team gave a self-reporting window, crowdsourced a community bounty for flagging clustered wallets, and ran on-chain graph analysis before cutting allocations. a lot of people who thought they had adequate separation found out they did not. wallets that shared an IP at any point during the eligibility window were binned together. wallets funded from a single hot wallet in the same block range were binned together. wallets that signed into the same dapp with identical browser fingerprints on different “identities” were, in some reported cases, also binned.

i ran about 80 wallets through the LayerZero eligibility period. 71 of them received allocations. the nine that did not had one thing in common: at some point during testing, i had used a shared residential proxy exit node across two wallet profiles on the same day. i confirmed this by going back through my proxy session logs. the correlation was clean. that failure taught me more about what isolation actually means in practice than any amount of theorizing.

this article is for people who already understand the basics, meaning you know what a residential proxy is, you have used an anti-detect browser before, and you have farmed at least one major protocol. i am not going to explain what MetaMask is. what i will do is explain the specific stack architecture that held up under real adversarial conditions, where the weak links are, and what to watch for as detection methodology keeps improving.

background and prior art

wallet isolation as a concept predates airdrop farming. the earliest serious writing on browser fingerprint separation comes from the digital advertising and e-commerce fraud communities, where publishers and platforms have been fingerprinting browsers since around 2010. the EFF’s Cover Your Tracks project (now archived but previously at coveryourtracks.eff.org) was doing public fingerprint uniqueness scoring for years. anti-detect browsers like Multilogin entered the market originally serving affiliate marketers and ad arbitrage operators, not crypto farmers.

the application to airdrop farming became necessary once protocols moved beyond simple snapshot-at-block-height eligibility. early protocols like Uniswap (2020 UNI drop) and 1inch did minimal Sybil filtering. ENS did slightly more. but starting with Arbitrum in 2023 and accelerating through LayerZero, Eigenlayer, and subsequent drops, teams began applying graph-theoretic clustering: build a graph where wallets are nodes and shared attributes (funder address, IP, timing, dapp session, device fingerprint relayed through WalletConnect) are edges, then cut clusters. if your cluster is large enough to look automated, you get zeroed or your allocation gets divided across the cluster rather than multiplied. the LayerZero documentation on their Sybil process and public community posts described self-reporting as a mechanism where Sybil operators could confess to farming and receive a reduced allocation, rather than nothing. the fact that they offered this exit suggests they expected the clustering to be imperfect and wanted to surface wallets they had not already caught.

the prior art on the technical side is scattered. forums like bitcointalk and various telegram channels have had discussion threads going back years. what has been missing is a consolidated, honest account of what the stack actually looks like at the operator level. that is what this article tries to provide.

the core mechanism

isolation works across four layers. you need all four. weakness in any one layer creates correlation.

layer 1: network identity

each wallet profile needs a dedicated IP that does not share exit nodes with any other profile. this means residential proxies with sticky sessions, not datacenter proxies (datacenter ranges are flagged by most major dapps and RPC providers), and not rotating proxies that cycle exit nodes between requests.

the vendors i use are Bright Data and IPRoyal. bright data costs more but has broader residential pool coverage in Southeast Asia, which matters for protocols that geo-restrict or weight activity. iproyal is cheaper per GB and has worked fine for most EVM farming. as of early 2026, bright data residential bandwidth runs around $8.40 per GB on the pay-as-you-go plan, and iproyal runs around $1.75-3.50 per GB depending on tier. for 80 wallets doing light interaction farming (a few transactions per week per wallet), i budget roughly $30-60/month in proxy costs.

the critical thing with sticky sessions is knowing how long they actually hold. bright data sticky sessions on residential IPs are documented to hold for up to 10 minutes of inactivity before the session resets. if you are signing transactions with long delays between actions, you can drift to a new exit node mid-session without realizing it. i now keep a lightweight session checker script that pings an IP-echo endpoint before each transaction batch.

import requests

def get_exit_ip(proxy_url: str) -> str:
    resp = requests.get(
        "https://api.ipify.org?format=json",
        proxies={"http": proxy_url, "https": proxy_url},
        timeout=10
    )
    return resp.json()["ip"]

call this before and after each session. if the IP changes, abort and re-establish the sticky session before touching the wallet.

layer 2: browser fingerprint

each wallet profile needs a browser identity that is internally consistent and does not share attributes with other profiles. the attributes that matter most are: user-agent string, screen resolution, canvas fingerprint, WebGL renderer string, timezone, language headers, and installed fonts (via CSS font enumeration).

i run Dolphin Anty for most profiles and GoLogin for a subset. both allow you to set these attributes per profile and store them persistently. the important thing is that you are not just randomizing these attributes on each launch. randomization is detectable because the resulting fingerprint will not match any real device profile. instead, good anti-detect browsers pull from databases of real device fingerprints and let you assign one consistently to each profile. dolphin anty’s free tier gives you 10 profiles. their paid tier starts at $89/month for 100 profiles as of early 2026. for anything over 50 wallets, the economics work.

the less obvious fingerprint vectors:

timezone must match the proxy’s geographic location. if your proxy exit is in Chicago and your browser timezone is Asia/Singapore, that is a fingerprint inconsistency. set timezone to match the proxy region.
webRTC IP leak. many anti-detect browsers claim to handle this, but test it explicitly using a webRTC leak checker. your browser’s local and public IP should both route through the proxy.
clipboard and font access APIs. some dapp front-ends make API calls that can fingerprint font enumeration behavior. dolphin anty and gologin both mask this but verify the settings are on.

layer 3: wallet funding

the funding chain is where most operators get lazy and where most Sybil detection focuses. every wallet needs to be funded through a different path, and those funding paths need to be temporally separated.

the cleanest approach i have found:

accumulate operating capital in a single cold wallet that never touches any protocol you are farming
route funds through at least two intermediary hops using privacy-preserving bridges or simple manual timing separation (different days, different amounts)
fund each farming wallet from a unique intermediary, not directly from a shared parent

i am not going to recommend specific mixing services because the regulatory status of those varies and this is not legal advice. what i will say is that on-chain timing analysis is real: funding ten wallets from the same parent address within the same block range is a strong clustering signal, even if the IP and browser fingerprint are different.

layer 4: behavioral timing

automated scripts that hit the same dapp at the same second across multiple wallets are trivially detectable. human behavior has variance. i add jitter to all transaction sequences.

import time
import random

def human_delay(base_seconds: float, variance: float = 0.4) -> None:
    """
    pause for base_seconds plus or minus variance*base_seconds
    simulates human interaction timing
    """
    jitter = base_seconds * variance * (random.random() * 2 - 1)
    time.sleep(max(0.5, base_seconds + jitter))

beyond timing, session length matters. real users do not sign 15 transactions in 8 minutes. spread interactions out across days where the farming window allows it.

worked examples

example 1: arbitrum stylus testnet campaign (2024)

one of the 2024 testnet campaigns on Arbitrum required deploying contracts through their Stylus SDK. i ran 40 wallets. setup:

40 sticky residential IPs from bright data, assigned one per dolphin anty profile
profiles configured with US and EU device fingerprints to match the proxy geographies
wallets funded through 8 different intermediary addresses over 3 weeks, roughly 5 wallets per intermediary, with 1-3 day gaps between funding batches
transaction scripts with human_delay(base=120, variance=0.5) between major steps
all 40 wallets qualified, none were flagged in the post-campaign Sybil review

estimated cost: $45 in proxy bandwidth, $89/month dolphin anty subscription (shared across all campaigns), roughly $120 in gas across the 40 wallets.

example 2: layerzero eligibility window (2024)

as mentioned in the intro, i ran 80 wallets. the 9 failures traced to two proxy sessions where i had been debugging a script issue and accidentally used the same sticky session for two different wallet profiles within the same day. the sessions were 4 hours apart but the exit IP matched across both.

the 71 successful wallets used the full isolation stack. each received an allocation. the aggregate allocation across 71 wallets was meaningful. the 9 failed wallets were allocated 0.

lesson: even a single IP collision, even hours apart, was enough for the clustering algorithm to link those wallets. the threshold was not “same IP at the same time.” it was “same IP at any point in the eligibility period.”

example 3: small protocol farming, 15 wallets, recent (2025)

for smaller protocols where the anti-Sybil analysis is less sophisticated, a lighter stack works fine. i run GoLogin’s $49/month plan for 100 profiles, use iproyal proxies at the lower price tier, and do less rigorous funding separation.

this is worth noting because operational cost scales with the stakes. spending $300/month on infrastructure for a protocol with a $50k total airdrop pool does not make sense. calibrate the stack to the likely return. for tier-1 protocols with $100M+ in expected airdrop value, run the full stack. for smaller experiments, a lighter setup is acceptable.

edge cases and failure modes

1. sticky session drift under load

already mentioned above, but worth emphasizing: sticky sessions are not guaranteed. if you are running many wallets simultaneously and your proxy vendor’s pool is under load, sessions can reassign exit nodes mid-use. the fix is to check exit IP before each transaction group, not just at session start. consider building a pre-flight check into any automation framework.

2. WalletConnect relay fingerprinting

when you connect a wallet to a dapp via WalletConnect, the relay server sees the connection request. the connection includes metadata about the client. some dapps and analysts have reportedly used WalletConnect session data as a clustering signal. the safest approach is to use direct browser wallet injection (MetaMask or Rabby extension inside the anti-detect browser) rather than WalletConnect wherever the dapp supports it. for mobile-first dapps where WalletConnect is the only option, this is harder to avoid. the folks at multiaccountops.com/blog/ have written on WalletConnect relay behavior and session metadata in more detail than i will here.

3. RPC provider correlation

if all 80 of your wallets hit the same public RPC endpoint (say, a shared Infura or Alchemy endpoint), and the RPC provider logs IP-to-wallet-address associations, that is a correlation source that exists outside your proxy infrastructure. use separate RPC endpoints per profile, or run your own node, or use per-profile RPC endpoints from a provider that does not aggregate logs. some operators use Ankr’s pay-per-call endpoints with separate API keys per wallet cluster. the Ethereum JSON-RPC specification is the underlying standard here, but the privacy properties depend entirely on the endpoint you call.

4. on-chain gas token sourcing

even with perfect network and browser isolation, if you gas up 20 wallets from Binance to the same deposit address in the same hour, you have created a chain-traceable link. exchange withdrawal patterns are one of the most common Sybil detection vectors because they are easy to analyze. use separate exchange accounts per wallet cluster, or use decentralized on-ramps, or bridge from different source chains with meaningful time separation between operations.

5. dapp front-end telemetry

modern dapp front-ends often include analytics SDKs (mixpanel, amplitude, segment) that send behavioral telemetry back to the protocol. this telemetry can include mouse movement patterns, session duration, click sequences, and sometimes client-side fingerprints beyond what the browser exposes via the standard APIs. blocking these telemetry calls entirely (via uBlock Origin within the anti-detect profile) is an option, but aggressive blocking can itself become a fingerprint signal if the baseline for the dapp is “almost all users have analytics enabled.” the safer approach is to allow analytics to run normally, which means your sessions need to look like human sessions with realistic dwell time and interaction patterns. for more on browser-level fingerprinting countermeasures, antidetectreview.org/blog/ has detailed comparisons of how different anti-detect browsers handle this.

what we learned in production

the biggest shift in my thinking after LayerZero was moving from “set it up once” to treating isolation as an ongoing operational checklist. you verify exit IPs before sessions. you audit funding paths before farming windows open. you run fingerprint consistency checks on profiles after updating the anti-detect browser (updates can reset or alter profile configurations in ways that are not obvious). isolation is not a configuration you apply once. it degrades if you do not maintain it.

the second lesson is that the weakest link is usually the human in the loop. automated scripts maintain consistent behavior. when i am manually testing a profile or debugging an issue, that is when shortcuts happen. using the host machine’s browser to check something “quickly” on a wallet that belongs to an isolated profile. connecting two wallets to the same WalletConnect session out of convenience. these are the moments that create the correlations that cluster detection finds. i now have a hard rule: any interaction with a farming wallet goes through its designated profile only, no exceptions. it sounds obvious but enforcing it consistently is harder than it sounds.

the economics of this approach are real. by may 2026, the infrastructure cost across my active campaigns runs around $200-300/month between anti-detect subscriptions and proxy bandwidth. that is a real operational cost that needs to factor into ROI calculations. for campaigns where the per-wallet expected value is less than $50, the math does not always work. concentrate the full stack on high-signal protocols with credible treasury and active user metrics, and run lighter configurations on exploratory farming. this is why i track campaign ROI per infrastructure dollar, not just in absolute terms.

the cluster-detection tools are also improving faster than the isolation tools. protocols are hiring firms with serious on-chain analytics capabilities. the graph analysis that LayerZero applied is table stakes now. future drops from well-funded protocols will almost certainly add additional clustering signals: behavioral biometrics, dapp session metadata correlation, bridging path analysis, and potentially coordination with other protocols to share Sybil lists. the operators who survive that environment will be the ones who have built isolation that is deep, consistent, and regularly audited, not just the ones who bought a proxy subscription and called it done.

there is also a community knowledge-sharing asymmetry worth noting. the protocols doing Sybil detection are not publishing their exact methodology. you are flying partially blind on what signals they are using. the conservative approach is to isolate against every possible signal, even the ones that seem unlikely, because the cost of isolation is low relative to the cost of getting a 0 allocation. if you want more discussion on current detection methodology, proxyscraping.org/blog/ covers proxy-level detection from the defensive perspective.

references and further reading

Ethereum JSON-RPC API documentation - the underlying standard for wallet-to-node communication, relevant for understanding RPC-level correlation risks.
LayerZero developer documentation - primary source for understanding the protocol’s own documentation and community governance, which includes historical context on their Sybil reporting process.
Bright Data residential proxy documentation - vendor documentation on sticky versus rotating session behavior, which directly affects isolation reliability.
Ethereum account model overview - useful reference for understanding the on-chain account structure that isolation strategies work around.
EFF’s Surveillance Self-Defense guide on browser fingerprinting - foundational reading on how fingerprinting works from a civil liberties research perspective, applicable to understanding what dapps can and cannot see.

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.