This document was created as a reference for the Bancor contributors and community members. It frames three prominent ideas following the recent rounds of brainstorming regarding the most compelling path back to protocol health, in context of the existing revenue mechanisms already built into the Bancor infrastructure. Those changes are:
- DAI Remittance
- Protection Fund
- Yield Throttling
The expectation is that comparing the proposed modifications to the protocol with their present-day counterparts will add an element of familiarity and expedite understanding and comprehension for the reader.
In short, this document is intended to serve as the basis from which productive communication, messaging, explanations, and active discussion with and between community members may arise. Effort has been made to use examples with easy numbers that accurately reflect the behavior of the smart contracts. Therefore, the figures and examples herein may also be used to construct more elaborate explainers, should they become necessary, as the discussion within the community matures.
This document is not a DAO proposal in and of itself; it is for communication purposes only.
The BancorDAO produced two major infrastructure upgrades within a few months of its creation: the liquidity mining (i.e., incentives, or rewards) campaigns, and the Bancor Vortex. The Vortex is a generic mechanism that can be used to manage the BNT token economy, by adjusting token burning, paid for by network fees collected during trades. While conceptually identical, the Vortex mechanisms on V2.1 and V3 have nuanced behaviors, made necessary by the differences in the design of the versions of the system.
The recovery model is largely inspired by the paradigm created by both Vortex systems (V2.1 and V3), and their relationship with liquidity providers and value accrual for the network. Therefore, these systems are described in sufficient detail to provide the reader with the necessary background - a prerequisite to a productive conversation about the proposed road to recovery.
The Vortex system on V2.1 is more straightforward to understand, and the reader is encouraged to return to the V2.1 section to reorient themselves if the material later in the document feels overwhelming.
The Vortex is powered by fee accumulation within the protocol, collected during trades. Therefore, to fully elucidate the behavior of the Vortex, it is important that the fee collection system is well articulated. As the mathematical descriptions for these processes are unhelpful for most readers, instead, a heuristic approach is employed which does not make use of the familiar equations that describe AMM behavior. The process can be understood by considering only that which is written in the main text, and following the amounts displayed alongside the token icons.
Consider a trading pool with the following characteristics:
TKN liquidity: 2000 tokens
BNT liquidity: 3000 tokens
Trading fee: 1%
Imagine that a trader swaps 400 TKN for 500 BNT, before the fee is applied. Necessarily, all swaps affect the state of the pool and therefore the coordinate position on its bonding curve. Therefore, the TKN liquidity is changed to 2400, and the BNT liquidity is changed to 2500 [the reader can easily verify that the trade left the pool invariant k = x×y constant at 6,000,000]. To apply the trading fee, 1% of this total trade amount is separated and the rest are sent to the trader who purchased them. Therefore, the trader receives 495 BNT, and the remaining 5 BNT are collected as a fee. The Vortex always operates on this amount - the small fraction of tokens left behind by the trader as a commission to the system.
The 5 BNT collected as a trade fee are then subject to a further split; some proportion is to become the property of the liquidity providers, and the rest is to become the property of the Vortex “burner”. Assume a Vortex rate (i.e. “network fee”) of 20%. Therefore, a total of 1 BNT is moved to the vortex, and the remaining 4 are given back to the liquidity providers. A curious legacy design artifact from the early days of AMM technology, the fee paid to liquidity providers is allowed to accumulate within the pool. The 4 BNT in this case are added to the pool reserve balance, causing the pool invariant to grow, while also slightly dampening the price impact of the trade. Therefore, following the fee accumulation, the TKN liquidity remains at 2400 as before, but the BNT liquidity becomes 2504 (i.e. 2500 + 4).
The reader can easily verify that the trade left the pool invariant k=x*y constant at 6,000,000
Vortex V2.1: TKN to BNT trade
On V2.1, the process for trades in the other direction is identical, but reversed. For this part, we can consider an identical setup, where BNT and TKN have switched places. Therefore, assume a trading pool with the following characteristics:
● BNT liquidity: 2000 tokens
● TKN liquidity: 3000 tokens
● Trading fee: 1%
A trader swaps 400 BNT for 500 TKN, again - before the fee is applied. The BNT liquidity immediately following the trade is 2400, and the TKN liquidity is 2500. After separating the 1% fee, the trader receives 495 TKN, and the remaining 5 TKN are split between the vortex and liquidity providers. As before, assume a Vortex rate of 20%; 1 TKN is moved to the vortex, and the remaining 4 TKN are added to the pool reserve balance.
Vortex V2.1: BNT to TKN trade
It is important to note here that the Vortex burner contract collects a diversity of tokens, including BNT. The fate of the collected tokens is the same; each is swapped for vBNT, the governance token of Bancor. The reasoning for burning vBNT over BNT directly is outside the scope of this tutorial; however, for all intents and purposes it is appropriate to equate vBNT and BNT burning, except that vBNT burning is more efficient. Thus, the utility of the Vortex system is realized: it permits value captured from trading activity to be directed towards reduction of the BNT supply, a necessary economic counterbalance to the BNT inflation caused by the impermanent loss protection.
It should also be noted that during the first leg of the TKN burner action, where a swap is first performed into BNT, the TKN that was once collected by the protocol is now returned to the pools from where it was originally taken. Therefore, at the end of a Vortex burner sequence, there is no loss of TKN from the system, save for one edge case. The swap of TKN for BNT moves the BNT rate, proportional to the size of the trade and the depth of the pool. If the burner contract has collected a large amount of TKN, or if there have been large withdrawals on the TKN pool causing its available liquidity to diminish, this trade may result in an arbitrage opportunity. Under this circumstance a small amount of the TKN will likely be traded out thereafter.
The Bancor Vortex V3 is very nearly identical to Vortex V2.1. However, the V3 architecture requires some specific attention, along with an optimized handling for fees collected in TKN. The following examples use precisely the same setup as those described in the previous section (Vortex V2.1), and for the sake of brevity, the common steps are not described explicitly. The same amounts of BNT are received by the trader, and the Vortex burner contract. The BNT accrued by liquidity providers still accumulates on the pool, causing the pool constant to grow.
The key difference between V2.1 and V3 during a TKN to BNT trade is the interaction with the staking ledger: In the example above, the 4 BNT inherited by the liquidity providers is necessarily added to the BNT staking ledger. This step is important, as it is the only way the system keeps record of the increased withdrawal potential for liquidity providers; without this step, regardless of the addition of BNT to the trading liquidity (or master vault, for that matter), the liquidity providers would not be able to access the fee paid. In short, if the staking ledger is not updated, the fee would accumulate as normal, but without any change to the protocol’s calculation of what it owes its liquidity providers.
Vortex V3: TKN to BNT trade
Fee collection for the Vortex V3 with respect to TKN is identical to that described for BNT collection, regarding the staking ledger and so on. However, unlike V2.1, the Vortex V3 does not collect TKN. Whenever the network fee is collected in TKN on V3, there is an immediate trade back for BNT after the update to the pool constant and TKN liquidity.
Vortex V3: BNT to TKN trade
The immediate swap from TKN back into BNT is noteworthy. This swap delivers the full TKN amount paid by the trader as a fee directly to the pool, atomically, during the swap itself. There is no batch of TKN to be returned to liquidity providers at a later date. Such an approach can ameliorate the possibility of creating problematic arbitrage opportunities, and is therefore more adept at maintaining protocol TKN levels versus the system on V2.1.
Since the Vortex V3 does not collect TKN, the burning step is exclusively a 1-leg swap from BNT to TKN.
Vortex V3: Token Burner