Product Heuristics: Understanding and Comparing Proposed Changes to Protocol Behavior

[mbr]

Purpose of This Document

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:

1. DAI Remittance
2. Protection Fund
3. 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.

Review Bancor Vortex V2.1 and V3

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.

Heuristics, not Mathematical Models or Implementation Notes

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.

The Bancor Vortex V2.1

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

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

[mbr]

Understanding the Recovery Proposals

The following sections describe three models that are currently under investigation, and are intended to help the protocol restore its TKN reserves to parity (i.e. recover the deficit). It should be stressed that while these sections can be read on a stand-alone basis, the prior descriptions of the Vortex V2.1 and V3 are suggested as an introductory reading to prepare the reader for some of the concepts on which these models are built. In other words, a sufficient understanding of the Vortex mechanisms on V2.1 and V3 is considered required knowledge hereafter.

The models under discussion assume a relatively high network fee compared to the status quo for the network today. In the following examples, the network fees are arbitrarily fixed at 90% (or 100%, depending on context).

Model #1: DAI Remittance

The DAI Remittance model represents a significant shift from the status quo for liquidity providers to AMM protocols, because participants would receive regular disbursements in DAI, as opposed to the accumulation of the token provided. This has an important consequence for the valuation of bnTKN and bnBNT - in neither case are fees added to the staking ledger, and therefore the maximum withdrawal is equal to the principal.

This is achievable through the Vortex architecture, with some modifications. The following examples demonstrate the current thinking, with a discussion dedicated to exploring the implementation challenges and feasibility, advantages, and justification vis-a-vis restoring the TKN balances within the protocol to parity.

Consider a trading pool with the following characteristics:
● TKN liquidity: 3600 tokens
● BNT liquidity: 2400 tokens
● Trading fee: 5%

A trader swaps 1200 TKN for 600 BNT before the fee is applied, leaving 4800 and 1800 tokens in the TKN and BNT liquidity reservoirs, respectively. After separating the 5% fee, the trader receives 570 BNT, and 30 BNT remains. In contrast to the previous examples, the remaining BNT is used exclusively for burning. Nothing is added to the vault, and the balance on the staking ledger is not increased; instead of an 80/20 split between LPs and Vortex, 100 are going to the vortex for burning and 0 to LPs.

Note that this behavior is akin to a 100% Vortex burn rate on the BNT side. This example alone seems to provide no grounds to incentivize BNT staking; however, in the BNT to TKN trade example (where TKN is collected in fees) introduces this missing component.

In short, under the DAI Remittance Model, BNT burn rates for fees collected in BNT are 100%. The intention is to provide a reliable, and sustained drain for the market excess BNT, until the TKN reservoirs are restored to parity. The increased burn rate raises some important questions regarding the target of the burn. For the sake of argument, assume that the vortex can burn half the accumulated BNT directly, and use the other half to burn vBNT. The precise proportions can be the subject of later discussions, and optimizations.

DAI Remittance Model: TKN to BNT

Trades in the other direction is not an equal and reversed process. Consider an identical setup, where BNT and TKN have switched places:

● BNT liquidity: 3600 tokens
● TKN liquidity: 2400 tokens
● Trading fee: 5%

The trade occurs as expected, but the fate of the collected fee is changed compared to BNT. Here, assume an “effective network fee” of 90%. In contrast to the standard behavior, this 90% is added to the master vault balance of TKN, rather than being sent to the Vortex. This is the reverse of the expected behavior of the network fee, regarding the destination for the network-collected amount. However, the designation is suitable as the tokens added to the vault do not result in any increase to the pool token valuations (i.e. the staking ledger is not updated) - which is expected behavior of the network fee. Under these circumstances, the accumulation of network fees in the absence of a commensurate increase in the staking ledger is a compelling method to address the TKN deficit, if a deficit exists. Therefore, a synergy exists between BNT burning and TKN accumulation while the protocol’s obligations to users remain frozen on a per-token basis; LPs participate in the distribution based on what they staked, not what the current value of the TKN is. Thus, there is a case to be made for approaching a TKN surplus over time.

The network fee component of the TKN swap fee is 90%; the remaining 10% is sent to a Vortex substitute, termed the “remittance fund”.

DAI Remittance Model: BNT to TKN

