Proposal to start sunsetting Bancor V3

[alphavalion]

Received some feedback offline about the price that token should be put up for sale. The suggestion is that the 5% premium should be based on the 30 day TWAP to account for large price movements.

The option to use the current price for the 5% premium is left in the proposal should the data not be available for calculation of the 30 day TWAP.

These tokens to have a strategy created TKN-ETH in Carbon that will sell them via a limit order at a 5% premium based on the last 30 day time weighted average price or current price if 30 day TWAP is not available.

[Jindo]

(post deleted by author)

[Jindo]

(post deleted by author)

[alphavalion]

I do not want to comment on this reply as this is not part of my proposal and it is better if this gets moved to a separate thread as it is off topic. I ask that you remove and delete this comment and start a new thread instead. My proposal is quite simple and is targeting a small amount of surplus pools in Bancor v3.

[Jindo]

done, I am eagerly awaiting marks response to your thread. Once the big brains on the team confirms your ideas legitimacy, then I’m ready to vote and give it a shot.

[mbr]

Comment on Sunsetting Bancor V3

This is an excellent proposal - I think it is well-structured, and its intent is clear and unambiguous. However, there are aspects to its content that I want to address, with a view to creating something that is immediately actionable. I have prepared a commentary, and a proposed revision to the original proposal that I now invite for further discussion.

As highlighted in a prior comment, I have expressed my personal views about Bancor’s legacy products already. Both V2.1 and V3 were designed to serve a use case that the crypto industry has mostly rejected. These products were the continuation of the philosophy that on-chain liquidity protocols and projects live to serve the token economy with a spirit of collaboration and mutual support. While I maintain that liquidity remains an obscene obstacle for new tokens and their communities, I no longer have any interest in addressing it. The harsh reality is that there will always be an innate, systemic risk in supporting exchange liquidity for new tokens by offering your own simultaneously as their numeraire. My personal ambitions are to recover the deficits on all tokens permanently, wind down the legacy protocols, and move on with products that speak directly to the demographics settling down into the blockchain ecosystem. Therefore, I am relatively well-aligned with the proposal presented above.

For newcomers, I have prepared a brief overview of the specific mechanics of Bancor V3 that this proposal is partly relying on. This section has been added as an appendix (see bottom of this thread).

The Current Proposal is Incomplete.

In the interest of moving to something immediately actionable, I want to address each item from the original proposal which describes an on-chain action.

1. Disable trading on all these pools by setting the funding limit to 0 (some of them already have this value). This will burn around 92,000 BNT from circulation and reduce the supply by this quantity.

• There are no issues here whatsoever, because this is an action that is already part of the implemented smart contracts.
• So long as there exists a surplus for each of these tokens, removing all trading liquidity and burning the BNT from their pools will lock the surplus state forever.
• Users who have the associated bnTKN will forever be able to withdraw without incurring a loss.

2a. Any surplus token quantities for every token in this list to be removed from the V3 master vault and moved over to Carbon.

• There is no decentralized method to move tokens from Bancor V3 to Carbon, and a description of such a method has not been included with the proposal.

2b. These tokens have a strategy created TKN-ETH in Carbon that will sell them via a limit order at a 5% premium based on the last 30 day time weighted average price or current price if 30 day TWAP is not available.

• This point is predicated on 2a, which currently lacks sufficient detail to implement.
• There is no decentralized method that would allow anyone to compose strategies with funds that aren’t already available in a strategy they control, or in their own wallet, and a description of such a method has not been included with the proposal.
• Carbon has no internal or external price oracles, TWAP or otherwise.

3a. Whatever ETH is recovered from these sales to in the future create a carbon BNT-ETH strategy that creates a buy wall at a 5% discount based on current BNT price.

• This point is predicated on 2a and 2b, and both lack sufficient detail to implement.
• There is no decentralized method that would allow anyone to decompose strategies that they don’t own, and a description of such a method has not been included with the proposal.
• There is no method that allows for multiple strategies to be consolidated into a single strategy, and a description of such a method has not been included with the proposal.
• Carbon has no internal or external price oracles, TWAP or otherwise.

