Guide: How to handle multi-claim airdrops with shared wallets
Guide: How to handle multi-claim airdrops with shared wallets
running airdrops across a wallet set is manageable when you’re solo. the moment you bring in a partner, a virtual assistant, or a small team sharing access to the same wallets, coordination breaks down fast. someone claims early and burns gas on a wallet another person planned to use for a different snapshot. the consolidation sweep happens before the claim window closes. two people try to send from the same address at the same moment and both transactions revert. i’ve seen all of these happen in team setups that looked fine on paper.
this guide is for operators who are running multi-claim airdrop campaigns, meaning multiple wallets all eligible for the same drop, and who share access to those wallets with at least one other person or automated process. it covers how to structure wallet ownership, coordinate claim windows, manage gas without stepping on each other, and sweep rewards cleanly. if you’re a solo operator with 20+ wallets, most of this still applies since you’re essentially coordinating with your past and future self.
by the end you’ll have a system preventing double-spend collisions, keeping a clean claim record per wallet, and scaling to larger sets without proportional overhead.
what you need
- wallet infrastructure: a set of EOA wallets (externally owned accounts) or a Safe multisig for high-value shared custody. for most operations, EOAs with private keys stored in a password manager or hardware wallet are sufficient.
- tracking spreadsheet or database: Google Sheets works at small scale. at 50+ wallets i’d move to Notion or Airtable. at 200+ you want a lightweight sqlite or postgres db.
- RPC provider: Alchemy or Infura free tier handles low volume. paid plans start around $49/month on Alchemy Growth. use separate API keys per operator to isolate rate limits.
- gas wallet: one dedicated wallet per chain that holds only gas (ETH, MATIC, BNB, etc.), refilled manually. never mix gas funds with farmed assets.
- claim coordination tool: a shared doc, a Telegram group with pinned claim statuses, or a simple task tracker. the exact tool doesn’t matter, the discipline does.
- consolidation script: a basic ethers.js or web3.py script to sweep ERC-20 tokens from multiple wallets to one destination. i’ll include a template in the steps below.
- anti-detect browser (optional but useful for team setups): if your teammates are logging into web-based claim UIs, browser fingerprint collisions across shared sessions can trigger fraud flags. the guides at antidetectreview.org/blog/ cover which profiles to use per wallet in these setups.
costs to budget: RPC at $0-$49/month, gas (variable, budget 0.01-0.05 ETH per wallet per claim on mainnet, much less on L2s), hardware wallet if custody is shared ($79-$149 for a Ledger Nano S Plus).
step by step
step 1: assign wallet ownership before the claim window opens
before any claim is live, every wallet in your set needs a single designated “owner” for that campaign. this doesn’t mean the private key belongs to that person, it means that person is the only one who initiates transactions from that address during this campaign. document it in your tracker with columns: wallet address, assigned operator, chain, claim status (unclaimed / claimed / failed / swept).
expected output: a spreadsheet where every row has a clear owner. no ambiguity.
if it breaks: if two operators are listed or the column is blank, stop and resolve before the claim window opens. ambiguous ownership is the root cause of most coordination failures.
step 2: set up a gas distribution wallet per chain
create one wallet per chain that exists solely to fund gas. load it with enough native token to cover all wallets in your set. for 50 wallets on Arbitrum claiming a simple ERC-20, budget around 0.002 ETH each plus 20% buffer. for mainnet ETH, multiply by 10-15x depending on current gas prices. you can check live estimates using Ethereum’s gas documentation for how gas is calculated, then check a gas tracker for live gwei.
distribute gas to each wallet before the claim window opens. do not wait until the day of, you will either rush or overpay.
expected output: each wallet in your set has enough native token to execute exactly one claim plus one transfer out.
if it breaks: if gas distribution transactions are pending or stuck, check that you’re not using too low a gas price. on L2s this is rarely an issue but on mainnet during high activity periods you may need to set a manual max fee.
step 3: lock the claim order before anyone starts
in your tracker, assign each wallet a claim slot: a time window or a sequence number. “wallet A claims between 09:00-09:30 SGT, wallet B claims 09:30-10:00 SGT” is one approach. another is batching by operator: operator 1 handles wallets 1-25, operator 2 handles wallets 26-50. the point is preventing two people from submitting transactions from the same wallet simultaneously.
for team communication i use a Telegram group with a pinned message that operators update as they claim. format: 0xabc...def | CLAIMED | 09:14 | tx: 0x123
expected output: a sequential or batched claim schedule that every operator has confirmed they understand.
if it breaks: if someone claims out of order and creates a nonce conflict (two pending transactions from the same wallet), you’ll need to cancel the lower-priority one by sending a 0 ETH transaction to yourself with the same nonce and a higher gas fee. MetaMask’s documentation covers how to do this manually through the advanced transaction settings.
step 4: execute claims and update the tracker in real time
each operator works through their assigned wallets, claiming and immediately updating the shared tracker. do not batch-update at the end of your session, the whole point of live tracking is that other operators can see what’s done.
# example tracker update format (for a shared google sheet via python)
import gspread
gc = gspread.service_account(filename='service_account.json')
sh = gc.open("airdrop_tracker")
ws = sh.worksheet("campaign_xyz")
# find row by wallet address, update status
cell = ws.find("0xYOUR_WALLET_ADDRESS")
ws.update_cell(cell.row, 4, "CLAIMED")
ws.update_cell(cell.row, 5, "2026-05-19 09:14")
ws.update_cell(cell.row, 6, "0xTX_HASH_HERE")
you don’t need to automate this at under 50 wallets. but at 200+, automating the tracker update from your claim script reduces errors under pressure.
expected output: tracker shows real-time claim status. at the end of the window, every wallet is either CLAIMED, FAILED, or deliberately skipped with a reason noted.
if it breaks: if a claim transaction fails (contract reverted, insufficient gas, wrong merkle proof), mark it FAILED in the tracker immediately and note the error. do not retry without diagnosing. most failures are either “already claimed” (someone else already submitted from this address) or “not eligible” (the wallet didn’t meet the snapshot criteria).
step 5: run a cross-check before closing the claim window
before the deadline, run a cross-check: pull the on-chain claim status for every wallet in your set and compare against your tracker. most protocols expose a hasClaimed(address) view function on the distributor contract. you can query this in bulk with a short script.
const { ethers } = require("ethers");
const provider = new ethers.JsonRpcProvider("YOUR_RPC_URL");
const distributor = new ethers.Contract(
"DISTRIBUTOR_CONTRACT_ADDRESS",
["function isClaimed(uint256 index) view returns (bool)"],
provider
);
const indices = [0, 1, 2, 3]; // wallet indices from merkle tree
for (const idx of indices) {
const claimed = await distributor.isClaimed(idx);
console.log(`index ${idx}: ${claimed ? "claimed" : "unclaimed"}`);
}
expected output: every wallet marked CLAIMED in your tracker returns true on-chain. any mismatches need immediate attention.
if it breaks: if your tracker says claimed but the contract says unclaimed, the transaction likely failed silently or was dropped. check the tx hash on the block explorer. if it never confirmed, you may still have time to retry.
step 6: consolidate rewards to a cold wallet
once the claim window has closed and all wallets are in CLAIMED or FAILED status, sweep the tokens. use a consolidation script that iterates through each wallet and transfers the full token balance to your designated cold wallet.
const { ethers } = require("ethers");
const TOKEN_ADDRESS = "0xTOKEN_CONTRACT";
const DESTINATION = "0xCOLD_WALLET";
const wallets = [
{ address: "0xWALLET1", privateKey: "0xPRIVKEY1" },
// ...
];
const provider = new ethers.JsonRpcProvider("YOUR_RPC_URL");
const tokenAbi = ["function transfer(address to, uint256 amount) returns (bool)",
"function balanceOf(address) view returns (uint256)"];
for (const w of wallets) {
const signer = new ethers.Wallet(w.privateKey, provider);
const token = new ethers.Contract(TOKEN_ADDRESS, tokenAbi, signer);
const balance = await token.balanceOf(w.address);
if (balance > 0n) {
const tx = await token.transfer(DESTINATION, balance);
await tx.wait();
console.log(`swept ${balance} from ${w.address} | tx: ${tx.hash}`);
}
}
run this during low-traffic hours to keep gas costs down. on L2s like Arbitrum or Base, timing matters less. on mainnet, sweeping during the weekend typically saves 30-50% on gas.
expected output: destination cold wallet holds the full consolidated token balance. all source wallets show zero token balance.
if it breaks: if a transfer reverts with “insufficient gas”, the gas wallet may have run dry after the claim transactions. top it up and retry.
step 7: archive the campaign in your tracker
after consolidation, mark the campaign as complete in your tracker. archive the sheet or tag the database rows. record: total wallets claimed, total tokens received, total gas spent, net value at time of sweep. this data is useful for projecting future campaign economics and (if you’re in a jurisdiction where this is taxable) for keeping records. note: this is not tax advice, consult a qualified accountant in your jurisdiction.
expected output: a clean archived record you can reference in three months when the token has vested and you need to look up your cost basis.
common pitfalls
not locking the nonce before shared access: if two operators try to submit from the same wallet seconds apart, you get a nonce collision. one transaction confirms, the other reverts. solve this with strict per-wallet operator assignment, not trust.
using the same RPC endpoint for all operators: shared RPC endpoints under one API key can hit rate limits mid-campaign. give each operator their own Alchemy or Infura key.
sweeping before the claim window closes: some protocols allow late claims or have extended windows. sweeping early doesn’t cause problems on its own, but if you accidentally moved the gas token you may not be able to claim a straggler wallet. run the cross-check first.
mixing gas and reward tokens in the same wallet: when you’re rushing during a claim window it’s tempting to keep everything in one place. don’t. separate gas wallets give you clean accounting and prevent accidentally sweeping gas funds.
no written handoff between operators: verbal coordination via voice chat works until someone drops off mid-session. always have a written record. the Telegram pin or shared tracker is the source of truth, not anyone’s memory.
scaling this
10 wallets: a Google Sheet and a Telegram group message per claim is enough. manual everything.
100 wallets: you need the database-backed tracker and the automation script for cross-checks. manual claiming is still viable if you have 2-3 operators with clear batches. budget 4-6 hours for a full claim session per campaign. at this scale, browser profile management becomes relevant if claims happen through web UIs. the team at multiaccountops.com/blog/ covers fingerprint isolation patterns that hold up at this size.
1000 wallets: manual claiming is no longer viable. you need a claim bot that reads from your database, submits transactions with appropriate gas settings, handles retries on failure, and writes results back to the database. this is a full engineering project. you’ll also need multiple RPC endpoints across providers to handle the transaction volume without hitting rate limits. gas management becomes its own subsystem, with auto-refill logic triggered when a wallet’s native balance drops below a threshold. at this scale, the coordination overhead shifts from human coordination to infrastructure reliability.
where to go next
- How to build a wallet tracker for airdrop eligibility checks: covers querying merkle trees and snapshot data in bulk before campaigns go live, so you know exactly which wallets to prioritize.
- Guide: Setting up RPC rotation for high-volume wallet operations: once you’re past 100 wallets, single-provider RPC is your bottleneck. this guide walks through load-balanced RPC setups.
- Back to the full article index for all operator guides.
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.