The remittance fund is Vortex-V2.1-like, in the sense that it accumulates a variety of tokens, save for BNT, and then batch-swaps them for another token. However, that is where the similarity ends. In contrast to Vortex activity, which provides a deflationary counter-balance to BNT, the remittance fund is proposed to swap its accumulated tokens for DAI and to eventually distribute it to liquidity providers. Further, the consolidation of all collected tokens to DAI should ideally have access to outside markets; using the pools on Bancor exclusively to perform this task is unlikely to be as efficient as using the amalgam of liquidity, available anywhere/everywhere.

DAI Remittance Model

The description provided here is essentially complete up to the collection of TKN in the remittance fund. The manner in which the collected tokens are exchanged for DAI, the method that determines the exact disbursement amounts to each liquidity provider, and how liquidity providers receive the DAI, remain open questions.

[mbr]

Model #2: Protection Fund

The Protection Fund concept is more familiar, and can be thought of as a direct stand-in for the BNT minting/burning method that was recently paused. At its core, the original inspiration for the Vortex was to introduce a means by which protection premiums can be extracted from the system over time. Ignoring the interference caused by liquidity incentives programs, the general concept is that BNT burned via the Vortex mechanism is equal to, or in excess of, BNT minted for protection payouts. In principle, this economic requirement can be rigorously enforced - the amount of BNT destroyed over time can be used to define the exact amount allowed to be printed to cover apparent deficits. Unfortunately, this does nothing to ameliorate the underlying issue. Put simply, there is an argument to be made that any system that is contingent on BNT distribution to individuals with no interest in the token has failure modes leading to collapse in terms of severe market disruptions.

The Protection Fund Model addresses these concerns directly. First, the protection mechanism is self-funded exclusively from protocol performance. This is equivalent to limiting the protection status through comparison of the BNT burning and minting rates. However, the model is not reliant on BNT whatsoever: liquidity providers receive protection via the distribution of tokens other than BNT. Therefore, the systemic risk that gave rise to the present emergency is massively reduced, if not completely eliminated. Moreover, liquidity providers earn the same token they contributed, which is more familiar, and suffers from fewer development challenges.

To explore this idea further, consider an identical trading pool to that presented in the previous section:

● TKN liquidity: 3600 tokens
● BNT liquidity: 1800 tokens
● Trading fee: 5%

The scenario is identical to the TKN to BNT trade presented for the DAI remittance model; 1200 TKN are first traded for 600 BNT, then a 5% fee is applied. The trader leaves with 570 BNT, and 30 BNT are passed to the rest of the process. Whereas the DAI Remittance model burned 100% of BNT at this juncture, the Protection Fund concept applies the same 90% network fee for both BNT and TKN. Therefore, the 30 BNT associated with the trade fee in this example are split, with 27 tokens sent to the Vortex for destruction, and 3 tokens sent into the master vault. The staking ledger is updated accordingly.

The intended consequence of the rapid BNT burning (resulting from the increase in the network fee) is the same as described in the previous examples. The diminishing ratio of BNT/TKN is the fastest and most efficient means to restore the protocol’s TKN balances and reduce the implied deficit in the near term.

Protection Fund Model: TKN to BNT

At first glance this appears to be identical to the Vortex V3, albeit with a much higher burn rate. However, it is important to note that the trading liquidity is not updated in this case - there is no slow drift associated with the pool constant. While only a minor consideration for BNT, the consequences for TKN are profound. To examine this case, consider the reversed case, where BNT is traded for TKN:

● BNT liquidity: 3600 tokens
● TKN liquidity: 2400 tokens
● Trading fee: 5%

In contrast to the Vortex V2.1 and V3 systems, the 3 TKN received by the collective TKN liquidity providers is not added to the trading liquidity. There are two consequences with respect to pool behavior from the trading perspective. First, the pool depth is determined exclusively by deposit/withdrawal actions, and trades have an accelerated price impact. The size of these discrete effects on a per-trade basis is negligible. However, there is an obscure third consequence that benefits the protocol directly. Since the collected fee is not part of the trading liquidity, it cannot be extracted by traders. Thus, accumulated fees are not themselves subject to the directional market moves, which reduces the rate at which the deficit can increase compared with either the Vortex V2.1 and V3 systems.

The most important component is the transfer of the collected network fee to another Vortex substitute, the Protection Fund. Transfer of tokens to the Protection Fund is exclusive to the TKN process; therefore, the fund is collecting 90% of all TKN trade revenue.

Protection Fund Model: BNT to TKN

