How are rewards distributed?
A detailed look at Merkel Airdrops
What is Merkle Airdrop?
Merkle Airdrop is a smart contract used for bulk token distribution on the Ethereum network
This smart contract contains a list of addresses which can claim rewards.
Users/Claimants may be asked to enter them on a form.
These address are hashed and a Merkel Tree is constructed.
To prove that one address has a claim to an airdrop, it must submit a proof in the form of a Merkel proof.
This however means that the user would pay gas for it.
Brief overview of Merkel Tree
Merkle Tree
The Merkle Tree is simply a data structure in the form of a binary tree, the value of the nodes, the leaves being the hash of the data.
To create a Merkle Tree , from the data we have, use the hash function to compute the corresponding hash value of the data, which will be the leaf node of the tree. Continue to hash adjacent values until there is a unique hash value (Root of the Merkle tree). How is a Merkle Tree computed in the figure below?
Merkle Tree helps in verifying and verifying data integrity while consuming only a small amount of storage space (due to the small size of the hash). In Blockchain, Merkle Tree is very popular to verify transactions (Used in Bitcoin, Ethereum, etc.)
Merkle Root:
The smart contracts in ethereum use the Merkle tree as the data structure. This data structure has the hash of transactions or data blocks as the leaf node. The non-leaf nodes are a hash of its own children. Starting from the bottom, every two pairs of nodes combine to form an upper node. The Merkle tree ends with a single node on top also known as the root node which is the hash of the last two remaining non-leaf nodes. Source: https://www.researchgate.net
Merkle Proof
Merkle Proof is used to check whether the input data belongs to the Merkle Tree or not without having to reveal all the data that make up the Merkle Tree .
We will look at the example illustrated in the picture above to be able to understand what Merkle Proof is? In this example we need to prove that the data K belongs to the Merkle Tree . We need to calculate the Hash of K and then gradually climb to the root of the Merkle Tree , if the value of the Merkle Tree root is the same as the given Merkle Root value, it proves that K belongs to the Merkle Tree .
Instead of having to use all the data from the AP to recalculate the Merkle Root to see if it is the same as the original Merkle Root ? We just need to get the back nodes of the tree to verify that the K belongs to the Merkle Tree .
The hash of L can then calculate the hash KL
HJ ‘s hash can then calculate the IJKL hash
The MNOP hash can then calculate the IJKLMNOP hash
Hash of ABCDEFGH
From there we can completely calculate the Merkle Root that only needs to know the 4 node values in the Merkle Tree
Merkel Distributor and Uniswap
Uniswap's use case
Uniswap wanted to airdrop UNI tokens during launch to everyone that used uniswap.
In regular Merkel Airdrops , user will need to have registered their addresses via a form, these addresses are then collated and hashed into the Merkel root.
This root was entered into a MerkleDistributer smart contract which allowed uses who signed in with their wallet addresses to claim rewards
The MerkleDistributer smart contract also had checks in place to ensure one address can only claim once
To create such a list of addresses, Uniswap had the snapshot taken on the 1st of September and every address on that snapshot was eligible to claim 400 UNI tokens including the 1200 addresses that submitted failed transactions.
How did Uniswap get the data?
Uniswap had the snapshot of the data of its users i.e the wallet addresses and the swaps each address took part in. This was done using the Ethereum ETL.
Uniswap configured its own Ethereum node to fetch the data from the blockchain using Ethereum ETL.
Uniswap collected the data of the users using the snapshot node.
This enabled them to calculate the hashes ahead of the transaction.
They then used these hashes to form a Merkle tree.
The root node enables the accessing of all the data of the Merkle tree.
Shibaswap's use case
Uniswap had to distribute only one token as a reward , Shiba Swap has
3 Shiba Inu Eco system Token rewards - SHIB, LEASH, BONE
5 Top Coin (ETH, wBTC, USDC, USDT, DAI) Rewards
3 Bone Rewards part of Shiba Inu Eco system Token rewards
1 Ryoshi's Vision Rewards
1 PERL Rewards
1 F9 rewards
1 ZIG rewards
1 xFund rewards
That is a total of 16 different rewards, and thus 16 different MerkleDistributer contracts are deployed.
Separate Merkel roots need to be created and added to each MerkleDistributer .
As explained here , for each bi-weekly rewards a starting block and end block are picked and the addresses within that snapshot which has interacted with various contracts which facilitate staking/BURY-ing and Yield farming/DIG-ing a filtered out out into a list and this list is them grouped and hashed to create Merkel roots for each MerkleDistributer .
One way of getting the desired data from the snapshot interval is setting up a local Ethereum node and querying it for that.
There are however Big Data Pipelines like Ethereum ETL that lets you convert blockchain data into convenient formats like CSVs and relational databases.
This process is repeated for every distribution.
Eventhough these are rewards , the user pays the gas fee since the user is already going through with a transaction and Shibaswap gives reward tokens in the same transaction. a.k.a WOOF-ing.
Sourced from Merkle Airdrop: The Airdrop solution for token issuesSourced from Case Study: Uniswap (UNI Tokens Distribution)
Last updated