3b. The buy wall to be revised every 7-30 days and when the current price of the buy wall is off by 10% or more from the current BNT price.

• This point is predicated on 2a, 2b, and 3a, and each lacks sufficient detail to implement.
• There is no decentralized method that would allow anyone to edit strategies that they don’t own, and a description of such a method has not been included with the proposal.
• Carbon has no internal or external price oracles, TWAP or otherwise.

4a. Whatever BNT is recovered from takers eating into the buy wall to later be burned after a sufficient amount of BNT is acquired.

• This point is predicated on 2a, 2b, 3a, and 3b, and each lacks sufficient detail to implement.
• There is no decentralized method that would allow anyone to withdraw tokens from strategies that they don’t own, and a description of such a method has not been included with the proposal.

4b. This can be voted via a separate proposal similar to the recent proposal that burned BNT which had accumulated in V3.

• This point is predicated on 2a, 2b, 3a, 3b, and 4a, and each lacks sufficient detail to implement.
• The similarity to the recent proposal re: the burning of accumulated BNT from Bancor V3 is dubious, as Carbon has no such function.
• Carbon’s fee burner implementation via a modified Bancor Vortex contract was described in the final proposal for Carbon (BIP 28), and was approved by the BancorDAO via Snapshot vote in April 2023.
• The procedure is for Carbon to collect tokens, and then anyone can call the fee burner which will then perform the swap via the existing liquidity pools on Bancor V2.1 and V3.

[mbr]

Summary of Apparent Issues.

Changing the trading liquidity to zero is the only part of this proposal that is currently supported. Every other aspect of the proposal, while sound in purpose, lacks technical definition. Moreover, after having considered several tentative approaches to achieving these goals, I still have nothing that I would characterize as being scrutinized to the required levels of confidence before being presented in a public forum. However, that doesn’t mean I am arriving completely empty-handed.

I am happy to provide two actionable recommendations, one of which may form a proposal in and of itself.

Recommendations

1. Begin Setting the Trading Liquidity of Surplus Pools on Bancor V3 to Zero.

The ten pools stipulated by the original author is a good start. As noted above, this is already supported by the existing contracts and does not require any additional smart contract work. This will lock the surplus status, and allow the DAO to burn in excess of 90,000 BNT. This will immediately and permanently lock in the surplus status for each of these tokens.

The process highlighted by the present proposal is a good one. Over time, the DAO can submit similar surplus token wind-down proposals as exhibited here. My personal preference is for this to be a gradual process.

Therefore, I recommend that new stand-alone proposals be drafted, which asks the DAO to approve a reduction in the trading liquidity on AUC, KTN, SHEESHA, APW, IDLE, and HEGIC to zero. The DRC, FODL, DAO, and DDX pools already have zero trading liquidity, so no actions need be taken in those cases.

This raises another significant point, which I have myself been attempting to rectify. It is generally advisable to split a complex proposal, such as this one, into discrete decisions. Were this proposal to be defeated as-is, we obtain a lot less information than if it were submitted in parts. For example, DAO members may agree with reducing the trading liquidity to zero, but object to another aspect of what is proposed. Lumping several decisions together creates an unnecessary ultimatum; the proverbial baby need not be tossed out with the bathwater. Much of our governance processes and documentation is severely out-of-date. As the DAO regroups and updates its policies and procedures, it is my ambition to bring attention to this matter and formalize it. Until then, I hope that we can agree that there is value to separating complex proposals into their constituent parts and asking the DAO to vote on each individually. Therefore, nullifying the trading liquidity on each of AUC, KTN, SHEESHA, APW, IDLE, and HEGIC ought to require six (6) separate votes on Snapshot.

2. Implement a Function which Transfers POL to the Carbon Fee Burner.

The original proposal makes two stipulations about how the excess TKN (aka the “protocol-owned liquidity”) should be handled, after the trading liquidity has been nullified.

2a. Any surplus token quantities for every token in this list to be removed from the V3 master vault and moved over to Carbon.

2b. These tokens have a strategy created TKN-ETH in Carbon that will sell them via a limit order at a 5% premium based on the last 30 day time weighted average price or current price if 30 day TWAP is not available.

Additional detail is offered by the author following this last point, which is contingent on the strategy creation element - which is simply untenable at this point. I can address both of these points with a slight change in focus. Rather than moving the token excess to Carbon for strategy creation, instead, it can be moved to the fee burner. Then, these tokens can be handled as normal using the existing fee burning infrastructure if appropriate; where no token liquidity exists on V2.1 or V3, these tokens can simply be held until a new method is available that allows these tokens to be traded for BNT elsewhere on the market.

I recommend that a new function be defined that allows token excess to be moved from V3 to the Carbon fee burner, which can be called by anyone. This function should have the following characteristics:

• The caller chooses a token for which a token surplus exists, and the trading liquidity is presently set to zero.
• The surplus is moved from the Bancor V3 master vault, to the Carbon Fee Burner contract.

To elaborate the proposed function, a simple python program is provided in the appendix, and its outputs called for DRC and AUC are provided here for the sake of illustration.

DRC

The current state of DRC is tabulated below:

Resource	Balance	Token
Master vault	16348845	DRC
Staking ledger	1	DRC
Trading liquidity DRC	0	DRC
Trading liquidity BNT	0	BNT
Carbon fee burner	0	DRC

After the function call, the new state of DRC on Bancor V3 and the balance transferred to the Carbon fee burner is tabulated below:

Resource	Balance	Token
Master vault	1	DRC
Staking ledger	1	DRC
Trading liquidity DRC	0	DRC
Trading liquidity BNT	0	BNT
Carbon fee burner	16348844	DRC

AUC

The current state of AUC is tabulated below:

Resource	Balance	Token
Master vault	6338967	AUC
Staking ledger	274	AUC
Trading liquidity AUC	4162871	AUC
Trading liquidity BNT	16205	BNT
Carbon fee burner	0	AUC

The trading liquidity for AUC is currently non-zero. The function call cannot proceed until this is nullified.
Simulating a DAO vote to nullify the trading liquidity…

Resource	Balance	Token
Master vault	6338967	AUC
Staking ledger	274	AUC
Trading liquidity AUC	0	AUC
Trading liquidity BNT	0	BNT
Carbon fee burner	0	AUC

A successful DAO decision has nullified the trading liquidity for AUC.
This action destroyed 16205 BNT. We can now proceed with the function call.

After the function call, the new state of AUC on Bancor V3 and the balance transferred to the Carbon fee burner is tabulated below:

Resource	Balance	Token
Master vault	274	AUC
Staking ledger	274	AUC
Trading liquidity AUC	0	AUC
Trading liquidity BNT	0	BNT
Carbon fee burner	6338693	AUC

[mbr]

Appendix

The Mechanism of Adjusting Trading Liquidity on Bancor V3

The design of the Bancor V3 protocol affords the DAO superb control over factors contributing to the systemic risks mentioned in the previous paragraph. Unlike typical AMMs, Bancor V3 can artificially reduce its bonding curve by partitioning the tokens available in its vault between “on-curve” and “off-curve” components. These mechanics are described in the Comprehensive Description of Bancor 3 section of BIP 15, and can be scrutinized in detail via the Bancor V3 simulation resources. Trading liquidity adjustments were expected to be a fairly routine aspect to management of the protocol. To understand what is being proposed, it is important that the arrangement of Bancor V3 be addressed.

The Master Vault

The Master Vault is where all the protocol tokens are stored. These are the “true” token balances; all deposits and withdrawals occur to and from this contract.

The Staking Ledger

The Staking Ledger is a record of the tokens received by the protocol, and is used to measure deficit and surplus resulting from trading via the protocol’s bonding curves, on a per-token basis (i.e. direct measurement of impermanent loss). When the master vault balance of a token is greater than the staking ledger balance, that token is in surplus; when the master vault balance of a token is less than the staking ledger balance, that token is in deficit.

The Liquidity Pools

The Liquidity Pools do not contain any tokens. The organization of Bancor V3 is inspired by Balancer V2, where the liquidity pools are designed to focus solely on the AMM functionality and are separated from the token management and accounting processes.

New function demo (illustrative purposes only)

from tabulate import tabulate

