Skip to content

Airdrop Development

In short

An airdrop is a distribution problem: eligibility, a push or Merkle-claim mechanism, sybil resistance, optional vesting, and gas at scale. We build all of it, with open-source distribution tooling (disperse2) and Merkle-claim engineering behind us. Contracts hardened before audit.

$2B+
assets secured
0
vulnerabilities across delivered projects
250+
projects since 2016
1M+
developers (Solhint)
Trusted by teams building on-chain

Getting a token to thousands or millions of addresses safely is harder than it looks. It means deciding who qualifies, choosing how the tokens move (a direct send or a claim), keeping the distribution from being drained or farmed, and doing it all without a gas bill that dwarfs the drop.

The failures are public: a claim contract that double-pays, an eligibility list gamed by sybils, or a distribution that runs out of gas halfway through.

Protofire has shipped 250+ blockchain projects since 2016, and moving tokens to large recipient sets safely is tooling we build and maintain. Our open-source disperse2 does multisend to thousands of addresses and handles non-standard tokens like USDT that break naive implementations, and we build the Merkle-proof claim contracts that make large drops gas-efficient.

This page is about distribution mechanics; the token itself and its vesting design are covered separately, and airdrops are usually one piece of a broader launch.

We build the distribution you need: a one-off airdrop with the eligibility, claim, and vesting around it, or a repeatable distribution system. We maintain Solhint, the Solidity linter used by 1M+ developers, so the contracts moving tokens to real users are held to the standard the ecosystem checks against.

What an airdrop actually requires

The eligibility, the claim mechanics, and the gas at scale are where an airdrop is actually engineered.

01

Eligibility

The snapshot and rules that decide who qualifies: on-chain activity, holdings, allowlists, and sybil filtering, computed off-chain and committed on-chain.
02

Distribution method

Push (direct multisend) or pull (a claim contract with a Merkle root), chosen for the recipient count, gas budget, and UX.
03

Claim contract

A gas-efficient Merkle-proof claim so recipients pull their tokens, with the eligibility root fixed and verifiable on-chain.
04

Vesting

Optional cliffs and linear or streaming unlocks on claimed tokens, so a drop does not all sell at once.
05

Gas & scale

Batching, L2, and gasless-claim options that keep a distribution to thousands or millions of addresses affordable and reliable.
01

What airdrop development covers

Push vs pull distribution

Two ways to move tokens: push (you send tokens directly to every address) or pull (recipients claim from a contract). Push is simple and good for smaller, known lists; our open-source disperse2 does multisend to thousands of addresses in batches. Pull scales better for large or open drops and shifts the gas to whoever claims. We build both and choose based on your recipient count, gas budget, and whether the list is fixed or open.

Merkle airdrops

For large distributions, a Merkle airdrop is the standard: the full eligibility list is hashed into a single root stored on-chain, and each recipient claims by submitting a proof. It keeps on-chain cost flat regardless of list size and makes eligibility verifiable without publishing the whole list on-chain. We build the claim contract, the off-chain list and proof generation, and the safeguards against double-claims and malformed proofs.

Eligibility & sybil resistance

An airdrop is only as good as its eligibility. We build the snapshot logic (on-chain activity, holdings, and behavior over a time window), allowlist handling, and sybil-resistance filtering that keeps a drop from being farmed by thousands of throwaway wallets. The rules are computed off-chain and committed on-chain as a fixed root, so the eligibility cannot be quietly changed after the fact.

Vesting & streaming airdrops

A drop that fully unlocks on claim is often sold the moment it lands. We build vesting into the claim so tokens release on a cliff and linear schedule, or stream continuously, keeping recipients aligned past the first block. Vesting-at-claim contracts are the same discipline we apply to token allocations, applied to the airdrop.

Gas at scale & non-standard tokens

A distribution to hundreds of thousands of addresses can cost more in gas than the tokens are worth if it is built naively. We keep it affordable with batching, Merkle-claim (gas paid by claimers), L2 deployment, and gasless-claim options, and we handle the tokens that break simple code: non-standard ERC-20s like USDT that do not return a boolean, which our disperse2 tooling already accounts for.

Claim UX

If recipients cannot claim, the airdrop fails no matter how good the contract is. We build the claim interface: wallet connection, eligibility check, proof submission, and clear states for eligible, already-claimed, and not-eligible, so recipients actually receive what they earned.

02

How an engagement works

1

Snapshot & eligibility

We define who qualifies and when: the snapshot block, the on-chain criteria, allowlists, and sybil filters, and we generate the eligibility list and Merkle root. Deliverable: a verifiable eligibility set and a distribution plan.
2

Build & test

The claim or multisend contracts, the vesting logic, and the claim frontend, built, tested against double-claims, malformed proofs, and gas at scale, and hardened ahead of an external audit.
3

Distribute & support

Deployment, the claim window with monitoring, support through the distribution, and reporting on claim rates, with the eligibility root and results verifiable on-chain.
03

What teams build airdrops for

A Merkle-claim airdrop to thousands or millions of addresses
Sybil-resistant eligibility from an on-chain snapshot
A direct multisend to a known recipient list
Vesting on claimed tokens so a drop does not dump
Gas-efficient or gasless claiming at scale
A claim frontend recipients can actually use
04

Distribution mechanics we run

Protofire has shipped 250+ blockchain projects across 60+ networks since 2016, and getting tokens to a lot of addresses safely is tooling we build and maintain. Our open-source disperse2 does multisend to thousands of addresses in batches and, importantly, handles non-standard tokens like USDT that do not follow the ERC-20 return convention and break naive multisend code.

