How to Airdrop Tokens to NFT Holders

Why Airdrop Tokens to NFT Holders

The relationship between NFT communities and token launches is well-established in crypto. Projects like Bored Ape Yacht Club (which airdropped ApeCoin to BAYC holders), Pudgy Penguins, and dozens of other successful collections have used NFT holder airdrops to launch tokens with immediate distribution and community support. The pattern works because NFT holders are already invested — financially and emotionally — in the project's success.

From a distribution perspective, airdropping to NFT holders solves the cold start problem that plagues new tokens. Instead of launching a token to zero holders and hoping people buy, you launch to a known set of supporters who immediately have a stake. This creates initial trading activity, DEX liquidity interactions, and DexScreener visibility from day one.

The airdrop also functions as a marketing event. Announcing an upcoming airdrop to NFT holders generates social media buzz, increases NFT floor prices (as people buy to qualify), and attracts attention from traders and media who cover airdrop opportunities. The anticipation cycle drives organic growth for both the NFT collection and the upcoming token.

For projects building utility tokens, the NFT-to-token pipeline creates a natural ecosystem. NFT holders receive governance tokens, staking tokens, or utility tokens that provide additional functionality within the project. This layered ownership model (NFTs for identity/access, tokens for governance/utility) has become the standard architecture for crypto-native communities in 2026.

How to Snapshot NFT Holders

The technical process for snapshotting depends on the chain and NFT standard. On EVM chains (Ethereum, Base, Arbitrum, Polygon), you query the NFT contract's ownership mapping at a specific block height. For ERC-721 contracts, the ownerOf(tokenId) function returns the current holder of each token. For ERC-1155 contracts, the balanceOf(address, tokenId) function returns how many of each token ID a specific address holds.

Several tools simplify this process. Alchemy's NFT API provides a getOwnersForCollection endpoint that returns all current holders of an NFT contract in a single call. Moralis offers similar functionality with cross-chain support. The Graph protocol allows you to write custom subgraph queries that capture holder data at any historical block. For Solana NFT collections (Metaplex standard), Helius and Magic Eden APIs provide collection holder data.

The practical steps are as follows. First, announce the snapshot date and block number to your community in advance — typically 48-72 hours before the snapshot. This gives legitimate holders time to ensure their NFTs are in their own wallets (not listed on a marketplace or held in a lending protocol). Second, at the target block, execute your snapshot query and export the results. Third, verify the data by spot-checking several known holders. Fourth, publish the snapshot data (or a Merkle root of the data) so holders can verify their inclusion.

A critical detail: exclude NFTs held by marketplace contracts, lending protocol contracts, and other smart contracts that are not end-user wallets. When an NFT is listed on OpenSea, it may be held by the OpenSea contract rather than the seller's wallet. These contract addresses should be filtered out to prevent tokens from being sent to inaccessible addresses. Most NFT API services flag contract addresses, making this filtering straightforward.

Filtering Your Holder List

The first filter should remove all non-wallet addresses. This includes marketplace contracts (OpenSea, Blur, LooksRare), lending protocol contracts (NFTfi, BendDAO), bridge contracts, and the zero address (0x000...000). These addresses cannot meaningfully receive and use airdropped tokens. Most snapshot tools flag contract addresses automatically, but manual verification of the largest holders is recommended since new contracts appear regularly.

Quantity-based filtering is common for collections where some holders own many NFTs while others own one. You might set a minimum threshold (e.g., must hold at least 2 NFTs to qualify) to focus the airdrop on more committed holders. Alternatively, you might create a proportional distribution where the airdrop amount scales with the number of NFTs held — a holder with 10 NFTs receives 10x the tokens of a holder with 1 NFT.

Trait-based filtering allows you to target specific subsets of your collection. For example, you might airdrop only to holders of "legendary" rarity NFTs as a premium reward, or target holders of a specific trait that relates to the token's utility. This requires accessing each NFT's metadata (traits, attributes, rarity score) and joining it with the holder data. The result is a filtered list that targets exactly the audience segment you want to reward.

Activity filtering removes wallets that appear abandoned. Check each address for recent transaction activity (within the last 30-90 days) on the target chain. Sending tokens to wallets that have not transacted in months is wasteful — those tokens will sit unclaimed, reducing the effective circulating supply and potentially creating confusion about the token's holder count. Blockchain explorers and analytics APIs make activity checks straightforward to batch-process.

Preparing the CSV Distribution File

The CSV file should contain two columns with no headers: the first column is the recipient address, and the second column is the token amount. For EVM tokens, use the full token amount with decimal places (e.g., 1000.5 for 1000.5 tokens). For Solana SPL tokens, the same format applies. A sample row looks like: 0x742d35Cc6634C0532925a3b844Bc9e7595f2bD18,1000

Amount calculation depends on your distribution model. Common approaches include: flat distribution (every qualifying holder receives the same amount), proportional distribution (amount scales with number of NFTs held), tiered distribution (different amounts for different holder categories like whale/regular/new), and rarity-weighted distribution (rarer NFTs receive larger allocations). Calculate amounts in a spreadsheet before exporting to CSV to avoid errors.

Decimal handling is a common source of errors. If your token has 18 decimals (standard for ERC-20), you can specify amounts in human-readable format (e.g., 1000 for 1000 tokens) — most distribution tools handle the decimal conversion automatically. However, verify this with your chosen tool before executing. Sending 1000 when you meant 0.001 (because decimals were not accounted for) is an expensive and irreversible mistake.

Deduplication is essential. If a wallet holds multiple NFTs and you are doing a proportional airdrop, ensure the CSV has one row per wallet with the total amount, not multiple rows for the same wallet. Multiple rows for the same address will result in multiple separate transfers, each incurring gas costs. Consolidating into one transfer per wallet reduces total gas by 30-50% for distributions with many multi-NFT holders.

Before executing, validate your CSV. Check that all addresses are valid (correct length, correct checksum for EVM), that amounts are positive numbers, that total distribution matches your intended allocation, and that no single address is receiving an unexpectedly large amount (which might indicate an error). A few minutes of validation prevents costly mistakes in an irreversible on-chain distribution.

Choosing Your Distribution Method

Direct push distribution is the simplest approach: you send tokens directly to each holder's wallet. The tokens appear in their wallet without any action required on their part. This provides the best user experience (holders receive tokens automatically) but is the most expensive because you pay gas for every individual transfer. For small distributions (under 500 recipients), direct push through OpenLiquid Multisender is the most practical option.

Claim-based distribution requires holders to visit a website or interact with a smart contract to claim their allocation. This reduces the project's gas costs significantly because holders pay their own gas for the claim transaction. However, claim-based distributions typically see only 40-70% claim rates — many eligible holders never bother to claim, especially if the airdrop value is small relative to the gas cost of claiming.

Merkle drop distribution is a gas-efficient version of the claim model. You deploy a smart contract containing a Merkle root of the entire distribution list. Holders submit a Merkle proof to the contract to verify their eligibility and claim their tokens. The contract only needs to store the Merkle root (32 bytes) rather than the entire holder list, making deployment cheap. This is the standard approach for large airdrops (thousands of recipients) where direct push gas costs would be prohibitive on Ethereum mainnet.

For most NFT holder airdrops on L2 chains (Base, Arbitrum) or Solana, direct push through a multisender tool is the best choice. Gas costs are low enough that paying for every transfer is practical, and the automatic delivery ensures maximum reach. On Ethereum mainnet, Merkle drops are preferred for distributions over 500 recipients due to the high per-transfer gas cost.

Executing the Airdrop with OpenLiquid Multisender

The execution process through OpenLiquid Multisender follows these steps. First, open the OpenLiquid Telegram bot and select the Multisender tool. Choose your chain and connect the wallet holding the tokens to be distributed. Upload your prepared CSV file containing recipient addresses and amounts.

The Multisender validates your CSV automatically, checking for invalid addresses, duplicate entries, and amount formatting issues. It then displays a summary showing the total number of recipients, total tokens to be distributed, estimated gas cost, and the platform fee (1% of the total token value distributed). Review this summary carefully — once the distribution begins, it cannot be reversed.