MASTER_VAULT = {
    'DRC' : 16348845,
    'FODL' : 10174584,
    'DAO' : 3375,
    'AUC' : 6338967,
    'DDX' : 6116,
    'KTN' : 37335,
    'SHEESHA' : 789,
    'APW' : 73710,
    'IDLE' : 32074,
    'HEGIC' : 1641375
    }

STAKING_LEDGER = {
    'DRC' : 1,
    'FODL' : 37,
    'DAO' : 0,
    'AUC' : 274,
    'DDX' : 0,
    'KTN' : 3,
    'SHEESHA' : 0,
    'APW' : 9,
    'IDLE' : 5,
    'HEGIC' : 458
    }

TRADING_LIQUIDITY = {
    'DRC' : {'BNT' : 0, 'DRC' : 0},
    'FODL' : {'BNT' : 0, 'FODL' : 0},
    'DAO' : {'BNT' : 0, 'DAO' : 0},
    'AUC' : {'BNT' : 16205, 'AUC' : 4162871},
    'DDX' : {'BNT' : 0, 'DDX' : 0},
    'KTN' : {'BNT' : 14213, 'KTN' : 23336},
    'SHEESHA' : {'BNT' : 11548, 'SHEESHA' : 789},
    'APW' : {'BNT' : 20370, 'APW' : 25936},
    'IDLE' : {'BNT' : 16327, 'IDLE' : 27518},
    'HEGIC' : {'BNT' : 13247, 'HEGIC' : 468402},
    }

CARBON_FEE_BURNER = {
    'DRC' : 0,
    'FODL' : 0,
    'DAO' : 0,
    'AUC' : 0,
    'DDX' : 0,
    'KTN' : 0,
    'SHEESHA' : 0,
    'APW' : 0,
    'IDLE' : 0,
    'HEGIC' : 0
    }

def nonzero_master_vault_balance(token):
    return(MASTER_VAULT[token] > 0)

def nonzero_trading_liquidity(token):
    return(TRADING_LIQUIDITY[token]['BNT'] > 0)

def token_in_surplus(token):
    return(MASTER_VAULT[token] >= STAKING_LEDGER[token])

def set_trading_liquidity_to_zero(token):
    TRADING_LIQUIDITY[token] = {'BNT' : 0, f'{token}' : 0}
    return(None)
    
def measure_token_POL(token):
    return(MASTER_VAULT[token] - STAKING_LEDGER[token])

def nullify_trading_liquidity(token):
    bnt_destroyed = 0
    if nonzero_master_vault_balance(token):
        if nonzero_trading_liquidity(token):
            if token_in_surplus(token):
                bnt_destroyed = TRADING_LIQUIDITY[token]['BNT']
                set_trading_liquidity_to_zero(token)
    return(bnt_destroyed)
                
def move_POL_to_carbon_fee_burner(token):
    if nonzero_master_vault_balance(token):
        if not nonzero_trading_liquidity(token):
            if token_in_surplus(token):
                CARBON_FEE_BURNER[token] = measure_token_POL(token)
                MASTER_VAULT[token] = STAKING_LEDGER[token]
    return(None)

def printer(token):
    data = [['Master vault', MASTER_VAULT[token], token],
            ['Staking ledger', STAKING_LEDGER[token], token],
            [f'Trading liquidity {token}', TRADING_LIQUIDITY[token][token], token],
            ['Trading liquidity BNT', TRADING_LIQUIDITY[token]['BNT'], 'BNT'],
            ['Carbon fee burner', CARBON_FEE_BURNER[token], token]]
    print(tabulate(data, headers = ['Resource', 'Balance', 'Token'], tablefmt = 'pipe'))
    print("\n")
    return(None)

def demo_new_function(token):
    print(f"The current state of {token} is tabulated below: \n")
    printer(token)

    if nonzero_trading_liquidity(token):
        print(f"The trading liquidity for {token} is currently non-zero. The function call cannot proceed until this is nullified.")
        print("Simulating a DAO vote to nullify the trading liquidity...\n")
        bnt_destroyed = nullify_trading_liquidity(token)
        printer(token)
        print(f"A successful DAO decision has nullified the trading liquidity for {token}.")
        print(f"This action destroyed {bnt_destroyed} BNT. We can now proceed with the function call.\n")

    move_POL_to_carbon_fee_burner(token)
    print(f"After the function call, the new state of {token} on Bancor V3 and the balance transferred to the Carbon fee burner is tabulated below: \n")
    printer(token)
    return(None)

