To support the proposed token migration to V3, vote FOR
To oppose the proposed token migration to V3, vote AGAINST
TL;DR
The Bancor 3 Pool Creation Proposal started the migration to V3 with 4 initial pools with an expectation of more pools going live in the coming days/weeks.
This plan was suggested in the proposal as a safety consideration.
This proposal is intended to complete the migration to V3 by migrating over all other tokens outlined in BIP 17
Summary
The quick migration to V3 in the 4 pools previously approved shows the strong demand from LPs to be staking in V3.
Constant monitoring of V3 behavior shows that the pools are indeed functioning as intended.
The rollout of additional pools is planned between May 29th and June 5th.
The goal is get the pools live as soon as practical and as close to simultaneous as practical however issues and complications that often cannot be predicted in advance may occur, and as a result, a window is proposed.
Of course, if there are any unexpected events on Ethereum (such as airdrops causing gas spikes, hacks or anything else unforeseen) or in the deployment of the pools that would create unnecessary risk, these dates should not be considered more important than any user or protocol safety concerns.
Safety First
This proposal does not require that the pools are either deployed in a single batch or in multiple batches, rather it suggests that during the deployment safety and user funds are the top priority.
Accordingly, if any specific issues arise in a particular pool, this proposal, if passed, grants the right for those pools to have deposits and/or trading disabled immediately and later voted on by the DAO similar to how it was outlined in BIP 21
To support the proposed token migration to V3, vote FOR
To oppose the proposed token migration to V3, vote AGAINST
Missing quite a few critical pieces of info from the above PROP ^
There should be dates and deadlines for subsets of pools. Communication to your LPs is important.
Setting hard dates and times for pools to rollout is honestly disingenuous and could actually become a security risk. Giving core contributors more flexibility in monitoring the pools being deployed equals more checks/security/peace of mind. What exactly is the rush?
Creating a roll-out PLAN and adjust as needed shouldn’t be that much of a security/legal risk. Being able to communicate expectations to your userbase shouldn’t be this hard.
No rush, but setting expectations and letting Depositors know when they are able to migrate is critical.
Personally I’d rather see a faster deployment with flexibility than a slower roll out with a planned schedule. I think this migration needed a bit more structure for sure but at this point I’d rather have us fully live as soon as possible and the tentative dates of the 29th-5th still give us a good idea as to when the pools will be live and if it makes things better from a security standpoint as Tyler mentioned I’m even more for it.
Thank you for your feedback, I have edited the proposal:
The goal is get the pools live as soon as practical and as close to simultaneous as practical however issues and complications that often cannot be predicted in advance may occur, and as a result, a window is proposed.
FYI, there is a bootstrapping process for every pool that gets created on bancor. This includes things like setting the funding rate (different for every pool), setting fees (different for every pool), monitoring for minimum amount of TKN liquidity to enable trading, setting BNT/TKN rates, monitoring pool depth and making sure that trading liquidity is doubling as expected, etc…
Hence, there is a procedure for every pool and each one requires some nontrivial amount of time for it to be fully up and running. There is flexibility built into this proposal for this reason and some of the others that have been expressed already.
Pool Genesis, Bootstrapping, Restricted Growth, and Shutdown
At the time a liquidity pool is first established, the Bancor Network may begin accepting tokens from users and issuing pool tokens, before trading is possible.
The BancorDAO prescribes a liquidity threshold, denominated in BNT, that represents the minimum available liquidity that must be present before the protocol bootstraps the pool with BNT. This parameter is adjustable, and is set to 1,000 BNT at the time of launch.
After sufficient TKN liquidity has been collected, prior to the activation of trading by the pool, the process of bootstrapping the pool with BNT to enable trading is handled via the DAO msig.
The minimum BNT liquidity for all pools across the protocol is a global setting.
The BancorDAO governance process prepares and approves a new token in the whitelisted assets, with a defined BNT funding limit.
The pool is created via a permissionless process, and initial TKN are added by members of the community.
No BNT is created by the protocol at this time; however, bnTKN pool tokens are issued at a 1:1 rate with the provided TKN.
The DAO msig confirms the current status of the TKN provided, using external market prices (e.g. CoinGecko, Coin Market Cap) and initializes the pool to begin trading if there is sufficient value to meet the threshold for minting the minimum BNT liquidity. The minimum BNT threshold is 10,000 at the launch of Bancor 3, and is adjustable by the BancorDAO thereafter.
The DAO msig then sets a TKN/BNT rate, commensurate with the market prices of both assets.
The protocol then mints the minimum BNT liquidity, and creates trading liquidity with the appropriate amount of TKN.
Vault token balances of TKN that exceed the minimum BNT liquidity are used to grow the pool according to an exponential growth curve, until the BNT funding limit is exhausted.
The pool’s liquidity depth begins at the minimum BNT bootstrapping amount, regardless of the available TKN inside the vault.
Future liquidity additions trigger the following process:
New liquidity is accepted into the vault, bnTKN is issued as normal.
If the spot rate is within a preset tolerance of the EMA rate, the pool depth is allowed to double, or become equal to the vault balance of TKN (whichever is smaller).
If the spot rate is outside of the EMA tolerance, no changes are made to the pool depth.
If a withdrawal is made while the BNT balance of the liquidity pool is below the minimum threshold, a security mechanism is activated, and the pool is returned to its bootstrapping state.
All BNT is removed from the pool, and destroyed. Therefore, trading is no longer possible.
Withdrawals can still be processed with a conditional insurance schedule.
Deposits can still be accepted, however the pool will remain inactive.
Pending an investigation by the BancorDAO, the pool can be reactivated via the same pool initialization process as is used for pool genesis.