# \[RFC\] Kill WBTC/DIGG/graviAURA Gauge

**URL:** <https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493>\
**Category:** General Proposal\
**Created:** [July 21, 2022, 7:07pm UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493 "2022-07-21T19:07:32Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![justwanttoknowathing](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@justwanttoknowathing](https://forum.balancer.fi/u/justwanttoknowathing)\
**Post date:** [July 21, 2022, 7:07pm UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493/1 "2022-07-21T19:07:32Z")

</div>

### Motivation

The [approval of the WBTC/DIGG/graviAURA gauge](https://snapshot.org/#/balancer.eth/proposal/0x7acc8e26392f751c1afa41784cb803fbbb9c271a41006bac142afb71304b4d8e) passed – albeit with a notable amount of dissent, 49.62% – over objections that DIGG is not a suitable asset to incentivize. This gauge now takes nearly 31% of all BAL emissions and, given the total market capitalization of DIGG is [barely over $3M](https://www.coingecko.com/en/coins/digg), is and will remain incapable of returning nearly the amount spent on it to the Balancer protocol. While the [“core pools” proposal](https://snapshot.org/#/balancer.eth/proposal/0x28bd2c5580f5a8effacdceb0aec52e9bc63987fa4f4a39f8b8223257ca4376cc) will eventually help mitigate this, Balancer holders should not sit idly by and countenance such an egregiously wasteful allocation of BAL.

### Specification

If approved, the DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will call `grantRole` on the Authorizer `0xA331D84eC860Bf466b4CdCcFb4aC09a1B43F3aE6` with the following arguments:

role: `0xec1d467d9ab03a0079c22a89037209f5763aec973897ea763e2cf25d71a5f12e`  
account: `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f`

The role can be verified [here](https://github.com/balancer-labs/balancer-v2-monorepo/blob/master/pkg/deployments/action-ids/mainnet/action-ids.json). This will give the DAO Multisig the ability to call `killGauge` on a pool’s gauge.

The DAO Multisig `0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f` will then call `killGauge` on the WBTC/DIGG/graviAURA Gauge `0x5204f813cF58a4722E481b3b1cDfBBa45088fE36`

---

<div class="post-metadata">

**Author:** ![solarcurve](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/solarcurve/32/1487_2.png) [@solarcurve](https://forum.balancer.fi/u/solarcurve)\
**Post date:** [July 21, 2022, 8:13pm UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493/2 "2022-07-21T20:13:43Z")

</div>

I definitely understand where you’re coming from with this. The problem is there’s a lot of pools the CREAM whale could vote for that are quite a bit worse than this one imo. If this proposal passes he’ll move to one of those and this process repeats for the next few months as we play whack-a-mole.

We could pass a framework as many have suggested and include in there the automatic killing of a gauge that violates the framework (no vote required). Then we only vote once and the whack-a-mole can happen autonomously without bothering voters.

Downside to that approach is it would almost certainly end up killing some gauges we’d rather not have killed.

For now I favor doing nothing. Voting for this pool is far better than voting for the CREAM pool as this pool can actually generate non-zero fees. There are some other pools he could vote for that would be far worse.

---

<div class="post-metadata">

**Author:** ![HashError](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/hasherror/32/1951_2.png) [@HashError](https://forum.balancer.fi/u/HashError)\
**Post date:** [July 22, 2022, 2:22pm UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493/3 "2022-07-22T14:22:36Z")

</div>

As the creator of the DIGG pool and requestor of the gauge the intent was to create a sustainable primary liquidity pool for DIGG in the Balancer ecosystem. The vision for the pool’s long term prospects remain unchanged in my view.

Digg and it’s gauge are not the root cause of the issue that requires addressing here but I understand it’s an easy target for everyone from every angle.

Which pool’s gauge will be the next to be put on the chopping block after/if you are successful in killing Digg’s?

Fully support dialogue to address root cause issues that improve the sustainability of the Balancer ecosystem.

---

<div class="post-metadata">

**Author:** ![Tritium](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/tritium/32/2011_2.png) [@Tritium](https://forum.balancer.fi/u/Tritium)\
**Post date:** [July 22, 2022, 6:40pm UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493/4 "2022-07-22T18:40:10Z")

</div>

Can we please just take a month or two and try to get some sort of a sensible framework together before we keep coming with pitchforks after gauges?

I’ll try to work on something ASAP.

It is also worth noting that coingecko is wrong, and all but 8 of the 573 DIGG in existence are currently in supply. The market cap is therefore 7.5 million. It wasn’t 7.5 million before this whale started accumulating, but the point is that it is not hard for a whale to pump a token to 5 million market cap.

This is not a good indicator. It is not so simple to figure out what good indicators are. It takes time, conversation, research, analysis, more time and more conversation.

@Xeonus started doing some of this in the forum post to kill the cream gauge. I suggest we refocus on a more data driven approach to defining a framework that actually meets sensible objectives. Here are the objectives I can decipher so far:

- more than 10-20% of the vote on anything but a megacap pair that has a huge potential TVL is bad.
- Revenue is important
- Blackholes, and things leading to it are problematic
- Coins need to have active teams and development

I define a complete blackhole as voting for for a pool with more veBAL value than it has in AUM over a sustained period of time (more than a round or 2). It becomes a real backhole, if the emissions earned are going to increase the vote

Is this about right? Did I miss anything?

---

<div class="post-metadata">

**Author:** ![eaglelex](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/eaglelex/32/1009_2.png) [@eaglelex](https://forum.balancer.fi/u/eaglelex)\
**Post date:** [July 22, 2022, 8:35pm UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493/5 "2022-07-22T20:35:58Z")

</div>

I agree 100%. We would make the CREAM whale’s game.

---

<div class="post-metadata">

**Author:** ![Bobbay\_StableLab](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/bobbay_stablelab/32/2180_2.png) [@Bobbay\_StableLab](https://forum.balancer.fi/u/Bobbay_StableLab)\
**Post date:** [July 24, 2022, 11:56am UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493/6 "2022-07-24T11:56:24Z")

</div>

As @Tritium mentioned, a framework would be much more ideal. Using a community-decided framework to us to kill gauges will not only act set a standard for the community but also for those protocols that wish to enable gauges.

They will now be aware of the criteria that can be used to _kill_ a gauge and will reduce the tension, as people we understand that we are following a framework, rather than it being based on bias or emotional decisions.

---

<div class="post-metadata">

**Author:** ![Fernando](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/fernando/32/56_2.png) [@Fernando](https://forum.balancer.fi/u/Fernando)\
**Post date:** [August 5, 2022, 5:11pm UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493/7 "2022-08-05T17:11:42Z")

</div>

Did you get to think of anything in the meantime @Tritium?

Another factor I think we should add is the a maximum APR. Anything much higher than 100% is a very wasteful way of deploying LM. Maybe 150% could be a threshold, currently the DIGG pool is at 292%.

This framework would force whales (here I really mean in general, not just the CREAM whale) to also contribute with votes that benefit the broader ecosystem through common goods pools (like wsETH, bb-a-USD etc.) where LM is distributed to a wide number of LPs, not just the whales voting.

---

<div class="post-metadata">

**Author:** ![Tritium](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.balancer.fi/tritium/32/2011_2.png) [@Tritium](https://forum.balancer.fi/u/Tritium)\
**Post date:** [August 7, 2022, 11:20am UTC](https://forum.balancer.fi/t/rfc-kill-wbtc-digg-graviaura-gauge/3493/8 "2022-08-07T11:20:38Z")

</div>

I had proposed a starting point for a basic framework here:

> [@\[RFC\] Simple Framework for veBAL gauge voting](https://forum.balancer.fi/t/rfc-simple-framework-for-vebal-gauge-voting/3520/5):
>
> Desired State: No gauge should take over 10% of all veBAL unless it granted an exception by balancer governance. I think any policy that’s based on a set % of veBAL emissions is doomed to fail. For example, what stops a large veBAL holder from voting for a tokenX/ETH gauge, getting it delisted, trading it along the way, and moving on to the next victim? Who would want to enter the ecosystem, rely on it for providing sustainable liquidity, and build things on top of it - if their gauge can…

I was basing it more on % of veBAL voting. We could also do ROI, but that fluctuates a lot more, is harder to calculate as a fixed number, and in the end a whale could just add more deposits and still capture more veBAL.

For example, how would you set this 100% ROI rule on the DIGG pool? Including AURA or not? Max boost or min boost? Take using what measurements? At what time? Remember that the ROI of a small pool can quickly be lowered by just depositing more assets (which whales can do).

I would rather discuss general frameworks than more individual requests to kill gauges though, so maybe we can resume a conversation over here: [https://forum.balancer.fi/t/rfc-simple-framework-for-vebal-gauge-voting](https://forum.balancer.fi/t/rfc-simple-framework-for-vebal-gauge-voting). Get something implemented, and then apply it consistently? If the DIGG gauge gets killed with nothing else done, we just move onto the next one and spend all our time doing this over and over again.