After confirmation, the Multisender begins batching transfers. It groups recipients into batches of up to 500 transfers per transaction and submits each batch to the blockchain. For a distribution to 1,000 holders, this means 2 on-chain transactions rather than 1,000 individual transfers. Each batch transaction is submitted with optimized gas settings, and the tool monitors confirmations to ensure all batches succeed.

During execution, the Multisender provides real-time progress updates: batches submitted, batches confirmed, and tokens distributed. If a batch fails (due to insufficient gas or a token approval issue), the tool identifies the failed batch and allows you to retry without re-sending already-completed batches. After all batches complete, a final summary shows every recipient address, amount sent, and transaction hash for verification.

For very large distributions (10,000+ recipients), the process takes longer but follows the same pattern. OpenLiquid automatically manages nonce sequencing, gas estimation, and batch sizing to handle distributions of any scale. The largest distributions may take 15-30 minutes to complete on chains with longer block times, but the process is fully automated once started.

Cross-Chain Airdrops to NFT Holders

The simplest cross-chain scenario involves two EVM chains. If your NFT collection lives on Ethereum and your token is on Base, you can use the same wallet addresses from your Ethereum snapshot directly in a Base distribution. EVM addresses (0x...) work identically across all EVM chains — the same private key controls the same address on Ethereum, Base, Arbitrum, Polygon, and all other EVM networks.

However, there is a practical consideration: not all Ethereum NFT holders have used Base. Sending tokens to an address that has never transacted on Base is not technically harmful (the tokens will be there when the holder eventually uses Base), but it may result in many recipients not discovering or accessing their airdrop. To improve claim rates, you can filter your snapshot to include only addresses that have activity on the target chain.

Cross-chain airdrops between EVM and Solana are more complex. EVM addresses (0x format) and Solana addresses (base58 format) are fundamentally different. You cannot send SPL tokens to an Ethereum address or ERC-20 tokens to a Solana address. To bridge this gap, projects typically require holders to link their Solana address to their Ethereum address through a verification step (signing a message with both wallets). This creates a mapping table that enables cross-ecosystem distribution.

OpenLiquid Multisender supports distributions on all 8 chains independently. For a cross-chain airdrop within the EVM ecosystem, prepare your CSV with the snapshot addresses and the token amounts, select the target chain in the Multisender, and execute. The addresses are the same — only the chain and token contract differ. For larger cross-chain strategies involving multi-chain token deployment, consult the chain-specific guides for each target network.

Airdrop Cost Breakdown by Chain

Chain	1,000 Recipients (Individual)	1,000 Recipients (Multisender)	10,000 Recipients (Multisender)
Solana	$5-$10	$2-$5	$20-$50
Base	$20-$100	$10-$50	$100-$500
Arbitrum	$30-$150	$15-$75	$150-$750
Polygon	$50-$300	$25-$150	$250-$1,500
BNB Chain	$100-$400	$50-$200	$500-$2,000
Ethereum L1	$5,000-$15,000	$2,000-$10,000	$20,000-$100,000

The cost differential between chains makes the choice of airdrop chain strategically important. If your token already exists on Ethereum, consider deploying it on a cheaper L2 (Base or Arbitrum) specifically for the airdrop distribution. Bridge the airdrop allocation to the L2, distribute there, and let holders bridge to Ethereum if they prefer. This approach can save 95-99% on gas compared to distributing on Ethereum mainnet.

Timing also affects costs on all chains, but especially on Ethereum. Gas prices follow predictable daily patterns, with the lowest prices during early morning UTC hours. Scheduling your airdrop execution during off-peak hours can reduce gas costs by 20-40%. For large distributions that take 15-30 minutes to complete, starting during a low-gas window ensures the entire distribution benefits from favorable pricing.

The OpenLiquid Multisender platform fee (1% of total distributed token value) is calculated on the token value at the time of distribution. For a distribution of 1,000,000 tokens worth $0.01 each ($10,000 total value), the platform fee would be $100. This fee is separate from gas costs and is paid in the native chain currency (ETH, SOL, MATIC, etc.). See the pricing page for current fee details.

Frequently Asked Questions