As its namesake suggests, the Protection Fund replaces the currently paused IL protection mechanism. Conceptually, the process should feel very familiar. During a withdrawal, the protocol attempts to cover the liquidity provider’s deficit with the funds it has available (previously with BNT). In a very direct way, the Protection Fund is a direct substitute for the Vortex. Whereas the previous approach with V2.1 and V3 was to collect and burn BNT, and then reissue it later as needed, the Protection fund simply collects and re-issues TKN without the abstraction into BNT as an intermediate step.

Herein lie some challenging design decisions. For example, one might prefer the issuance of TKN from the protection fund to be in a form that the liquidity provider is happy to receive. At the same time, there is some reason for the TKN issued during a protection payout to be the same TKN contained within the fund, prior to the withdrawal. Therefore, the Protection Fund and DAI Remittance models have a common problem: in both cases a diversity of different tokens must be consolidated into common, and well-established denominations. DAI or any of the established stable coins seem like an attractive choice. However, this exposes the Protection Fund to potential “losses” during rallies, making it more difficult to cover liquidity providers - potentially when the protocol is under the greatest stress. This is a symmetrical argument; during capitulations, denominating the Protection Fund exclusively in stables is preferable. Therefore, there is a reason to have the fund somewhat diversified, which may require active management. This is a substantial implementation question, but not necessarily the most important. As with the DAI Remittance model, the rules governing access and distribution of value are non-obvious.

[mbr]

Model #3: Yield Throttling

The Yield Throttling model is a natural continuation of the current paradigm. Liquidity providers would still earn yield denominated in the tokens they provide, and this yield would be accrued to the single-sided pool token via the staking ledger. The modification to the existing paradigm is that the yield component of the fee (i.e. the iteration made to the staking ledger) is some proportion (static or dynamic) of the fee paid by the trader. The overall process is akin to a generalization of the Vortex concept, with the exception being that TKN that would have been diverted to BNT burning is instead added directly to the vault. The concept is that the rate of TKN accrual by the protocol would outpace the protocol’s liabilities, save for directional risk. In a sense, it is similar to the Protection Fund model, where each token is responsible for covering its own withdrawals. However, BNT is committed to token burning as normal. Therefore, the process for BNT is identical to the protection model.

Yield Throttling Model: TKN to BNT

During trades from BNT to TKN, the self-covering nature of the model becomes more evident. Consider the same familiar case as explored in the model examples:

● BNT liquidity: 3600 tokens
● TKN liquidity: 2400 tokens
● Trading fee: 5%

The scenario plays out as before; 1200 BNT are first traded for 600 TKN, then a 5% fee is applied. The trader leaves with 570 TKN, and 30 TKN are used as inputs to the throttling mechanism. Whereas the Protection Fund model would divert 90% of the fees to another location (eventually to be swapped for DAI and ETH as per the management of that fund), the Yield Throttling model simply adds these tokens back to the vault.

Yield Throttling Model: BNT to TKN

Among the other talking points that will accompany these ideas, the implementation simplicity of the Yield Throttling model is its strong suit. Whereas the DAI Remittance and Protection Fund models lack specific implementation details en route to achieving some of the desired behavior, the Yield Throttling model can be used with only minor changes to the existing smart contracts. This is the most practicable of the three ideas discussed here, meaning that development resources can be sooner directed to improving protocol revenue and overall value proposition of the project.

Conclusion

This document has been prepared to assist with community discussions. It introduces a generic graphics format that makes clear the relationship between the constant product AMM behavior, trade fee, network fee, and the accumulation and distribution of tokens via the staking ledger and the Bancor Vortex. The reconfiguration of the Vortex is underscored with respect to its ability to separate yield (earned by LPs) from fees (paid by traders). While only three possible reconfigurations are presented, the intention is for this tutorial to inspire new proposals that aren’t necessarily predicated on what is presented.

[PaperStreetCapital]

Thanks for putting this all together Mark, really appreciate the time and effort.

I was an instant fan of the Yield Throttling model, especially for its intuitive simplicity and ease of implementation. One thing I see in all of this is that through this wild time, we may have discovered a much more robust solution to Impermanent Loss, in such a way that allows for a long runway to not only recovery, but for the protocol to thrive. Of course there’s going to be disagreement to that sentiment, but I also take a longer-term view on things.

[ZenoBNT]

I was an instant fan of the Yield Throttling model, especially for its intuitive simplicity and ease of implementation

I have similar thoughts.

The Path Forward for Bancor 3 #defi #cryptocurrency #BancorDAO