bgd-labs / aave-governance-v3-interface Goto Github PK

At the moment, the search works on the client side and only by the proposal title.

It would be nice to also search by proposal description. Most likely, this will require a separate API.

Since the Safe wallet is a contract, we cannot execute delegation tx with signatures. For delegation with the connection of the Safe wallet, we use regular delegation transactions, inside the Safe UI, the Safe SDK helps us to collect all these transactions into a batch of transactions and there are no problems with tx tracking in the our UI.

But if we connect a Safe wallet using Wallet Connect, then we cannot use Safe SDK and since there can be many transactions, there are problems with tracking the status for this transactions, at the moment there is a warning in the our UI about this.

Required voting power showing as 0, and consequently the proposal passing, even if 182k is far from the required 320k.
Don't have reproduction, but when refreshing the page, got fixed

links related to gnosis don't link to the proper explorer

The link here for Snapshot is wrong, as it is using the IPFS hash of the proposal instead of the Snapshot link

Example:

On https://vote.onaave.com/proposal/?proposalId=11, the link of "Snapshot voting" is https://snapshot.org/#/aave.eth/proposal/0x2fa324a635a80a4f64b8636199440b6ef8687135aa81ccf396570eb8aecc7bed (non-existent Snapshot link) where is actually the IPFS hash of the proposal https://vote.onaave.com/proposal/?proposalId=11&ipfsHash=0x2fa324a635a80a4f64b8636199440b6ef8687135aa81ccf396570eb8aecc7bed

The correct Snapshot link being https://snapshot.org/#/aave.eth/proposal/0xb8790aeb32267062c1500deb613ad15ebd5deac4d78d1786cb1690c12d0512c9

Due to incorrect calculation of gas, delegation does not execute all parameters that are passed. At the moment I have increased the gas in the tx.
We need to test how it will behave on mainnet

Button should say Can be executed instead of Can be execute

My idea is to expand the functionality of the UI and add to it the possibility of returning a fee for creating an proposal. @NikitaMesh and I thought about it and we see something like this flow and design:

Flow:

1. Connect wallet
2. Button in the window of the connected wallet (if this connected address created at least one proposal)

3. Window in which the address will be able to see the creator of what proposal it is, and can see the availability of whether it can return the fee for this proposal.

4. Default transaction window like in representation or delegation.

5. There will also be a button on the proposal details screen for a cancellation fee refund (creator and when it's available only).

I think this will be enough.

Approximate implementation time:
Design: 1-2 days
Implementation: 2-4 days
(in parallel)

What do you think @eboadom @kyzia551 ?

Both on preview of voters list and popup, if the connected wallet has voted, it should appear highlighted somehow

It would be good to have a section showing proposal info that is not particularly important for everyone, but might be important enough for some to show at least somewhere.

• creator ENS/address

Follow up to: #77

• On the reports screen it would be nice to have a link to the source of the report (the seatbelt repo) as sometimes the report is huge & there are subreports i want to check.
• While on the "create proposal" view the reports are shown on the ui, on the other pages it's _blank links. I think would be good consistently inline the report.

At the moment, connecting through the Coinbase Wallet mobile application does not work when using Safari desktop, the application freezes.

We need to determine what the cause is and fix the problem.

Proposal search doesn't work correctly in some cases need take a look and fix.

At the moment the voting power block on the proposal details screen is located at the bottom on mobile devices, it might be worth moving it to the top

It would be nice to add an RPC switch to the UI

When there is currently an issue with the ipfs file, the ui faces two problems:

• it's taking super long to load
• when it loads the proposal with broken/missing ipfs will not render at all. It should render all the info though - except ipfs. It's quite important to still understand which actions a proposal will execute / current voting result etc even if the ipfs is broken.

There is a typo on the the votes box, if you have not voted on proposal:

Should be:
You didn't vote on this proposal

The bold part should be open for voting, instead of only voting.

On scroll and metis there is no tenderly, therefore reports will never be available.
Let's link to the foundry report in this case.

- https://github.com/bgd-labs/seatbelt-gov-v3/blob/main/reports/payloads/534352/0x6b6B41c0f8C223715f712BE83ceC3c37bbfDC3fE/2.md
+ https://github.com/bgd-labs/seatbelt-gov-v3/blob/main/reports/payloads/534352/0x6b6B41c0f8C223715f712BE83ceC3c37bbfDC3fE/2_forge.md

Add an association for payloads details screen about which proposal they are attached to, if attached.

the voters box is jumping back to the top on every refresh

When proposal is ready to be executed, it doesn't make sense to show the text Proposal is time-locked as when it is in time locked, it is not executable.
Provably should say Proposal can be executed or even no text at all

I think the text shows previous state, but its a bit confusing on this specific step

In my eyes there's currently two things that are a bit lacking in regards to delegations:

• transparency on the delegates
• ease of delegation

Transparency

While there is a list of delegates on the governance forum.
It is not immediately clear:

• how much power these delegates have (voting & proposition)
• 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)
• what these delegates stand for (some have a small description on the forum, but's that essentially it)

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.

Add title "by BGD Labs" and two icons (Twitter add Site link). Component and block placement are in figma.

fail preview card is maybe too negative. Maybe the red colour on the card background is enough, and instead of fail -> end whenever the proposal is not passing.
Keeping will pass... on the happy path

Better to have longer ENS, preferable showing them fully unless they are pretty long, or if small devices

On the "executed at" there seems to be a typo (two commas), also would be quite useful if this date was a link to the execution transaction.

On the button to go back shows Execute proposal when it provably should be Execute payloads

Even if there are more votes than initially visible when opening the popup, there is no element showing about the possibility of scroll, or even any count of votes in this view (there is outside, which actually should not most probably).

My proposal:

• Add some design component to show more clearly that is possible to scroll.
• Add count on this popup (both for For and Against votes)
• Remove the count of votes outside Show all ${count} -> Show all

Scenario is the following:

• The connected wallet is giving proposition power to address A on AAVE, but not giving delegation for stkAAVE and aAAVE.
• The new delegation action is giving to address A proposition power on the missing assets: aAAVE, stkAAVE.
• When confirming, it triggers signature (plus I guess passing the data on the batch tx of delegation) for AAVE, even if no change is intended from the current state.

This adds totally unnecessary extra gas to the transaction.

Solution: whenever there is no change on certain type of delegation and asset, nothing should be signed/submitted for it.

Currently, pagination and filtering on the proposal list screen are not written to the query string in the IPFS version

https://vote.onaave.com/proposal-create-overview/?ipfsHash=0x2343307e9056837bfd3567bebd4774a67802e74bd097574cdb85e93a294407a2&votingPortal=0x9b24C168d6A76b5459B1d47071a54962a4df36c3&payload%5B0%5D.chainId=1&payload%5B0%5D.accessLevel=1&payload%5B0%5D.payloadsController=0xdAbad81aF85554E9ae636395611C58F7eC1aAEc5&payload%5B0%5D.payloadId=83&payload%5B1%5D.chainId=137&payload%5B1%5D.accessLevel=1&payload%5B1%5D.payloadsController=0x401B5D0294E23637c18fcc38b1Bca814CDa2637C&payload%5B1%5D.payloadId=42&payload%5B2%5D.chainId=43114&payload%5B2%5D.accessLevel=1&payload%5B2%5D.payloadsController=0x1140CB7CAfAcC745771C2Ea31e7B5C653c5d0B80&payload%5B2%5D.payloadId=16&payload%5B3%5D.chainId=56&payload%5B3%5D.accessLevel=1&payload%5B3%5D.payloadsController=0xE5EF2Dd06755A97e975f7E282f828224F2C3e627&payload%5B3%5D.payloadId=6&payload%5B4%5D.chainId=8453&payload%5B4%5D.accessLevel=1&payload%5B4%5D.payloadsController=0x2DC219E716793fb4b21548C0f009Ba3Af753ab01&payload%5B4%5D.payloadId=9&payload%5B5%5D.chainId=100&payload%5B5%5D.accessLevel=1&payload%5B5%5D.payloadsController=0x9A1F491B86D09fC1484b5fab10041B189B60756b&payload%5B5%5D.payloadId=5&payload%5B6%5D.chainId=10&payload%5B6%5D.accessLevel=1&payload%5B6%5D.payloadsController=0x0E1a3Af1f9cC76A62eD31eDedca291E63632e7c4&payload%5B6%5D.payloadId=18&payload%5B7%5D.chainId=42161&payload%5B7%5D.accessLevel=1&payload%5B7%5D.payloadsController=0x89644CA1bB8064760312AE4F03ea41b05dA3637C&payload%5B7%5D.payloadId=16&payload%5B8%5D.chainId=1088&payload%5B8%5D.accessLevel=1&payload%5B8%5D.payloadsController=0x2233F8A66A728FBa6E1dC95570B25360D07D5524&payload%5B8%5D.payloadId=7&payload%5B9%5D.chainId=534352&payload%5B9%5D.accessLevel=1&payload%5B9%5D.payloadsController=0x6b6B41c0f8C223715f712BE83ceC3c37bbfDC3fE&payload%5B9%5D.payloadId=3

Rendering is currently a bit messy

Not rendering the icons imo is perfectly fine, but the code should be rendered as block.

Waiting for proposal execution

when a proposal has succeeded and the result has been bridged back to mainnet, currently the ui shows Pending execution.. While technically that's correct (as it's pending execution of the proposal), it's also misleading as by execution ppl naturally understand execution of the payload, but in this case it's just he execution of the proposal = queuing of the payload.

Perhaps better "Pending payload queuing via proposal execution", idk

"Will expire in x", as long as bridging is not finished.

Currently the ui shows "will expire in x" as long as not all payloads have been queued.

As we know: the proposal was executed & the paylaods have not yet been queud, perhaps better to show sth lik "Pending payload queuing via bridge"

Payloads not yet queued will show "time-locked"

Not sure what "time-locked" means exactly... To me that state is quite confusing tbh.

If the proposal is executed & message is not yet bridged, should probably say exactly that "Awaiting queuing via bridge"

Quite sure especially @eboadom will not like the suggested messages, so plz suggest alternatives 😅

From a puristic view one could say should just be "pending queuing" in all cases... at for most users that's all the info they need.
I think i would still be confused with this though & it would hide problems (like failing automation) as from the ui alone will be hard to tell why its "pending queueing".