BIP15: Proposing Bancor 3

All the comments here so far are a great starting point to discuss the merits of the Bancor3 proposal.

But, now allow me to play the devils advocate for a bit.

The following is coming mostly from the perspective of a BNT holder, who may or may not stake more $ in TKN than $ in BNT on Bancor3.

Under the Bancor v2.1 system, most BNT holders bought BNT for 3 things

  1. They thought the token price would appreciate above their entry
  2. They thought the dividend income from LM or organic APRs would be worth the opportunity cost of buying BNT vs other tokens
  3. They had to buy BNT in order to stake it into a pool where there was no room for the TKN in order to make room.

Under Bancor3, 1 & 2 remain the same, but #3 goes away.

Are there new economic forces under Bancor3 which require users to buy more BNT, thus putting a buy pressure on the token price?

Additionally, with TKN->TKN swaps bypassing BNT as a swap, is “token not needed?”

Is BNT under Bancor3 serving only as a backstop in the event that the protocol must mint something of value in order to compensate LPs in the event of impermanent loss being more than fees collected (which based on v2 metrics, happens quite a bit)?

If this is the case, unless APRs massively increase (and not from LM), then BNT doesn’t seem like the best investment for a prospective BNT holder.

I am worried that the ‘upgrade’ from v2.1 to v3 does not improve BNT’s stature as an investment vehicle.

That being said, from a TKN perspective, Bancor3 seems like a great deal, even better than v2.1. But v2.1 was already a great deal for TKN LPs, one of the best (thus why the single staked TKN room ran out on many pools with LM). With the introduction of infinity pools, doesn’t this mean that since users can stake unlimited amounts of TKN and BNT, organic yields will be even lower than they are with v2.1?

Additionally, one could argue that Bancor v2.1 did not suffer from a liquidity issue - we had more liquidity than we needed in most pools that were properly co-invested or incentivized with LM. Bancor v2.1 however lagged greatly vs competitors in fees/liquidity income (which maps to non-LM APR), and I don’t see Bancor3 addressing this core issue at all (a 20% 2 hop swap gas reduction isn’t going to cut it since it will still be more than Uniswappy v2 protocols which Bancor3 will be competing against on sidechains and other L1s).

Thanks!

3 Likes

Where’s your data on this statement? Fees w/o accounting for IL means nothing.

2 Likes

Here’s some data -

Our flagship pool, LINK, has an 80% liquidity share but only 24% trade volume share. Turnover (far right) is trade volume / liquidity. As you can see, Bancor trails every major dex in almost every token.

I admit this is volume data and not fees, but it’s hard to get fees from all protocols at any point in time and I don’t have time to do it. That being said, until recently, fees were either at or below Uniswappy v2 protocols, so using volume as a proxy for fees is probably pretty fair to do.

2 Likes

Old FUD. Get new material.

BNT is now the ultimate set/forget index token. Taxable events are basically non-existent as well.
BNT is used as the sole numeraire for all swaps, cross-pool (cross-chain?) with only a single hop required ever.
bn{wrapped} collat will be the ultimate money lego going forward as they are essentially up-only.
Quit playing at Devil’s Adv and do some work

2 Likes

No, it doesn’t necessarily mean that. think the FARM pair. FARMs native yield is something like 30-40%, liquidity provision is much lower than that clocking in a below 10%. if we have say a 50/50 split between that would put the apy dead between 10 and 45 at 25%~, as the superfluid liquidity increases the APY gets higher. It’s really dependant on the applications of superfluid liquidity although the team has expressed they wish to intergrate native token staking. It will be a balancing act, the example you give is only true if Bancors trading liquidity yields > Superfluid Yield.

This is debatable, the only reason univ3 appears to have more fees is because they’ve increased their Impermanent Loss greatly. V3 on UNI is completely unprofitable as was seen by the study Mark put together.

I believe you answered your own question here but you miss the key element that as liquidity in the network grows so does BNTs value from the liquidity depth gained. Also about the, happens quite a bit, part If you compare us to basically any emmisions based protocol we are way winning.

2 Likes

A simple question, what is the yield for staking BNT in V3? Now my BNT is staking in the USDT/BNT trading pair with about 40% yield.

1 Like

Simple question, but I don’t think there is a simple answer.

There was a proposal (passed ?) to fix a BNT emission schedule going forward. So you could assume x% staked and work out the yield.

However, that misses:

  • all the BNT LP fee from swaps (I’m assuming all fees effectively goto the staked BNT, so we we issue more POL $BNT, we should get more fee income for staked BNT).
  • BNT reserved for IL protection uses.
  • What multichain implementation we develop.
  • effect of the vortex.
  • Some BNT added to non rewarded pools will migrate and so dilute the rewards.
  • As the $BNT price increases, the liquidity pools will effectively sell BNT onto the open market, so that results in more BNT circulating, which could be staked (and so lower yields…).

So, I think the answer is “it depends”.

Personally, I’m guessing 15% to 40% APY for $BNT in B3 within the first 6 months of being live. Lower if the BNT price pumps, lower also if AUM doesn’t migrate / grow.

2 Likes

at no point you were able to unlock space with BNT directly (you had to be lucky). buy pressure comes from the fact that bnt recieves 50% of trading fees. my hope is that volume will greatly go up and generate a nice income. people then will buy bnt to get some of the fees.

1 Like

As you suspected, there are no simple answers.

I have just recently made this proposal available. There is indeed a fixed BNT emission schedule proposed. I have also provided a formula there that can help with calculating the BNT/BNT rewards rates over time.

1 Like

Under the infinity pool is says the following. So it sounds like to external users there may still be “funding limit” set by the DAO, such that while it is technically unlimited, it is restricted(by the “BNT funding limit”)?

  • The BancorDAO determines the available liquidity for trading, through adjustment of the “BNT funding limit” parameter.
1 Like

@DFV the funding limit determines the amount of BNT that the protocol can provide to a specific pool, which in turn defines the amount of liquidity used for trading.
So trading liquidity is limited, but the amount that tokens users can deposit into pools is still unlimited, it’s just that only a portion of these tokens will be used for trading.

2 Likes

Thanks @yudi . I see, so as an example, for the USDC pool which always have had no space, what would that mean when that pool is overwhelmed by unlimited deposits under bancor 3, would the APY/APR just drop since only a portion of that is used for trading?

1 Like

@DFV indeed, and the market will find the right APR/liquidity on its own.
Of course the DAO can incentivize more liquidity there by offering rewards.

2 Likes

The draft proposal has been deprecated, and replaced with the following, completed version. A revised google doc is available, and all sections are copied onto this forum (below).

Major changes are:

  • The minimum BNT liquidity threshold has been increased from 1,000 BNT to 10,000 BNT.
  • Additional discussion is included to clarify the utility and behavior of pool tokens, including and especially during the cool down period prior to withdrawal.
  • Minor changes to language and presentation, to help with comprehension by non-experts, and especially non-programmers.
  • Discussion regarding vBNT issuance during migration is now included.
  • Flash loans are now part of the initial Bancor 3 release.
  • Typing errors are corrected, including equations.

Concise Summary of Features

Omnipool

The term “omnipool” refers to the overall reorganization of the new system of smart contracts; it is not a specific feature. In addition to the features detailed below, the omnipool also refers to a single reservoir of BNT; users are no longer required to make a choice as to which specific pool they wish to contribute their BNT liquidity to, as it is deposited into a single network pool. All trades will be routed via the BNT omnipool. BNT stakes generate single-side pool tokens, in addition to vBNT – the governance token of the BancorDAO.

Impermanent (“Divergence”) Loss Protection

