How Airdrop works¶

TokenTable Airdrop distributes tokens to large numbers of recipients, with optional vesting rules and access control rulesets. It also keeps gas costs down; on TON, for example, it uses sharding.

Airdrop uses merkle trees, which keep the cost of a distribution and its vesting rules constant. Vesting is applied when the tree is generated. If an allocation unlocks over 6 calendar months, the data is split into 6 leaf nodes, each with its own claimable timestamp, and the smart contract treats them as 6 separate claims. The TokenTable frontend hides this split from users.

Access control rulesets live in an optional external hook contract. The distributor calls the hook before and after each claim, and the hook reverts when a condition fails (see claim hooks). Fees are charged separately from the hook: the distributor asks the fee collector configured on its deployer contract for the fee. Some variants instead carry a fee amount in each claim's data.

On EVM chains, TokenTable also offers a signature distributor. There, a signature from a signer the project sets authorizes each claim instead of a merkle proof.

When a recipient claims their allocation, the TokenTable backend generates the merkle proof that the claim sends to the smart contract. TokenTable generates the proofs, but the address that deploys the contract (normally the project owner) owns it, and only that owner can change the distribution or withdraw tokens. TokenTable cannot move the tokens or change the merkle root. With the signature distributor, whoever holds the authorized signer's key decides which claims are valid.

TokenTable does control the fee configuration: the owners of the deployer and fee collector contracts choose which fee collector and fee apply to the contract.