A perpetual pool distributes a fixed percentage of its remaining balance each epoch, rather than a fixed number of tokens. The pool mathematically can never run out, rewards decay smoothly rather than in the 4-year shocks Bitcoin's halving produces, and token inflation stays fully predictable. Only two parameters need to be set: the distribution rate and the epoch length.
This tokenomics mechanics series covers principles we apply regularly in client work, across a wide range of project types. Each post focuses on one concrete mechanism: how it works, when to use it, and where it breaks. The goal is useful building blocks, not survey writing.
The problem
Projects generally want to give incentives for various actions performed. Common examples include:
- Staking
- Providing liquidity
- Performing certain platform actions (trading, playing a game, and so on)
- Being a validator (for L1 blockchains and other use cases)
Running out of tokens to award is a real problem, especially when the inflow of tokens is less than the outflow. So how should projects balance this? The usual options include careful balance of inflows and outflows, ongoing token inflation, or the use of real yields. None of those is optimal on its own: they either rely on a lot of assumptions, create additional selling pressure, or perform poorly in bootstrapping the early days of the project.
The solution
Perpetual pools are an allocation used for rewards and other incentives, where the amount of rewards given out gradually decreases over time. This is not a new concept. It is one of the very first crypto economics concepts introduced by Bitcoin, where it is called halving: block rewards are cut in half every 4 years. This produces a reward distribution chart like the one below:
Halving can work, but it has its own shortcoming: supply and price shocks every 4 years when the halving hits. I recommend a simpler and more elegant approach. Distribute a fixed percentage of the total pool amount over a certain period (epoch). Let's walk through an example. Say you have a pool of 1,000,000,000 tokens allocated as a reward for traders on your platform. You want those tokens to last several years at least, and you want to avoid big supply shocks. One approach would be to distribute 0.1% of the outstanding token amount in the pool each day. In practice this means:
- Day 1: Pool starts at 1,000,000,000 tokens. 0.1% of pool = 1,000,000 tokens distributed.
- Day 2: Pool now at 999,000,000 tokens. 0.1% = 999,000 tokens distributed.
- Day 3: Pool now at 998,001,000 tokens. 0.1% = 998,001 tokens distributed.
- And so on.
The resulting reward curve follows the same general shape as Bitcoin's halving, but without the 4-year cliffs. Rewards decay continuously, so the pool never drops by a large percentage overnight and holders are never exposed to a sudden supply shock from an expected mechanic. The chart below shows the difference in shape:
The approach has three desirable properties:
- The pool can never run out of tokens, since it only distributes a percentage of the remaining balance.
- Early platform adopters get more rewards on two counts: the pool is fuller, and the same amount of tokens is shared across fewer people.
- Token inflation is fully predictable.
The approach reduces to a simple rule: distribute X percent of the remaining tokens in the pool, every Y days. Only two variables are left to determine, the distribution rate X and the epoch duration Y. Both depend on the specific project's needs and requirements, which is where most of the tokenomics design work actually happens.
A perpetual pool is rarely the only lever in a real token economy. For other mechanics in the series, including how to support the buy side of the market, see the soft price floor article. Pools and price floors work together as complementary levers: one manages outflow of rewards, the other supports demand.
