1 post tagged


Airdrop evolution

The airdrop buzzword can be heard numerous times nowadays. Airdrop itself is a popular approach to give away the token to the community.

Airdrop is a popular way to distribute project tokens to the community. So popular that sometimes leads to congestion in the network Ethereum and important commissions in transactions. More recently, this mechanics, which was used to vote on the stock exchange FCoin, has led to sad consequences for the entire network of Ethereum itself. A suitable algorithm allows solving several problems of smart contracts, which operate with extensive lists of users’ addresses. The fact is that putting into the contract a list of even a few thousand addresses and letting this set of addresses do something directly in the contract will not work – in the block, every byte is saved and this is too expensive.

To solve the problem, it is necessary to determine whether the address belongs to the list of “white” addresses in the contract code. If yes, then allow the desired action. The proposed option will enable to solve this problem quite merely by keeping only one number in the contract. The algorithm of brilliant cryptographer Ralph Merkle is widely used in virtually any decentralized software to ensure the integrity of data sets.

Airdrop & ACL

There is such a practice – to release your token and send out its small amounts to tens of thousands of addresses, for which there is, for example, at least 1 ETH. Such spam is extremely popular now to promote your own projects tokens. Few people like the appearance on their balance of someone’s unknown tokens. Nevertheless, the projects need this, and orders for airdrop are prevalent. This is usually done in an old-fashioned way, like this (in the example of Ethereum, but other block contracts with contracts, EOS, for example):

  • Create an address where enough tokens are stored for distribution to all from the list, or they provide in the token contract the ability to create (mint) the required number of tokens to the specified address (when sending the transaction from a particular privileged address);
  • Put on this address is enough Ethereum, enough to pay for the commission for each shipment of tokens to the user;
  • Run a distribution script that iterates through the addresses and for each creates a transaction that transfers (or toms) tokens to the specified address.
    That is, it’s just a pass on the heap of addresses and sending tokens to everyone. In decentralized systems, this push strategy is usually pretty lame, expensive, generates security holes, and generally, it’s spam.

On the commission takes much money (the more addresses, the greater the commission). Besides, at the time of mailing the commission can grow, because the load on the network grows, the cost of the transaction grows too;
Mailing requires writing a script that will send transactions, and the script contains a secret key that gives access to a heap of tokens;

Mailing must be programmed and be able to continue from the place where everything has broken down.

At the same time, the solution is much simpler, which, as is the case in decentralized networks, most of the work is delivered by the software on the client side. This is access control using the Merkle tree – an incredibly convenient data structure to store in the contract only one fixed-size number (merkleRoot), which contains information about all the data included in the tree (about a massive list of recipient addresses, for example).

There is no magic here: information proving that the address is present in the list of allowed, client code provides independently, doing relatively voluminous calculations, and eliminating the need to view a huge list of addresses. The structure of the Merkle tree is extremely useful for a variety of tasks.

So, this algorithm is suitable for creating huge ACL (Access Control List), which allow you to give access to some function of the contract to millions of accounts. To do this, you need to write down a single number in the contract to verify that the account belongs to the list.

Consider the scheme with airdrop, because it is now in high demand on the market and is a demonstrative and straightforward example of smart contracts with large ACLs.

In general, Merkle-proof can be described as “the path that can be traversed from the user’s address in the Merkle tree to Merkle-root itself.”

The Merkle-proof proof consists of log₂N hashes (rounded up to the whole). Each hash is the same size as Merkle-root, which we recorded in a contract-airdrop. That is, for a list of 1024 addresses, the user must provide 10 hashes, and for ~ 4 billion addresses – only 32 hashes. It is in the protocol of construction and presentation of evidence that the main “counter” of the contract hides – the storage of the minimum amount of information to determine the belonging of some data to an extensive list. Also, the more the list is, the higher the gain.

In reality, the contract is supplemented by the ability to take unused tokens, update Merkle root and enter time limits, for example, to prohibit the release of tokens after some time. The contract is quickly updated to distribute an arbitrary number of tokens to each address, in this case, the file contains not just the recipients’ addresses, but also the necessary sums of tokens, and the merkle-proof function is slightly modified, but the general algorithm does not change from this.
Advantages and disadvantages of Merkle-airdrop.

Separately, one can distinguish the advantages and disadvantages of the above method in comparison with the traditional script distribution:


The transaction that requires tokens costs little gas, and this number is a constant, depending on the size of the “white” list;
After the launch of the contract, it does not require the slightest support, and all activity is provided by users;
Allows you to work with lists of almost arbitrary size with a minimum consumption of storage block.


It is necessary to spread the public address list somewhere;
The client code needs to see all the addresses in the “white” list and execute a fairly resource-intensive code.
In this algorithm, there are no secrets, such a payoff from the memory of the contract is generously “paid” for the work of the code on the client side to verify the membership of the list. This approach demonstrates very well the difference between the models of using smart contracts in comparison with traditional centralized systems.

The traditional distribution of tokens by the script in response can be countered only by a simple and understandable scheme of work. Moreover, the efforts of the programmer to run ordinary airdrop at times exceed the efforts for laying out the Merkle-airdrop contract, the launched script should be monitored so that it does not fall off in the middle of the list so that it does not run out of funds for commissions for transactions, make sure that no one stole the key with which the script signs transactions. Plus, if you have a file with addresses, you really do not need a programmer-it’s extremely easy to implement such a contract through public services.

Features of the implementation

In addition to the basic smart contract, the full DApp for Merkle-airdrop has some features in the implementation. In the Merkle-airdrop scheme, a significant amount of work is assigned to the code in the user’s browser, for example, building Merkle proof, for which you need to run through the entire address list. The list of addresses should be stored somewhere, and for the user, it should be no more difficult than uploading the file to the server.


The main “advantage” of the traditional distribution of tokens on the list is that this scheme allows you to cast tokens even to those who do not want it. There are also special perversions when you can send out tokens so little that the exchange does not even allow you to make transactions with them, and users are forced to watch these “scraps” on their addresses without being able to get rid of them.
The problem of airdrop, when the company distributes part of the system tokens in the community, is of course extremely important for the development of projects. However, such a decision is unfriendly to users and inefficient in general. So in general, smart contracts tend to gravitate towards the concept of “pull” rather than “push,” in which network users are initiators and controllers of business processes, and stories, when someone centrally imposes something on tens of thousands of users, gradually the past.