Liquidity provided on Bancor 3 is immediately protected from impermanent loss, including all fee revenue accrued thereon. To enable immediate protection, withdrawals are subject to an exit fee, and a cooldown period, both of which are adjustable by the BancorDAO. At launch, these values are 0.25%, and 7 days, respectively.

Single-Side Pool Tokens

Liquidity stakes on Bancor 3 are represented by single-side pool tokens. These pool tokens represent the fully protected valuation of the user’s stake, including all value accrued on the position since the stake was established. These pool tokens are fungible, composable ERC20 tokens.

Infinity Pools

Bancor 3 supports unlimited liquidity provision for all assets in its network. There are two major components in every pool; the trading liquidity, which is used to support exchange, and the superfluid component, which can be used for essentially any purpose. The superfluid component will be of paramount importance in upcoming phases of the Bancor 3 phased rollout. The fate of the provided liquidity is determined by the network settings, which are established via the governance process.

Bootstrapping

Following a successful whitelisting proposal, the network will immediately begin accepting TKN stakes to its superfluid component, where TKN refers to a cryptocurrency token, other than BNT. Trading pools are initialized and bootstrapped by the DAO msig signers, after sufficient liquidity has accumulated. At this time, the superfluid component is partitioned, such that the minimum amount of TKN liquidity is available for trading. Thereafter, the pool depth is allowed to double in size with each new staking action, independent of the size of the stake.

Automatic Shutdown

The logic contained within the functions of Bancor 3 assumes the price quoted by each of its pools is reliable. As pools become illiquid, this assumption is no longer valid. Therefore, to prevent abuse, pools with fewer than 1,000 BNT (adjustable by the DAO) tokens in their reserve following a liquidity add/remove event are automatically dismantled. During a shutdown, all TKN trading liquidity is returned to the superfluid component, and all BNT trading liquidity is removed and burned by the protocol.

Governance

Bancor 3 is under the exclusive control of BancorDAO. The existing governance policies and processes are inherited by the new release, and vBNT continues to serve as the voting token. All contracts, including vaults, are upgradeable, and governed by the DAO alone.

Rewards Programs

Staking incentives are supported by Bancor 3 in two formats: auto-compounding, and standard. Unique to Bancor 3, the auto-compounding rewards are a “gasless” solution that does not require the user to take any additional actions, and is a true single-sided distribution that is without recourse to an intermediate swap step. The auto-compounding mechanism requires the type of reward token and staked token to be the same; in situations where the reward and stake have different identities, the standard rewards format can be used instead. The standard rewards contract is derived from the industry standard established by Synthetix and requires users to manually claim rewards in the familiar way. These rewards programs are open to all projects that wish to use them, for example, to incentivize liquidity for their own assets.

Advanced Withdrawal Logic

Bancor 3 utilizes an improved set of operations to increase the likelihood that users withdrawing from the protocol will receive the full value of their stake including impermanent loss compensation entirely in TKN; the new algorithm attempts to avoid reimbursing TKN liquidity providers in BNT. The logic is symmetrical, and also allows the protocol to better manage its liabilities, resulting in a more financially efficient method of providing impermanent loss insurance.

External Impermanent Loss Protection

To assist the BancorDAO with its risk management, and support whitelisting new tokens, external teams can commit to providing their own token as part of the impermanent loss coverage for their users. The external coverage dampens the potential risks to the protocol, and therefore makes whitelisting potentially volatile tokens more attractive for the DAO. Moreover, the external coverage provides greater assurance to TKN stakers that the value of their withdrawal will be realized exclusively in the TKN they provided.

Bancor Vortex

The function of the Bancor Vortex remains unchanged in the new release; however, its specific behavior is modified to be more efficient. Rather than collecting a wide variety of token types, the Vortex on Bancor 3 will collect BNT exclusively; fees earned in TKN are swapped immediately for BNT. Therefore, triggering the Vortex results in a single swap of BNT for vBNT directly, rather than a myriad of swaps across numerous TKN pools for BNT as a first step. This simplified arrangement has consequences both for the effective value burned, and an improved gas efficiency overall.

Migration

The transition from v2.1 to Bancor 3 can be performed via a “one click” process. Users with many unique stakes on a single pool will benefit from batch transfers of these positions. Gas costs are dependent on the number of unique pools a user has staked to. With the full deployment of Bancor 3 contracts, the rewards programs on v2.1 will be stopped; it no longer makes sense to incentivise liquidity there after Bancor 3 is available. An alternative rewards program will be created on Bancor 3, and serves to further incentivise users to migrate.

Flash Loans

Bancor 3 will allow users to borrow arbitrary quantities of tokens without providing collateral, so long as the loan is repaid within the same transaction.

Abridged Description of Bancor 3

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

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.

Impermanent (“Divergence”) Loss Protection

  • The goal of impermanent loss protection is for the value of a user’s principal, and all fees and rewards earned thereon, to be 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 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.

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.
    • Tokens on the Bancor Network are stored in a 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 confirms the current status of the TKN provided, using external market prices (e.g. CoinGecko, Coin Market Cap) and initializes the pool to begin trading if there is sufficient value to meet the threshold for minting the minimum BNT liquidity. The minimum BNT threshold is 10,000 at the launch of Bancor 3, and is adjustable by the BancorDAO thereafter.
      • 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 removes the requirement 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, which may be a relevant factor for some of those voting on the whitelist proposal in the BancorDAO governance process.
  • 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 collected 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 collected 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 retired. Unclaimed rewards from v2.1 will be recorded, and made available as a one-time claimable airdrop (at a massive reduction in gas costs).

Flash Loan Support

  • All assets in Bancor v3 can be borrowed using flash loans.
  • A flash loan is a Web 3 innovation giving anyone access to vast amounts of capital for a single block, while using the blockchain to guarantee that the funds are all returned (in addition to a fee).
  • Flash loans must be returned in the same block they are borrowed.
  • This makes it difficult to use web3 for flash loans unless one has access to a platform that can bundle transactions together.
  • This leads to sometimes deploying bespoke contracts with a series of transactions to execute before and after a flash loan, as this naturally bundles them together.
  • Platforms such as Flashbots do have web3 transaction bundles, however, and can be used to execute complex flash loan strategies.

Comprehensive Description of Bancor 3

Re-evaluating the Insurance Vesting Time

The original economics paper explored a generic scenario where the impermanent loss associated with a user’s stake, and the value thereof, is dissected using established models. The approach was deliberately simplistic, and conservative. For a new protocol with a novel insurance mechanism, the constraints afforded benefits in its ease of communication, and easily accessible analytics. It is from these calculations that the insurance vesting period was determined, which protected the protocol from speculated risk during its launch phase.

These calculations have been repeated without these assumptions, using a Monte Carlo simulation method informed by data gathered over the last 12 months of Bancor operations. The results support a far more optimistic insurance vesting period, which can allow for the current schedule to be retired. Importantly, this creates an opportunity to remove the most stubbornly difficult property associated with user positions, and effectively clears a path towards a fully-fungible, composable, ecosystem within Bancor.

The assumptions made during the construction of the previous model resulted in a square root profile for the option value over time; the option value grows very quickly on short time frames, and then flattens out over longer time frames. The break-even point was deduced using a relative volatility of 100%, and approximate APY of 40%. Neither of these assumptions have proved an accurate reflection of reality; however, it was from this data that the 100 day protection threshold was founded. Under the new analysis, the situation is far less worrisome. The real option value is practically linear, and ultimately benign, even on short time frames.

The trend on short time frames is towards a flat line with a slightly negative gradient for volatilities at or below 100%; longer timeframes and higher volatilities produce some notable curvature. These charts can be used to derive the breakeven APY directly from volatility and holding period. At 100% volatility, the breakeven APY starts at 25%, and is reduced to ~22% after 12 months, reflecting a very gentle gradient. At lower volatility ranges the slope is practically non-existent; at 50% volatility, the breakeven APY starts at 6%, and is reduced to 5.8% after 2 years.

