Set Rules for Gauges Management to Prevent Governance Attacks

Author(s): @curiousjoe curiousjoe#6201, with advice and guidance from @nickeuler.

Date: 2022/07/02

Absolute permissionless state of gauges makes governance attack easier. That will harm the interests of other loyal users and is detrimental for the long-term growth of our protocol. So we can make some rules to increase the costs of governance attacks and to help users activate more legit markets and participate in more decentralized distribution.

Euler was created with the innovations of permissionless lending markets, reactive interest rates and protected collateral, which is in the spirit of Web3. As we are trying to make DEFI more decentralized and autonomous, we should not only emphasize the permissionless side but also focus on security. So that we are permissionless on a more solid basis.

There are signs of a governance attack on market creation and gauge voting recently. Someone is taking advantage of the permissionless side of our protocol. There is a chance that someone can make his own token with a blacklist so only he can own it. If he creates a market on Uniswap, activated it on Euler and buy enough EUL tokens to vote for his own token in the Gauges, he can singlehandedly receive more EUL distribution.
We need to set some rules in gauge management so that we can make similar attacks less viable and more costly.

Rules for Gauges Management:

  1. Limit gauge tokens to ones on a token list. (i.e. coingecko) Only tokens on a legit list can be created as a market. If it is some private tokens with no value, we should not allow it as a legit gauge asset;

  2. Only assets that reach a certain amount of supply on Euler, for example $250k (or some other large amount), can be voted on in the gauges and receive EUL distribution;

  3. Only assets reach an oracle rank of medium or above are eligible for EUL distribution.


hmm…we indeed have sort of prequiste : with wETH trading pair on Uniswap v3…

It’s more of prerequisites for the gauges than the markets actually.

At Curve, we have a DAO onboarding process for gauges.

Gauges can be seen as a DAO’s endorsement of a certain product. In a permissionless protocol (factory deployments of markets), you can’t just hand out gauges like candy: we realised this with the Mochi incident, where someone super-incentivised their pool and gauge, got lots of folks in, and had infinite mint possibilities: eventually the attacker siphoned off lots of 3CRV and market-bought CVX and locked it, which lead to another debacle.

It could have been avoided with a few simple checks: how many folks own the token, is it infinitely minted, is it a standard ERC20 compliant token contract, does it have ownership access, and so on. All of this is done internally by the Curve community: all gauge proposals are scrutinised and lots are rejected for being outright cash-grabs or scams (the DAO learned their lesson and is now sponsoring due-diligence teams to better inform voters of gauge proposals).

Yes, this is a lot of work. But this is just how it is. You can make it automated by coming up with a few heuristics to ameliorate issues, but attacks can still happen.


so we’re trying to create a trustless lending protocol or something like a cream?

I support a set of rules for gauges management and the suggested rules make a lot of sense. As I see it, rule 1 helps reduce risk of bad faith tokens used for gaming the system and rules 2 and 3 ensure healthy markets for chosen tokens.

Curious how we would decide on a list that minimizes the risk. The list needs to be very robust because I think the other two rules could still be gamed if someone has the resources for supplying on Euler and setting up a medium ranked oracle.

sure, pls share any idea of how we can improve further. and together we can make a better list.

Thanks for bringing it up. Thanks for creating so much great content, both English and Chinese.

Thanks for the clarification.

Sure, thanks. Curve has been there for long and its experiences is always beneficial.
As we are trying to make it more autonomous. Any idea of how we can improve the list of rules?
I believe the intention is to make a better balance between permissionless and security.

We are trying to make it permissionless on a secure basis, I believe.

well gauges are a representation of a DAO doing a business deal with the liquidity providers of a market set up by the DAO. So it makes sense that a gauge is permissioned! after all: you’re inflating your precious tokens to incentivise activity!

which is why we like the non-autonomous, permissioned way. But if you wanted something autonomous (gameable, mind you), this will ALWAYS come at the cost of decentralisation.

I’m much in favor of permissioned markets: there’s a hundred different ways for folks to scam a DAO (e.g. look at what happened with Solidly in Fantom) and you’re never going to be one step ahead.

one suggestion could be that the markets you want to incentivise must have more than one oracles. this already will get rid of any scam tokens (because at least one of the oracles has to be a chainlink one!).

1 Like

in your opinion uniswap2 is secure?

