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).
Option 2 seems the best way to go forward.
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.
Option 1: Should remove 10% veBAL cap. 100% emission completely determined by vote.
Option 2: Should remove 10% LMC. 10% emission to veBAL; 90% controlled by vote.
I can accept any of the above options。
I prefer option 1 for two reasons:
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!
/vote 1
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:
~~
TL:DR We will be voting for option 1.
Eugin - DeFiance Capital.
Recall that the proposal states any gas for the migration would be reimbursed.
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:
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.
Thanks to everyone for this discussion. Some game theory regarding option 1: Those who LP in a specific pool will probably always maximally vote with their veBAL for their specific pool (max self interest) and hope that others will vote for the BAL-ETH-veBAL-Pool. Those who only have vebal will vote for BAL-ETH-veBAL-Pool. As most veBAL-Holders will LP in specific pools (boosting feature) I expect voting for BAL-ETH-veBAL-gauge to be consistently less than 10 percent, if we choose option 1.
I am for option 2, as a lot of people locked their veBAL for that guaranteed 10%
Seems like Option 1 makes life easier.
Given it’s veBAL holders voting only and, the option to do a retro at a later point (mentioned by @Fernando), I’m ok with 1 as well.
Firstly, excited to see the level of thought and discussion that everyones has added.
I’m in support of implementing Option 1 (with the inclusion of removing LMC allocation) and conducting a review at the 8 week mark. This will provide actual data and remove the current levels of uncertainty.
Option 1 because it’s simpler and has less changes.