We build Merkle-proof claim contracts for large drops, the sybil-resistant eligibility behind them, and the vesting-at-claim that keeps a distribution from all hitting the market at once, the same discipline we apply to token allocations and launch mechanics. Because we secure $2B+ across delivered projects with zero vulnerabilities and maintain Solhint, the linter 1M+ developers rely on, the contracts moving tokens to real users start from the standard the ecosystem sets.

“A Merkle claim keeps a million-address drop about as cheap as a small one.”

Open source we’ve shipped

The Protofire repositories behind this page

disperse2

→

Airdrop and multisend distribution, handles non-standard tokens like USDT

Part of 190+ open-source repositories from Protofire

Distribution methods we build

MethodWho pays gasScales toRecipient actionBest for
Push (multisend)You (the sender)ThousandsNone, tokens arriveSmaller, known recipient lists
Pull (Merkle claim)The claimerMillionsSubmit a claimLarge or open eligibility sets
Gasless claimSponsored via paymasterLargeSign, no gasConsumer drops removing all friction

FAQ

What is airdrop development?
Airdrop development is building the system that distributes a token to many addresses safely and affordably. It involves several parts: eligibility (deciding who qualifies, usually from an on-chain snapshot plus allowlists and sybil filtering), a distribution mechanism (a direct multisend push, or a pull-based claim contract with a Merkle root), optional vesting so claimed tokens do not all unlock at once, gas engineering so a large drop stays affordable, and a claim frontend recipients can actually use. Each of these is a place an airdrop can fail if it is not engineered carefully. Protofire builds all of it, drawing on open-source distribution tooling we maintain (disperse2) and Merkle-claim engineering, so the drop is designed against those failure modes rather than assembled from a template.
Should we use a direct send (push) or a claim (pull) airdrop?
It depends on the size and openness of the distribution, and we help you choose. A push airdrop sends tokens directly to every eligible address; it is simple, requires nothing from recipients, and works well for smaller, known lists, and our open-source disperse2 handles the multisend in batches including for non-standard tokens like USDT. A pull airdrop has recipients claim from a contract, usually via a Merkle proof; it scales to millions of addresses because on-chain cost stays flat regardless of list size, and it shifts gas to whoever claims rather than you paying for everyone, including addresses that never engage. The trade-off is that pull requires recipients to take an action and a claim frontend to support it. For large or open drops we almost always recommend a Merkle claim; for a bounded, known list a push can be simpler and a better experience.
How do you prevent sybil attacks and farming?
Sybil resistance is designed into the eligibility, because an open airdrop with weak rules is an invitation to thousands of throwaway wallets farming the drop. We build eligibility from an on-chain snapshot over a time window rather than a single moment, so genuine activity is distinguishable from last-minute gaming, and we combine on-chain behavior (holdings, activity, and interaction patterns), allowlists, and heuristics that filter clustered or automated wallets. The rules are computed off-chain and committed on-chain as a fixed Merkle root, so eligibility is transparent and cannot be quietly changed after the fact. No filter is perfect against a determined farmer, so we scope the trade-off with you (stricter rules exclude some real users, looser rules admit more sybils) and design the criteria to fit what the drop is actually rewarding, rather than promising a sybil-proof list that does not exist.
Can you vest the airdrop so it does not immediately sell?
Yes, and for most drops it is worth doing. A distribution that fully unlocks the moment it is claimed is often sold immediately, which hurts the token and the recipients who hold. We build vesting into the claim contract, so tokens release on a cliff and linear schedule or stream continuously after claiming, keeping recipients aligned past the first block. The schedule is enforced on-chain and visible, so recipients know exactly what unlocks when. This is the same vesting discipline we apply to team and investor token allocations, applied to a much larger set of addresses, and we design the schedule to match what the airdrop is meant to achieve, whether that is rewarding past users, bootstrapping governance participation, or seeding liquidity, rather than a one-size default.
How do you handle gas for a very large airdrop?
By choosing a mechanism that keeps cost proportional to the drop rather than the list size. A naive push to hundreds of thousands of addresses can cost more in gas than the tokens are worth, so for large drops we use a Merkle claim, where the on-chain cost is a single root plus each recipient's own claim gas, meaning you are not paying to send tokens to addresses that never engage. We also deploy on L2s where gas is a fraction of mainnet, batch operations where a push makes sense, and can add gasless claiming through a paymaster so recipients claim by signing without holding gas at all. And we handle the tokens that break simple distribution code, non-standard ERC-20s like USDT, which our disperse2 tooling already accounts for. We scope the gas model against your recipient count and budget in the design phase, so the distribution is affordable before it is built.
Do you build the claim frontend and handle non-standard tokens?
Yes to both. The claim frontend is where airdrops succeed or fail in practice: we build the interface that connects a wallet, checks eligibility against the Merkle root, submits the proof, and shows clear states for eligible, already-claimed, and not-eligible, so recipients actually receive what they earned rather than bouncing off a broken page. On tokens, we handle the ones that break naive distribution code: several widely used ERC-20s, USDT being the classic example, do not return a boolean on transfer, so multisend and claim code written to the strict standard reverts on them. Our open-source disperse2 already accounts for these non-standard tokens, and we carry that handling into claim contracts, so your distribution works with the token you actually have rather than only the idealized version. We test the whole flow against these edge cases before an audit.

Reviewed by Luis Medeiros, Field CTO at Protofire. Last reviewed: August 2026.

Book a call with Alejandro Losa

Schedule a call with our Web3 Solution Architect to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved

Message us on Telegram