This proposal is to define the role of vBNT and itās representation of staked BNT. Itās my hopeful assumption that it represents BNT locked to the protocol and not a certain pool, and the reason for the clarification is made clear soon.
Abstract
At the moment, the only other thing that allows staking without need to claim BNT to wallet is LM Rewards, I want to also have this for staked BNT, allow people to re-stake [better put, instead of removing liquidity and having BNT go to their wallet, they can instead migrate the liquidity to a different pool]
Motivation
Simply put I never intended to unstake my BNT so I did the only thing that made sense to me, take the vBNT and convert it so I can continue to stake more and fund my continued interactions with the protocol. - this should make it clear why Iām so eager to find out how we reflect on this proposal - literally decides my fate with Bancor.
Benefits
Allows both locked[no vBNT] and staked BNT that is user controlled the option to freely (although maybe there would be some restriction on movement, based on the token amounts) move between pools to provide best yield.
Side Note:
My input for only 1 BNT staking pool for whitelisted LM would alleviate this proposal all together, since BNT would be automatically migrated on the users behalf, so vBNT would have no hindrance.
Also, since Iām not sure of all the features of v3, it may already address some/all of the concerns of this post.
For
Allow for re-staking of BNT without regard to vBNT balance. [user would not be able to withdraw BNT to wallet without vBNT]
I like the idea behind this proposal as it provides some good suggestions about how we can potentially improve the staking experience with BNT. I have deduce the following points from the initial post:
Allow people to migrate BNT from one pool to another without unstaking
Potentially have a system that balances BNT across pools to get you the best yield
Suggestion for a single BNT pool that everyone stakes against and lets the system allocate this BNT to where it is needed
With that out of the way, I am not sure how much of the above is feasible to implement? There are technical limitations that the DAO might not be aware of and in some cases it might not make sense to do (contract complexity might lead to expensive TX (we already have this problem)). Without getting input from the developers these type of proposals even if passed might not actually lead to anything actionable.
I think the DAO should definitely have control over certain parameters (where and when they make sense) but other implementations items should be left to the developers and not be dictated by governance. We can certainly provide guidance via community calls, development feedback in discord/telegram, topics on forums, Github issues, reaching out directly to Bancor folks (MBR/Nate), etcā¦
I wonder if these types of proposals are better suited to the āTemperature Checkā format similar to the current Ethreum scaling proposal that is live on snapshot. Essentially, they are non binding and meant to purely gauge the community interest to provide guidance to Bancor developers.
If these were indeed the OPs intent, I really like these ideas. It makes life so much easier for the BNT LP.
It sounds crazy, but I donāt think we should put gas costs at a super high priority, at least not at firstāthatās an optimization. The reason is that gas is going to get cheaper (Casper + L2), and even so, there are ways to offset oneās gas cost, there are even ways it can be done from the development side. Gas is expensive now, and that makes it an issue now, and Iām not saying that we should ignore it, because I can say from experience that gas costs do influence investor decisions, right now, because it sucks down so much money that it does have a measurable effect on profits; but it will not always be so, and in a decade weāll all be laughing at ourselves and each other over how much we overpaid for gas in these recent times. (250 gwei at $4000/ETH for a deposit? nah im good thx)
Implementation detailsāwhat data types are used, what language is used, how the code is organized, etc.āshould be left to developers; overall design and functionality are part of the end-user (i.e., the community) experience. We canāt just throw up our hands and say, āwell, the developers are the ones doing it so we canāt have a say in whatās done.ā Thatās kind of a load of crap because without the community around it, Bancor would be nothing more than a gaggle of code living in an abandoned corner of the Ethereum and EOS networks. Iām also not saying that the developers are slaves to our whims; what Iām saying is that itās a partnership, and both sides of the room need to actively work together to make this thing work and to bring prosperity to everyone involved. We need to tell the developers what we want/need so they have a better guide for focusing effort and theyāre not wasting precious developer time on things that might not be as helpful; but we also need the developers to tell us what canāt be done or what would be unreasonably difficult to implement, so that weāre not wasting precious governance time on things that are wholly impossible or are going to be more of a waste of developer time than theyāre worth. I think weāve all done a fantastic job at this so far (speaking solely from the community side of things, mind), and I donāt see that weāre in danger of stepping away from that anytime soon.
Yes, I like the thread on the suggestion to allow claiming a custom amount:
which had one of the developers chime in and explain why claiming was design in a such way to encourage claiming the full amount. I donāt necessarily think that is a proposal that should go up for a vote for the DAO to decide since a good case has been made already by one of the developers for claiming the full amount. Ideally, I donāt think the DAO should be guiding implementation details as you suggested and that should be left to the developers.
Perhaps this is a problem with the medium (discourse?) which is not well suited for feature requests. After submitting a feature request for snapshot (https://features.snapshot.org/feature-requests) using their feature request platform, I think that type of system lends itself better for these types of suggestions. Essentially the community can submit ideas about the product and those that are popular get upvoted by members so that the developers can prioritize on features that we are asking for. Either that or we create a section on discourse for feature requests (might be worth doing).
Wanted to make sure that I noted that, those three points are exactly what Iām aiming for, in addition, this was definitely more geared towards the coding development team as feedback for v3 and beyond. Although, I did want to make sure this potential idea was brought forth (seems it was also addressed in the community call) - which is a good sign.