This is an important realization, as it also helps to re-evaluate an option-based attack vector. Due to the flatness of these curves, the opportunity to extract value via the effective provision of free options by the protocol is significantly reduced, and only remains practical in instances where volatility exceeds 100%. Moreover, the specific route of this hypothetical exploit - a type of arbitrage - might not be possible to perform. Contributing liquidity for short time periods before withdrawal, and assuming a volatile move, does increase the cost of insurance to the protocol. However, the profit accrues to arbitrageurs, not to the person providing and withdrawing the liquidity; therefore there is no profit motive for the liquidity provider to behave this way. Regardless, the apparent attack vector requires an appropriate response. To this end, the prohibitively protective mechanics (i.e. the 100-day vesting period) are replaced with a short cooldown period, and a small fee only at the moment of removing liquidity. Taking these points under consideration, user deposits can be treated as completely protected from impermanent loss from the first instant.

A 7-day Cool-Off Period

If an attack vector exists, either discretely or abstractly, its frequency and potential damage can be effectively nullified with the introduction of a mandatory waiting period, prior to the withdrawal of user’s funds. Compared to the current 100 day vesting period, a 7-day cool-off represents an effective drop of 93% in mandatory wait time prior to full protection. In context, the additional prudency still affords users an improved offering, without conceding any vulnerabilities to the system.

Exit Fees

As a final circumspection against bad behavior, exit fees are introduced into the Bancor ecosystem for the first time. The exit fee is designed to temper the profit motive of the imagined exploit vector. Fortuitously, the severity of the speculative attack is fairly minor, and a 0.25% exit fee is sufficient to render it void. The exit fee is treated as a relief mechanism, and allows the pools from which a withdrawal is processed to retain a small amount of residual value, which alleviates the insurance burden by the same amount. It also serves a financial purpose in defining a geometric surface, beneath which users can withdraw their stake entirely in its own denomination, regardless of the relative surplus or deficit state of the network. This point is discussed in detail while addressing the behavior of the withdrawal algorithm.

Single-Sided Pool Tokens

The proposed upgrade fundamentally changes the meaning of pool tokens in AMMs. The AMM pool token concept, or “smart token”, was introduced by Bancor with its initial whitepaper and persists essentially unaltered to the present day. The concept was built around the assumption that liquidity providers would participate in both sides of the pool; however, with the introduction of single-sided staking by Bancor, a revision of the pool token idea is overdue. Bancor v2.1 still makes use of traditional pool tokens, although their role in the system is permanently obscured from view. A plethora of auxiliary mechanisms are required to support single sided staking, which can largely be replaced by a purpose-built system that assumes the contribution of only one token, rather than two or more.

Single-Sided Stakers as First-Class Citizens

To establish a system that assumes single-asset staking, the logic surrounding pool tokens is overhauled. The elimination of insurance vesting, outlined above, eliminates the non-fungibility of user stakes and provides the foundation from which the new pool token logic is constructed.

Single-sided pool tokens are no longer explicitly linked to the sum of the pool reserve balances. However, their value must still be determined as a share of something. For the purpose of this document, the pooled value is referred to as the “staked amount”, which is necessarily treated entirely independently of pool reserves. To achieve this, the protocol must maintain a separate ledger for staked amounts, that is updated with every swap to account for the accumulation of fees.

The system is easiest to understand assuming it is already established; exploring the transition from the current system to the new one, or the transformation of a pool following a whitelisting decision are considerably more involved. Therefore, the following sections are organized according to their relative intuition. First, the system is described assuming the establishing steps have already occurred, without any attention paid to what these steps were, or how they were done. Then, the more onerous challenge of addressing the establishing steps are handled in their own section.

Bootstrapping Behavior

To illustrate how the system works, we will constrain the system to an oversimplified case with only three pools: ETH, wBTC and LINK, in addition to the BNT omnipool. Assume that these pools have just recently earned whitelist status, they each have a BNT funding limit of 40,000 BNT, and all are completely empty.

The protocol is in the “bootstrapping phase” for all three assets. Users can still interact with the system and deposit liquidity - which is essential for the process. The system needs to attract sufficient quantities of each token to overcome the minimum liquidity threshold prior to the activation of each liquidity pool, respectively. The default minimum liquidity threshold is 10,000 BNT (previously 1,000 BNT in an earlier draft of this proposal), meaning that the pool must mint 10,000 BNT during its activation, and therefore there must be at least a commensurate value of TKN available in the vault. Assume that the prices of each asset are as follows: BNT = $2.50, LINK = $15.00, ETH = $2,500.00, wBTC = $40,000.00. Therefore, to bootstrap each pool, at least $25,000 of each asset must be available in the vault.

During the bootstrap phase, Alice deposits 100 ETH, Bob deposits 100 bnwBTC, and Charlie deposits 10,000 LINK. By default, the initial pool token value is 1:1 with the underlying asset, and only changes after revenue begins accumulating. Therefore, each of these characters receive 100 bnETH, 100 bnwBTC and 1,000 bnLINK pool tokens for their contribution, respectively, and the balances of the staking ledger are updated accordingly.

However, the trading liquidity available on the pools remains unchanged until the BancorDAO msig signers initialize each pool.

The condition to initialize a pool is that there must be at least 10,000 BNT ($25,000 at the quoted price) worth of each token - in this case all three satisfy the criteria. The BancorDAO msig signers then sign a transaction with the rate of BNT/TKN for each of the bootstrapping assets. In this case, BNT/ETH = 1,000, BNT/wBTC = 16,000, BNT/LINK = 6. The trading liquidity on each pool begins with exactly 10,000 BNT and the commensurate amount of TKN as determined by the rates supplied by the msig signers.

It is important to note here that each of these pools have been stated to have a 100,000 BNT funding limit, 10× higher than the bootstrapping depth. This is because the pools should equilibrate with the rest of the market and grow in a controlled manner. Therefore, only a fraction of the available ETH, wBTC and LINK has been committed to trading at this stage. The other important change is that the BNT that was created by the protocol causes its own pool token to be issued, bnBNT, which becomes the property of the Bancor Protocol.

Fortunately, the rate at which the pool can grow is independent of the new liquidity additions, and is determined entirely by the token balances available in the vault. To demonstrate, suppose that each user deposits just 1 more TKN each to their respective pools; Alice deposits 1 ETH, Bob deposits 1 wBTC, and Charlie deposits 1 LINK. Each of these tokens is accepted directly to the vault. Assume that no trading has yet occurred on the pool, therefore the valuation of each pool token remains at 1:1 for the time being. Therefore, each user is issued one additional bnTKN.

The most important point to note in the change in the system state depicted above is that the additional 1 TKN unit staked was essentially ignored - when the protocol is changing the available trading liquidity, the total vault balance is taken into account, rather than the amount the user has just provided. Each of the pools where a new TKN was staked resulted in a doubling of the available trading liquidity.

Trading and Fees: Implementation Note

The equations depicted here describe the transition between states; not the method. In the paragraphs below, the nature of the trades and fees on Bancor, including the Bancor Vortex is described. A portion of the swap revenue is collected and swapped back for BNT atomically, as part of the trade. This is how the contracts behave mathematically. After the vortex fee amount is determined, the swap function is simply called using this number as the input. The equations below are inclusive of all steps, but aren’t featured in the code.

Trading and Fees: BNT to TKN

Continuing from the system state described above, the details of how the trading pools are used as a price oracle, the behavior and purpose of the price EMA, and the response of the staking ledger to the accumulation of swap revenue will now be discussed in detail. For the purpose of demonstration, let each of these pools have a 1% swap fee, and a Vortex rate of 20%.

Assume a trader swaps 2,000 BNT for LINK; from the perspective of the trader, 2,000 BNT are sent into the vault, and 300 LINK are removed from the vault and sent back to him. The change to the system state is much more involved. The change in the vault balances agrees with the trader; 2,000 BNT is received, and 300 LINK was emitted. However, the change in the available trading liquidity presents the first evidence of a consequence of the new design.

While the vault balance of BNT was increased by the expected amount, the change in the available trading liquidity is less than this amount. The difference is due to the effect of the Bancor Vortex, which confiscates a portion of trade revenue as a form of insurance premium, that helps to stabilise the BNT economy. In this case, the fee apparent to the trader is 0.303 LINK; the Bancor protocol awards 80% of this amount to LINK liquidity providers (i.e. 0.2424 LINK) by simply iterating the staking ledger. The remaining 0.0606 LINK are used to perform a reverse swap, and purchase BNT atomically at the tail end of the trade. This BNT is removed from the trading liquidity, but it continues to reside in the vault. The fraction of the BNT tokens belonging to the vortex is recorded on the Vortex Ledger; the fate of these BNT tokens is discussed in detail in a later section.

Therefore, during the trade the following components of the system were changed:

  1. The vault balances. The change in the vault is always in agreement with the trader’s intuition. In this case, the trader sent 2,000 BNT into the vault, and received 300 LINK from it. Therefore, the vault balance of BNT must have increased by 2,000 BNT, and decreased by 300 LINK.
  2. The staking ledger. Trading fees are always taken from the target asset. Therefore, the value of the bnLINK pool token must be appreciated by 80% of the fee apparent to the trader (i.e. the total fee - vortex rate). A total of 2.42424 LINK tokens are added to the staked amount, which becomes the property of the bnLINK pool token holders.
  3. The vortex ledger. One fifth of the fee paid by the trader is collected, and swapped back to BNT. The BNT purchased during this step is left where it is inside the vault, and the amount is added to the vortex ledger.
  4. The trading liquidity. After accounting for the effect of the collection by the vortex, and the swap back to BNT, the reason for the changes in the trading liquidity to appear as they do, become apparent.

The change in the BNT and LINK trading liquidity can be expressed as follows:

where a1† and a1 are the BNT trading liquidity balances of the pool after and before the trade, respectively, b1† and b1 are the LINK trading liquidity balances of the pool after and before the trade, respectively, d1 is the pool fee (e.g. 0.01, or 1%) and e is the Vortex rate (e.g. 0.2, or 20%). The number of BNT tokens being sent into the vault is x, and the number of LINK tokens sent back to the trader is tknOut. The change in the TKN trading liquidity (and therefore the amount of TKN received by the trader) is unchanged from the standard case. The calculation of the fee awarded to liquidity providers, denominated in its own TKN and added to the staking ledger is:

And the calculation for the fee given to the Bancor Vortex, denominated exclusively in BNT and added to the vortex ledger is:

Trading and Fees: TKN to BNT

Assume now that a trader wants to perform the opposite action, perhaps to close an arbitrage opportunity left open by the previous swap. The trader sends 302.9981 LINK into the vault, and the vault sends 1977.6155 BNT to the trader. As before, the trader’s intuition agrees with the changing state of the vault balances; however, the changes in the trading liquidity and staked balances require closer examination.

In this trade, the target asset is BNT. Therefore, there is no need to perform a second, virtual swap at the end of the trade. Instead, the vortex fee is taken directly from the effective fee. Importantly, this results in a slightly reduced change in the growth of the BNT trading liquidity as judged from the trader’s perspective. The trader’s fee totals 19.9759 BNT, of which 3.9952 BNT becomes the property of the Bancor Vortex. The difference (15.9807 BNT) is added to the BNT staking ledger, and causes the value of the bnBNT pool token to appreciate.

Therefore, during the trade the following components of the system were changed:

  1. The vault balances. The change in the vault is always in agreement with the trader’s intuition. In this case, the trader sent 302.99814 LINK into the vault, and received 1977.615545 BNT from it. Therefore, the vault balance of LINK necessarily increased by 302.99814 LINK, and decreased by 1977.615545 BNT.
  2. The staking ledger. Trading fees are always taken from the target asset. Therefore, the value of the bnBNT pool token must be appreciated by 80% of the fee apparent to the trader (i.e. the total fee - vortex rate). A total of 15.980731 BNT tokens are added to the staked amount, which becomes the property of the bnBNT pool token holders (at this point in the narrative, is the protocol only).
  3. The vortex ledger. A portion of the fee paid by the trader is effectively collected, and added to the vortex ledger.
  4. The trading liquidity. The apparent disagreement between the intuitive result, and the one obtained, is accounted for by the effect of the BNT collection by the vortex.

The change in the BNT and LINK trading liquidity can be expressed as follows:

where a1† and a1 are the BNT trading liquidity balances of the pool after and before the trade, respectively, b1† and b1 are the LINK trading liquidity balances of the pool after and before the trade, respectively, d1 is the pool fee (e.g. 0.01, or 1%) and e is the Vortex rate (e.g. 0.2, or 20%). The number of LINK tokens being sent into the vault is x, and the number of BNT tokens sent back to the trader is bntOut. The change in the TKN trading liquidity (and therefore the update to the available LINK trading liquidity) is unchanged from the standard case. The calculation of the fee awarded to liquidity providers, denominated in BNT and added to the staking ledger is:

And the calculation for the fee given to the Bancor Vortex, denominated exclusively in BNT and added to the vortex ledger is:

Trading and Fees: TKN to TKN

Assume now that a trader wishes to exchange 1 ETH for wBTC. From their perspective the process is similar to that described above. A total of 1 ETH tokens are sent into the vault, and the vault sends 0.055712824 wBTC tokens back, and the change in the vault balances agree with the trader’s intuition (as before). However, this situation compounds the effects described in the previous two sections. The changes in the trading liquidity balances, and the accumulation of value to the vortex ledger, can be deduced by considering the two separate legs of the process:

  1. Swap 1 ETH for 942.857143 BNT

  2. Add 7.619047619 BNT to the staking ledger

  3. Add 1.904761905 BNT to the vortex ledger

  4. Swap 942.857143 BNT for 0.055712824 wBTC

  5. Add 0.000450205 wBTC to the staking ledger

  6. Add 1.973681795 BNT to the vortex ledger

It is important to realize that there is no BNT transfer, despite both pools reporting a change to the BNT trading liquidity. A virtual trade has been performed, where BNT is still used as numeraire, and which allows for the relative value of ETH and wBTC to be known. Since the liquidity pools are virtual, their relative balance of BNT can be adjusted as though the tokens were sent, when in fact the BNT remains where it was in the vault. Thus, a quasi-single hop trade is achieved.

Therefore, during the trade the following components of the system were changed:

  1. The vault balances. The change in the vault is always in agreement with the trader’s intuition. In this case, the trader sent 1 ETH into the vault, and received 0.055712824 wBTC from it. Therefore, the vault balance of ETH must have increased by 1 ETH, and decreased by 0.055712824 wBTC.

  2. The staking ledger. Trading fees are always taken from the target asset, in this case there are two:

  3. The first virtual trade to BNT, resulting in a 7.619047619 increase to the BNT staked balance.

  4. The second virtual trade, resulting in a 0.000450205 increase to the wBTC staked balance.

Therefore, the value of the bnBNT pool token, and wBTC pool token must be appreciated by 80% of the fee apparent to the trader (i.e. the total fee - vortex rate).

  1. The vortex ledger. Both virtual trades have an apparent effect on the vortex ledger. In the first virtual trade to BNT, one fifth of the fee paid by the trader is collected by the vortex directly; in the second virtual trade, one fifth of the fee in wBTC is swapped back to BNT. Both are added to the BNT balance of the vortex ledger.
  2. The trading liquidity. The changes to the trading liquidities on both pools can be understood after accounting for the effect of the collectionby the vortex.

The change in the BNT, ETH, and wBTC trading liquidity can be expressed as follows:

where a1† and a1 are the BNT trading liquidity balances of the source pool (BNT-ETH) after and before the trade, respectively, b1† and b1 are the TKN trading liquidity balances of the source pool (BNT-ETH) after and before the trade, respectively, a2† and a2 are the BNT trading liquidity balances of the destination pool (BNT-wBTC) after and before the trade, respectively, b2† and b2 are the TKN trading liquidity balances of the destination pool (BNT-wBTC) after and before the trade, respectively, d1 is the source pool fee (BNT-ETH, e.g. 0.01, or 1%), d2 is the destination pool fee (BNT-wBTC, e.g. 0.01, or 1%), and e is the Vortex rate (e.g. 0.2, or 20%). The number of ETH tokens being sent into the vault is x, and the number of wBTC tokens sent back to the trader is tknOut. The change in the ETH trading liquidity (and therefore the update to the available ETH trading liquidity) is unchanged from the standard case. The calculation of the fee awarded to the bnwBTC, and bnBNT pool token holders is:

And the calculation for the fee given to the Bancor Vortex, denominated exclusively in BNT and added to the vortex ledger is:

The Moving Average

A moving average is utilized as a security measure, where sudden changes in the pool reserves can be detected, and prevent abuse of the protocol’s features. The moving average (ema) is updated with the first trade of the block, for any asset according to the following formula:

where r is the spot rate in units of BNT/TKN as determined by the trading liquidity balances of the pool, and α is an arbitrary constant that determines the responsiveness of the moving average. The α term is a global variable, set at 0.2 (or 20%) at launch of Bancor 3, and is intended to provide a consensus rate for the pool that is resistant to virtual price manipulation attacks. The following chart is an arbitrary depiction of the ema behavior relative to the spot price on a per-block basis. The ema is measured and updated before an action is executed; therefore, the ema response is delayed by a minimum of one action (e.g. a trade or add/remove liquidity event). Further, the ema is only adjusted once per pool, per block.

At genesis, the ema rate is set equal to the spot rate. Therefore, in the above scenario each of the liquidity pools began with the following rates:

However, the trading situations do have an effect. To demonstrate, assume that the trades described above happen on consecutive blocks. For the LINK trading pool, both the spot rate and the ema begin at 6, as set at the genesis of the pool. Since the ema is adjusted before the trade is executed, the first trade has no effect on the ema; the spot price changes as expected. The new spot price becomes relevant in the next block, as the ema is updated prior to performing the second trade. First, the ema is updated using the new spot rate, then the second trade is processed. In this example, the lag of the ema means there is a significant gap between it and the spot price after the first block; however, the adjustment in the second block, prior to executing the second trade, results in a close agreement thereafter.

Since only one trade has been executed on both the ETH and wBTC pools, the moving average for both remains at the genesis rate (i.e. the ema will update to the during the next trade).

Staking TKN

The ema serves as a detection mechanism for unusual spikes in the price of an asset against BNT, and prevents changes to the depth of the trading pools to protect the system from harm. To illustrate the effects of the ema, the current state of the system in the present narrative will be carried forward, with each of Alice, Bob, and Charlie providing one additional TKN to the system. Unlike the prior examples where liquidity is added, both the ema, and the pool token valuation need to be taken under consideration.

Before the demonstration continues, recall that each of the pools have a preset 4,000 BNT funding limit at this point in the narrative, and up to this point in time all three have only exhausted half of that amount. Further, recall that the ability to increase the available trading liquidity is determined by the vault balance of the TKN in question, and the current depth of the pool, rather than the amount being contributed by a user during any deposit event.

Alice now deposits 1 ETH. Since no fees have yet accrued to the bnETH pool tokens (i.e. ETH has not yet been the target of any particular trade), the value of the bnETH pool token remains unchanged. Her 1 ETH is added to the vault, the staking ledger is updated, and a new pool token is created for Alice.

Assume that this deposit is occurring on a block wherein no actions have taken place on the ETH pool. Therefore, the ema has not been updated in this block, and it remains where it was. This allows for the effective price quoted by the pool to be evaluated with a view to detecting artificial price manipulation. The protocol’s confidence is determined by the relative deviation between the ema and spot prices; the protocol will only allow the pool’s trading liquidity to be changed if the difference between these values is small.

In this instance, the addition of Alice’s 1 ETH occurs when the ema on ETH remains at 1,000, whereas its spot rate is 907.26. The deviation between the spot rate and the ema is measured relative to the ema, as follows:

Since Δ is fixed at 0.01, the equation above can be expressed as the following boolean:

where r is the spot rate. In this case, Δ is 0.0927; the tolerance of the protocol is 0.01. Therefore, the protocol will not allow the trading liquidity to be changed on this block. However, Alice’s 1 ETH is still accepted into the vault, and she is issued bnETH pool tokens as normal. Since there is no change to the trading liquidity, the protocol will not mint BNT, and will not issue itself bnBNT.

Bob now deposits 1 wBTC. In contrast to Alice’s situation, fees have accumulated on the wBTC pool token. Therefore, the rate of pool token issuance is affected. The staking ledger is reporting a staked amount of wBTC of 101.00045, and the supply of bnwBTC is 101. Therefore, the rate of bnwBTC to wBTC is 0.999995543, and this quotient determines the number of bnwBTC pool tokens Bob will receive.

Assume that this deposit is occurring on the same block as Alice’s deposit, where the trade between ETH and wBTC had been executed on the prior block. Therefore, the wBTC ema has not been updated in this block, and also remains at the genesis rate.

In this instance, the addition of Bob’s 1 wBTC coccurs when the ema on wBTC remains at 16,000, whereas its spot rate is at 17,534. The deviation (Δ) between the spot rate and the ema is 0.0959, and as before, the protocol will not allow the trading liquidity to be changed on this block. Regardless, the vault still accepts Bob’s wBTC, and issues him bnwBTC as normal.

Charlie now deposits 1 LINK. As was the case for Bob, the fee accrual on bnLINK will affect the issuance of pool tokens. The staking ledger is reporting a staked amount of LINK of 10,003.42, and the supply of bnLINK is 10,001. Therefore, the rate of bnLINK to LINK is 0.999758, and the issuance of bnLINK to Charlie is determined by this number.

Assume that this deposit occurs on the block following the two LINK trades previously discussed. In this instance, the addition of Charlie’s 1 LINK occurs when the ema on LINK is 5.9998, whereas its spot rate is at 5.9988. The deviation (Δ) between the spot rate and the ema is 0.00017, which is inside the tolerance levels of the protocol, and the protocol will allow the trading liquidity to update.

Trading liquidity always updates according to a strict set of criteria. In simple terms, the protocol will always try to increase the liquidity by as much as possible, up to a maximum BNT liquidity increase of 2× relative to the current depth, and without exceeding the preset funding limit. In this example, the current BNT depth on the LINK pool is 20,013.993668. Therefore, with a sufficient funding limit, the pool could double in size, up to a maximum BNT depth of 40,027.98734 BNT. However, the protocol has previously contributed 20,000 BNT of its 40,000 BNT funding limit - it can only increase the trading liquidity by a maximum of 20,000 BNT. The protocol will always default to the smallest of these two values.

By convention, the protocol trusts the ema rate over the spot price. Therefore, in this example, the BNT/LINK quotient is treated as 5.9998. The maximum allowed increase is the BNT funding limit, 20,000 BNT. Therefore, 3333.998732 LINK and 20,000 BNT are added to the trading liquidity. As the protocol is minting BNT, it is simultaneously issuing new bnBNT pool tokens for itself. Since the bnBNT pool token has appreciated in value, this will need to be taken into account.

The staking ledger is reporting a staked amount of BNT of 60,022.384, and the supply of bnBNT is 60,000. Therefore, the rate of bnBNT to BNT is 0.999627065. As the protocol mints 20,000 BNT to increase the trading liquidity, this amount is added to the BNT staking ledger, and the protocol issues itself 19,992.5413 bnBNT pool tokens.

Unstaking TKN

Withdrawals are predicated on two equally important concepts:

  • Liquidity providers should be able to withdraw their stake entirely in the token they provided.
  • Any withdrawal should not affect the stakes of other users.

The challenge to meeting these criteria is that the staked amounts will rarely be in agreement with the vault balances. The scale of the problem is also dependent on the proportion of the overall staked amounts being withdrawn by the user, and the relative deficit or surplus for the same TKN. Bancor 3 introduces a novel algorithm for processing withdrawals, which has been constructed specifically for use with the new architecture. This aspect of the protocol’s activities is the most technically challenging to understand. To help structure this part of the discussion, the examples will diverge from the narrative presented up to this point, and will instead use arbitrary cases to demonstrate the logic and consequences of the algorithm.

The state of the system is described using the following variables, and each is a discrete input in the withdrawal algorithm:

a, the BNT balance of the trading liquidity, as judged from the spot rate.

b, the TKN balance of the trading liquidity, as judged from the spot rate.

c, the difference between the TKN balance of the vault, and the TKN trading liquidity.

e, the TKN balance of the staking ledger.

m, the associated pool fee for the TKN being unstaked.

n, the exit fee of the system.

w, the TKN balance of the external protection wallet.

x, the precise TKN value of the bnTKN tokens being withdrawn.

The role of the moving average in unstaking actions is slightly different to staking actions. First and foremost, if the deviation (Δ) exceeds the protocol tolerance, the transaction is simply reverted; it is not possible to calculate a ‘default’ withdrawal if there is strong disagreement between the moving average and the spot rate. For the rest of this discussion, it is assumed that this tolerance check has passed.

Pool 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 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 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.

Committing to the Cooldown

As described above, users commit to a 7-day cooldown period before their withdrawal is processed. Importantly, the total number of TKN that can be redeemed for the pool tokens relinquished by the user is determined at the commencement of the cooldown period. Therefore, any value appreciation on the pool token (i.e. additional trading fees and/or auto-compounding rewards) during the cooldown period is effectively forfeited. However, the user may elect to cancel their withdrawal at any time, at which point the forfeited value appreciation is returned.

Consider the following situation. A user has 1,000 bnTKN tokens, valued at 2,000 TKN. After deciding to withdraw, they commit their bnTKN to the cooldown contract, and their value is recorded (x).

After 7 days have passed, the user will be entitled to receive the value associated with their stake, at the time the cooldown process was started. Imagine that during this time, the accumulation of rewards and/or trading revenue caused the bnTKN valuation to appreciate.

At any point during, or after the cooldown, the user may elect to cancel the withdrawal process. Moreover, once the cooldown process has completed, the user has unlimited time to make a decision. However, the value of their withdrawal (x), will persist; if the user commits to the cooldown and then waits a century before confirming the withdrawal following the cooldown, the value of their withdrawal remains the same as it was when they started the process. However, the moment they cancel the withdrawal, the x value is erased, and the bnTKN tokens are returned to their wallet. The action of re-committing to the cooldown then generates a new x value, and thus the user can easily retrieve any lost fees and rewards, assuming their cooldown period was poorly timed. In the example above, the user can improve their withdrawal valuation by 4.095% if they cancel, and then begin the cooldown again.

Introduction to the Withdrawal Algorithm

After a withdrawal has been confirmed by the user, the protocol’s task is to deliver the withdrawal value back to the user, either entirely in TKN, or as a combination of TKN and BNT. The design of Bancor 3 assumes that users prefer to receive their withdrawal denominated entirely in TKN. Naively, it seems impossible to return all funds denominated in TKN to the user, if the total TKN in the vault is less than the staked balance, without exacerbating the deficit further. Therefore, in cases where the vault balance of TKN is less than the amount staked, the protocol has an obligation to cover the deficit via BNT minting. While true, one could argue that the user is likely to use the BNT they are issued to perform a swap for the TKN that was withheld. In doing so, the user indeed removes additional funds from the protocol; however, such an action also opens an opportunity wherein an arbitrageur will return the pool to balance, and restore the relative deficit of the system.

The opposite is also true. Imagine the antithetical case where users provide BNT exclusively, and the protocol mints the TKN side of the pool. During a BNT deficit, a user’s withdrawal may be partially reimbursed in TKN, which they may immediately swap back for BNT. As they perform the swap, the relative price of BNT is increased vs TKN, then rebalanced with external markets through the actions of arbitrageurs.

This is an important realization. The assertion that BNT must be used to compensate TKN liquidity providers directly, (and by extension, TKN to BNT providers in an imaginary version) becomes weak. Rather than give the user BNT for them to swap, the swap can be made an implicit component of the withdrawal. Further, TKN in excess can be used to recover lost BNT, and help to maintain a healthy equilibrium between the protocol and its environment.

While this reasoning is good, it is also incomplete. The value of a swap is impacted by slippage, and therefore the depth of the pool, as well as its swap fee. Moreover, the fact that a BNT minting event could be coupled with an implicit swap opens the protocol to potential abuse through withdrawal back running attacks, which artificially increases the value of a user’s withdrawal. As alluded to in an earlier section, a withdrawal fee of 0.25% is introduced, and is used to evaluate the explicit exploitability of the method. In short, so long as the back running profit margin is equal to or less than the value represented by the withdrawal fee, then the protocol will allow the user to withdraw the totality of their position exclusively in TKN, regardless of the deficit. Similarly, the protocol will attempt to recover BNT by quoting it at a higher price when withdrawals are performed during a TKN surplus state, only if the arbitrage value is less than the withdrawal fee.

In addition to these considerations, the protocol also maintains an awareness of the current pool depth, and the TKN available in the vault which are not presently available as trading liquidity on the pool. The withdrawal algorithm simultaneously handles these considerations, such that the user’s withdrawal is taken exclusively from non-trading vault reserves where possible, and the anticipated, rebalanced state of the pool returns to its prior depth level. One way to visualize this behavior is to imagine the continuum of both the available trading liquidity, and non-trading liquidity as a proportion of the balance on the staking ledger. Let these proportions be the x and y axes of a three-dimensional plot, where the z axis represents the relative size of any withdrawal, relative to the total balance of the staking ledger. The resulting plot describes a surface, the volume under which defines all possible withdrawals where the protocol can exercise the logic above without causing itself financial disadvantage. Importantly, the exit fee and swap fee for the specific asset undergoing withdrawal change the shape of the surface. The plot below assumes a swap fee of 0.2% and a withdrawal fee of 0.25%.

TKN Surplus Examples

A TKN is in surplus if the total vault balance is greater than the staked amount, after accounting for the exit fee. It is necessary to separate the vault balance into the trading liquidity (b), and non-trading liquidity (c) components; b + c is the vault balance of TKN:

where e is the TKN balance of the staking ledger, and n is the withdrawal fee (e.g. 0.0025, or 0.25%). So long as the above expression evaluates as True, the protocol is in an effective surplus (i.e. the quantity of TKN exceeds that of the combined user stakes). Therefore in all cases, it is guaranteed that any user withdrawing will receive only TKN. However, the protocol will also attempt to reduce the surplus and recover BNT from the secondary markets. The following paragraphs will explore the three different situations that cover the discrete behaviors of the withdrawal algorithm during a surplus state of TKN.