demo_new_function('DRC')
demo_new_function('AUC')

[PaperStreetCapital]

Thanks for putting this all together, agree with the approach as it starts the process by “skimming” the excesses off the top where available. That window will continue to open as Carbon gets running and the increased value of BNT (generally from the burning mechanism) forces more of the surplus to the top, where this future process collects and removes more of V2/V3.

@mbr

Much of our governance processes and documentation is severely out-of-date. As the DAO regroups and updates its policies and procedures, it is my ambition to bring attention to this matter and formalize it.

To add to this, I’ll get back to my notes I had on what I put together from a few weeks ago (Updating the DAO due process). Seems like with this proposal coming together it can bridge the gap I hit on how to treat V2/V3 procedures while they were technically still active. Rethinking through this to form some bridge scaffolding to an updated DAO will be useful.

[foxsteven]

Interesting feedback @mbr

I do agree that the current proposal as written is not detailed enough to actually be implemented.

@alphavalion - What are your thoughts on the suggestions from @mbr?

Are you planning to update the proposal?

[alphavalion]

In the jungles of Mexico without much internet access. I will have more input this week and I am delaying vote on this until May 28th.

[frdrck]

This conversation should only be happening after the deficit is resolved, not before. Perhaps a proposal to use Carbon to gain funds (not just fees) to relieve the deficit could speed up the process. If you want to sunset v3, start with sunsetting the deficit first with urgency.

[alphavalion]

@mbr

Therefore, I recommend that new stand-alone proposals be drafted, which asks the DAO to approve a reduction in the trading liquidity on AUC, KTN, SHEESHA, APW, IDLE, and HEGIC to zero. The DRC, FODL, DAO, and DDX pools already have zero trading liquidity, so no actions need be taken in those cases.

Sure this is OK on my end and I see no problem with creating separate proposals to achieve this goal that sets the trading liquidity on all these pools to 0 and burns any BNT that is currently allocated. I should be able to spin up new proposals next week to have this go to a DAO vote.

@mbr

2a. Any surplus token quantities for every token in this list to be removed from the V3 master vault and moved over to Carbon.

2b. These tokens have a strategy created TKN-ETH in Carbon that will sell them via a limit order at a 5% premium based on the last 30 day time weighted average price or current price if 30 day TWAP is not available.

Additional detail is offered by the author following this last point, which is contingent on the strategy creation element - which is simply untenable at this point. I can address both of these points with a slight change in focus. Rather than moving the token excess to Carbon for strategy creation, instead, it can be moved to the fee burner. Then, these tokens can be handled as normal using the existing fee burning infrastructure if appropriate; where no token liquidity exists on V2.1 or V3, these tokens can simply be held until a new method is available that allows these tokens to be traded for BNT elsewhere on the market.

I disagree with this method as once the trading liquidity is set to zero on these tokens there will not be any liquidity left on Bancor to use the vortex effectively which most likely means that they will be dormant without being utilized. Furthermore, if there was any liquidity left on v2.1, this just opens up an arbitrage opportunity that someone else is going to capture and does not help Bancor.

Perhaps more important here is that our focus as a community should be 100% on Carbon and utilizing the protocol to our own advantage (NOT the vortex). We have tokens that are in surplus in need to be converted to ETH and which can help bootstrap Carbon’s TVL, volume, fees, etc… and creating a TKN-ETH pair that sells these tokens for ETH is what should be done to spotlight the new Carbon protocol. The headline that you will see on crypto twitter for this is quite simple and writes itself:

“Bancor DAO uses Carbon to create trading strategies paving the way for other DAOs to do the same”

@mbr

• There is no decentralized method to move tokens from Bancor V3 to Carbon, and a description of such a method has not been included with the proposal.

I do not buy this comment about a decentralized method not existing. The DAO voting for such set of actions to occur should be all that is required for the following:

