Building a sybil farming team: roles, tools, security

Running a solo farming operation has a ceiling. You can manage maybe 30-50 wallets before the coordination overhead eats your edge, and at that scale you’re still leaving substantial upside on the table compared to a coordinated team running hundreds of wallets with proper role separation. i’ve watched operators plateau at solo scale for months, convinced they were doing it “efficiently,” while teams with cleaner infrastructure were farming three to five times the wallet count with fewer mistakes.

The shift from solo to team farming isn’t just about headcount. it’s a structural change in how you think about risk, information flow, and operational security. when a solo farmer gets caught in a sybil sweep, they lose their wallets. when a poorly structured team gets caught, they can lose everything, including the wallets of people who trusted them with real capital. the stakes are categorically higher, and the failure modes are different. this guide covers what actually works at the team level, what blows up, and what i’ve had to learn the hard way running operations in Singapore and coordinating with contributors across Southeast Asia.

One more framing note before we get into structure: nothing in here advises circumventing KYC, impersonating real people, or any form of identity fraud. what we’re talking about is coordinating legitimate wallet infrastructure, task division, and operational hygiene for protocols that have publicly announced airdrop programs with no formal eligibility screening beyond on-chain activity. operating in gray areas requires clear thinking about where the lines are.

background and prior art

The concept of a Sybil attack comes from distributed systems research, named after the 1973 book about a woman with dissociative identity disorder. in networking terms, it describes a single actor controlling multiple identities to gain disproportionate influence. The original Sybil attack paper by John Douceur at Microsoft Research (2002) established the theoretical framework, and crypto protocols have been grappling with practical versions of it ever since. Gitcoin built an entire product, Gitcoin Passport, specifically to assign “humanity scores” to wallets so grant allocations couldn’t be dominated by Sybil clusters. that product is now used by a growing number of protocols as a gatekeeping layer for airdrop eligibility.

The farming community has been running multi-wallet operations since at least 2020, but the craft has matured significantly. early airdrop farmers on Uniswap and dYdX were running crude scripts with shared IP addresses and obvious on-chain fingerprints. the Arbitrum airdrop in March 2023 was a major inflection point: Arbitrum’s team published a detailed Sybil detection methodology that flagged wallets based on funding source, timing correlation, contract interaction overlap, and gas behavior. operators who survived that sweep had built clean separation. those who hadn’t lost weeks of work.

the core mechanism

A well-structured sybil farming team separates four functions that solo operators conflate: capital management, execution, identity management, and monitoring. when one person handles all four, any mistake in one area contaminates the others.

Capital manager. controls the funding wallets, the “root” addresses that seed individual farming wallets with gas and working capital. this role should never touch farming wallets directly. the flow is: CEX withdrawal to intermediate wallet, intermediate wallet to batch distributor, distributor to individual wallets. each hop adds separation. the capital manager decides allocation per wallet, approves top-ups, and tracks net capital deployed. in our setup this is a single person with hardware wallet signing (Ledger or Trezor), and they’re not involved in any execution.

Execution operators. these are the people actually doing transactions: bridging, swapping, providing liquidity, completing governance actions, whatever the protocol requires. execution operators work in isolated browser profiles with dedicated proxy assignments. they don’t know the funding path, they don’t share machines, and they don’t talk about wallet contents in any logged channel. each operator handles a fixed batch of wallets, typically 20-40 depending on protocol complexity. the goal is that if one operator’s opsec fails, the blast radius is contained to their batch.

Identity layer (social accounts). many protocols require Discord activity, Twitter/X engagement, or governance participation, not just on-chain transactions. managing these at scale requires a separate set of tooling and usually a dedicated person or two. this is where antidetect browsers become critical infrastructure. for a review of current antidetect options and how they compare on fingerprint quality, see our antidetect browser buyer’s guide. aged accounts, email separation, and profile warming schedules all live in this lane.

Monitoring and analytics. someone needs to watch for protocol announcements, snapshot blocks, eligibility criteria changes, and early Sybil filter signals. this role is often underinvested in small teams. in practice it means setting up Dune dashboards, watching governance forums, and maintaining a structured spreadsheet of wallet status per protocol. when a snapshot gets announced with 24 hours notice, the monitoring person is the one who catches it.

