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.
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.
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.
- 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?
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