[BIP-56] Re-enable CREAM/WETH 80/20 Gauge [Ethereum]


The following is a proposal for the re-whitelisting of the CREAM<>WETH pool gauge to be found here.


On July 14th 2022, a BIP was presented for voting to the Balancer Community for the “killing of the CREAM gauge” (BIP-28). The majority of veBAL weight voted in favour and, consequently, a transaction to “kill the gauge” was executed by the Balancer DAO multisig. Vote results (54,88% YES vs. 45,12% NO) can be found here.

On July 21st 2022, BIP-30 was also presented to the Community for voting. This time the proposal was to “purge” unused gauges. On the BIP-30 the majority of veBAL voted against the implementation with the following voting result: 53,43% NO vs. 46,57% YES. Voting submission was one of the highest ever recorded with roughly 3M veBAL votes (15 times higher than the quorum).

Despite the high voting participation that should give legitimacy to the result, it was decided to have a Community vote again, on the same topic, without giving any kind of robust rationale that could support the decision. The only reasoning found is the loose statement of a supposed “wide support of Delegators”. This claim, however, is not backed by any publicly available evidence and does not represent a valid condition for a vote to be reconsidered. Additionally, we would like to remind the Community that neither Delegates nor Gov. Council members have veto powers.

Consequently, on July 28th 2022 (only one week later), the same vote was repeated (among other things using the same BIP number [BIP-30]) and reverted the previous result.

The event created a historical precedent: the BalancerDAO Governance can disregard (and therefore possibly revert) a legitimate voting result without the need to present any kind of reasonable motivation or display any sort of supporting evidence.

We take this opportunity to point out that there is no indication of what conditions must occur for a vote to be repeated. The only official guidelines (vague and generic) only outline what conditions a Forum Proposal needs to meet so to be voted on Snapshot. This information can be found on the Governance Process Revamp 2.0.


For the reasons expressed above, we request a vote for the reestablishment of the CREAM<>WETH gauge as we believe we face a similar Governance environment/conditions to the examples detailed above: the vote to kill the [CREAM<>WETH] gauge passed with similar margins to the [BIP-30] (Purge unused gauges) and we would like to follow the same iter as the BIP-28. We consider the BIP-28 re-vote a valid precedent.


We request to have a vote to add back a gauge to the CREAM<>WETH pool.

If the Community votes YES, the BalancerDAO will add a gauge to the 80/20 CREAM/WETH pool.

The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will call grantRole on the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 with the following arguments:

role: 0x076e9815202aa39577192023cfa569d6504b003183b2bc13cd0046523dfa23ea
account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

The role can be verified here. This will give the DAO Multisig the ability to call unkillGauge on a pool’s gauge.

The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the AuthorizerAdaptor at 0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75 and call performAction using 0xd34fb267 for the data(bytes) argument and 0x9F65d476DD77E24445A48b4FeCdeA81afAA63480 for the target(address) argument.

Additional information regarding pool details and original proposal can be found here.


BalancerDAO Governance has demonstrated a certain degree of unreliability when it comes to vote results/rules/guidelines compliance and the above example should serve as clear evidence.
We expect this proposal to go to a snapshot vote when enough debate has been achieved and feedback received.
The failure to bring this proposal to a vote by any of the members in charge, will be considered a case of Governance Mutiny and consequential actions will be taken.

Additional notes

This proposal follows the general guidelines proposed by the Governance Process Revamp 2.0 to be found here and intends to follow the additional recommendations specified on BIP-4.

1 Like

Hey Andrea

Thanks a lot for posting this proposal. I totally understand where you are coming from.

The concerns you raised in regards to the governance process seem fair. I am always for 100% transparency. We are not hiding anything. We are serving the best interests of the DAO and users of the Balancer protocol.
A big however though - the CREAM gauge consists of an unhealthy token that only has value because of the entity that holds large quantities of it. This is just the latest of many issues with this token: https://twitter.com/peckshield/status/1561356431084986371

