BIP15: Proposing Bancor 3

DAO Archive (SUBMITTED)
2

Abridged Description of Bancor 3

The following sections are intended to provide an intermediate level of detail regarding the design of Bancor 3.

Impermanent (“Divergence”) Loss Protection

  • The value of a user’s principle, and all fees and rewards earned thereon, are immediately and permanently protected against the effects of price divergence (the phenomenon commonly referred to as “impermanent loss”).
  • The 100-day insurance vesting schedule of version 2.1 is replaced with an effectively instantaneous insurance policy, contingent on the following criteria:
    • The pool is sufficiently liquid, such that a minimum balance of 1000 BNT (adjustable by the DAO) remains after the withdrawal is processed by the protocol.
    • The user completes a mandatory 7-day “cooling off” period, wherein the user forfeits any rewards and fees that have accrued during this time. The user may elect to cancel their withdrawal, at which time any forfeited fees and rewards are immediately returned to their withdrawable balance. In the event that a user completes the withdrawal at the conclusion of the cooling off period, the rewards and fees accrued on their stake during the cooling down period are distributed to the remaining liquidity providers.
    • A 0.25% exit fee (adjustable by the DAO) is introduced, whereby a fixed proportion of the total value of the pool tokens being liquidated is forfeited at withdrawal. The exit fee is simply deducted from the user’s withdrawal and left as residue inside the pool; it has no effect on the ROI of remaining users (the reasoning for this will be made apparent in later sections).

Single-Sided Pool Tokens

  • Bancor 3 introduces some important new concepts with regards to the fungibility and composability of liquidity pool tokens.
  • The single-sided staking and protected liquidity paradigms are a natural expression of the new design; the insured valuation, and the representative asset are intrinsic properties of the Bancor 3 pool tokens.
  • Therefore, single-sided staking becomes a “first-class citizen” of the system:
    • Pool tokens are only aware of their protected value (staked balance).
    • Pool token value is independent of either reserve balance.
  • To achieve this behavior, the concept of a “staking ledger” is introduced. The staking ledger becomes the de facto source for the valuation of any pool token, and is independent of the vault balances.
    • Each pool token issued by the Bancor Protocol has its own staking ledger.
    • The contribution and withdrawal of liquidity by users causes the staking ledger to update itself, commensurate with the amount of value being added or removed from the system:
      • New pool tokens are issued during liquidity contributions so as to maintain the pro rata ownership of the staking ledger by all pool token holders, which itself represents the full insured value for that asset.
      • Users burn their pool tokens during liquidity removal, and the staking ledger is reduced proportionately with the overall reduction in the pool token supply, as judged from its erc20 contract.
    • Each staking ledger is denominated entirely in its cognate TKN units for any TKN (including BNT).
    • Protocol revenue (i.e. the pool fees, or the commissions paid by traders) is distributed to users by increasing the balance of the staking ledger, equal to the value captured. Therefore, as the staked amounts are increased due to trading activity, the valuation of its pool token also increases.
  • The Bancor Protocol is the de facto BNT liquidity provider, and it is the only entity capable of providing BNT directly to the system.
    • The Bancor Protocol receives single-sided pool tokens for its liquidity contributions.
    • Non-protocol BNT liquidity providers (i.e the BNT users), burn their BNT in exchange for the protocol’s own pool tokens.
    • BNT liquidity withdrawals require the protocol to mint new BNT tokens, which are then exchanged for the user’s pool tokens. Therefore all add/remove liquidity actions taken by BNT users are a simple exchange within the system; pool tokens are not created or destroyed as a result of BNT user actions.
  • The syntax for Bancor-issued pool tokens is a ‘bn’ prefix, followed by the symbol for the underlying asset.
    • Staked BNT is represented by the bnBNT pool token, staked ETH is represented by the bnETH pool token, and so on.

Omnipool

  • The current system where BNT liquidity providers are required to choose specific pools wherein to stake their BNT, is replaced with a single network staking pool.
    • The bnBNT pool token represents all BNT staked in all pools across the network; fees paid in BNT arising from trading on any of the network’s assets are treated as equivalent.
    • The Bancor Network sends its own bnBNT pool tokens to users, in exchange for their burning an equivalent amount of BNT. Additionally, users receive an equivalent amount of vBNT governance tokens.
    • The Bancor Network mints new BNT in exchange for the return of pool tokens and vBNT by users during the withdrawal of their liquidity.
      • vBNT and bnBNT must be provided in a 1:1 ratio during withdrawal.
      • The vBNT is destroyed, whereas the protocol takes possession of the bnBNT tokens.

