Open sakulstra opened 5 months ago
how much power these delegates have (voting & proposition)
- we can afford to receive this data on-chain on the delegate details screen, for example
what these delegates do (how active they are), in regards to onchain data (e.g. proposal creation, voting), but olso in regards to offchain activity(forum, snapshot)
- It’s not clear to me also, how to do this without receiving event data
what these delegates stand for (some have a small description on the forum, but's that essentially it)
- take this description from the forum and add it to a static file
What do we need to start promoting this into implementation:
This raises the question: do we have enough resources, (I mean human resources), to do this? And how much of a priority is this? @eboadom @kyzia551
As Tally & Karma both are stuck on old governance I think this is a bit more "urgent" than i initially thought. I did a relatively shitty prototype here: https://github.com/bgd-labs/aave-governance-ui-helpers/pull/43 to fetch the delegation events on all the tokens.
I think as a very minimal prototype it might make sense to just have a super basic list view with:
Delegate: 0xsth(or ens)
Proposition delegates: 19
Voting power: 17
Would be a good start and then we can improve on that. Perspectively though, I think it would be nice to have some more "rich data" and being a local app can become a bit problematic in that sense I think. Perhaps makes sense to rethink our data infrastructure of all of this.
In my eyes there's currently two things that are a bit lacking in regards to delegations:
Transparency
While there is a list of delegates on the governance forum. It is not immediately clear:
Therefore I think it would be great to have a page where all known delegatees are listed. There could/should probably be a details page for each delegatee showing some analytics (to be improved down the road).
Ease of delegation
It would be great if on this potential details page there was a "1click delegate" functionality where the delegatee is pre-filled etc.
I think an initial implementation could be based just on a static set of known addresses. Down the road we might want to fetch delegats from onchain data instead, as not everyone is active on the forum and "voting activity" might be interesting for any voting address, not just delegates.