Thanks everyone for your comments and valuable input!
I guess the main argument raised for option 2 is the expectation veBAL holders had of getting 10% of LM at the moment they locked.
Interestingly, the exact people who locked (current veBAL holders) are the ones who are going to decide their fate in this vote (of course some new people will lock between now and the snapshot vote but that shouldn’t be significant). So if the 10% LM is really important to them we will see that in the vote outcome.
Members from the liquidity mining committee themselves are advocating to eliminate it and no one had any objections. If this continues to be the case for the next day or two I will edit the proposal to add this point for both options.
To conclude, I’m also of the opinion that in both options the free choice of % allocations across chains is much healthier and a better outcome than the expected fixed structure. This will scale and evolve much better than having to vote to change allocations for chains every time.
Thanks, Fernando and the rest of the Balancer Labs team, for taking the initiative and being open!
As a member of the Partnership sub-DAO, I share the opinion that LM share (10%) has been somewhat problematic and think the best step, for now, is to allocate that part to the veBAL voters.
Similair to @Mike_B - I think hard-coded BAL amounts per chain are sub-optimal - I favor having BAL rewards for all chains being voted on through 1 interface, regardless of network.
I believe the best set-up to be 90% rewards being distributed by veBAL holders and 10% of the rewards going to veBAL holders as @Andrea81@zekraken and others mentioned!
It is inspiring to see such constructive discussions around this topic showing once more that we have a powerful community backing BAL.
I also want to signal as a LMC-member that I am in favor of completely removing allocations to the LMC. That is the only true path towards decentralization and makes veBAL tokenomics even stronger. If a protocol wants incentives it needs to commit to veBAL (or bribes) to get there.
In terms of which option is more favorable: I am also leaning slightly towards option 1 because of the arguments @Mike_B has already pointed out:
The distribution of protocol fees in BAL will be enough to offset any IL. I personally think that the additional 10% that are freed up will have a positive net effect on BALWars copmared to allocating them to veBAL lockers.
Very valid point that I totally agree with. Let’s start out with option 1 and see how it goes. In this way the team would have enough time to work out an elegant option 2 if needed.
It will be very interesting to see what option the community will choose.
@Mike_B@Xeonus@zekraken
I am unable to see how the independent proposal to distribute fees accrued in BAL in their original form rather than bbaUSD is an economical factor here. Could you guys please explain why you think this is a substantial substitute to the veBAL holder for the 10% of the emissions that they were previously guaranteed?
From my understanding, the proposal mentioned in OP just changes the currency in which the fees would be distributed. These fees would’ve been distributed to veBAL holder before anyways, just in bbaUSD. If my understanding of the other proposal is correct then it seems disingenuous imply that this is a factor in this decision here.
If my understand is incorrect and TomFrench’s proposal changes the economics (not just the currency) then it would constitute a more thorough explanation for the voters here.
I think this would be a factor in the decision against Option 1 and I suggest we don’t make a decision until more details are known. Part of the appeal of the veCRV system is its automation and removal of human control. If this added step reduces that autonomy then I’d be against it. If it’s any sort of multisig with human interaction required then I’d strongly advocate for not doing Option 1.
Maybe i positioned it incorrectly on my side because i wouldn’t represent it as a “significant substitute” but rather a potential substitute (forward looking) for those that wanted to get exposure the potential upside (maybe downside ) that BAL brings with it. The plan had only been to distribute stables.
But i get it, at point in time the protocol fee amount is what it is so the 10% veBAL amount is always additive at that moment. The case i was trying to make was to say that by putting that extra 10% into the system you could potentially increase volume which would generate additional protocol fees which could offset that missed 10% going to veBAL. I totally understand if the majority would rather have a guarantee however and not leave it to chance.
Ok thanks for clarifying. I think the economics of that argument are on the same direction but the scale and its certainty certainly aren’t comparable so, I’d suggest leaving that aside.
To reset the discussion and summarize the conversation thus far: seems most are against LMC guarantee anyways (would’ve been a part of option 2). So seems like the trade offs are:
Option 2: veBAL economics promised to users would be honored. But the users need to re-stake and vote.
Option 1: economics are now different by the virtue of not guaranteeing 10% of emissions to veBAL holders. Potential backdoors via Treasury manipulation could be a possibility. But users won’t need to restake.
Can there be a hybrid option that does the following?
Remove LMC allocation and add that 10% to veBAL voting power
Remove hard-coded allocations per chain
Maintain 10% guaranteed to veBAL holders
Personally I like the future-proof flexibility of not having hard-coded per-chain allocations and I think Balancer needs to keep its promise to those who have locked.
The hard-coded per chain allocation are not going to happen regardless. And it looks like there’s broad concensus on removing the LMC, which would also take care of your first point if executed.
The remaining point (whether 10% is allocated to veBAL holders) is the main decision point: in option 1 veBAL holders vote on the allocation, whereas in option 2 that is fixed to 10%.
The remaining point (whether 10% is allocated to veBAL holders) is the main decision point: in option 1 veBAL holders vote on the allocation, whereas in option 2 that is fixed to 10%.
It seems option 2 could be redefined to the hybrid I was referring to:
I think fixed 10% is the more elegant than 10% cap with extra spilling over to the treasury and possible unintended incentives/consequences.
I think this could end up being a “happy accident” that results in a more democratic system and a net positive for Balancer.
To maintain the future proof nature of this system I support either of these two options (edit: to clarify, the two options being keep as is, or redeploy for the fixed 10% veBAL distro), as long as it is permanent (to not disrupt smart contract systems built on top).
In terms of revenue maximisation for veBAL holders (particularly those that don’t partake in bribes), having 10% of supply going to this gauge would likely be optimal… but maybe there is a way for this to be done without having to redeploy the gaugeController for option 2 (for example using the treasury balance to maintain votes for this gauge).
I’d just like to add the frontend perspective on the two options regarding timelines.
Option 1:
Involves relatively minor changes and so it is very likely we can get Arbitrum/Polygon up and running by the 21st.
Option 2:
Involves more work that will probably not be possible to complete before next Thursday (21st) which would mean that Polygon and Arbitrum would not have any LM for an extra week (until the 28th).
I stand for Option 2 with LMC removed. Option 1 is simple but once the TVL of pools grows up, it is hard to migrate again. And what I’m concerned whether the LM rewards of Layer 2 will be decreased as whales hold their BPT on Ethereum.
I strongly agree here. The fixed 10% veBAL distribution was an arbitrary amount and not something I’ve seen in other veToken implementations. The point of this model is to lean into market-based mechanisms for directing issuance; it seems a bit backward to have this carve out.
That said, I do believe it’s a good practice to honor the social commitment that was made, especially to veBAL stakers who locked their BAL before this issue became known. If it’s not too onerous, I think it would be worth exploring the potential cost of allocating some BAL out of treasury to “top up” anyone who staked prior to this issue being publicized, in the event they end up receiving less than the 10% of issuance they had expected.
Another advantage of Option 1 is that it reduces governance overhead around allocating fixed percentages to gauges on various L2s. Again, the main point of the veBAL system is to automate the process by which long-term BAL holders can direct inflation, so let’s keep governance focused around big issues that are harder to automate.
I don’t particularly want to waste gas unstaking and restaking after less than a week of staking into veBAL.
Mistakes happen and because the Balancer team have been so quick to report this mistake (bravo indeed) we are still yet to see how the mistake plays out. As others have said it could work better than the original proposal because 10% was an arbitrary number. Consequently my advice would be play option 1 and commit to a community review 8 weeks after the snapshot result of this proposal.
If there’s one thing I’ve learnt in the last 18 months, going from total-defi-n00b to confident-user-level-n00b (not a programmer) it’s this; Don’t rush decisions!
Thank you @Fernando and team for being candid and steadfast with the gauges issues.
Given the options available,
DeFiance Capital believe that option 1 is the one that is more inline with the Balancer community at large.
~~
In the short term:
The simpler veBal voting model will make it easier for projects to bid for their liquidity pool. Perhaps the free market is the best way to allocate resources.
We have seen in curve wars that any inefficiencies is quickly resolved by “voting derivative dapps” like Convex and Redacted. We believe that this will repeat for Balancer and new voting dapps will be deployed in the short run. ( We know as a fact that Maki’s Aura finance will be deploying soon) - [Proposal] Allowlist Aura Finance in Balancer VotingEscrow
In other cases, projects that are keen to compete in veBal wars can still win by adopting strategies like token swap as seen by Aave’s proposal Snapshot
One contentious issue is Poly/ Arbi deployments will be disadvantaged as voting can only be done on ETH L1. Again, as of the previous point, we feel that “voting dapps” will enter the fray and better allocate resources.
At the same time, the crypto space have matured to the stage where there are production level solutions to cross-chain signalling. Our portcos like Dodo, LayerZero, InsurAce have cross-chain solutions built for similar use cases - we will be providing these introductions to Balancer.
~~
For longer term, strategic initiatives:
Ad-hoc LM programs could be approved and funded by the ecosystem fund. This approach is supported by the Balancer core team.
One thing to note here is that the migration to option 2 gets more painful the longer the gauge system is used (and the larger it gets). I’d say that whatever choice we make should be permanent.
Love the suggestions @delitzer and @Hoodoo! Also thanks for your detailed comment @Eugin, really appreciate it.
I’d like to take the suggestions and make a compromise for option 1 so people who locked their BPT into veBAL don’t feel disadvantaged:
First of all, option 1 doesn’t mean the 10% won’t be respected, it just means it’s not a certainty but it could still happen with enough votes for the veBAL gauge.
If option 1 passes, I suggest we reassess the situation in 8 weeks like @Hoodoo suggested with hard data in our hands: I still think many people can vote for the veBAL distribution because they don’t want to use bribe markets and don’t have any specific gauge they prefer.
Depending on the reassessment, there are two ways to compensate veBAL holders who locked expecting 10% if we collectively decide to make up for that: 1) Treasury locks and votes for veBAL or 2) BAL from the ecosystem fund can be distributed via merkle orchard to all those who locked before this issue has been identified and published on this forum.
Hopefully this makes this decision a lot easier for the community.
Also, since we already heard a lot of opinions and this situation is time sensitive (we need to avoid more weeks without LM for Arbitrum and Polygon) I’d suggest we move this proposal to a snapshot this evening EST.
I’m adding the “Implementation” section that will detail the transaction the governance multisig will need to sign for the option decided to be implemented by BLabs smart contracts team.
) that BAL brings with it. The plan had only been to distribute stables.