Gas consumption benchmarks for popular airdrop patterns

This repository contains a series of tests to measure gas usage for popular airdrop patterns with various token standards and airdrop mechanisms. Including:

• native currency (ETH);
• ERC20;
• ERC721;
• ERC1155.

The custom mapping-based contracts (AirdropClaimMappingERC{20/721/1155}), and to some extent AirdropClaimMerkleERC{20/721/1155} and AirdropClaimSignatureERC{20/721/1155} as well, are purposely written poorly to fit common assumptions and patterns found in the wild.

Table of contents

• Overview
  • Airdrop mechanisms (custom contracts)
  • Airdrop solutions (including already deployed contracts)
• Results
  • ERC20 (push-based)
  • ERC20 (claim-based)
  • ERC721 (push-based)
  • ERC721 (claim-based)
  • ERC1155 (push-based)
  • ERC1155 (claim-based)
  • ETH (push-based)
• How to run
  • Setup
  • Usage

Overview

Airdrop mechanisms (custom contracts):

Airdrop solutions (including already deployed contracts):

This Readme is an attempt to showcase the results in an organized and sorted manner.

Note: The benchmarks do not include the gas consumption for the bytecode contract, as a current limitation with Forge; this should actually be the most efficient way for airdropping ERC20 tokens.

Results

The tables below are based on gas benchmarks with the following parameters:

• 1,000 different random recipients;
• random amounts between 1e10 and 1e19 (10 * 18 decimals), except for ERC721 (1 token per recipient);
• some amounts are repeated randomly to better simulate real world scenarios (see here);
• randomness is generated with Solady LibPRNG, taking advantage of random calldata generated with fuzzing (see the unnamed uint256 parameter in each test function);
• the gas consumption is measured with Forge;
• Thirdweb contracts are supposed to be deployed as a proxy pointing to the actual implementation, so the cost of deploying the implementation is not included in the report.

See the full report for more details or generate it yourself.

Notes

For claim-based airdrops, multiple measurements are taken into account:

1. deployment/initilization (e.g. Thirdweb contracts require only a proxy to be deployed, but the proxy needs to be initialized with the airdrop data, which can be quite expensive);
2. deposit/airdrop (e.g. depositing tokens, writing the airdrop data to the contract);
3. claim.

Steps 1 and 2 are aggregated into Gas deployment, with the details for each amount in such way: total (deployment/initialization + deposit/airdrop).

For push-based airdrops, the gas cost of deploying and initializing the contract is ignored, as all solutions, excluding Thirdweb, are already deployed and available for use (direct call to the airdrop function).

ERC20 (push-based)

ERC20 (claim-based)

This comparison is opinionated. Some arguments to support it:

• The difference in deployment cost is too significant for AirdropClaimMapping to be considered a viable solution. Although, in pure gas terms, for 1,000 recipients, it's still cheaper than the Thirdweb and signature-based solutions, i.e. it will spend less gas in total.
• Although the deployment for Thirdweb's AirdropERC20Claimable is half the cost of AirdropClaimMerkle or AirdropClaimSignature, the increase in gas for claiming is too significant to have it ranked higher. I believe that the deployer paying ~400-500,000 gas instead of ~200,000 cannot justify each single claimer having to pay ~90,000 gas instead of ~86,000.

In any case, these are only benchmarks, with a ranking provided for convenience.

It's also worth noting that the top 1 and 2 custom contracts are really just mock implementations. Although they do allow claiming on behalf of another account, they lack some checks and utility functions (e.g. pausing the claim)—the position of these contracts in the ranking is not a recommendation to use them, but rather based on the gas consumption.

ERC721 (push-based)

ERC721 (claim-based)

It really hurts to not put AirdropClaimMapping in the last place, but Thirdweb's AirdropERC721Claimable really is too much with both the ~30M gas deployment and the ~218k gas claims. With 1,000 recipients, it is more than 219M in gas just for users to claim their tokens...

Also, AirdropERC721Claimable does not allow for airdroping specific tokens to specific accounts, it will just allow to claim n amount of tokens, and read the tokenIds array in ascending order. So it basically looks like a minting function.

ERC1155 (push-based)

It's worth noting that GasliteDrop1155 takes advantage of multiple recipients with same amount by packing them into a single struct. Which much better simulates real world scenarios (e.g. users being rewarded the same amounts for the same token IDs after accomplishing a similar task). See:

1
struct AirdropTokenAmount {
2
    uint256 amount;
3
    address[] recipients;
4
}

In these tests, there are ~14% of recipients aggregated with the same amount. As the proportion of recipients with the same amount increases, the gap in gas consumption between GasliteDrop1155 and Thirdweb's AirdropERC1155 contract will increase as well.

ERC1155 (claim-based)

These contracts allow only for claiming a single token ID per recipient, to fit the Thirdweb pattern.

ETH (push-based)

Note: There tests use already initialized accounts—that is, accounts that were sent 1 wei prior to the measurement—to better simulate real world scenarios. This helps to avoid the cost of both the cold account access (2,500 gas) and the initialization surcharges (25,000 gas). See here for reference

ETH (claim-based)

How to run

Setup

1. Clone the repository and navigate to the root directory

1
git clone git@github.com:0xpolarzero/airdrop-gas-benchmarks.git
2
cd airdrop-gas-benchmarks

2. Install Foundry

3. Customize the amount of recipients here and the amount of ERC1155 tokens ids to distribute here

Usage

1. Run all tests with gas snapshots

1
# Output to stdout
2
forge test --gas-report
3
# Output to file
4
forge test --gas-report > gas-report.txt

2. Run benchmarks for a specific token/currency

1
# BenchmarksERC20
2
# BenchmarksERC721
3
# BenchmarksERC1155
4
# BenchmarksETH
5
forge test --mc BenchmarksERC20 --gas-report

3. Run benchmarks for a specific contract/solution

1
# AirdropClaimMapping
2
# AirdropClaimMerkle
3
# AirdropClaimSignature
4
# Disperse
5
# wentokens
6
# GasliteDrop
7
# BytecodeDrop
8
# Thirdweb
9
# ...
10
forge test --mt AirdropClaimMapping_ERC20 --gas-report

4. Run a specific test

1
# See the name of each test
2
forge test --mt test_ERC20_GasliteDrop --gas-report

Disclaimer

Warning: The custom contracts shared in this repository are not meant to be used in production. They are not audited, and some of them are written precisely to showcase how inefficient airdrops can be if not properly designed. This does not only apply to gas consumption, but also to security and usability.