The communication layer tying all this together should be end-to-end encrypted and compartmentalized. we use Signal for async coordination, with separate group chats per protocol. no wallet addresses in group chats, ever. wallet inventories live in an encrypted spreadsheet (Cryptomator over a shared cloud volume) that only the capital manager and the relevant execution operator can access.

worked examples

Example 1: zkSync Era airdrop preparation (2023-2024)

zkSync Era was the most-anticipated airdrop of the 2023-2024 cycle. our team ran 180 wallets across four execution operators (45 wallets each). capital was seeded from two intermediate wallets, each funded from separate CEX accounts with a 10-day delay between funding events. total capital deployed was approximately $28,000 USD across all wallets, averaging about $155 per wallet for gas and protocol interactions.

Each wallet needed: multiple bridge transactions (we used the native zkSync bridge and Orbiter Finance), at least 3-5 DEX swaps on zkSync, some liquidity provision on SyncSwap, and ideally some contract deployment or NFT mint to show contract diversity. execution operators ran 4-6 hours per week per wallet batch, spread over three months. total team labor: roughly 800 operator-hours. the airdrop was delayed and ultimately distributed in June 2024. our team received allocations across 140 of 180 wallets (40 were flagged and excluded). at ZK’s initial price of around $0.30, those 140 wallets averaged roughly 2,100 ZK each, for about $630 per wallet. gross payout was approximately $88,200, against ~$28,000 capital and estimated $15,000 in labor cost at our internal rate. net positive, but the margin was tighter than expected due to the flagged wallets.

What got wallets flagged: post-mortem showed the 40 flagged wallets had funded from the same intermediate wallet within a 48-hour window and had near-identical interaction sequences. two operators had copy-pasted a task checklist literally rather than varying the order and timing.

Example 2: Hyperliquid (HYPE) November 2024

Hyperliquid’s airdrop was notable for being almost entirely on-chain based with no social requirements and no KYC. our team allocated 60 wallets to this one, operated by two people. the protocol required trading volume on the Hyperliquid perpetuals platform and some holding of USDC in the account. each wallet ran $500-$2,000 in trading volume over three months. the snapshot was unannounced.

All 60 wallets received allocations. HYPE launched at around $3 and quickly ran to $10+. average allocation per wallet was approximately 900 HYPE. at a conservative $5 average sale price, gross payout was $270,000 across 60 wallets, against roughly $8,000 in capital and $4,000 in labor. this was the cleanest operation we’ve run because the protocol had no social fingerprint requirements, the on-chain behavior was naturally varied by the trading activity itself, and there was no Sybil filter announcement to create last-minute scrambles.

Example 3: Across Protocol and smaller protocol farming

Not every protocol pays at Hyperliquid scale. Across Protocol’s airdrop in early 2024 was a useful comparison point. we ran 30 wallets, received allocations on 28 of them. average allocation was around $180 per wallet. total gross: ~$5,040, against roughly $2,000 in capital and $1,200 in labor. barely worth it in isolation, but operations like this run alongside larger targets, using the same infrastructure and operators in off-peak hours. the marginal cost of adding a small protocol to an existing operation is low if the infrastructure is already built.

The lesson here: portfolio the protocols, don’t mono-bet. a 30-wallet operation on Across as a side allocation to a larger zkSync run adds maybe 5% to operator workload and can materially improve total payout if the airdrop is generous.

edge cases and failure modes

1. Funding path contamination

The most common mistake i see in team setups is wallets that share a visible funding ancestor too close to the snapshot. on-chain analytics tools like Chainalysis and the open-source Ethereum tracing infrastructure make it trivial to walk a wallet’s funding history several hops back. a two-hop separation (root wallet to intermediate to farm wallet) is the bare minimum. three hops with timing variation and different intermediate wallet ages is better. the intermediate wallets should ideally have some “natural” activity, not just be pass-through addresses that receive and immediately redistribute.

Counter-strategy: treat the funding path as infrastructure you build months before you need it. intermediate wallets should be at least 90 days old and have some independent transaction history before they touch farming wallets.

2. Behavioral fingerprinting

Protocols and analytics firms have moved beyond simple clustering by funding source. they look at transaction timing patterns, contract interaction sequences, gas price behavior, and even the specific human-readable patterns in how someone builds a swap transaction. wallets operated by the same person at the same keyboard tend to show correlated timing patterns at the minute level. two wallets shouldn’t be doing transactions 30 seconds apart on the same protocol.