Infinity Pools

  • The version 2.1 paradigm, where the TVL of the network is limited by the liquidity capacity of its pools, is replaced with a vault system that delineates the staked assets from the available trading liquidity.
    • All tokens on the Bancor Network are stored in a single secure vault.
    • The liquidity pools do not contain tokens; they are a logic layer above the vault that dictates the exchange of assets between the vault and a user.
    • The pools are modular. At launch, each pool is a standard constant product bonding curve; however, modified pools with customized behavior can be substituted to serve novel use cases.
    • The effective slippage is determined by the virtual balances reported by each of the liquidity pools, which is a subset of the total liquidity available from the vault.
    • Therefore the liquidity pool depth is bounded by the token balance of the vault, but can report an effective trading liquidity that is smaller than this number.
  • The BancorDAO determines the available liquidity for trading, through adjustment of the “BNT funding limit” parameter.
  • TKN liquidity contributions following the exhaustion of BNT funding continue to be accepted into the vault, and pool token issuance and redemption continues as normal.
  • Therefore, the capacity for staking on the Bancor Network is unlimited.

Pool Genesis, Bootstrapping, Restricted Growth, and Shutdown

  • At the time a liquidity pool is first established, the Bancor Network may begin accepting tokens from users and issuing pool tokens, before trading is possible.
  • The BancorDAO prescribes a liquidity threshold, denominated in BNT, that represents the minimum available liquidity that must be present before the protocol bootstraps the pool with BNT. This parameter is adjustable, and is set to 1,000 BNT at the time of launch.
  • After sufficient TKN liquidity has been collected, prior to the activation of trading by the pool, the process of bootstrapping the pool with BNT to enable trading is handled via the DAO msig.
    • The minimum BNT liquidity for all pools across the protocol is a global setting.
    • The BancorDAO governance process prepares and approves a new token in the whitelisted assets, with a defined BNT funding limit.
    • The pool is created via a permissionless process, and initial TKN are added by members of the community.
      • No BNT is created by the protocol at this time; however, bnTKN pool tokens are issued at a 1:1 rate with the provided TKN.
    • The DAO msig evaluates the current status of the TKN provided, using external market prices (e.g. CoinGecko, Coin Market Cap) to determine if there is sufficient value to justify the minting the minimum BNT liquidity.
      • The DAO msig then sets a TKN/BNT rate, commensurate with the market prices of both assets.
      • The protocol then mints the minimum BNT liquidity, and creates trading liquidity with the appropriate amount of TKN.
    • Vault token balances of TKN that exceed the minimum BNT liquidity are used to grow the pool according to an exponential growth curve, until the BNT funding limit is exhausted.
      • The pool’s liquidity depth begins at the minimum BNT bootstrapping amount, regardless of the available TKN inside the vault.
      • Future liquidity additions trigger the following process:
        • New liquidity is accepted into the vault, bnTKN is issued as normal.
        • If the spot rate is within a preset tolerance of the EMA rate, the pool depth is allowed to double, or become equal to the vault balance of TKN (whichever is smaller).
        • If the spot rate is outside of the EMA tolerance, no changes are made to the pool depth.
  • If a withdrawal is made while the BNT balance of the liquidity pool is below the minimum threshold, a security mechanism is activated, and the pool is returned to its bootstrapping state.
    • All BNT is removed from the pool, and destroyed. Therefore, trading is no longer possible.
    • Withdrawals can still be processed with a conditional insurance schedule.
    • Deposits can still be accepted, however the pool will remain inactive.
    • Pending an investigation by the BancorDAO, the pool can be reactivated via the same pool initialization process as is used for pool genesis.

Governance

  • The governance contracts from version 2.1 persist essentially unchanged.
  • Users who have staked BNT in the network receive vBNT in return, at a rate 1:1 with the bnBNT tokens. Alternatively, vBNT can be purchased directly from the pool.
  • The vBNT token is used for governance purposes; it may be staked in the voting contract, and is used to weigh the user’s agency in governance decisions.

