This document describes a Token Design pattern that allows greater control and flexibility when dealing with dynamic token supplies. The elastic supply model is a generalization of a specific implementation developed by Ampleforth, and in particular the concept of scalar based supply adjustments.

The core mechanism works by adjusting the balances of all accounts by multiplying by scalar value in order to make arbitrary adjustments to the total supply. This adjustment to the total supply, called a rebase, has many practical applications in the context of token engineering.

In Ampleforth this strategy is used to efficiently update balances for every account, modulating the total supply in response to changes in token price in order to create a market incentives to stabilize unit price in long run equilibrium, but the same strategy can be used in other contexts to accomplish many different goals.

For example, you might implement a staking incentive by issuing tokens to active stakers and then rebasing the supply (in the same transaction) so that the operation results in zero net issuance, the active stakers will have the same balance as before the operation (but a higher relative percentage of the supply), and inactive stakers will have their balances and their percentage of the supply decreased. This may seem unintuitive at first, but it could be significantly more tax efficient because active stakers would not be taxed on the issuance as income, and inactive stakers may even be able to document the decrease in their balance as a loss or as asset depreciation (disclaimer: not a tax lawyer or accountant).

However, In practice having the token balances in an account increase or decrease without the account taking any action may violate assumptions made by wallets, contracts, and exchanges about the behavior of a token. While there is no way to avoid that issue entirely, by adopting a common pattern, we can make it easier for people to reason about their token supply and balances.

General Elastic Token Pattern

We can think of the Elastic Token Pattern as a standard way for a token to maintain two distinct representations of the the same token distribution. The expectation would be that the stable balance for an account generally won’t change as a result of global state changes, whereas volatile balances may be adjusted based on global state changes. Neither balance should be considered the true balance as they are both representations of the same underlying value, instead users and integrators may choose to use one representation or the other depending on specific context.

Each Elastic Supply Token should have the following:

And the token contract should maintain the following invariants: