Request for Brainstorm : Thoughts on Money Market powered Governance Attack

Risk
1

Governance attack

One of the premises of decentralized governance is that token holders will act in good faith as they are holding assets and thus are exposed to the consequences of the decisions and votes they make.
This is for example the rationale behind the Maker Emergency Shutdown module, which requires to burn a consequent amount of MKR in order to shutdown the maker protocol. As of today the amount of MKR in Aave isn’t enough to trigger the emergency shutdown but the last thing we should want for the protocol is that the growing interest from the Maker community in using Aave puts the Maker Protocol and DAI, an essential building block of our ecosystem, at risk.

Beyond Maker, it’s all the decentralized governance ecosystem which can fall victim to such an attack. The closest exemple to such a governance attack is what happened with the Steem blockchain with centralized exchanges getting involved. Not your tokens, not your protocol.
This was an influence based attack, but a whale backed attack in DeFi would look like someone using ETH as collateral to borrow YFI, MKR, UNI or Aave in order to propose and pass a malicious proposal. This is a threat that makes governance aware and risk averse stakeholders reluctant to use protocols such as Aave since, as they use their token as collateral, someone else can borrow those tokens for governance attack.

Voting with aTokens

aTokens are the representations of your deposits in the Aave protocol.
To prepare the ongoing token migration, LEND borrowing was blocked which also enabled the use of aLEND as a voting asset, since double voting was not possible as the underlying LEND could not be borrowed.
This was a success and open now the possibility for other protocols to support aTokens votings.
If the underlying token can’t be borrowed, then risk averse stakeholders could vote in their respective governance using aTokens if the protocol supports it (As they should!)
aUNI, aMKR, aAave and aYFI could be used for both governance in their respective protocol and leverage in Aave.

Regarding the Aave governance, it seems clear that it can’t allow voting with aAave if Aave can be borrowed as it opens to a “leverage governance attack” : e.g. a holder of 100 AAVE could deposit it into the protocol, getting 100 AAVE. Somebody else (or himself, but lower amount) could then borrow the 100 AAVE. At this point, from 100 AAVE, 200 “units of voting power” have been created. Even considering from the governance that the supply to measure voting power from should be 200 (AAVE+aAAVE), in practice, a person doing this kind of leverage by himself will just “boost” his voting power compared with plain AAVE holders not leveraging.

Enabling aToken support also solves the difficult of calculating the proper combined supply and with it percentage over it: e.g. in a potential scenario where to submit a proposal to the Aave governance is needed a percentage of combined AAVE+aAAVE+stkAAVE supply, the fair calculation of this percentage is more complex than just using the AAVE supply (as non-deposited AAVE supply + aAAVE supply = AAVE supply).

For the previous reasons, there are two points of discussion/solutions proposed for this thread, with complete openness for others appearing:

  1. Not enabling AAVE and UNI as borrowing assets on the Aave protocol and disabling MKR and YFI, while pushing for those protocols to support aUNI, aYFI and aMKR voting.

  2. Setting a global borrowing limit on those assets in the Aave protocol, considering the governance voting thresholds, and taking this limit into account on the calculation of voting power.

This thread is inspired and consequential to the discussion/polling with positive outcome here Aave Protocol Token Addition - Community Sentiment Poll , and Proposal to add AAVE as collateral only.

What are your thoughts on the matter and which road do you think is the best for the growth of the aave protocol and the safety of DeFi governance as a whole ?

13 Likes
2

In traditional securities lending/stock lending markets, borrowing shares in order to vote on corporate events are regarded as poor corporate governance, although not illegal, it is discouraged by the industry. Fund managers with good corporate governance will choose to recall the stocks being lent out before the vote(xdate), or put a freeze period around corporate events. Governance voting in crypto world is more frequent events, AAVE can introducing a weighted voting system based on the period of holding, making bad governance vote more costly, the aAAVE should not be allowed to vote, if you put your token on lending platform, you give up its voting right in exchange for interests. it is up to other protocols to decided if aMKR, aUNI are allowed to vote.

4 Likes
3

A couple thoughts here.
Either

  1. Don’t make aAAVE part of the voting power but allow deposit (no interest) to use as collateral only. Staking is the “interest bearing” incentive, don’t offer interest on deposited AAVE used as collateral. Just like LEND was. If deposited for use of collateral, maybe you surrender the gov voting power??
    Or
  2. In lieu of aAAVE, use stkAAVE as the function of deposit (staked aave) and borrow against the value (collateral) that is being staked = stkaave

People that “borrow” against the value have the freedom to go buy any token, in this case AAVE, #1 would easily solve the issue.

Stkaave + aave remains voting power

For stkaave collateral, If slashing can be 30% of the stake, worst case scenario… Let’s say stkaave is used as collateral up to 30% LTV, then if the collateral position of the loan drops below 1.0, the Stkaave is liquidated, and put back into the Aave reserve, similar time how slashing would work per say, continually protecting The protocol. Then stkaave can actually be “more secure” if part of the collateral pool, and could drive more to defend collateral/loan positions to ensure their staked aave isn’t liquidated

Possible? Either #1 or #2 above?

If you can’t borrow against the “value” of Aave in some form, you are eliminating a primary use case in which I (And many) was/were drawn to the platform to begin with and the concern of 1 step forward, now 2 steps back. Token use case is crucial. Governing is only a small portion of importance (to me anyway) - happens to be an added benefit to the token value, not the only value.

4

Hi Jeffrey and SlaAve, thanks for your thoughts!
Let me address them in order.

Borrowing in traditional market : I agree it’s seen as poor corporate governance, but the greater threat here is that you cant really make a governance attack at the scale of a DeFi Protocol in tradFi. So the reasoning behind this proposal is to actually prevent a destructive attack on a DeFi protocol such as Maker with the ER or any other with a malicious proposal.

Weighted voting system : Possible but most likely tricky if you do something else that simply holding your tokens, needs to be researched more.

Bad governance more costly : It would still be possible, at some point over 40% of the LEND was deposited in Aave. With enough funds, anything becomes possible.

aAave not allowed to vote : I think a large majority of the voting supply would be lost with such a decision. The primary use case is not to “give up voting rights in exchange for interest” but actually to use as collateral to borrow against, hence the proposal to disable the ability to borrow AAVE.

SLaAve :

  1. I think you misunderstood the idea. The proposal is to reproduce the same parameters as LEND, where aLEND was also a voting asset because you could only use as collateral and were not allowed to borrow LEND.

  2. stkAAVE should also be use to vote.
    Using stkAAVE as collateral would be possible (astkAAVE) but a different use case as not everyone will stake

If you can’t borrow against the “value” of Aave in some form, you are eliminating a primary use case : On the contrary, the idea here is not to stop using AAVE as collateral but to disable the possibility to borrow AAVE and ONLY use as collateral

TL:DR

  • By disabling the borrowing of governance tokens, users using AAVE as collateral in the platform would still be able to vote in governance matter.
  • The protocol would neither enable “poor governance” nor being used for what could be direct threat for the DeFi ecosystem (Maker ER)
  • It’s an opportunity to push aTokens as voting assets in other protocol as they will be able to leverage and vote without putting at risk their protocol
4 Likes
5

Yep! I misunderstood. Collateral = good!

I am good with not being able to borrow it. Makes sense. Thanks for taking the time to clarify, man… I may have wasted a few brain cells in that response in my misconception…

1 Like
6

Haha no worries, if you misunderstood then I just wasn’t clear enough !

1 Like
7

I think this does a good job of addressing the governance attack issue while improving the functionality of the platform by allowing suppliers to retain governance rights through aToken voting integration.

Just trying to better assess the drawbacks. Particularly what % of borrowing activity is attributable to tokens that would potentially be no longer borrowable? Also, any concerns about the effects of a growing mismatch in supplied/borrowed assets since you’d be adding more utility to a subset of supplied tokens while at the same time making them unborrowable?

The global borrowing limit on individual assets could also be a viable solution. The continued growth of governance enabled assets is a trend that’s unlikely to reverse so completely removing them as borrowable assets could prove costly in the long run.

8

Thanks Jordan, AAVE is governance token and token holders should be encouraged to excercise “governence duty”, they get rewarded by “profit sharing” - so soon to be, treating AAVE as interests bearing finance assets does not fit into the governance protocol. Lending out AAVE while retaining voting power does not sound fair to hodlers. In traditional stock lending business, stock being lent means transfer of “legal” title to borrowers.

1 Like
9

Hi Jeffrey, the idea is actually to disable the ability to lend out AAVE and others governance token. So it would not be possible to lend aave. The largest majority of AAVE holders using the protocol use it as collateral to borrow stablecoins.

2 Likes
10

Hi Jordan, this sounds good.

11

Hi @Jordan,

Great proposal which highlights an interesting attack vector that could lead to systemic risk not just for Aave but for the crypto ecosystem more broadly. I think it’s right for the community to think carefully about how to mitigate this. Our main concern with solution 1 (removing the ability to borrow governance tokens) is the long-term effect this could have on demand for Aave’s product.

To be clear, this wouldn’t be much of a problem right now. Looking at the data, currently governance tokens make up only ~6% of total demand for borrowing on Aave.

Interestingly, if we exclude stablecoins and ETH, governance tokens make up ~45% of total demand for borrowing on Aave.

734×409 7.71 KB

image

Crucially, as my colleague @YanDelphi pointed out earlier in this thread, banning borrowing of governance tokens will not just have consequences for borrowing demand but also for supply by creating a mismatch in supplied/borrowed assets resulting in lowered interest rates for depositors. Governance tokens currently make up about ~6.5% of deposits and ~13.4% when removing ETH and stablecoins.

While the numbers are small currently, we can also observe that governance tokens have been making up an increasing amount of borrow volume, deposit volume as well as unique addresses recently.

1238×768 41.5 KB

Our view is that while removing borrowing of governance tokens would have minimal effects on Aave right now as they represent only a small percentage of supply/demand, the longer-term effects of this can be more detrimental given the growth of governance as a sector.

Our belief is that most tokens will eventually incorporate governance functionality and thus Aave may lose market share to less risk-conscious competitors such as CREAM which allow for borrowing of governance tokens. As we mention earlier, this will not just affect demand for borrowing but also supply of assets as the mismatch of supplied/borrowed assets on Aave would mean competitors would likely be able to offer superior rates on deposits. While voting with aTokens is undoubtedly a great feature, at this point we would begin to question whether the loss in market share from banning borrowing of governance tokens is worth the added utility of allowing users to vote with their aTokens.

We feel the alternative solution of implementing a borrowing limit for governance tokens is less extreme and suffers from less of these issues. The borrowing limit could also be calculated dynamically based on governance voting thresholds and the number of active votes occurring in the various protocols. The protocols could also begin accounting for this borrowing limit in their total supply/voting power calculations. To further mitigate the loss of demand for Aave, rather than banning borrowing once the borrow limit is reached, Aave could also ban voting with aTokens once the borrowing limit is reached. This way, the attack vector is mitigated without demand suffering.

To summarise, we believe in the long-term the marginal utility of allowing users to vote with their aTokens is not worth the potential loss in demand for borrowing governance tokens, which would also have downstream consequences for governance token deposits. This is especially the case given we think governance will continue to become a more important part of the space. As such, we favour solutions that allow Aave to continue being a competitive player in supply/demand of governance tokens.

5 Likes
12

Hey everyone :slight_smile:

Very interesting and important topic !

I agree about the fact that governance attack can be a real issue, however, it’s also true that it could take some cut to the protocol if borrowing governance token was disabled.

What about using StkAAVE only to vote ?

For now, StkAAVE isn’t listed so it can’t be borrowed, and @Emilio mentioned that even if we may be able to use Stkaave as a collateral, it would be on a market itself, so it may be easier to disable borrowing on this market rather than on the main market ?

We could also extend the Cooldown period to 15 days, in order to get only good intention from users that vote, because there would tokens should be locked 1 week before vote and 2 weeks after.

This way AAVE token could be borrowed but it would not be possible to vote with it unless it’s staked for some time.

For other governance tokens, it could also work with a proposition on each forum, we can already stake YFI in the governance pool to vote, so it would only require to add a bigger staking time needed to vote before and after, but i dont know the governance on Maker or other protocols (can we already stake to vote MKR, UNI ? )

Do you think voting with staked assets only could allow a better governance by getting only people involved to be able to vote (and delegations of course for those who don’t stake) or is it really complicated to set this up ?

1 Like
13

Very interesting topic - such important to avoid malicious votes from actors.
I think adding time lock variable into protocols voting power is also a solution.

To limit borrowing amount seems partial to me and not so effective if user can go to CREAM when limit is reached.
Also convincing the biggest ecosystem stakeholders to vote only with aTokens will be complicate.

Let’s take a look at DAO that are less subject to attack : Curve. Why so ?

  1. You can not borrow Curve tokens on Aave. Ok but you can on CREAM. Yes but for 105% APY. Why so expensive ?
  2. Because there is time lock. 20.8% of the total CRV supply is locked in exchange of veCRV.

Cooldown is an interesting feature to continue to dig in order to insure voters are long term skined in the game participants. imo

Question

Not enabling AAVE and UNI as borrowing assets on the Aave protocol and disabling MKR and YFI, while pushing for those protocols to support aUNI, aYFI and aMKR voting.

How aUNI aMKR, etc can remain bearing fees tokens if you can’t borrow theme and pay fees for that?

14

Hi Aave fam!

This discussion is very timely. MakerDAO just experienced its first significant flash loan voting event. More details here:

MakerDAO is addressing flash loan risks in an upcoming governance upgrade, but for the time being the system is somewhat vulnerable to manipulation.

3 Likes
15

They already found a solution proposed by Kurt Barry.

How can you prevent flashloan votes ?

Even just a single block delay between locking and freeing MKR in the Chief would be sufficient. This is one of the solutions we’re researching (already have the code under review, in fact).

In fact, it maybe not Aave to start regulating assets available on the borrow side (as soon as they respect established risk policy) but rather at DAOs to take necessary action.
Luckily, this first “flash loan gov attack” was not that costly (vs $30M Black Thursday) while putting the light on the urgent need to take actions.

Maker Team declared

We feel that oracle and liquidation risks are less than that of governance attack

1 Like
16

Great discussion!

I do have a few points though.

Although great in theory, the issue here is that you cannot control DeFi as a whole. If AAVE is available to borrow elsewhere, the same flash governance attack can occur. It is also overall beneficial to allow borrowing of assets, it increases liquidity and allows for greater price discovery.

I don’t know about the borrowing limit either, since supply isn’t necessarily fixed some governance tokens. (i.e. UNI.)

If only there was a way to do something like “lock” your voting tokens for a single block, then have them returned to you afterwards. This would instantly solve the flash-loan dilemma, preventing the loan from being paid back. At least, that’s how I understand it.

As stated by @TheoRochaix, it turns out this solution is already being studied! I’m sure, if it turns out to be as efficient as anticipated, Aave will follow suit.

1 Like
17

I agree with @YanDelphi and @jose_delphi that blocking borrows makes Aave less compelling to users.

However, how are Borrow Limits set? And as others have said, they don’t solve the problem at an ecosystem level – assume the emergence of N money markets, and the threat remains. A difficult problem emerges where you dynamically set borrow limits according to ecosystem participants, but you’re then exposed to oracle and further malicious actor issues.

Maker’s solution highlight by @TheoRochaix blocks flashloan attacks, but doesn’t block large actors from simply borrowing against their assets.

I would like to propose an alternative solution – bTokens.

bTokens are essentially the same as borrowed tokens, except they are tagged and can therefore be handled differently by governance systems. Different governance systems could experiment with their own designs but they might say, for example, that a bToken must’ve been held for a particular time. Or that for the first x weeks, a bToken only has y % of the voting power of a normal token.

Whether to lend in bTokens is a binary option, set per pool. So the UNI pool can either lend out UNI or bUNI. In my opinion, this decision should actually be made by holders of the third-party token themselves, as it principally impacts them rather than Aave.*

*if the community did opt to go down the Borrow Limits route, I’d also propose that this is configurable in large part by the holders of the deposited token. This would better-align interests with the ecosystem.

1 Like
18

was not that costly

That’s true, but I think we should need to follow the discussion on MKR close enough to measure the risk.
I think DeFi has a lot of potential and we have not seen the worst part, we need to contemplate the other side(malicius attacks).

19

Any thoughts on this @Jordan?

In general I’m keen to get feedback on the idea of—

  1. assets that are tagged as ‘borrowed’
  2. giving TKN holders partial governance over their own asset pools

Having read @jose_delphi’s recent aDAO proposal, I feel (2) also increases the ecosystem’s perception of a protocol they can use on their own terms.

20

Hey @oaksprout ! I think the idea is very interesting

Indeed with aAAVE, th 2) might be quite easy to implement. ie: there is 1000 AAVE deposited, 300 is borrowed, so the voting power of the aAAVE is not 70% of the AAVE voting power. This dynamic solution might be good for aAAVE while keeping the ability to borrow AAVE.

The Flash Loan fix highlighted by @TheoRochaix actually is only a fix for Maker governance process. It doesnt fix all the other governance attack vector, and it doesnt fix the maker ER risk.

I agree as well that the Delphi proposal, gives a new light on this issue. However the protocol might need a temporary solution in the meantime before this is technically implemented.

Re: bTokens, i would ping someone more technical than me to give a better feedback knowing the architecture of the protocol.

3 Likes