BIP15: Proposing Bancor 3

[mbr]

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

3. 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.
4. 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: