Radish<>Aave | Proposal for new Governance UI / Power Delegation and historical data with visualizations

[ Updated Dec, 16, 2022 ]

Hello, Denny here :wave:

I’m the founder of radish.la. We applied for a grant to enhance AAVE Governance UI with features like on-chain/snapshot proposals, visualization of vote/proposal power and delegates data for token holders, participation, and creation of proposals.

About US

Radish is a team of engineers that helps DAOs create software for their ecosystem. Formed by a group of engineers with knowledge on real-time solutions and banking services.

Our goal with AAVE is to provide token holders, functional, correct, user-friendly and error responsive solutions.

The Problem

image.png

As an AAVE token holder, when you navigate to app.aave.com/governance users will see a complete status of the ongoing proposals and vote on them. The current UI is functional for listing proposals, participation, and delegation of power.

The problem is that as a user I want to know an overall status of the “Governance” in the AAVE Ecosystem, ongoing proposals, top delegates, and if desired an account-address specific overview of one’s Governance Power.

There’s where we plan to enhance the current UI

Proposal | Governance Overview

3 - Governance.png

Token Holder Overview

2 - Account.png

On-chain Proposal creation / Payload

1 - New Proposal - Onchain - IPFS Hash - Paste Hash.png

NOTE: This proposal creation UI expects the AIP to be submitted at GitHub - aave/aip: Aave Improvement Proposals, a holder will then create the payload within this frontend.

Complete ARC→AIP→Simulation and Payload execution process

There’s a possible solution to have almost every part of the proposal creation and execution within the governance UI, the simplest one is to impersonate a proposer with a shared GitHub account, with this we submit the AIP for review and pull any comments/PR modifications or request to the UI.

If this can be functional to AAVE Token holders, we’ll update or create another proposal that considers this process, the payload simulation and last but not least unify the feedback provided to AIP from the maintainers and Guardians.

Related links:

Proposal Overview

To enhance AAVE Governance overview for AAVE Token holders we are creating a platform within https://app.aave.com that unifies snapshot.org and AAVE on-chain proposal for voting, proposal creation, Governance overview and delegation.

For our UI we are taking snapshot.org UI as reference, holders already know the mechanism behind this UI. The frontend will provide the user delegation and participation history, and address-specific information.

Take a look at the complete user flow in this Figma Mock

The Project Goals

Currently, Aavenomics are fueled by proposals at https://governance.aave.com which ratified through community voting on snapshot.org UI to gauge holders and on-chain AIPs.

We want to provide AAVE token holders a better way to interact with the protocol governance by giving them a user-friendly, responsive and functional UI to participate and validate proposals.

Project Milestones

We plan to develop the software in 3 cycles. 1 Cycle per month. That said, to keep the community updated we’ll be sharing weekly overall status of the platform to Stakeholders either trough this forum or if required, by email.

Each project cycle output will be a live URL for testing, participation and validation of each item within the cycle scope. We are also open to having weekly revisions in Discord or other to showcase and iterate over the project scope, and it’s implementation.

NOTE: The UI we are showing in Figma mocks is not absolute, which means we are open to adding/changing colors, copy, wording or adding different chart visuals.

User Personas

  • Holder: A connected account with available proposal/vote power
  • User: Anyone connected (or not) and using the Governance UI

Cycle 1 – Governance user landing & Proposals View/ Voting

  • Governance: Users can see the intro copy and links for “AAVE Governance”
  • Governance: Holders can delegate power to them or specific addresses
  • Governance: Users can see an overview of the proposal status (open, pending, closed)
  • Governance: Users can see the latest open/ongoing proposals
  • Proposals: Users can view the list of ongoing proposals
  • Proposals: Users can filter proposals by date (If required) and status
  • Proposals: Holders can view a proposal definition and vote on the proposal

Cycle 2 – Account Governance & Delegates

  • Governance: Users can see a list of the top Delegates
  • Governance: Users can see an overview of the delegates with a reference of the percent delegated and total units delegated
  • Governance: Holders can delegate power to delegates in the list
  • Account: Users can see an overview of the governance power (vote and proposal) an address have
  • Account: Users can see a graphic reference with information about an address proposal participation and proposal creation
  • Account: Apart from the graphic reference, Users can see and filter an address proposal activity

Cycle 3 – Proposal Creation

At this point, the platform can be shared with the AAVE users, so they can test the platform and provide feedback around the platform.

The scope for this cycle is to build the proposal creation UI:

  • New Proposal: Holders make a SnapshotX proposal within the UI
  • New Proposal: Holders can setup AIP payload – Transaction list within the UI

Cycle 3 – Termination and Live Deployment

  • After user acceptance, and address iteration comments/suggestions, we can make an official launch for the platform : )

Technical Scope

Our priority is to give the best frontend experience. A responsive and consistent system by taking into consideration all the trickery required to tailor a distributed software.

Our stack will be the regular NextJs, TailwindCSS, Typescript codebase as used in current interface at GitHub - aave/interface: An open source interface for the decentralized liquidity protocol Aave.

Data will be fetched from AAVE Subgraphs, and we’ll use current implementation tooling within AAVE repos(Aave · GitHub, utils, contract-helpers, aave-js)

Budget Breakdown

We are putting our best engineers to provide the best experience to AAVE token holders and develop the Governance platform within 3 months.

Resources (3.4 FTE/month)

  • Product Engineers
    • Senior Frontend Developer (5K USDC/month)
    • Frontend Developer (2K USDC/month)
    • Support UI/UX Engineer (1K USDC/month)
    • Support Solidity Engineer (Radish Team)
  • Project Manager
    • Denny Portillo (Radish Team)

Governance Participation and Research

30 AAVE to be used within the AAVE Governance and to put ourselves “in the skin”.

Management and Support fees

50 AAVE (~ $3,000 USD) for support and management fees for us - Radish Team.

Rewards summary

  • Cycle 1: 8K USDC + 30 AAVE
  • Cycle 2: 8K USDC
  • Cycle 3: 8K USDC + 50 AAVE

Total rewards

  • USDC: 24K
  • AAVE: 80

Hope to get feedback and keep building. Any suggestion to make the platform better for AAVE holders is welcome. If any reader is in the need of building primitives for the Web3 ecosystem, ping me on telegram as @d3portillo or by email at denny@radish.la

4 Likes

wow! that looks so cool! :fire: :fire: :fire:

1 Like

Hi @D3Portillo the mockup you made looks very cool and some historical data could be something that would benefit being displayed. But i dont see how and why this little change costs so much money. You are asking for 39k and 90 Aave upfront. Maybe im just not familiar with the service and prices for this but for me this seems so much and i think the @AaveLabs could easily implement this feature too within days without the need to pay that much.
So the benefit compared to the costs and what already exists is not visible to me. Sorry

1 Like

Hi @D3Portillo,

These look cool, but I don’t think they are original. To me, it seems like a design copy of snapshot.org with some additional features.

I agree with @EzR3aL on the fee proposed. For the effort required the cost is pretty high.

Maybe a collaboration with the @AaveLabs and refinement of the costs can work?

2 Likes

Hey @EzR3aL thank you for taking a look to the proposal, and as you can see in the budget details. We’re putting the most effort on Frontend. This is not a re-design of the current views.

Our team is adding the ability to make on-chain proposals from Contract along with the off-chain method using Snapshot, basically having both within the same governance UI.

We are also adding the ability(apart from the Data Visualization) to delegate vote and proposition power when viewing a holder within the platform, you can see it’s Delegatees and Delegators. We can also add the feature where one Guardian can cancel the proposal and optionally leave a reason.

Talking about the budget, I agree that upfront payment and the sum USDC + AAVE can be less. Nevertheless we cannot reduce developers budget. Maybe we can reduce roadmap down to 2 months and Project Management budget which adds up to having the platform available within a shorter time frame.

I’m glad you like the screens @G-Blockchain. We took snapshot.org design as reference because that’s what we are accustom to. For the budget, we can ship it in shorter time frame and no upfront : )

Hi @D3Portillo,

I work in the Product team and would love to get on a call to provide some feedback.

Could you message me on discord to schedule a time?

Sent you a dm @0xGraham. You can ping me on Discord too, Denny Portillo#0086 or telegram, d3portillo : )

Hey @zarpos, @G-Blockchain, @EzR3aL and @0xGraham, we have updated the proposal based on latest comments : )

Hope you can take a look at the proposal again and suggest something we can update or any type of concern.

looks cool! I agree with that some uı updates would make governance better

1 Like

Overall it looks really great :fire:

1 Like

Hi there!

I think it would be best to make incremental improvements to the UI rather than changing it drastically. It’s great that you drew inspiration from snapshot, but I am concerned that deviating too much from our current branding and design elements could potentially create a jarring experience for our users. What do you think about focusing on making small, consistent updates rather than making a major transformation?

From a user experience perspective, I have some concerns about the data fragmentation and information architecture of the elements on the page. Multiple calls to action are vying for the user’s attention simultaneously, making it challenging to understand the most effective path toward completing each task. This can potentially create a confusing and overwhelming experience for the user.

On the navigation side; you borrowed the lateral menu but not the back structure of the snapshot. The current UI has this back mechanic full screen. Would suggest taking a look into that.

Your Problem Statement.
The problem is that as a user I want to know an overall status of the “Governance” in the AAVE Ecosystem, ongoing proposals, top delegates, and if desired an account-address specific overview of one’s Governance Power.

The issues you mentioned can be easily resolved without requiring a complete redesign. Adding tiles for open, pending, and closed proposals should help improve the page’s data fragmentation and information architecture. And by separating the account page into the main page with a “details” button, we can provide a clearer path for users to follow.

This mockup draft solve the problem without a complete redesign.

1 Like

Hello, wanted to give feedback here a while ago and forgot.

Disclaimer: I was a contributor to the ui you can currently see an on app.aave.com, therefore this post obviously has some bias, but also some technical background that might be missing

The problem with “enhancing” the governance in regard to the mentioned features I think it’s not possible without compromising on some of the design goals of this ui: being functional only with ipfs + rpc. You can quite literally drop the build on a dropbox and it would still work. No server is needed.

Currently, Aave - Open Source Liquidity Protocol is served straight from ipfs + rpc.
There’s no central server for caching or similar - there’s some trickery done with periodic builds and inlining immutable proposal data to archive this without blasting the rpcs & ipfs gateways, but there’s no external server needed.

For the current feature-set this is “fairly easy” as you can fetch proposals + voters at build time and only “fetch updates” since then. As a proposal & votes can no longer change once it reached a certain state, it’s possible to have certain assumptions about the cache. The generated static payload size for this hydration is neglectable & it’s the same for every user.

For achieving stuff like:

  • top delegates (governance overview screen)
  • delegatees (token holder overview)
  • things to be seen in @Oxkis screenshots

this story is getting a lot more complex as this info is not directly obtainable with a single on-chain call, but you need to process essentially all AAVE and stkAAVE transfers and/or delegate events (current total power is easy, current power composition is not).

On-chain Proposal creation / Payload

In my personal opinion, this is a kinda useless feature.

I understand the motivation, but the reality is that most AIPs create an aip pr & payload repository which then receives iterations due to feedback from auditors or technical reviews. In most cases, the developers will also test execution and check if it archives what they want (either manually or via tools like GitHub - bgd-labs/aave-tenderly-cli). Only after that the proposals are created - usually via reviewed scripts that were part of these reviewed repositories. Therefore I sadly don’t see who would ever use this “proposal creation” ui.


On a side note i noticed that on the screenshots quorum and differential are removed, which are very important part of the proposal flow. Without it you cannot understand if a proposal is passing or not. Simply removing it makes this whole thing a bit :man_shrugging:

Afaik the current ui uses mui not tailwind.

In the past subgraphs have not been terribly reliable, aave/interface dropped all graphql & subgraph dependencies a while ago. Not sure how good of an idea it is to rely on this data source. Also afaik the subgraphs are still hosted on legacy “hosted subgraphs” which will be turned off at some point in a not too far future - not sure if someone stepped up to host on grt powered subgraphs yet.


All of that said I’m generally in support of an additional governance ui.

Client diversity is imo always good - especially assuming this client would be licensed in a more open way (MIT?). With a more open client it might actually be easier for projects to adopt aave governance & to contribute back.
Also this would allow you be less constrained by aave/interface design decisions - you could quite literally use a real database & server.


My concern with these kinds¹ of proposals more broadly is that they are only useful if hosted, maintained & trusted after receiving the grant. I don’t really see why anyone would be incentivized to do so as there’s no revenue stream.

¹ talking about any grant proposal targeting sth that is not self-sustainable at all. Paying 30k+$ for a project that might become stale right after it is “finished” might not be so sustainable for the DAO.

3 Likes

Hello @sakulstra,
I appreciate your clarification and understanding of the constraints. I had originally intended on my reply to use the current UI to show that the proposal could be implemented with less effort. Still, your insights, links, and knowledge prove the complexity of the task alongside the maintenance phase after the final deployment will not be sustainable, and I agree.

My brother and I are currently working on creating educational tours to help users understand the mechanics and steps for using AAVE. We would appreciate your insights and guidance if you have the time to share them with us.

5 Steps for AAVE Guided Education

Thank you again for sharing your knowledge and expertise!