Token distribution mechanics in crypto

Token distribution mechanics in crypto

If you are fundraising or investing in a token sale, at one point, you’ll have to distribute these new tokens.

When the time comes, you must choose one of two distribution models. Both play a central part in understanding cryptocurrency's decentralized (defi) ecosystem.

At the end of this, you’ll have a clear understanding of both - and be able to compare and choose the one that best suits your needs.

How do you distribute tokens?

There are two distribution models for all blockchains, be it Ethereum or another layer 1/2. You can create unique mechanics for both.

Simply put: distribution is proactive, and claiming is the passive approach.

Let’s define them:

Distribution is sending tokens to several wallets simultaneously using a smart contract. Closely related to airdrops, back in the ICO era of 2016.

Claiming is when the recipients of the tokens have to claim the tokens themselves. This approach is often made by sending tokens to a smart contract. The smart contract is responsible for ensuring the right wallet can claim the tokens and that they are receiving the right amount.

Many chose to create a claiming portal to make this easy to do. A simple UI where you connect with Metamask to interact with the smart contract makes the process as easy as possible.

Let’s dive in and discuss different use cases and their benefits and drawbacks.


There are two times when you should go with distribution:

  1. Your investors are okay with you possessing the tokens before distributing them out.
  2. Your token setup is either very easy or advanced.


  • The cost of distribution is lower than setting up a claiming smart contract.
  • You don’t need a developer.
  • Suppose you can manage the cap table or allow changes to an allocation by supporting OTC, for example. In that case, you need to keep a historical trail of the changes and use the updated cap table before making the subsequent distribution. With claiming, this would have to be coded into the smart contract.


  • You will pay the gas fee for sending the tokens. If the gas price is higher than usual, it might cost more to send the transactions than the cost of deploying the claiming contract and sending the tokens to the contract.
  • You are responsible for distributing the tokens at the correct time. So make sure to mark it in your calendar. Sending tokens a day or a week later than when people were supposed to receive them leaves a bad taste in people’s mouths.


There are two times when you should go with claiming:

  1. There is a lack of trust in the person responsible for distributing the tokens. Or the person has incentives that misalign with the people that will get the tokens.
  2. The specific time and date of when the token needs to be payout are vital, and there is no wiggle room. Ten minutes off is deemed unacceptable.


  • You derisk yourself by having code dictate and enable claims of tokens at a given time. You put the responsibility on the investor. If they forgot to claim, that’s not your problem. If they were supposed to receive tokens on a specific date, and you failed to send them - they’ll be frustrated.
  • If you have a simple use case where the token issuance is set up so they will receive everything at once, setting up a claiming contract isn’t too demanding for a developer with blockchain technology experience. You have open-source repositories on Github. OpenZeppelin, a highly reputable startup, maintains the most popular one.


  • The smart contract must support lock-up if your token has a cliff. The ability to only claim the token after some time has passed.
  • If you have vesting, the investor must claim a number of tokens in batches. Typically at monthly intervals, the smart contract needs to unlock the allocation at specific dates and account for an investor claiming two batches at once, for example.
  • Unclaimed tokens are lost unless you specify what the smart contract will do with tokens that have not been claimed after a certain point in time. At a larger scale, this means the token has less liquidity, as fewer tokens are in circulation.
  • By customizing the default OpenZeppelin template, you should, and the investor will likely request that it undergo a security audit. An audit varies in cost depending on the length and complexity of the contract; from a reputable provider, you can expect to pay a minimum of $10K.


Choosing the right mechanic comes down to complexity. Unique tokenomics, vesting schedules, lock-ups, and the possibility of change increase complexity. At each end is distribution, and claiming is located in the middle. You need to consider trust, payout time, and cost.

If trust is high, distribution is preferred.

If payout time is vital, claiming is preferred.

If financial cost is essential, distribution is preferred.

Sebastian Almnes

Sebastian Almnes

CEO of Presail - the #1 platform for token management 🇳🇴 🇺🇸