Therefore, I just want to point out that re-enabling a gauge for an unhealthy token is not something I want to just pass along. My main focus is to protect the DAO and its users from malicious intent. In this case it would be justified. Especially as the large token holder entity diverted most of veBAL emissions to the DIGG gauge after killing the CREAM gauge. That’s also why we are currently discussing the gauge framework to make our protocol actually self-sustainable. I really hope you understand why we are going through all these iterations!

In any case, a proper proposal was posted and meets the requirements. Therefore, it should be treated like any other proposal and could go to a vote after discussion. Question remains if in this case we dwell into very dangerous territory in regards to how the large entity took our protocol and emissions hostage.


Unhealthy is the new subjective word in town. CREAM was accumulated same as BAL tokens , as investors. As for the issue you pointed out, see: https://twitter.com/CreamdotFinance/status/1561673525706260481

There is no hostage situation, at any point in time, other players can enter the game, accumulate vebal/cream and eat a pie of the distribution cake!



Precisely for this scenario, I understand where you are coming from regarding the re-vote.

Since there are no clarifications on re-votes, we can amend the governance framework to include it. There should be some form of guidelines on what invokes a re-vote and how often a re-vote can happen.

I dont’t believe they disregarded the initial BIP30 vote. Initially, it was a very close vote, so if the community deems a re-vote, that should be fine. Maybe to invoke a revote, community members have to be vocal in the discourse to make it more transparent.

Gauge framework

Maybe we should pause enabling gauges until we can clarify the framework. Even though it is somewhat of a heated discussion, it is better to pause onboarding gauges, whilst we determine as community, how we want to evaluate gauges.


Hmm interesting. I tend to agree, Balancer Governance has not been doing a great job of listening or adapting proposals to meet the needs of their HODLers and voters.

It does just seem like a small team of people kind of trying to ram things through without taking much feedback. It also seems like we will have to push a second proposal through for the gauge framework in order to have our requests for anything but 50m/2% heard. The process of taking feedback and adjusting governance at balancer needs work.

That being said, I also believe that 30% of veBAL voting for a low mcap token that hasn’t held real votes or done real governance in a long time isn’t healthy.

I would request/suggest @Andrea81 that you restructure this vote to take into account some of the feedback.

Here is mine:

30% of veBAL to Cream is not good (esp when humpy has more than 50% of LP)
30% veBAL to DIGG is also not great.

5-10% veBAL to DIGG, BADGER, CREAM and at least another DAO(KNC), maybe slowly thinning out over a few more, sounds to me like a much better situation for everyone than now, and is starting to sound like a reasonable middle ground for humpy.

I know balancer needs more revenue too, but a number of ideas have been put forward to raise revenue for the DAO here: [BIP-XX] Introduce Gauge Framework v1 - #60 by Jubi. They have been brushed aside.

I’d much prefer to see this proposal for a 50/50 or a 40/40/20 gauge, and I think it would be very mature, and demonstrate a better way to use these capped gauges to request it with a 5-10% cap on veBAL votes.

We have to start finding middle ground!


Hello @Xeonus,

Thank you for your reply!

DAO self-sustainability starts from cost-controlling measures. I do not see much of that going on unfortunately. From the outside it seems stakeholders are penalised by decisions made to limit free market behaviour while a number of small groups (aka SPs) receive millions of dollars in funding.

No discussion around frameworks should take place until drastic measures to reduce costs are introduced.

But let’s leave this discussion to the appropriate Forum section :slight_smile:

Dear @Tritium ,

I am working on the principle of reciprocity with the pretense of obtaining the same treatment given to BIP-30 (re-vote) to BIP-28. Any variation to the proposal would mean a new, separate pool and gauge request.

Any negotiation for the distribution of potential voting rights to users participating in other pools is a topic I don’t want to go into as it goes outside of my competences.

This is verifiably false. You can read the delegate threads in the citadel and see each one voted yes and their reasoning. Our governance framework does not outline what constitutes a valid condition for a vote to be reconsidered - thus, it is simply not possible for you to declare this condition was not a valid reason to re-vote.

