Proposal: Allow the Bancor protocol to grow TKN trading liquidity via an external trigger

This proposal is expected to appear on Snapshot for voting on 2022-07-10T15:00:00Z. Make sure to stake your vBNT for voting before this date and time to participate in the DAO decision.

TL;DR

  • An enhancement to the current workflow that allows for trading liquidity to be increased/decreased is being introduced. This enhancement is a function that has been developed and allows trading liquidity to grow/shrink in pools while deposits are disabled. If trading liquidity is being increased, it lets tokens that are sitting outside the bonding curve, be matched with BNT to be made available for trading. The opposite will occur if trading liquidity is decreased (tokens are moved out from the bonding curve).

  • In order to grow/shrink trading liquidity in pools, BNT minting (only when growing) needs to occur and this is typically triggered upon deposits. It is being proposed to the Bancor DAO to allow for this type of minting (only when growing) to happen without deposits via an alternative external trigger.

  • A preliminary list of pools that could potentially qualify for being grown via this external trigger are the following:

$CROWN, $MFG, $PHTR, $MONA, $DAPP, $BBS, $wNXM, $DAI, $USDT, $USDC, $HOT, $BORING, $AMP, $LQTY, $MANA, $SHEESHA, $OCEAN, $UMA, $DAO, $MLN, $RLC, $RPL, $ENS, $DDX, $RAIL, $YFI, $GTC, $INST, $wSTETH, $RARI, $ANKR, $VITA, $GRT, $renBTC, $eRSDL, $IDLE

  • Assuming this proposal passes, then it would allow the Bancor DAO to increase the trading liquidity to its maximum capacity with the caveat that the limit to growth is still the pre-approved trading liquidity as voted on by the Bancor DAO for these tokens. See BIP17 for $BNT minting limits in B3 token pools (should be relatively up to date) BIP17: Bancor 3 Initial Whitelist, BNT Funding Limits, and Swap Fees

  • There are currently no pools under consideration for shrinking their liquidity.

Due to the emergency actions taken on 6/19:

BNT distribution for covering deficits in withdrawals was disabled. In addition, BNT deposits across the entire protocol were also disabled while the protocol has BNT distribution disabled. Increasing/decreasing the trading liquidity in pools (up to their specified trading liquidity limit) was triggered by deposits that are now disabled. This proposal is seeking to allow the DAO to trigger an increase of trading liquidity in pools via an external trigger and let tokens sitting outside the bonding curve be paired with BNT for trading liquidity. Note: we can also decrease trading liquidity in pools using this external trigger as well.

The Bancor DAO has already approved the trading liquidity limits for all tokens that are listed in Bancor 3. A large number of pools in Bancor 3 have TKN liquidity but have failed to grow to their full trading liquidity depth. Part of the reason for not being able to grow is that pools are required to be in a “stable” state (“ispoolstable” parameter returns true), meaning that the spot rate must be within 1% of the EMA (exponential moving average) rate. If it is not within this range then pools where “ispoolstable” returns false will not be allowed to have their trading liquidity increased.

The EMA was new to Bancor 3 and required some tuning in order to get it stable. Recent changes in Bancor 3 have allowed this to occur and even though pools might have EMA and spot rate within 1%, they are currently not able to grow their trading liquidity. The reason for this is because the “ispoolstable” check runs when an LP deposits or withdraws from Bancor. With deposits being disabled, this has made it very difficult to trigger the growth of trading liquidity in a pool.

It is worth mentioning that liquidity in a pool can only double from the previous amount. To illustrate, on Bancor 3 we need a minimum of 10K BNT in TKN liquidity in order to bootstrap a pool. This means that if a pool has been approved for 160K in BNT trading liquidity, that a deposit after the pool is bootstrapped would double the trading liquidity to 20K BNT. The next deposit would double the pool to 40K BNT, 160K BNT, etc… until the pool has grown to the BNT trading liquidity limit that has been approved by the DAO.

In order to allow for trading liquidity to grow in pools while deposits are disabled, an external function has been developed that can trigger a growth event (assuming that the spot and EMA rate are within 1% of each other). When these conditions are met, new BNT will be minted to grow the trading liquidity and given the current situation at hand (BNT distribution disabled) this proposal seeks to get approval from the Bancor DAO to allow for this type of minting to occur (grow trading liquidity in pools via an external trigger).

FOR: Approved the minting of new BNT to grow trading liquidity in Bancor 3 Pools to the pre-approved limits by the DAO.

AGAINST: Do not allow the minting of new BNT to grow the trading liquidity in Bancor 3 Pools

7 Likes

This is a clear YES from me.

Are you going to boost the pools listed above to their maximum trading liquidity? Or juts trigger it once per pool?

1 Like

Thanks @glenn for your hard work & proposal. Smart MFG has moved their MFG treasury stake to v3; however, the liquidity has been significantly (but understandably) bootstrapped so this proposal would be a great step. We support increasing our v3 liquidity pool, but obviously in a safe & healthy manner for the Bancor protocol. Keep up the great work team! :+1:

4 Likes

This proposal would increase it for you, right now MFG has 25,318 BNT and 1,395,533.202
MFG liquidity. Far from your co-investment limit

1 Like

Glad to you see you supporting this.

1 Like

Do we need a vote on this?

This seems to just be a fix to deal with our current situation. We have already approved the trading liquidity for each of these pools - this fix would simply let us realize what we’ve already voted on.

3 Likes

We were curious about this as well, since MFG was already approved for the 800K BNT liquidity limit through 4 prior proposals on v2.1

1 Like

The method to increase trading liquidity that was outline in the V3 proposal/docs was based on deposits.

If the DAO wants to add a second method (I myself am in favor of this) it should be approved by the DAO

1 Like

Without proper data on what the proper/ideal “Trading Limit” to “IL Exposure” should be, I’m hesitant to assume v2.1 or previous approved Trading Limits are at all viable with the protocol in its current state.

We obviously want pools that are able to be traded on to start building fees and recover the deficit. But without knowing how much IL risk we are taking on and how much BNT we are minting and diluting the supply it’s highly risky.

We have 100 86 pools that aren’t even bootstrapped currently:
image
so there’s plenty of work to be done to start getting non-existent pool fees vs trying to capture more fees through increasing TVL without evaluating IL exposure.

To add here, note that the Bancor DAO voted to ratify emergency measures which essentially means that all deposits are disabled at the moment. Growing trading liquidity via a trigger is effectively bypassing the original method which was in place and I think it should require the DAO to allow it (hence this proposal and note that this has passed the Bancor DAO as of yesterday).

Additionally, this will also bring new BNT into circulation and given that BNT distribution has been disabled then the DAO should be aware of this occurring. This proposal is essentially permitting the Bancor DAO to grow trading liquidity via an external trigger which is technical in nature and typically not something the Bancor DAO has voted on regularly in the past (technical proposals/requirements/details/etc…). Going forward, this might be a common occurrence and the Bancor DAO might be more involved with these types of proposals.

Lastly, there have been some community members that have brought up how much trading liquidity is going to be grown for each pool etc…With this in mind, I am planning on creating new proposals with this information for the DAO to approve individually per pool (some pools might be batched where and when it make sense).

Looking forward to the new proposal. Dont forget $ENJ

Keep in mind the fastest thing would be for you to simply make a proposal to increase ENJ to its max approved limit.