1. Create a TKN-ETH disposable strategy on Carbon that sells TKN via a limit order at a 5% premium based on the last 30 day time weighted average price.

Getting the 30 day time weighted average price for these tokens is simple and can be done via any coin tracker site out there. This is an elementary exercise and does not require any oracles.

Average of each day’s price = (Open + High + Low + Close)/4

Average of 30 days = (Average of first day’s price + Average of second day’s price +…+ Average of thirtieth day’s price)/30

I have seen the math of the Carbon whitepaper and I am quite certain this is rudimentary for anyone in the Bancor team to perform.

Why is this comment even here?

@mbr

Carbon has no internal or external price oracles, TWAP or otherwise.

The method that I am describing does not need any of this.

2. Any ETH that is acquired from step 1 to have a BNT-ETH strategy that creates a buy wall at a 5% discount based on current BNT price. The buy wall to be revised every 7-30 days and when the current price of the buy wall is off by 10% or more from the current BNT price. The goal being that the buy wall should move up as the BNT price goes up.

You don’t need any oracles to figure out the price of BNT. You can easily get the price of BNT against ETH from either v2.1 or v3 via the ETH-BNT pool. Again, this is not a hard exercise to perform when you are creating the Carbon strategy.

3. Whatever BNT is recovered from takers eating into the buy wall to later be burned after a sufficient amount of BNT is acquired. This can be voted via a separate proposal similarly to recent proposal that burned BNT which had accumulated in V3.

We acquire BNT when someone sells into the ETH backing. Burning this BNT should be an easy task as we have done multiple BNT burns in the past.

With the above said, I would like to remind the entire Bancor Community that we previously voted to take

1. renBTC surplus from v3:

Proposal: Rescue any available value from protocol owned renBTC in V3

TL;DR Ren has advised holders to bridge back as they are sunsetting this version December 20th 2022 Bancor V3 has: MasterVault Balance 20.37031372 renBTC Staked Balance 0.03051750 renBTC Protocol Owned 20.33979622 renBTC This proposal suggests that the BancorDAO should use DeFi protocols to trade its renBTC for BNT and then burn the BNT. This can help reduce the deficit across all pools in V3. If for some reason there is not sufficient liquidity left in DeFi protocols, this proposal sugges…

2. move the funds from the Bancor V3 mastervault to a new address (0x362BA1e1e50FF430E6744522e18FC6D13ef08758) using the “Bancor Network: Deployer” address

Ethereum Transaction Hash (Txhash) Details | Etherscan

3. From the new address (0x362BA1e1e50FF430E6744522e18FC6D13ef08758) sell renBTC tokens for wBTC via Curve

Ethereum Transaction Hash (Txhash) Details | Etherscan

4. From the new address, sell wBTC for ETH via Curve

Ethereum Transaction Hash (Txhash) Details | Etherscan

5. From the new address, sell ETH for BNT via Bancor:

Ethereum Transaction Hash (Txhash) Details | Etherscan

Ethereum Transaction Hash (Txhash) Details | Etherscan

Ethereum Transaction Hash (Txhash) Details | Etherscan

6. From the new address, burn the BNT

Ethereum Transaction Hash (Txhash) Details | Etherscan

Proposal: Rescue any available value from protocol owned renBTC in V3

TL;DR Ren has advised holders to bridge back as they are sunsetting this version December 20th 2022 Bancor V3 has: MasterVault Balance 20.37031372 renBTC Staked Balance 0.03051750 renBTC Protocol Owned 20.33979622 renBTC This proposal suggests that the BancorDAO should use DeFi protocols to trade its renBTC for BNT and then burn the BNT. This can help reduce the deficit across all pools in V3. If for some reason there is not sufficient liquidity left in DeFi protocols, this proposal sugges…

Again, there was no:

@mbr

• decentralized method to move tokens from Bancor V3

to move renBTC from v3 to a new address, sell renBTC for wBTC via Curve, sell wBTC for ETH via Curve, sell ETH for BNT via Bancor, burn the newly acquire BNT. The DAO voting for this to happen was more than enough from a decentralization perspective to have these actions be performed.

I will be asking the same of the Bancor DAO via a separate proposal to perform the steps that I have described. This separate proposal will be brought for vote after the round of proposals to disable trading liquidity on all these tokens has concluded. The explanations that have been given are not sufficient or strong enough to justify why the process that I have described can’t be performed given similar operations performed in the past.

I would like to thank the entire Bancor community for the support that I have receive on my proposal. Together we will push forward and make this a reality.

[alphavalion]

I created 10 proposals to set the funding limit to 0 on the initial pools mentioned in this thread.

Proposal to set funding limit to 0 on DRC Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread and Bancorians should read that post to have an understanding about this proposal TL;DR DRC pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer trades as there is no BNT liquidity allocated to it. Any BNT liquidity …

Proposal to set funding limit to 0 on FODL Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread and Bancorians should read that post to have an understanding about this proposal TL;DR FODL pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer trades as there is no BNT liquidity allocated to it. Any BNT liquidity…

Proposal to set funding limit to 0 on DAO Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread and Bancorians should read that post to have an understanding about this proposal TL;DR DAO pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer trades as there is no BNT liquidity allocated to it. Any BNT liquidity …

Proposal to set funding limit to 0 on AUC Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread and Bancorians should read that post to have an understanding about this proposal TL;DR AUC pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer trades as there is no BNT liquidity allocated to it. Any BNT liquidity …

Proposal to set funding limit to 0 on DDX Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread and Bancorians should read that post to have an understanding about this proposal TL;DR DDX pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer trades as there is no BNT liquidity allocated to it. Any BNT liquidity …

Proposal to set funding limit to 0 on KTN Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread https://gov.bancor.network/t/proposal-to-start-sunsetting-bancor-v3/4279 and Bancorians should read that post to have an understanding about this proposal TL;DR KTN pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer…

Proposal to set funding limit to 0 on SHEESHA Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread https://gov.bancor.network/t/proposal-to-start-sunsetting-bancor-v3/4279 and Bancorians should read that post to have an understanding about this proposal TL;DR SHEESHA pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no lo…

Proposal to set funding limit to 0 on APW Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread and Bancorians should read that post to have an understanding about this proposal TL;DR APW pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer trades as there is no BNT liquidity allocated to it. Any BNT liquidity …

Proposal to set funding limit to 0 on IDLE Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread and Bancorians should read that post to have an understanding about this proposal TL;DR IDLE pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer trades as there is no BNT liquidity allocated to it. Any BNT liquidity…

Proposal to set funding limit to 0 on HEGIC Bancor 3 pool

Expected on Snapshot on June 4th, 2023 This proposal is split from the discussion that has happened in this thread and Bancorians should read that post to have an understanding about this proposal TL;DR HEGIC pool on Bancor v3 has a surplus This proposal is looking to set the funding limit to 0 Summary This is fairly simple and straight forward. Setting the funding limit to 0 on a Bancor 3 pool means that it no longer trades as there is no BNT liquidity allocated to it. Any BNT liquidit…

voting to happen this Sunday 6/4/2023 on all proposals

[foxsteven]

Thank you @alphavalion

I personally support this.

One question, and I’ll ask it here and on one of the proposals:

If by the time this passes the pool is no longer in surplus, what should be done?

[alphavalion]

I can set a condition on the “for” vote on these proposals

“Set the funding limit to 0 on the Token pool if it is currently in surplus. Otherwise, if at any point in time within 30 days of this proposal passing the pool goes into surplus then the funding limit can be set to 0.”

What do you think?

[foxsteven]

Not sure it’s critical but didn’t want anything unclear to be voted on.

Option 1: Leave the proposal as is, worst case, if the pool goes into deficit the DAO can vote to create trading liquidity again.

Option 2: Edit the “For” to

For

Set the funding limit to 0 on the TKN pool provided the pool is still in surplus at the time.

[alphavalion]

I modified the proposals and left a 30 day window period for the pool to be shutdown if at time of passing it is no longer in surplus.

[Jimmy]

I’m a little bit confused about surplus. Take MPH for example, https://analytics.bancor.network/ tells us there is a surplus for MPH, however my MPH position at V2 is in deficit.

[foxsteven]

This proposal is related to V3.

The ability to move TKN on and off curve is unique to V3.