The most important decision the protocol makes is to evaluate the abuse vector described above. To do this, two important thresholds are calculated, hlim and hmax; the former determines whether there is sufficient non-trading TKN in the vault to support the user’s withdrawal without changing the trading pool depth, and the latter determines if an apparent abuse vector exists. These two values are calculated as follows:

These two values, hlim and hmax, define the maximum value for x that is allowable without creating a possible abuse incentive. Therefore, the user’s withdrawal amount (x) must be less than both hlim and hmax:

To examine this further, consider the following case: the staking ledger reports a staked balance of 1,400 TKN (e), the vault balance of TKN is 1,500 TKN (b+c), the TKN trading pool has 1,000 TKN (b) and 1,000 BNT (a) in available liquidity. Then, a user confirms a withdrawal for 100 TKN (x).

In this case, hlim evaluates to 466.6667 TKN, and hmax evaluates to 501.486064 TKN. As the user’s withdrawal amount (x) is less than both of these values, there must be sufficient non-trading TKN in the vault to support the withdrawal, and there is no financial incentive to create the withdrawal for the purpose of back running. Therefore the protocol can attempt to recover a small amount of BNT from the outside markets.

The withdrawal algorithm has six different outputs:

P, BNT quantity to remove (burn) from the available trading liquidity.

Q, BNT ownership renounced by the protocol (i.e. removed from the staking ledger).

R, TKN quantity to add to the available trading liquidity from the non-trading liquidity.

S, TKN quantity to remove from the vault (and send to the user).

T, BNT quantity minted for, and sent to the user as compensation.

U, TKN removed from the external protection wallet and sent to the user as compensation.

The method for calculating each of these outputs is dependent on the state of the system. The case where there is a TKN surplus, and the user’s withdrawal satisfies the hlim and hmax checks, the outputs are calculated as follows:

It is important to note that during a surplus, the algorithm reacts by moving the price of BNT vs TKN in the pool; note that the pool began with a spot rate of 1:1, and arrived at a slightly higher price for BNT at the conclusion of the process. This repricing is such that, if and when the pool returns to balance (defined as state of the pool before the withdrawal was executed), the relative surplus of TKN compared to the staked balance will remain constant, (ignoring vortex fee effects). In essence, either the valuation of BNT is allowed to increase vs TKN, or the closing of a future arbitrage opportunity positively affects the total BNT balance of the protocol. The number of BNT burned from the trading liquidity is equal to the amount that would be returned in a hypothetically perfect arbitrage, assuming the rate inside the pool is in agreement with consumer expectations (i.e. the rest of the market). This anticipatory BNT is part of the process - while BNT is lost from the trading liquidity in this case, the protocol does not relinquish its pool tokens. It might be helpful to think of this as a small trade of TKN to BNT having just occurred. Whether or not the apparent arbitrage opportunity is closed immediately is irrelevant; for example, it is likely that these small adjustments will occasionally close existing arbitrage opportunities. It is only important that a compensatory action is taken by the protocol that addresses the implicit BNT valuation and/or its liquidity equilibrium state.

Such actions can only be taken if the hlim and hmax tests evaluate to True. To examine a case wherein these tests do not pass, consider a scenario nearly identical to that presented above, but where the non-trading TKN balance (c) is increased to 1,000 TKN. Therefore, the staking ledger reports a staked balance of 1,400 TKN (e), the vault balance of TKN is 2,000 TKN (b+c), the TKN trading pool has 1,000 TKN (b) and 1,000 BNT (a) in available liquidity, and the user confirms a withdrawal for 100 TKN (x).

In this case, hlim evaluates to 700 TKN, and hmax evaluates to 18.208192 TKN. For this scenario, the hlim test still passes, but the hmax test fails. Therefore, the protocol’s repricing strategy is potentially abusable, and the withdrawal algorithm will default to a different set of operations. As the protocol prefers to not interfere with the depth of the pool where possible, a bifurcation in the logic at this point is required. In essence, the protocol asks if there is sufficient TKN in the non-trading vault balance to cover the user’s withdrawal.

In this case the inequality is True, which essentially means that the user’s withdrawal can be processed without touching the trading liquidity. A modified method for calculating each of the algorithm outputs is necessary:

This is the simplest case to understand. The user withdraws their TKN directly from the vault, and no compensatory actions are taken. The last remaining case for withdrawals is when there are insufficient non-trading funds to process the user’s withdrawal - when the inequality presented above is False. Consider the situation where the vault balance of TKN is the same, but the proportion of funds used for trading liquidity is much higher. Instead of a pool only 1,000 TKN deep, let it be 1,995 TKN deep instead, while maintaining the same vault balance (i.e. the non-trading TKN balance (c) is reduced while the trading liquidity balance (a) is increased). As before, the staking ledger reports a staked balance of 1,400 TKN (e), the vault balance of TKN is 2,000 TKN (b+c), the TKN trading pool has 1,995 TKN (b) and 1,995 BNT (a) in available liquidity, and the user confirms a withdrawal for 100 TKN (x).

In this case, hlim evaluates to 3.5 TKN, and hmax evaluates to 36.325343 TKN. For this scenario, both of the hlim and hmax tests fail. As before, the protocol detects that its repricing method can be abused, and proceeds to check if the available non-trading liquidity is sufficient to cover the withdrawal.

In this case the inequality is False. Therefore, it is necessary to reduce the available trading liquidity. A third series of methods is required to calculate each of the algorithm outputs:

To summarise the outcome for this scenario, the protocol gives up what is left of the non-trading TKN, and then the remaining balance is taken from the trading liquidity. Since the pool depth is directly affected, the protocol must renounce the BNT component of the pool. Previously, the variables Q and R were treated independently, as the small change in the BNT trading liquidity was akin to a simulated swap, rather than a formal withdrawal. However, in this case Q = R, as the reduction in the pool is appropriately treated as the protocol performing a withdrawal. The Q quantity is denominated in BNT, and is later processed into its equivalence in bnBNT; both the BNT and the bnBNT are destroyed, and the staked balance of BNT is adjusted down, accordingly.

TKN Deficit Examples

A TKN is in deficit if the total vault balance is less than or equal to the staked amount, after accounting for the exit fee. It is necessary to separate the vault balance into the trading liquidity (b), and non-trading liquidity (c) components; b + c is the vault balance of TKN:

where e is the TKN balance of the staking ledger, and n is the withdrawal fee (e.g. 0.0025, or 0.25%). So long as the above expression is True, the protocol is in an effective deficit (i.e. the quantity of TKN is insufficient to reimburse the totality of all user stakes). In this state, it is possible that some users will receive partial reimbursement in BNT. However, the protocol will also attempt to reimburse users entirely in TKN using the reverse of the repricing strategy described for the surplus case - essentially to recapture TKN from the external markets. The following paragraphs will explore the three different situations that cover the discrete behaviors of the withdrawal algorithm during a deficit state of TKN.

As before, the potential for abuse is the most important component of the decision tree. The same thresholds, hlim and hmax, defined previously are used again here; however, the hmax calculation is modified to account for the reversed direction:

The hlim and hmax terms are used in exactly the same fashion as before; they define the maximum value for x that is allowable without creating a possible abuse incentive. Therefore, the user’s withdrawal amount (x) must be less than both hlim and hmax:

To examine this further, consider the following case: the staking ledger reports a staked balance of 2,000 TKN (e), the vault balance of TKN is 1,800 TKN (b+c), the TKN trading pool has 1,000 TKN (b) and 1,000 BNT (a) in available liquidity. Then, a user confirms a withdrawal for 100 TKN (x).