Just a couple of brainstormed ideas, not sure if feasible and could be terrible ideas…

  1. Threshold of existing history of liquidity availability or some other metric - Not sure if possible to track, but maybe set that potential gauges must have been running at minimum liquidity availability for X time period to show existing commitment at a certain level? This would block new protocols, but only for a period of time (i.e. three months or something).

  2. Set an ongoing check/approval of gauges by Snapshot ongoing concurrently with the upcoming epoch vote where users can vote to veto any of the gauges up for vote and if a threshold is hit then it is veto’d out for that upcoming epoch regardless of staked EUL (threshold could be X% of total of top Y number of wallets (not counting undistributed EUL), something where it would take something really blatant to meet that threshold). If something veto’d out twice or three times in a row then maybe longer penalty period where can’t be staked on for X epochs. If no one cares, no one vetoes, and everything goes through. If this process worked, could set low requirements for other rules to keep as open as possible.

I’m thinking it should be common sense for clear attacks on governance and rather than creating a whitelist, might be easier to have it rest on users to pay attention and veto should something ridiculous come up. A potential danger is making it so folks can collude and drive out legitimate gauges, but I think if the veto percentage threshold is high enough, it shouldn’t be a large risk in that direction? Another danger is that no one cares… but then, that’s just sad for a governance token…

Also, personal philosophical opinion - not a fan of the potential governance “attack” ongoing (especially since it can blacklist addresses, though I guess some other tokens on the list can also technically blacklist) and not sure if you can even change rules retroactively, but if so - I’m not a fan of retroactively changing rules and as much as I don’t like the current “Unknown token”, could think of the EUL given as a bounty for highlighting what I perceive as a small threat to the system. At current prices, its gauge would receive ~$25,000 worth of EUL right now.

1 Like

I think the first idea is in the right direction, the second one might be a bit too much as it’s already hard enough to drive people to vote to begin with, and worst-case scenarios like you mentioned.

This proposal hasn’t included the idea of retroactively changing the rules. I assume it would begin once it’s approved, like most other proposals.

The distribution of EUL aims to be decentralised, so I understand the few concerns above of an allowlist.

Perhaps we could consider increasing voting power for assets that fall in line with the desired metrics?

Currently, the gauges use quadratic voting and takes into account the time-weighted number of tokens staked. The proposal can also add a weight for preferred metrics (on a tokenlist, Supply, Oracle risk).

Another metric for the community to consider adding to the weight is the reserve factor. Currently, it’s default set at 23%, which also means that so far tokens that have been borrowed more will have contributed more to the reserves. Using this as a weight in the gauges’ distribution would reflect not only the preferences of users that actually borrow assets, but also assets that are contributing more to the protocol/community. If someone really aims to game the gauges’ distribution, this could also be seen as a cost given back to the community for their ‘attack’.

1 Like

I like this approach of adding weight to preferred metrics that favor the health and utility of the protocol. This means groups can focus on those areas if they want higher chances to be voted in. Do you think having tiers of bonuses or a scaling of bonuses would make sense? (i.e. bonus weight to vote starts at X level of liquidity and scales in some way with a max at Y level; though with changing levels of liquidity, etc. wonder if that could lead to some weird shenanigans). I think including length of time or averages with those metrics which help reduce risk as well, but not sure if that’s doable. Helpful to think about what makes a “good” asset for Euler and try to incentivize that.

One more note - as others have pointed out, autonomous means gameable, and while the above would mitigate some kinds of risk by ensuring more “useable” assets, it doesn’t mean a bad faith token can’t use their own wealth to hit those bonuses. Wonder if the risk of a token blacklisting everyone else or some other way to game the gauges is still worth protecting against or not in some additional way like Curve’s permissioned markets or some similar approach (like the currently proposed token list).

Thanks for the feedback; I agree, having a vote for veto might be too much and probably would lead to more headaches.

As an aside/brainstormy thought, not as related to the main topic, and no clue about legal ramifications, but regarding voting: I wonder if it would be worthwhile to experiment with offering a tiny piece of revenue to voters either divided by total votes cast or by some kind of lottery to those who vote within a certain timeframe to incentivize more engagement, maybe just in these starting stages (or in set times each year) to encourage habits of voting (though I guess folks can just delegate votes too…). (Or instead of revenue, lottery of NFTs with some random non-monetary privileges)