If anything can be considered a governance mutiny it is a single actor attempting to control the majority of voting power and force their will unilaterally upon the rest of the ecosystem. You can be a willing stooge in that effort if you want I guess.

Badger having 5 or 6 different people come in to copy paste the same arguments over and over and over, which have all been rebuffed, is not a productive method of providing feedback. Plenty of feedback has been listened to and incorporated for the gauge framework, notably adjusting the weight factor and offering a restriction on reconsidering promotion/demotion of gauges. Just because some feedback is provided very often and loudly by a small group of people does not mean it must be listened to if it does not actually make any sense.

@Andrea81 please update the specification to reflect the following as in the current form this proposal would not pass the Governance Council due to an unclear specification that cannot be implemented. Also, please say if you want this to go to a vote this Thursday or next week on Thursday.


The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will call grantRole on the Authorizer 0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6 with the following arguments:

role: 0x076e9815202aa39577192023cfa569d6504b003183b2bc13cd0046523dfa23ea
account: 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f

The role can be verified here. This will give the DAO Multisig the ability to call unkillGauge on a pool’s gauge.

The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with the AuthorizerAdaptor at 0x8F42aDBbA1B16EaAE3BB5754915E0D06059aDd75 and call performAction using 0xd34fb267 for the data(bytes) argument and 0x9F65d476DD77E24445A48b4FeCdeA81afAA63480 for the target(address) argument.

This will call unkillGauge() on the CREAM/WETH gauge.


hmmm very interesting. @Andrea81 you use the word ‘we’ a lot in this proposal, can you disclose who you are submitting this proposal on behalf of?

Also in terms of framing the discussion around a bad outcome or unfair outcome in terms of BIP 28 and BIP 30 let’s take a different look at the voting data. I’ve neve really been a fan of a voting system that is purely by the amount of tokens you hold (basically how much one can buy) vs. there being some layer of how many people voted a certain way. However, I ultimately honor this system that is place.

[BIP-30] Purge Unused Gauges
below you can clearly see one party voted no (and won) while 94% of other addresses voted yes, would everyone agree that a fair outcome? Also the vast majority of the purged gauges from the subsequent passed vote were grandfathered in from the old LMC oversight and never voted on. projects related to those gauges, or anyone really, can request to have those turned back on just as you’ve done here.


[BIP-28] Kill CREAM/WETH Gauge
look closely a the results below, because the picture isn’t the exact same one above, although it might as well be. 94% of addresses voted to kill the CREAM gauge because they thought it wasn’t good for the ecosystem. Even other LPs in the cream pool didn’t vote no.


i’m not exactly sure why we are playing games here. there have been 3 revotes and the only one being questioned is killing of unused gauges and that is being parlayed into a discussion about the cream pool getting killed. therefore i’m not sure why this is being framed as a proposal around the legitimacy of a revote. what about those other 2, should we undo those?

i’d like to remind everyone that one of those revotes (and a proposal the whale tried to kill off) was the AuraBAL stable pool which was very important to AURA getting off the ground. A system the whale is using today.

can we please be more direct about what this proposal is really about?


Why would this still take the same BIP number when this proposal fundamentally does an entirely different thing? Unkilling a gauge is much different than creating a new one + approving it. It would be very strange to have two BIP’s that functionally do different things.


I would be happy to put together an alternate proposal for an 40/40/20 CREAM/WETH/graviAURA gauge that specifically defined the new gauge type mentioned in the framework BIP with a cap set at 5 or 10%. Note that 10% seems to have a lot of favor.

@Andrea81 would the entity you represent consider requesting this for snapshot instead? Otherwise it is not worth my time. I think this would be healthier for the ecosystem and seems like a middle ground that pays respect both to large HODLers who have made big investments to farm balancer, and in the interests of everyone involved to maintain an ecosystem where BAL is not super concentrated on any one pool.

Everything always just seems so black and white. If we can agree to a middle ground it gets so much easier.

Thank you for the specification @solarcurve, post updated.

Regarding the voting timing, I believe voting next Thursday would not give the Community enough time to chime in.

