I am doing a project where I create a token and try to airdrop it to as many people as possible. The challenge is to figure out the most cost-effective way to do so.

I had two options:

  1. Create a "Token Vault" type smart contract, send tokens to it and pass an array of addresses and balances to some function.

  2. Just create a new function in my token code before deployment that will be similar to approve(), but has an array of addresses as input. And just let people perform transferFrom() afterward.

As you can tell, both of these options are quite similar and my main concern is that both of them require me to pass an array of addresses. As I understand, if I want to pass an array of 1000 addresses it will cost me 21000 gas + 1000 SSTORE operations (20000 gas id _spender is not in mapping) totaling at 20021000 gas (if it is indeed possible to pass 1000 at once and not in separate batches). Calculating the cost for this very moment gives us 0.02 ETH or 16.297$, but that is only because the price of gas is at 1 wei atm.

Well, imagine if I perform a successful Airdrop campaign to thousands of people and the network is going to be congested because of another CryptoKitties leaving us with an average price of gas between 20 and 30 wei for weeks. Yeah, the price of deploying such contract will skyrocket to around 0.5 ETH.

It is not a commercial project, so doing crowdsale (which would cost me very little compared to what I am planning to do) is out of the question. The main goal of the project is to make regular non-tech/crypto savvy people familiar with Ethereum platform and make them do simple stuff for the first time: like creating a wallet, buying ETH, interacting with smart contracts, etc...

You might ask, why in this case don't I create a mintable token that people can mint for themselves, effectively costing me 0 eth after I deploy my token contract? Well, I believe that in order to reach many people the token should have some form of hypothetical value, otherwise, nobody would go through the struggle of even setting up a wallet and loading it with ETH. And when tokens are freely mintable, even if there is a limit of tokens per address, it will not stop some people from abusing it by creating multiple accounts and accumulating large sums for themselves. In other words, I want to have an ability to regulate total supply, so that people are not able to abuse the Airdrop process and render the token worthless (which it is anyway, but at least it might have some speculative value that will motivate people to go through the whole process).

I believe that there should be a way to do this without expensive arrays of addresses. However, since I have zero to none programming experience, it is not so obvious. Maybe there is a way to use some unique codes that I can distribute between people, which they will have to enter in order to unlock their airdrop tokens? But I will have to do it in such a way that doesn't require me to pass an array of such codes to be remembered in the contract. And, for example, those codes will satisfy some mathematical function but would be super hard or impossible to generate for anyone but me.

I would appreciate your input guys! Thank you for reading and sorry for such a long post!


Looking the best cost-effective way of distributing tokens fairly without having to pass an array of addresses to the token contract.

3 Answers 3


So this option will require a decent bit of setup but it would indeed be the cheapest to do. You could create a payment channel of sorts by committing a large amount of tokens to a smart contract. You could setup the smart contract such that only permissioned addresses can request an airdrop. In order to request the airdrop they must submit a message signed by you.

This would be incredibly cheap as each user would pay the transaction cost of sending the coins themselves.

example (update):

Each user will be given a particular message h which is a combination of \x19Ethereum Signed Message\n32 + keccak256('user-address', 'airdrop-value') that you have signed, along with the signature parts vrs. When they post to your contract to withdraw their funds, they provide the necessary signature data (h,v,r,s), along with the values that make up message h to so that they can verify the unique message to them, but also verify that it was signed by you.

I recently had to figure this out myself and made a quick python program used to sign data and extract the necessary parts:


  • Thank you for your comment! I believe that you are totally right. At this stage, I am unable to implement this feature myself. But I will do my best to figure it out and if I do I will update this thread. Feb 8, 2018 at 1:28
  • By the way, since the message has to be unique for every user. In this case, don't I need to also save those messages in the contract so that they can be matched? Feb 8, 2018 at 1:40
  • 1
    The solution Im using in my contracts requires the user to provide the message contents so the message can be reconstructed. I'll update my answer
    – hextet
    Feb 8, 2018 at 5:35

Maybe will be useful to use open-source https://github.com/bulktokensending/bulktokensending Deployed version is here http://bulktokensending.online


No one mentioned Merkle Air-drops, maybe because they seemingly appeared after this question and chosen answer appeared?

Anyway, sounds to me like a better solution: instead of storing in the smart contract all the recipient addresses, which is costly in itself and bloats the chain, you

  • publish those somewhere (like IPFS)
  • build a Merkle tree with those addresses
  • store the root of the tree in the smart contract
  • give clients a way to present the smart contract with a Merkle proof showing that their address is in the list

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.