Writing a runbook so your airdrop farm survives you being away

Most airdrop farms live inside one person’s head. The wallet naming scheme, which proxy goes with which wallet, why a certain device stopped getting used, what “done for the week” means for a given chain. None of that is written down, because writing it down feels like busywork when you’re the only one who needs it. Then you go on a trip, get sick, or hand a chunk of the farm to someone else, and the whole thing stalls or gets run wrong. A runbook is the fix. It’s a boring document, and that’s the point.

This isn’t about automation scripts or bots. It’s about writing down the operational knowledge that currently only exists as habit, so the farm keeps running correctly (or stops cleanly) when you’re not the one at the keyboard.

Why a spreadsheet isn’t a runbook

A spreadsheet of wallets and balances tells you what exists. A runbook tells you how to operate it. Those are different documents and farms usually only have the first one.

The spreadsheet answers “how many wallets do I have on this chain.” The runbook answers questions like: what’s the minimum gap between transactions on a wallet, what happens if a proxy drops mid-session, which wallets are paired with which browser profiles and why, and what the sign that something’s gone wrong actually looks like. If you disappeared for two weeks, a spreadsheet lets someone see the farm. A runbook lets them keep it from breaking.

What actually breaks when nobody’s watching

Think through what has gone wrong on your own farm in the past, not hypothetically. Common failure points:

A proxy or SIM rotates or drops, and traffic that used to come from one IP suddenly comes from another, on a wallet that had a consistent fingerprint for months.
A browser profile gets reused for the wrong wallet because two profiles look identical in a launcher list.
A device (phone or VM) needs a reset or reprovision, and whoever does it doesn’t know it was tied to specific wallets, so the pairing gets scrambled.
Someone bridges or swaps on a schedule that doesn’t match the rest of that wallet’s history, because they didn’t know there was a pattern to keep.
A wallet that should have gone quiet for the season keeps getting used, because nobody wrote down that it was supposed to stop.

None of these are exotic. They’re the kind of thing that happens automatically when one person is holding the whole picture in memory and that person steps away. A runbook exists to move that picture out of your head and onto a page.

The core sections a farm runbook needs

Inventory and pairing. Every wallet, which device or profile it runs from, which proxy or connection it’s paired with, and which chains or protocols it’s active on. Not balances, not yield, just the operational pairing. This is the section someone reads first when they need to touch the farm.

Cadence rules. For each wallet or wallet group, what does normal activity look like: rough frequency, what kind of actions, what a quiet period looks like versus a dormant one. Write this as a description of the existing pattern, not as a target to hit. The goal is continuity of the wallet’s own history, not a schedule to force new wallets into.

What not to do. This section matters more than people expect. Write down the mistakes that are easy to make and hard to undo: don’t reuse a proxy across wallets that have never shared one, don’t move funds between wallets in the same cluster on the same day, don’t reset a device without checking what it was tied to first. A runbook that only says what to do leaves all the failure modes to be discovered the hard way.

Escalation and stop conditions. What does “something’s wrong, stop and wait” look like for this farm. Examples: a wallet gets flagged or delisted somewhere, a proxy provider has an outage, a chain does something unusual (a fork, a sudden gas spike, a protocol pause). Write down who or what decides to pause, and what “paused” actually means operationally (do sessions stay open, do you rotate everything, do you just stop touching it).

Where the keys and credentials live. Not the keys themselves. The runbook should say where credentials are stored (a password manager, a specific vault) and who has access, not contain the secrets inline. A document that gets shared, printed, or copied into a chat is a bad place for a private key.

Why the pairing logic deserves its own attention

Chain analysis firms build wallet clusters mostly from behavioral overlap, not magic. Funding patterns that trace back to a shared source, timing that lines up too consistently across “separate” wallets, identical transaction sequences, and infrastructure reuse (the same IP, the same browser fingerprint, the same device) showing up across wallets that are supposed to look unrelated. None of this requires anything exotic on the clustering side. It’s pattern matching across public and semi-public signals.

That’s exactly why a runbook matters here. The defense against clustering isn’t a trick, it’s discipline: keeping wallet-to-proxy and wallet-to-device pairings stable and distinct, not funding a batch of wallets from one source in a tight window, and not running identical action sequences across wallets at the same time. Those are policies, and policies drift the moment they’re not written down. The person who covers for you while you’re away doesn’t know that wallet 14 always uses its own dedicated exit and never touches the shared pool, unless the runbook says so.

This also isn’t a promise that following any of it prevents flags or clustering. Chain analysis has gotten better over time and there’s no configuration that guarantees a wallet reads as unrelated to others. The runbook’s job is to keep you consistent with whatever operational separation the farm already had, so a gap in coverage doesn’t introduce a new pattern that wasn’t there before.

Tooling notes belong in the runbook, not just in your head

If the farm depends on specific tools (an anti-detect browser for profile isolation, a particular RPC provider, a tracker for keeping tabs on eligibility windows), the runbook should note which tool is used for which purpose and why, plus any quirks you’ve actually hit. Not a review, just operational notes: this browser profile setup takes a few minutes to load correctly, this RPC provider has had brief outages before so a stalled transaction isn’t automatically a wallet problem, this tracker’s alerts are sometimes late so don’t treat silence as “nothing happening.” Write down what you’ve observed, not a verdict on whether the tool is good. That distinction keeps the runbook honest and keeps you from having to defend a claim you didn’t actually verify.

Test it before you need it

A runbook that’s never been used by anyone but its author isn’t tested. Before you actually rely on it, hand it to someone else, or to yourself after a week away from the farm, and have them (or you) try to operate from the document alone. The gaps show up fast: a pairing that’s obvious to you but undocumented, a step you do automatically that isn’t written anywhere, a term you use that means something specific but isn’t defined. Fix those, then treat the document as current until something about the farm changes.

Keep it current or don’t keep it at all

An out-of-date runbook is worse than no runbook, because it gives false confidence. Whoever follows it will trust it over their own judgment. Update it when a wallet’s status changes, when a proxy or device gets swapped, when a chain does something that changes your cadence. It doesn’t need to be elaborate. A dated changelog at the top, even three lines a month, is enough to know the document is still trustworthy.

None of this replaces judgment. A runbook is a record of decisions you’ve already made and the reasoning behind them, so the next person (including future you) isn’t starting from zero.

For more on running airdrop farms as an operation instead of a guessing game, including how we review the anti-detect browsers, RPC providers, wallets, and trackers we actually use, head back to the Airdrop Farming home page.

Get new guides and videos first — join the Telegram channel.