Research on Aave governance

Other
1

Hello there,

My name is Martin from ChainSafe Systems. We have been doing some research on Aave governance recently. The results sparked our interest and we would like to discuss those findings with interested folks.

Research

What have we done, so far?

First, we looked into the numbers of tokens that are excluded from voting because they have been moved out of Ethereum Mainnet. We thought there might be substantial dormant voting power.

Polygon: 123,444
Optimism: 157,088
Avalanche: 52,468
Arbitrum: roughly 2,000

We quickly learned that this assumption was wrong, so we moved on and looked at average participation and delegation on Mainnet to better understand the practice there:

  • Average participation for passed proposals 540k AAVE (0.34%)
  • Votes total supply 16M AAVE
  • 431 user delegated voting power to 152 other users
  • 8 delegatees have more than 10 delegators, with the top one having 35
  • 56 delegatees has 2+ delegators (excluding those with 10+)
  • 60 delegatees has 1+ votes, totalling 2.7M votes
  • Top one has 1.4M votes
  • Second one 222k votes
  • Third one 166k votes
  • All proposals with IDs 100+ were decided by 10 addresses or less and individual voting power was negligible

We realized that Aave governance works well from a technological standpoint, but a third look, this time on Etherscan, revealed that voting seems to be heavily underutilized today.

Out of this, we drew a couple of conclusions and came to a point that we felt discussing those with the community would help us move forward.

Assumptions

  • People don’t vote because it is expensive to do so
  • Allowing to vote even if tokens have been moved to a sidechain increases participation

So, what do you think? Is there an incentive for more participation in voting, if tokens on a sidechain would be usable?

Technical Considerations

In case the assumptions would be valid, something like this might be useful:

  • Wrap bridged tokens in a PowerDelegation token by implementing and deploying wrapper contracts on every side chain. It should be similar to GovernancePowerDelegationERC20.sol.
    Reason: Bridged tokens right now are generic ERC20 and do not support snapshots. Now in order to vote, the user will first need to lock their bridged tokens in the wrapper contract to gain voting power. Snapshots should be distinguished by timestamps instead of blocks to synchronize with Mainnet.
  • Deploy a simple Voting contract with a submitVote(uint256 proposalId, bool support, uint256 snapshotTime) in every side chain that will gather votes (there is no need to validate if proposalId is available on the Mainnet).
  • Deploy a side chain VotingSender contract that will have a function sendVotes(uint256 proposalId, uint256 snapshotTime) that will gather the votes from the voting contract and pass them to our bridge, Sygma.
  • Deploy a Mainnet VotingReceiver contract which will be receiving messages from the side chain VotingSender contracts through Sygma, check if the vote snapshotTime is valid for the specified proposalId, save(or update, in case the number of votes changed or the snapshotTime is > than the old one and ≤ than the one in the Governance proposal) the voting results for proposalId/snapshotTime and make two updateVoteSideChain(proposalId, support, votes) calls to AaveGovernanceV2. The votes parameter should be diff from the last call (there could be less votes as well if the snapshotTime increased, so the parameter should be int).
  • This would require updating AaveGovernanceV2 to store a proposal voting startTime along with all the other fields and have a list of trusted VotingReceiver contracts that are allowed to call updateVoteSideChain().

The above could be upgraded to support proposal creation as well.

We would be happy to discuss and learn from you.

Thanks and all the best

ChainSafe Systems

1 Like
2

Interesting analysis @martin and the ChainSafe Systems team!

For context, from BGD we are actively developing (in the last phase) a whole new iteration of version 3 of the Aave Governance system.
Final voting assets are still a WIP part of the development, but definitely, an important part of the AAVE “dormant” voting power will probably be participating in this new iteration, amongst other things.

We plan to have a more comprehensive update pretty soon.

6 Likes
3

Hey there,

thanks for this interesting look into your current development. Would you mind to quickly assess wether the assumptions we made hold or no from your point of view:

Would there be an incentive for more participation in voting, if tokens on a sidechain would be usable from your current point of view?

Would be great to learn new insights. As we are looking at this from a research perspective at the moment, any pointers are well appreciated.

4

Not answering for bgd, but i personally agree these are big issues for governance participation (in voting but also delegation).

What is missing from your dormant list is also:

  • aAave
  • stkabpt

Which are not eligible to vote but substantial parts of the ecosystem.

1 Like
5

Thank you sakulstra for those. We will add them to get a more complete view. It seems there might be value in affordable voting and delegation.

Would be interesting to hear opinions specifically from those ones who do take part in voting regularly.

Would someone from the voting folks want to share insights, too?

1 Like
6

First of, great that someone is looking at voting behaviour/trying to improve voting participation. In my opinion, governance participation is absolute KEY to the growth of DeFi in general and to AAVE specifically.

The analysis is good, but it is rather simple. It doesn’t look at crucial factors like (1)(already mentioned) aAAVE and stkABPT; (2) distribution of AAVE tokens by holder and (3) who these holders are (Is it a contract? Is it a centralised exchange? Is it a DeFi treasury? (4) Is the voting power usable at all - which in part is a question if it is, for example, liquidity in an AMM, or, is the voting power still locked in ETHLend, which is the case for 2.2553% of the total.(5) Maybe even, but that is a long shot, AAVE that has been lost for good (lost wallets, sent to contracts with no possibilty of recovery, etc.).

There are a lot of questions that come from these “unknowns”. For example, as I know the crypto community, do we even want, say a Binance wallet to vote, knowing that those tokens may not be owned by Binance and that Binance might speak for smaller holders that don’t have a say in the matter? Interests might be, depending on the voting issue, completely different for a centralised entity like Binance and “small time” voters. A company will probably always choose more risk, especially if they’re not the ones taking the brunt of the losses, if these risks good bad.

Either way, I digress - these are “bigger” questions that might not need answering to push up voting participation in the short term.

Your assumptions are mostly monetary in nature. I.e. people don’t vote, because voting participation in relation to their share on Ethereum mainnet is too costly. Yes, I can see that. Or, voting is prohibited, because - in a lot of cases - AAVE has been moved to another, cheaper, chain but their voting power was taken away by doing so (something, that, in my opinion, isn’t the biggest issue, considering that the voting power locked there is probably <4%).

An easy way of boosting participation, in my opinion, would be to give people that have deposited into an AMM pool, into the aAAVE pool, etc. the possibiltity to participate. I have no idea how that might work, but that could boost participation immensely.
Incentivise centralised exchanges to offer voting platforms that give people who hold AAVE on an exchange a chance to participate in voting by either choosing out of a pool of trusted delegates (probable) or, vote on every proposal (improbable - too much work for the exchange). Obviously this needs to be a very transparent system that is temper proof and trusted. All of this will cost a lot of money and means extra work for few benefits for the centralised exchange. But in a time where FTX happend (in addition to so much more) this could be sold to them as a trust builder.
In a further step, as already mentioned, give side chains and L2 the possibilty to participate in governance or, for lack of voting participation with Ethereum mainnet holders, have a gas fee refund system in place for governance votes.

Now, a very unpopular opinion: You can not boost voting participation because there is a general apathy in the crypto community considering governance. It is a tale as old as organised society. The people with little power (even if just perceived) do not like the decisions made by people with a lot of power (Central banks don’t know how to manage currency!; Banks just want your money, I don’t want to deal with them anymore!; Politicians are dumb and crash our economy!). Thus, a system emerges, such as cryptocurrencies, that gives them the possibility to participate in decisions that would normally be issued by a centralised power (be it the central bank, the board of a bank, another governing body). Yet, given this power people start to realise that decisions like these are not easily made and you need to have a certain know-how to even make a decision. You might not have the time to read up on it. Some might not even have the capacity to learn about interest curves, risk management, etc.
I think the crypto community as a whole has long preached a “new”, “open”, “free” and “transparent” system without thinking about the consequences and the work that needs to go into it. Thus a general apathy has formated that, at least for now, doesn’t have the biggest impact, because there is always someone that picks up the slack, but also leads to something like 0.34% of people making decisions. This is a deeper quarrel I have with the current crypto community - something that can hopefully change but might not.

Ahh, yes, then there is also the “wen MoOoOooN” guys, which I’m pretty sure just roll their faces over their keyboard to make investment decisions. Those don’t vote and that’s probably for the best.

All in all, this is a very complex issue. There might even be the need to throw some money from the treasury at this to analyse it and recommend changes. This might be a good opportunity to work with academic research, to get a neutral look at things. This also touches on multiple disciplines. A grant here and there would not cost the world.

1 Like
7

Thank you very much neptune for you comprehensive writeup of this. You are completely right, that the analysis that has been done so far is a rather young and simple one. Based on what you and sakulstra brought up, we have got better vision on what to analyse in the next step to come to a more insightful result that we will share.

For now splitting the analysis into a monetary observation and one that caters for non-monetary factors (like access to funds on exchanges that concentrate voting power that nobody really planned for).

I hope this will yield more specific questions from our end and a couple of assumptions we can invalidate by doing so.

In case someone who is frequently taking part in voting feels like sharing some further insight, we would incorporate those into our research as well.

8

Even if slightly outdated, it is probably helpful @martin if you look at the analysis done with the past proposal to reduce Level 2 governance requirements on RFC. Aave Governance. Adjust Level 2 requirements (long-executor) as it shows an overview of the governance power distribution, and how that affects the system.

1 Like
9

I agree with @martin in the fact that voting power must de accessible regardless of underlying blockchain for Aave gouvernance and specially for snapshot vote.

As @sakulstra said aAave and stkabpt miss their gouvernance power when stkAave does. I don’t really understand why. In addition that aAave token is back 1:1 by Aave token (Aave token is not borrowable).

Protocol security must be your first priority specially if we allow on-chain cross chain vote from L2 and sidechain to avoid double voting.

I recommend the following in importance order :

  • starting with voting power implementation for aAave V2 and V3
  • study the case of stkabpt needed implementation to allow voting power for their holders.
  • evaluate the needs to implement Aave and aAave voting power from other chains regarding without opening game theory failure.
1 Like