@StefanoBury_LongHash here’s the in-progress code for the staking contract - it is based on the synthetix/curve staking contracts
This will replace the current off-chain calculation for rewards (LPs will continue to earn BAL rewards for providing liquidity)
Thanks for following up @StefanoBury_LongHash!
My suggestion would be to keep things simple and summarize this RFC discussion with a new proposal for BAL staking that is very similar to Curve’s successful model. Maybe add the early sale penalty like @felix_macht mentioned if that’s easy to implement technically (I guess it’s all open source so we would just copy the battle tested contracts and avoid reinventing the wheel).
Then we would have vBAL (or whatever we want to call the token) when BAL is staked. That would have a boost proportional to how long its staked/locked.
Another very interesting aspect of Curve’s model is the gauge where vBAL holders can signal which pool they want to get BAL Liquidity Mining rewards create a positive feedback loop and further incentive alignment to hold your liquidity in the pool you vote for in the gauge. Maybe we could have a portion of the 145k BAL being distributed according to that vBAL allocation (similar to Curve’s gauge) and the rest by Ballers as is being currently done.
Quite a few projects are adopting this model:
I believe we would highly benefit from it too.
Curious to hear more opinions on this.
I thought about this too. Only potential issue is gaming of the system somehow, like 98/2 DAI/WETH 10% fee pool or smthin and a whale votes to give big rewards to it. Maybe it’s less of a concern today than it was in the past though.
I’d like this idea of locking BAL a lot more if we implement the gauge voting - anyone can make a pool and vote using locked BAL for it to get rewards. I’m just a bit concerned there may be some edge cases where whales point a ton of BAL rewards to really “bad” pools.
I can imagine when we have investment smart pools, a community might start one and collectively lock BAL to vote rewards in for it. DAO Treasury could do the same thing. Tons of possibilities here that could be quite interesting imo.
My concern with it is that LPs will only think about what works for them as an LP, not necessarily what’s best for the wider protocol. I can imagine pools being designed to maximise BAL with minimum impermanent loss, etc.
With Curve it’s much simpler, as they pretty much only have stablepools. I think it’d take an awful lot of thought to work out how you could get to a place where BAL stakers decide what gets incentivised/not, and how we ensure that the result is aligned with what’s best for the protocol.
Great points. I think I had an idea that could address your concerns.
Instead of defining the amount of BAL a pool gets just using the vBAL voting power it has, why don’t we make a correction with the utilization ratio of the pool (defined by average_daily_volume/average_tvl). This would ensure that bad pools (e.g. controlled by a whale) would not get as much BAL as legit pools. What that formula would look like exactly would require some more detailed discussion but is certainly a solvable problem.
There are still ways to attack this, for example: a whale creates a pool with a risky token so that they have 100% of the liquidity, then they can wash trade as much as they want for free. These cases would be quite obvious to spot: we could simply entitle Ballers to decide on invalidating a pool for the gauge voting if anything like this happens.
The gauge has the big advantage of making the LM process more community driven and creating interesting incentives like what @solarcurve mentioned:
I can imagine when we have investment smart pools, a community might start one and collectively lock BAL to vote rewards in for it. DAO Treasury could do the same thing. Tons of possibilities here that could be quite interesting imo.
Great comments and feedback. Before moving on to summarizing the discussion in a Proposal, I want to clarify whether we are still on the track to create a mechanism to stake BPT from the BAL-WETH pool and obtain vBPT, or whether we are circling back to staking BAL? Initial concerns around the latter was taking BAL out of circulation and specifically out of the BAL-WETH pool.
I would propose going forward with a proposal for staking BPT for the BAL-WETH pool in exchange for vBPT that gives you governance voting power + boosting of BAL rewards (total pool rewards don’t change but who earns what within the pool changes based on how long they stake BPT for) with option to un-stake for a penalty to keep things simple, then additional proposals can be written that add additional features, such as vote boosting, quadratic voting, etc.
WDYT?
We’ve spent a bit of time researching the rewards boost approach and formula from various other protocols and there’s a few decisions to be made around four design choices. Wanted to get your input on these prior to proceeding to proposal stage:
1. TOKEN VS. MULTIPLIER
There are two options to design the BAL rewards boost:
1. Token-based approach: With this approach, LPs would receive a number of staked tokens (i.e. vBPT) based on how long they stake for. For example (the numbers are purely illustrative): 1 vBPT if they stake for the min period of 1 week and 10 vBPT if they stake for the max period of 4 years, with a linear increase. The BAL rewards earned would be proportional to the number of vBPT the LP holds
2. Multiplier-based approach: With this approach, LPs would receive vBPT on a 1:1 basis to their BPTs. The rewards boosting would be, for example, 1.05x for the min period of 1 week and e.g. 3.5x for the max period of 4 years
Our perspective: The multiplier approach is more common and less confusing than having different ratio of vBPT tokens to BPT tokens, and the curve for vote boosting and rewards boosting is likely to be different so there isn’t a major need to link the two
The formula for rewards boosting would work, conceptually, as follows:
[LP’s share of pool] x [Multiplier] / [Sumproduct of LP’s share of pool and multiplier] = [Share of BAL rewards]
Simple example:
| LP | Share of pool | Staking | Duration | Boost | Boost x share | Share of rewards |
|---|---|---|---|---|---|---|
| LP A | 30% | No | N/A | 1 | 0.3 | 17.1% |
| LP B | 20% | Yes | 4 years | 3.5 | 0.7 | 40.0% |
| LP C | 50% | Yes | 1 year | 1.5 | 0.75 | 42.9% |
2. UPFRONT VS. FLEXIBLE LOCK UP AND BOOST
There are two options for the staking mechanism:
1. Upfront lock-up: This is what we have discussed so far and is basically the Curve mechanism, in which you choose the lock up period up front, and then you lock up your tokens. This could have the option to unstake, with a penalty
2. Flexible lock-up: With this model, there would be no upfront lock up. LPs can stake on an open-ended basis and the rewards boost would increase linearly over time (up to a point / limit, e.g. 4 years). In this model, let’s say there are two LPs, A and B. A and B begin staking at the same time, and their boost is the same at the beginning. A unstakes after 1 year, after which A stops receiving the rewards boost, while B keeps their BPT staked, and their rewards boost continues to increase (up to a limit)
Our perspective: The flexible lock-up addresses the points made earlier in the discussion about having an exit mechanism with a penalty, as well as the concerns about small token holders not willing to lock up for 4 years upfront. This option provides the most flexibility to LPs
3. REWARDS BOOST RANGE
What we have seen with other protocols, including Curve, Idle Finance, Pickle Finance, Badger DAO, and Cream Finance is from ~0.5x boost (i.e. multiplier of 1.05x) up to ~2.5-3x (i.e. multiplier of ~3.5-4x). If we are comfortable with this we will draft up a table for the Proposal as we did in the original post of this thread
4. Naming of staking token
There seems to be a bit of confusing on the naming of the staking token. Perhaps vBPT is a bit confusing, so maybe we just go back to calling it vBAL, i.e. those LPs who stake their BPT get vBAL
Looking forward to your comments, then will summarize and synthesize into a Proposal. Thanks!
Hello @StefanoBury_LongHash,
thanks for the great work you are doing!
TOKEN VS. MULTIPLIER
I very much prefer the approach that involves the Multiplier-based approach with a Flexible lock-up. It seems to me an innovative idea that at the same time encourages BPT staking.
Personally, I see the 4-year lockup period to be decided in advance as too restrictive and inflexible. In my humble opinion, it could drive away potential LPs.
REWARDS BOOST RANGE
No comments on this. Seems acceptable to me.
Naming of staking token
Regarding the naming, I would tend more towards vBPT since the staking is related to BPT and not BAL. If we call it vBAL the risk is to confuse the community even more.
Everything here seems fine. Staking usually comes with a service to the protocol. While 80:20 BAL/WETH BPT staking is better than locking BAL to do nothing, the BAL/WETH pool doesn’t really do much other than provide liquidity for BAL.
I think staking should add more value than just BAL liquidity, but I’m unsure on the best way to achieve that.
@Andrea81 @iyvy thanks a lot for your feedback!
@Fernando @bakamoto20 @DavisRamsey @felix_macht any thoughts from your end on the additional design choices (token vs. multiplier, upfront vs. flexible lock up, rewards boost range, and vBAL vs. vBPT name)? Would love to synthesize this into a proposal over the weekend.
Thanks!
Thanks so much for your thoughts and through research @StefanoBury_LongHash! Extremely helpful.
I do agree we should focus on staking 80/20 BAL/WETH BPT instead of pure BAL.
On your comment @iyvy:
I think staking should add more value than just BAL liquidity, but I’m unsure on the best way to achieve that.
I agree and think future versions of Balancer could use this pool also for other things like insurance (e.g. the safety module of AAVE which uses our BPTs), but IMO we should now keep things simple and make small, iterative steps.
2. UPFRONT VS. FLEXIBLE LOCK UP AND BOOST
While I see the advantages of the flexible approach, one clear disadvantage is that stakers that are willing to bet long-term on Balancer and would lock their BPT for 4 years don’t have the advantage of a large boost until 4 years in the future. A great thing of the upfront option is that LPs can benefit from their conviction immediately and this creates skin in the game. If users are scared of the long duration they can always choose a shorter period AND ideally we would have the penalty for early withdrawals.
Before finalizing this proposal though we have to hear the devs at Balancer Labs who will likely be responsible for implementing this on the smart contracts side. @Greg, @nventuro: I know the staking contracts are almost ready and being audited. Would the boost be a complicated thing to add to it? Or would it be possible to add it on another layer and so not changing the current architecture. The fact that the staked tokens are non-transferable/non-fungible probably means we would have an implementation challenge.
Excited with the progress here and looking forward to a final proposal soon!
Thanks a lot @Fernando !
Final thoughts:
(1) Looking forward to hear from @Greg and @nventuro on the technical feasibility / approach to this proposal
(2) For the Upfront vs. Flexible, wonder if this one we should put as two options in the Proposal? Let me also seed the idea in the Discord Forum to see what the broader Community thinks
That’s a good idea! We only have to be careful with not fragmenting into too many options (I’d say we choose 2 max) for the vote or else even if the majority wants the change they won’t agree on a single option and the proposal won’t pass (since the reject option would win).
Regarding the other uses of staked 80/20 BPT, I think an obvious next step I mentioned above (we could discuss implementing it together or after the staking changes) would be to do the gauge voting where liquidity mining BAL would be directed according to how much BPT is voted for each pool.
I think there should be a list of allowed pools which would be very inclusive (just to avoid gaming of people creating pools with rug-pull tokens and voting for these pools) and also some factor taking into account the efficiency of the pool (which I would define as LP fees divided by TVL).
Bringing into the discussion Dan Elitzer (@delitzer) which I’m sure has a sharp view on this topic!
Thanks @Fernando ! I think for most of the design choices we can put forward what we have agreed within this group and perhaps just leave the flexible vs. upfront locking as a design option.
Also looking forward to hearing from @delitzer !
I don’t think we should complicate the proposal with additional options, we should finalise something here to go to a vote, then if that vote fails consider the other option IMO. Otherwise we’ll split the “Yes” vote over a couple of options and could see it fall, which then makes it more difficult to put a new proposal forward for the single option.
Personally I think upfront makes much more sense than flexible for what we want to achieve. People who lock-up the most BAL for the longest period of time should instantly be rewarded for that, not have to wait. Ideally you’d have a max 4 year lock with the boost decaying over time (so e.g. when you have 6 months left your boost is the equivalent of if you locked for 6 months today), to encourage re-locking for longer periods.
The reason I reject the Flexible lock-up idea is that it doesn’t facilitate long term alignment. If Balancer encounters a troubling period, people could just instantly unlock and go somewhere else, whereas if they have their tokens locked they might engage with helping instead. In terms of the unlock with penalty for the upfront version: does Curve do this? Again, an issue I see with an early unlock here is that the ROI of locking in for 4 years with max boost then taking the haircut on the unlock could easily be more profitable than locking for a shorter period after a short period of time, even if the penalty was significant.
@StefanoBury_LongHash Thank you very much for putting together this proposal and revisions and driving this conversation.
To start, I’m very in favor of the vBAL proposal using 80/20 BAL-WETH BPTs, with a max lock at 4 years. Upfront locking makes the most sense to me as that is what everyone adopting a similar model has done and I don’t think this is an area it’s worth trying something different, given we have no evidence or even strong intuition that the flexible approach will lead to better outcomes. If the sentiment really is that there should be some flexibility, copy the oSUSHI proposal and apply a 50% early unlock penalty, and then perhaps have that decrease linearly over the locked period.
The power of this proposal will really become clear if/when vBAL is used to adjust liquidity mining gauges. I like the idea of an open liquidity mining system with the ability for BALers to step in and block malicious pools. However, we need to be prepared for a marked increase in both inter- and intra-protocol politics as a result. We can expect Yearn or other yield aggregators to create Backscratcher-type vault, then direct rewards to pools where they will be harvesting and selling BAL rewards. The Balancer community needs to be aware of this dynamic and comfortable with it, as it can be quite powerful, but also scary to see large amounts of claiming+selling. I think the dynamic is a net positive, but if the Balancer community freaks out and decides to somehow revoke rewards being used in this way, it could really backfire.
Ultimately, I strongly recommend moving forward with a vote on the vBAL proposal. Maybe the options are:
a) Implement vBAL using 80/20 BAL-WETH BPT with upfront locking [and maybe also the 50% early unlock penalty?]
b) Implement a different version of vBAL (go back to the forums)
c) Do not implement vBAL
Then, once we have this governance system in place, we can move forward more rapidly and confidently on topics like gauges and protocol fees, which I believe would further increase the flywheel effect.
My chief concern with vBAL being used to adjust liquidity mining gauges is that we will end up with all the BAL being allocated based on what allows LPs to earn BAL for the lowest risk, rather than what facilitates trade volume & fee generation for the protocol.
Without guardrails we’d (almost undoubtedly, imo) end up with loads of BAL being directed towards various stablepool iterations that don’t expose LPs to impermanent loss, with vaults being built on top of them by various partners. Lots of the pools would do very low volumes, and other pool types would suffer.
Other pools like WBTC-WETH, WBTC-WETH-DPI, etc would also likely end up with big shares. But by the end of it we’d be pretty useless as an exchange outside of the few assets that end up incentivised.
This is a very valid concern but I think we can solve that by tweaking the gauge system in a simple way:
Also, I would still keep a portion of BAL for Ballers to allocate for partner projects that keep their liquidity after LBPs and other important experiments. Maybe 15k BAL or so?
Finally, I agree with @delitzer about the three options to be voted on. We would need though a more detailed forum proposal with what exactly option a) would look like. Maybe you could help us with that @StefanoBury_LongHash if you agree with Dan’s suggestion?
Yep, great points raised by @bakamoto20 and these suggestions seem like they should mostly address them. Another blunt tool that could be layered on top would be capping the max amount of BAL that can be distributed weekly to each pool.
Thanks everyone for the additional feedback. I’m writing out the proposal for option (a) today as proposed by @delitzer and incorporating the additional points (e.g. around upfront locking which seems what most people are in favor of). The plan is to put it up on Snapshot for a vote mid-week (around Wednesday)