Counter-strategy: execution operators should work from randomized task lists, not sequential checklists. build timing jitter into your workflows. transaction spacing within a batch should vary by 15 minutes to several hours. some operators I know use basic scripts to randomize execution order per wallet per session.

3. Proxy and device fingerprint leakage

An antidetect browser without a dedicated, clean proxy is theater. if ten browser profiles share the same residential proxy exit IP, that’s a clustering signal. residential proxies are the baseline; datacenter proxies are flagged by most protocols immediately. the proxy-to-profile ratio should be 1:1 for high-value targets. for a deeper look at proxy sourcing and what to avoid, see proxyscraping.org’s residential proxy guide which covers the major providers and their traffic patterns.

Counter-strategy: assign proxies at wallet creation time and never rotate them mid-campaign. proxy geographic consistency should match the social account’s apparent region. for a single operation, buy enough proxy slots to cover your whole wallet count from day one.

4. Information leakage within the team

Teams fail on opsec not because of technical mistakes but because people talk. someone posts a wallet address in a group chat to “quickly check something.” someone screenshots their Dune dashboard and the wallet addresses are visible. someone uses a work laptop for farming and their corporate IT logs the traffic. these are the failure modes that matter at team scale.

Counter-strategy: clear rules, no exceptions. wallet addresses are never shared in any logged channel. protocol-specific channels contain no personally identifying information about which operator runs which batch. when in doubt, the communication rule is: treat every message as if it will be read by the protocol’s anti-Sybil team.

5. Cascade liquidation during volatile markets

Teams deploying capital into protocols that require liquidity provision or leveraged positions face market risk that solo farmers with smaller allocation often ignore. if you have 180 wallets each holding $200 in LP positions and the underlying asset drops 40%, you’re potentially looking at $14,400 in impermanent loss across the portfolio, before you factor in the airdrop value. teams sometimes end up in a position where the airdrop barely covers the protocol losses.

Counter-strategy: model the downside on capital deployment explicitly. for high-volatility assets, prefer stable pair LPs or protocols where the main activity is trading volume rather than passive liquidity provision. cap total capital per protocol at an amount you can afford to see go to zero.

what we learned in production

The biggest operational lesson from running a team versus solo is that your weakest link is almost always a human process, not a technical one. we had a perfectly clean technical setup on one campaign, dedicated proxies, hardware wallet signing, randomized execution, and we still had 15 wallets flagged because one operator had gone on vacation and handed his batch to a colleague who ran the entire 15-wallet sequence in a single afternoon from his home IP. one afternoon of laziness undid three months of careful setup.

The fix was structural: no wallet batch changes hands without a full handover protocol, including a one-week parallel observation period and explicit proxy reassignment. we also implemented a rule that no operator runs more than 10 wallets per session per day, with a hard stop. these constraints feel bureaucratic until you see what happens without them.

The second production lesson is about timing your exits. airdrop tokens drop in value quickly, often 50-80% in the first two weeks as farmers sell. the team needs a pre-agreed exit plan before the airdrop drops, not after. for our Hyperliquid positions, we agreed in advance on a tiered sell: 30% at market open, 40% over the following 48 hours via limit orders, 30% held for two weeks to see if price recovered. this prevented the coordination failure of different operators selling at wildly different times and getting different outcomes. pre-agreed exit rules are as important as pre-agreed entry strategies. for more on execution coordination and wallet management tooling at scale, see our multi-account operations guide and the broader multi-wallet strategy deep dive.

references and further reading

John Douceur, “The Sybil Attack,” Microsoft Research (2002) - the foundational academic paper defining Sybil attacks in distributed systems, required reading for understanding what protocols are actually defending against.
Gitcoin Passport documentation - the leading on-chain identity verification system used by protocols to screen for Sybil wallets. understanding how it scores wallets helps you understand what “legitimacy signals” protocols look for.
Ethereum.org developer documentation - the primary reference for understanding how Ethereum accounts, transactions, and contract interactions work at a protocol level, relevant for understanding on-chain fingerprinting.
Chainalysis blockchain analytics - the leading commercial blockchain analytics firm. their public blog covers clustering methodologies and how on-chain entities are identified, which directly informs what anti-Sybil filters look for.
Arbitrum Foundation governance and airdrop documentation - the Arbitrum airdrop was a watershed moment for Sybil detection methodology. the foundation’s published criteria set the standard that many subsequent protocols have followed or exceeded.

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.