Tokens - Status Quo and Bancor 3 Redesign
Tokens - Status Quo and Bancor 3 Redesign¶
Contrasting the new Bancor 3 pool token behavior against its predecessors may be helpful to establishing its unique design. Fortunately, the pool token concept is not complicated. In the typical case, a contract will exist wherein a collection of digital assets is stored. Contributions to the store of assets generates pool tokens for the user at a rate commensurate with the size of their contribution to the store of value. This is best demonstrated by example.
Imagine a yield-bearing token contract wherein a user stakes abcCoin, and additional abcCoins are added to that stake over time. This situation applies to many different projects, including yield aggregators such as yearn.finance. The idea behind the pool token is that a user’s claim_standard_rewards to the tokens inside the contract is exactly equal to their relative share of the pool token supply. For example, suppose the contract contains 10 abcCoin, and a user deposits an additional 10 abcCoin. The contract now contains 20 abcCoin, of which the user who just performed the deposit has claim_standard_rewards to precisely 50%. Therefore, the deposit should result in the genesis of sufficient pool tokens such that the supply on the ERC20 contract is doubled, and the 50% of that supply (i.e. the newly minted pool tokens resulting from the deposit, only) are sent back to the user. In this way, all previous contributors retain their pro-rata share of the abcCoin in the contract; the new user does not dilute the old users by any measure.
This is also true of conventional AMMs, such as Bancor v1. In these cases, the contribution of liquidity by users is measured against the liquidity that was already available in the pool. As an example, suppose a liquidity pool contains a 300:100 reserve ratio of abcCoin and xyzCoin, respectively, and the ABCXYZ pool token supply is currently at 100 total tokens. Therefore, each ABCXYZ pool token can be used to withdraw 3 abcCoin and 1xyzCoin at the current price; 50 ABCXYZ pool tokens can withdraw 150 abcCoin and 50 xyzCoin, and so on. As trading occurs across these assets, a small swap fee is left behind by traders as a commission to the liquidity providers. This swap fee grows the size of the pool over time, and in a perfect world, results in a financial return for the liquidity provider. Unfortunately, the effect of impermanent loss can nullify these returns and result in an overall loss of value.
In Bancor v2.1, double-sided pool tokens were still used, but were bound with a non-fungible user position at the moment of their creation. The reason for this is the need to track individual impermanent loss, accurately, while also timing the insurance vesting period. In Bancor 3, the insurance is tracked separately from the store of assets, through the staking ledger. Therefore, the single-sided pool tokens of Bancor 3 represent pro-rata ownership of a store of insured value, rather than a number of tokens. Of course, the insured value continues to be denominated as a number of tokens - but the face value of the bnTKN tokens of Bancor 3 are determined by the history of user stakes, rather than the available liquidity at any one time.