Auto Compounding and Standard Rewards

  • The single-sided staking paradigm, and the single-sided pool token system derived from the staking ledger can be used to create a rewards system that obfuscates the need for users to interact with a staking contract in cases where the reward token has the same identity as the staked token…
  • On Bancor 3, token projects, including Bancor itself, can create a rewards schedule by providing liquidity to a pool and then burning the pool tokens it has received at a predetermined rate. Therefore, the rewards budget is being used as liquidity from the first instant, and the ownership of the staked tokens is distributed to other stakers over time.
  • The process is straightforward:
    • Tokens are added to the pool, and bnTKN pool tokens are issued as normal.
    • The pool tokens are staked into a generic rewards contract, with customizable parameters:
      • Total number of tokens to distribute.
      • Type of emissions profile: linear or exponential decay.
      • Emission rate.
    • After the program is created, it can be paused, terminated, or restarted.
    • Interactions with the vortex cause the pool tokens to be burned in accordance with the parameters set by the contract; the vortex trigger also triggers the distribution.
    • As the pool tokens are burned, the token value they represent is distributed to the remaining pool tokens.
    • No contract interactions are required by users; so long as they hold the pool token, they are automatically participating in the rewards program.
  • The auto compounding system can be used in any instance where the reward token is the same as the staked token; it cannot be used to distribute BNT to TKN, or to distribute TKN to any pool other than itself.
  • For this use case, a generic rewards contract is also available, which is a modified version of the industry standard:
    • A standard staking contract wherein bnTKN (or bnBNT) pool tokens are staked.
    • Rewards are claimable by stakers manually, and requires a contract interaction.

The Withdrawal Algorithm

  • Withdrawals in BNT are easy for the protocol to process, and the logic is similarly easy to understand:
    • Users “sell” their bnBNT tokens back to the protocol for their face value.
    • The protocol “buys” their bnBNT tokens by minting BNT.
  • Withdrawals in TKN are far more complex.
    • Users redeem their bnTKN tokens for the underlying value, save for the exit fee.
    • At the time of the withdrawal, there are two important states that the system might possess, resulting from market effects and the influence of impermanent loss:
      • TKN is in deficit. The value of TKN has appreciated relative to BNT, and as a result the vault balance of TKN is less than the staked balance of TKN.
      • TKN is in surplus. The value of TKN has depreciated relative to BNT, and as a result the vault balance of TKN is greater than the staked balance of TKN.
    • The withdrawal algorithm is designed with the following priorities:
      • If possible, the user should receive the full value of their withdrawn stake in the TKN denomination they are expecting; if it is financially feasible to do so, the protocol should avoid partial refunds in BNT.
      • The relative deficit or surplus of the system in TKN should remain constant, regardless of the amount of TKN being withdrawn, or depth of the pool.
      • The overall pool depth should remain constant, regardless of the actions taken by the protocol to process the user’s withdrawal.
    • For this summary, the following brief description of the withdrawal algorithm is provided, and then elaborated in more rigor later in the document:
      • When TKN is in deficit:
        • Reduce the staked balance by the full amount.
        • Calculate the difference between the insured value, and the amount of TKN currently available to withdraw. In this case, the insured value is greater than the available TKN in the vault.
        • Calculate the cost of repricing BNT vs TKN, such that this amount can be returned to the system via the closing of an apparent arbitrage opportunity, and such that the pool balances return to their initial state before the withdrawal.
        • Calculate the value of closing such an arbitrage opportunity.
        • If the arbitrage value is less than the exit fee, execute the withdrawal as described.
        • If the arbitrage value is greater than the exit fee, mint BNT equal to the deficit value and refund the user with both tokens.
        • Whatever the outcome, the relative deficit of the system is unchanged.
      • When TKN is in surplus:
        • Reduce the staked balance by the full amount.
        • Calculate the difference between the insured value, and the amount of TKN currently available to withdraw. In this case, the quantity of TKN in the vault is greater than the insured value.
        • Calculate the cost of repricing BNT vs TKN, such that this amount can be ejected from the system via the closing of an apparent arbitrage opportunity, and such that the pool balances return to their initial state before the withdrawal.
        • Calculate the value of closing such an arbitrage opportunity.
        • If the arbitrage value is less than the exit fee, execute the withdrawal as described.
        • If the arbitrage value is greater than the exit fee, simply return the number of TKN the user is expecting.
        • If the repricing method can be executed, the relative surplus will remain the same, whereas if the repricing method fails, the relative surplus will grow.
  • In short, the withdrawal algorithm considers the state of the system and the size of the user’s withdrawal relative to the pool, then uses the value of their withdrawal fee to determine if it is financially feasible to recover ‘lost’ TKN or BNT from outside markets through repricing.
  • The effect is very small; the logic allows only for changes to the state of the system as a fraction of the size of the liquidity being withdrawn (i.e. equal to the size of the exit fee).
  • The reason for its introduction into the Bancor 3 is to address an apparent risk asymmetry between TKN and BNT liquidity providers, and stabilize the token economy within the protocol.