I would appreciate if the debate could continue for a few more days. Next week voting round seems more appropriate.

Did some quick digging in the balancer documents. Following the official documents, a re-vote can only happen 30 days after a failed vote. In regards to BIP-30, this means that these rules weren’t followed as BIP-30(#1) was on July 22nd and BIP-30 was on July 29th.

The last time the page was modified was around two months ago but posting this for transparency since no one should be exempt from the rules unless it is clearly defined. I’ll work on a post to define the governance processes in a clear manner, including re-votes.


to be clear, only approved snapshot votes have to be followed in terms of the governance process. You will not find a “30 day waiting period for re-voting” in an approved snapshot vote. That line in the docs was written by some random person and never ratified by voters.


I hate to have to beat a dead horse here. The CREAM<>WETH gauge as many others are clearly, not subjectively, unhealthy for Balancer. Please reference a multitude of information shared throughout the forum on this, mainly financials on the kill proposal. The gauge framework will be a step in the right direction, as quite clearly we can see BIP-19 has been.

You mention cost control measures in your comment to Xeonus, which I also find quite important. Currently the DAO will not be default alive extrapolating current rates across a year as Xeonus highlights in the State of Treasury. In regards to the gauge, this boils down to 2 things.

The first being this pool has roughly 3k USD TVL right now, so it is not earning a gauge by any means. Fees will not be generated by a stagnant farming pool. If there is a strong belief that Balancer is the place for CREAM, the pool should not have been drained. Please see how the THX discussion for re-enabling their gauge was approached. Their gauge was killed and if you graphed their pool’s TVL you would not even know when it happened.

The second, and more primarily, is an immense opportunity cost of emissions no longer being directed to new projects or profitable pools. To approve this gauge would prove any concern for DAO finances to be hollow at best. Counteracting the costs is possible with the emissions bringing in healthy and useful TVL. Overall, i do not support this motion.


People elected to represent Balancer have picked a fight with the single biggest Balancer voter

I suggest that more attention is paid to how to de-escalate and find consensus. A good compromise is one where neither party is happy or feels like they got everything they wanted.

The current burn-it-to-the-ground mentality should be abandoned for something both sides can live with but neither is completely happy with. Tritium’s proposal is an attempt at this. Are there other suggestions?

1 Like

I’m all for mutually beneficial arrangements where they can exist, but I feel this comment is not in good faith.

Framing this discussion in terms that describe the Balancer community as an aggressor is gaslighting in my opinion.

@zekraken and @ZenDragon have made a case with evidence that this Gauge was damaging the Balancer ecosystem, and I agree with them. I think perhaps both the community and the whale are beating dead horses here.


Fully supportive of this opinion and really annoying to still have this gauge as a topic of discussion.


Honestly I haven’t paid much attention to Cream, if there is still a community, product or development there. If there is we could just reenable it if the framework gets through.

Enabling it now would be … less than ideal

1 Like

Dear friend,

I also hate to have to beat a dead horse here. This proposal has nothing to do with healthy/unhealthy pools or good/bad for Balancer.
That is not the point of the proposal.
The proposal is just a request for a revote as conditions exist due to previous events.

While I certainly appreciate your inputs and find your articulations fascinating and stimulating I would prefer not to deviate from the point of the conversation.

Moreover, regarding cost controlling measures, I just expressed some some personal opinions based on what would make more sense before presenting any framework model which would possibly hurt main Balancer stakeholders. Thats it. Again, just a personal opinion.

What a first post to make. Many members of the community have offered to hold a discussion with ‘theone’ aka ‘humpydumpy’ a few times in the past and they have been ignored AFAIK. Sort of hard to hash things out and compromise on anything if there is no open line of communication, correct? Since the other party doesn’t want to have that discussion they can only be judged on their actions.

Do you think their actions thus far have been beneficial to the protocol overall? Sure they drove up the Aura and BAL prices as they acquired voting power over the past few days, but that could potentially only be a short term benefit. The community should be interested in the long term viability of the protocol.

We are still open, at any time, to have a discussion with the party that we are allegedly picking on.