Using curve’s stuff sounds great. A few questions tho:
We’ve been developing staking contracts for reward distribution for awhile. Can these support reward boosting with locked bal/weth BPT? Can these plug into curve contracts? Or did we just spend dev resources on these for nothing and need to use curve rewards distribution contracts (the gauges, etc)?
Can we pick and choose curve systems to use without using all of them? This proposal did not cover moving to automated liquidity mining via gauge voting but that is core part of curve’s system.
If we move forward with curve system per this vote, it would only include locking bal/weth BPT for a rewards boost and to vote on proposals. There would not be any voting on gauges and LM would continue to be entirely manual by the LM committee. Future discussion may not lead to the desire to implement a gauge system. We could be faced with a future where we have part of curve’s system and we need to build other parts to our unique specs. If we don’t have anyone who really knows vyper, could be a problem.
Moving to curve system would mean leaving snapshot and votes would need to be done using their on-chain system. Or we going to simply change snapshot to only allow locked BPT to vote and not implement curve on-chain voting?
Maybe I can think of more but these are first ones
The implementation of the curve framework does seem like it would need to be a big overhaul of the current system. Not sure how you would keep today’s model in place if you keep the part in about only BAL/WETH being the only pool eligible for locking/boosting.
Focusing in on the governance side, in either case, using on-chain voting or snapshot using BPT the only people that get to vote are those that have provided BAL or WETH to BAL/WETH. That is a bit of a different model than what curve has where every pool earning CRV incentives on mainnet is eligible stake LPs and then ultimately lock CRV for voting.
What if people, for whatever reason, don’t want exposure to WETH but feel forced to provide BAL to BAL/WETH just so they can vote? I guess i didn’t bring up that tidbit in the earlier proposal and i know the plan would be to add in other pools, but that could be a negative look at the start of this program for some people. Today’s implementation around voting is more inclusive and keeping it that way seems important.
I’m concerned the mechanics of this proposal lead to a gamification of boosting BAL/WETH liquidity at the expense of all other pools on Balancer. In the case of Curve, it works because they have 1/2 core pools that by nature attract all of the liquidity, trading volume, and routing. But within the Balancer ecosystem, the BAL/WETH pool isn’t meant to be a hub and spoke model where most trades route through that pool.
As is, we are already over-rewarding the BAL/WETH pool IMO. Taking a step back, liquidity mining is meant to be a short term measure to kickstart the flywheel of liquidity until long term LPing becomes a profitable endeavor. It is not meant to boost BAL price as much as possible short term to attract unsticky liquidity that will chase the highest APRs. Even without any LM for the BAL/WETH pair, I suspect Balancer would remain the most liquid venue for it so why is the protocol paying so much for LPs to add to that pair. I think the Ballers have done a great job using LM to highlight the unique features and pool types of Balancer and prefer we lean much more in that direction including things like Gnosis gas cost reimbursement. That grows organic retail traders and creates lasting value for the protocol even if it does have some short term negative price impact to BAL.
Switching to the technical implementation, it is clear even if we do want to use Curve’s contracts there will be some modifications necessary. And I hate to introduce Vyper contracts since all of our background, tooling, integrations, etc are all Solidity based. If it was the case where we we’re just “plug and playing” the contracts it might make sense to use the contracts as is (lindy effect and all). But since we will need to make somewhat meaningful changes I’d strongly prefer we do this in house even if it means a longer roadmap
I don’t think I agree that we’re over-rewarding the BAL/WETH pool. While you are right that the rewards attract unsticky liquidity that chases the highest APRs, even if not sticky, that liquidity being around is what makes the exchange useful to the traders we want to attract.
Liquidity begets more liquidity, and greater TVL will result in a greater BAL price, which increases APRs which attracts more liquidity.
All DEX’s currently seem to be trading at lifetime values of about 66% of their TVL. Doesn’t seem to matter whether it’s Sushi, Curve, Bancor or Balancer. Reducing BAL rewards for the BAL/WETH pool would result in more selling of BAL, which then creates reflexivity in the opposite direction.
I think a lot of liquidity is APR sensitive, even seemingly “sticky” liquidity, and when we wind down rewards for pools to zero, it’s quite typical for all of their liquidity to drip off to near zero over a few weeks.
Core to everything is that at the moment Balancer doesn’t attract enough trade volume. Whether that’s direct, or from aggregators. But I don’t think we’ll be able to build that trade volume without also attracting the mercenary capital that follows APYs around, which I think makes BAL price quite important. Other than Uniswap, I can’t think of a single successful DEX that doesn’t heavily incentivise their own token pools or do things with locking to somewhat sustain prices for their token (directly or indirectly).
Adding modifications to the original locking contract from Curve seems to be a deal breaker, since it’s in vyper and would have to be migrated to solidity before any modification. This is a major undertaking which is equivalent to starting from scratch: dev effort, time and cost of auditing, and the lindy effect being reset to zero.
Maybe a joint effort with some other teams that also want to have their own flavor of a staking+locking contract in solidity could speed things up and divert less attention from the BLabs dev team?..
One other very important point mentioned by @DavisRamsey and @zekraken is to make sure we don’t disrupt Snapshot voting. It wouldn’t be fair to leave any of these groups without voting power:
I talked to @fabien from Snapshot Labs and he confirmed this is possible, so we’re good on that front.
Suppose we call it “veBPT80” (this voting power from locked BPT of the 80/20 BAL/ETH pool).
Then in total we’d have 4 Snapshot strategies (ie ways to have voting power, all adding up to your final voting power):
BAL
BAL from BPTs (from any Balancer pool containing BAL)
veBPT80
delegations( BAL + BAL from BPTs + veBPT80 )
Currently Snapshot supports up to 8 strategies being active at the same time.
I think if this is implemented the only snapshot strategy would be veBPT80 tho right? A large part of why you lock is for “Governance Benefits” so we can’t let ppl who don’t lock continue to vote
It feels weird (maybe even wrong) to force people into an ETH exposure in order to be able to vote on Balancer governance. But either way, I suppose we can adjust veBPT80 (at the contract level) to have a lot more voting power than BAL.
Expanding a bit on how to implement LM for the 80/20 pool, one idea would be to use Curve’s mechanism for protocol fee distribution: using the Fee Distributor contract, which I suppose allocates fees according to each user’s veToken balance. Balancer could send the LM allocation for the 80/20 pool as if it were protocol fees being received. So no modifications would be needed. Can someone technical investigate if that’s the case?
I think that’s a great idea. I agree with Mike and others that changing anything in the Curve contracts would require us to do a full overhaul and rebuild the whole thing from scratch in solidity. This is a no-go at least for now given our limited resources.
Using the Fee distribution contract with Liquidity Mining BAL as if it’s just a fee captured by the protocol has exactly the same end effect that this proposal wanted: giving a boost to stakers considering the lock-up. Also, this same distribution contract could be used in the event the DAO votes to activate the protocol level fee in the future.
On voting power, I also agree with @followthechain that we should not force BAL token holders to stake to be able to vote. However, if they do, because of the staking boost, 1 BAL staked for say 4 years would have a lot more voting power than 1 unstaked BAL.
Something worth us having a look at is what GRO is doing with their LM rewards also. It seems to be successful, so far, information is here: Gro
Basically:
You earn GRO for staking pool tokens.
You can either claim the full amount after a 12 month vesting period, or forfeit 90% of your rewards and claim immediately.
Forfeited GRO is distributed to those staking pool tokens who have opted to wait the full 12 months as a bonus, those vesting can claim their share of this forfeited GRO every 14 days.
Seems to build upon what other projects have done recently, and a nice way to align LPs longer term. Could be mechanically much easier to implement something like this than Curve-style gauges.
Lots of people are using GRO and don’t seem to be put off by the vesting. Whether we’d have a more difficult time imposing something like this now, after so long distributing liquid BAL, I don’t know.
Thanks for sharing @bakamoto20! Maybe when we code the staking/locking contracts we could assess how much more challenging it would be for the governance to be able to decide for a vesting of BAL from LM. My guess is that it would complicate a lot the contracts and would probably not be worth it.
On a separate note, I’m coming across more and more projects that are interested in having the lock/staking contracts similar to Curve, but in solidity — so they feel more comfortable using and tweaking them if necessary. Check out this discussion by the Gnosis community who’s also considering this for GNO.
We started to work on a Solidity version of veCRV. Frax actually did a translation a while ago to Solidity but did not include the contract that distributes fees.
We’d be happy to collaborate on building and shipping this so both our communities can benefit! At the moment our biggest challenge is making the veCRV contract compatible with the Compound governance framework but I don’t think this will be an issue for Balancer.
We have people evaluating if the translation alone would be a good fit for us. Do you need all the infrastructure around the gauges or is that not relevant for you? In any case, it’ll be great to collaborate and share resources on this.
We’ll keep you up to date here in this thread, please do share any relevant info with us too.
We probably won’t need gauges, only the staking contract and the fee distributor.
Code is already fully translated for these two and we’re making tests. Will also keep you up to date on anything new but in the meantime the link in my post above has all the code.