In this case, hlim evaluates to 888.888889 TKN, and hmax evaluates to 1138.958507 TKN. As the user’s withdrawal amount (x) is less than both of these values, there must be sufficient non-trading TKN in the vault to support the withdrawal, and there is no financial incentive to create the withdrawal for the purpose of back running. Therefore the protocol can attempt to recover a small amount of TKN from the outside markets.

The withdrawal algorithm outputs are the same, although the sign is effectively reversed in P and R, relative to the surplus calculations. To maintain unsigned arithmetic, the following descriptions are provided:

P, BNT quantity to add (mint) to the available trading liquidity.

Q, BNT ownership renounced by the protocol (i.e. removed from the staking ledger).

R, TKN quantity to remove from the available trading liquidity (and send to the user).

S, TKN quantity to remove from the vault (and send to the user).

T, BNT quantity minted for, and sent to the user as compensation.

U, TKN removed from the external protection wallet and sent to the user as compensation.

The method for calculating each of these outputs is dependent on the state of the system. The case where there is a TKN deficit, and the user’s withdrawal satisfies the hlim and hmax checks, the outputs are calculated as follows:

Note the opposite behavior of the protocol, compared to the surplus case. During a deficit, the algorithm reacts by quoting a higher price for TKN. The same considerations applied in the previous argument also apply here; if and when the pool returns to balance (defined as state of the pool before the withdrawal was executed), the relative deficit of TKN compared to the staked balance will remain constant, (ignoring vortex fee effects). The number of BNT minted to the trading liquidity, and the amount of TKN taken from the trading liquidity, is determined such that a hypothetically perfect arbitrage trade would return the deficit to its pre-withdrawal value. As before, there is no specific requirement for the implied arbitrage opportunity to close immediately, or even eventually.

The method is abusable if the withdrawal value (x) is greater than hlim or hmax. To examine a case where these abusability thresholds are exceeded, consider a scenario nearly identical to that presented above, but where the TKN balance of the staking ledger (e) is increased to 2,200 TKN. Therefore, the vault balance of TKN remains at 1,800 TKN (b+c), the TKN trading pool has 1,000 TKN (b) and 1,000 BNT (a) in available liquidity, and the user confirms a withdrawal for 100 TKN (x).

For this scenario, hlim evaluates to 977.777778 TKN, and hmax evaluates to 87.855051 TKN. As the user’s withdrawal is still 100 TKN, the hlim test still passes, but the hmax test fails.

Therefore, the protocol’s repricing strategy is potentially abusable. Similar to what was discussed in the surplus sections, the withdrawal algorithm defaults to another set of operations, and a bifurcation occurs depending on the sufficiency of the non-trading TKN balance of the vault.

In this case the inequality is True; the user’s withdrawal can be processed without recourse to reducing the trading liquidity. The outputs of the algorithm are calculated as follows:

The most intuitive way to interpret this result is to add the TKN and BNT amounts together. In this case, the BNT/TKN rate is precisely 1:1, which makes it easy. The S and T outputs represent an amount of TKN, and BNT tokens sent to the user, respectively. Since these tokens have the same value, their sum should represent the total value the user was expecting, save for the exit fee. In this case, the sum is precisely 99.75, which is what we expect. These BNT tokens received in reimbursement are minted at withdrawal, and do not originate from inside the protocol. While this example uses a 1:1 valuation of BNT:TKN, the output T handles any BNT valuation.

Lastly, the case wherein the hlim or hmax test fails, and where it is impossible to refund the user without affecting the trading liquidity, should be considered. For this example, let the BNT trading liquidity (a) be 1,800 BNT, let the TKN trading liquidity (b) be 1,800 TKN, let the vault balance of TKN (b+c) be 1,850 TKN, and let the balance of TKN on the staking ledger (e) be 2,200 TKN, and assume the user confirms a withdrawal for 100 TKN (x).

For this scenario, hlim evaluates to 59.45945946 TKN, and hmax evaluates to 203.670372 TKN. As the user’s withdrawal is still 100 TKN, the hlim test fails, but the hmax test passes. The repricing method is therefore abusable. As before, the protocol proceeds to check if the available non-trading liquidity is sufficient to cover the withdrawal.

In this case the inequality is False. Therefore, it is necessary to reduce the available trading liquidity. A third series of methods is required to calculate each of the algorithm outputs:

As with its surplus counterpart, the outcome of this scenario is that the protocol gives up what non-trading TKN was left in the vault, and then takes the remaining balance from the trading liquidity. As this results in a formal protocol withdrawal of BNT, the Q output is populated, and is later transformed into an equivalent amount of bnBNT tokens. Both the BNT and the bnBNT are burned, and the quantity of BNT on the staking ledger is adjusted down appropriately.

External Impermanent Loss Protection

Withdrawals of TKN during a deficit can result in partial reimbursement in BNT, if the thresholds defined by hlim and hmax are exceeded. This is apparent in the algorithm output T, which represents the number of BNT tokens that should be created for the user. In all of the examples examined above, there is an input variable, w, that has been completely neglected, and which gives the protocol access to TKN of last resort.

The external impermanent loss protection feature of Bancor 3 provides token projects with the means to shoulder part of the insurance burden of the network. This is done by providing a fixed quantity of TKN to an external contract - not the vault - which the protocol can use to subsidize users directly in TKN if, and only if they would otherwise receive a partial reimbursement in BNT. The number of TKN provided to this contract is the w variable.

To explore this behavior thoroughly, at least two examples are required. Since the behavior of the external protection wallet is only relevant in cases where a user has received BNT from the protocol while withdrawing TKN, it seems appropriate to revisit the two examples above where this phenomenon has already played out (i.e. the previous two scenarios where either of the hlim or hmax tests failed. Consider the situation where the TKN trading pool has1,000 BNT (a) and 1,000 TKN (b) in available liquidity, the vault balance of TKN is 1,800 TKN (b+c), the balance of TKN on the staking ledger is 2,200 TKN, and the user confirms a withdrawal for 100 TKN (x). However, this time, let the external protection balance be 1,000 TKN.

The best way to describe the logic of the external protection wallet is to follow the same logic as before, to generate an intermediate set of T and U outputs; recall that T is the number of BNT tokens the user is to receive, and U is the number of TKN the user is receiving from the external protection wallet. The algorithm then determines precisely the quantity by which the T output can be reduced, by substituting BNT for TKN from the external protection contract. First, the protocol checks if the total TKN in the contract (w) is sufficient to replace all of the BNT tokens the user is receiving:

In this case the inequality is True - there is more than sufficient TKN available from the external protection wallet to substitute the entire BNT allotment the user would have received. The process is relatively intuitive - the new BNT amount (T†) is set to 0, and its value is converted into TKN units, which are then withdrawn from the external protection wallet.

Lastly, let the BNT trading liquidity (a) be 1,800 BNT, let the TKN trading liquidity (b) be 1,800 TKN, let the vault balance of TKN (b+c) be 1,850 TKN, and let the balance of TKN on the staking ledger (e) be 2,200 TKN, and assume the user confirms a withdrawal for 100 TKN (x). However, this time, let the external protection balance be 10 TKN.

The process is similar to the example above; however, there is insufficient TKN in the external protection contract to offset the entirety of the BNT reimbursement received by the user. Therefore, the protocol offsets the maximum allowed by the remaining TKN balance of the external protection contract, and then reimburses the difference with BNT:

In summary, the external protection method provides a higher level of assurance that TKN stakes can be withdrawn entirely in TKN, so long as there is sufficient TKN in the protection contract to support it. The method takes the amount of BNT being minted for the user as input, and the BNT to TKN exchange rate, effectively swapping out an equal quantity of BNT value for TKN value, until there is no TKN remaining.