External Impermanent Loss Protection

  • In version 2.1, the impermanent loss protection was offered exclusively in BNT.
  • In Bancor 3, token teams have the option to offer an external protection policy in their own token, thus reducing the apparent insurance risk for the BancorDAO, and supporting a more favorable view of the whitelisting proposal.
  • The external protection process is simple:
    • Each pool has an external protection balance, which defaults to zero when a pool is generated.
    • After the pool is created, the protection balance can be increased via a contract interaction, where tokens are sent to an address outside of the vault. Therefore the vault balance, and staked balances of the Bancor Network are not affected by this action.
    • After a token project funds the protection wallet, funds from it are used to reimburse liquidity providers that have experienced impermanent loss.
    • The Bancor Protocol does not default to the external protection balance unless it has to:
      • The withdrawal algorithm behaves normally.
      • If the user can withdraw their stake entirely in TKN as defined by the tolerances of the algorithm, the external protection balance will not be used.
      • However, if the algorithm defaults to a partial refund in BNT, then the external wallet is used to substitute the same value and the user receives everything in TKN.
      • If there is insufficient TKN in the external protection balance to cover this amount, the remaining TKN is used and the difference is refunded in BNT.
  • The external protection balance cannot be withdrawn, but it can be replenished by the token team at their discretion.

The Bancor Vortex

  • An insurance premium is confiscated from all trade revenue, and is used to fund the purchase of vBNT from its own liquidity pool.
  • vBNT purchased by the protocol is destroyed, and serves an important [indirect] economic deflationary property for the BNT token that helps to counterbalance the cost of insurance.
  • The process on Bancor 3 is significantly changed from that of version 2.1:
    • The new vortex operates via the collection of BNT, exclusively, and independently of its pool of origin.
    • Trades of BNT to TKN (and, by extension, TKN to TKN) are executed such that an implicit trade of the confiscated TKN fee back to BNT occurs instantaneously.
    • The arrangement relies on a modification to the trade function, and requires only one additional write method to be worn by the trader.
    • The accrued BNT exists inside the vault, and remains there until the Burner is triggered.
    • During a burn, the BNT remains where it is, vBNT is burned directly from the vault, and the trading liquidity on the vBNT pool is updated as though a trade was performed.
  • The vortex burner offers a small reward to anyone who triggers it, and a trigger of last resort is being implemented through integration with the Chainlink Keepers network.
  • Importantly, the auto compounding rewards program (see above) is attached to the use of the vortex.
    • As the vortex is triggered, it simultaneously calls a function to distribute rewards on a subset of auto compounding rewards programs.
    • The set rotates, such that the following vortex burner event distributes rewards on a different set of pools.

Migration from Version 2.1 to Bancor 3

  • v2.1 is upgraded to support migrating user positions directly into v3.
  • During migration, v2.1 positions that didn’t reach full insurance (100 days) are accelerated to full insurance.
  • The status of the system is preserved during the migration; there is no value loss on user’s positions.
  • The non-fungible user position is replaced by fungible pool tokens, which are issued after executing the migration function.
  • To make the migration function more gas efficient, the rewards programs, including the multiplier logic, will be discontinued. Unclaimed rewards from v2.1 will be recorded, and made available as a one-time claimable airdrop (at a massive reduction in gas costs).
2 Likes