---
tags: v3, core ui, discovery
---

# Core UI Discovery Notes (6/1/22)

- Walking through the Core UI Figma prototype coming from the initial Discovery user journey statements
- Starting with the *Proposals* view

## Proposals

- Using same pattern for v2 for the proposal cards but want to do user research to see if there are any changes we'd want to make
- Cards and steps are the same as v2 as of now
- In general, we won't be able to tell what all types of proposals are
- We can tell Tribute proposals (which could be a Membership) but we'll need a version of the card for supporting when we can't predict the details
- *View More Details* similar to the multi-call ones since everything is a multi-call now
- If we define the proposal type we should be able to get closer (via the proposal type metadata)
- We can see if it matches a pattern

## DAO Favorites List

- Moving away from Playlists -- removes an extra layer
- Edited in *Settings* and can access a *Search* if they don't see a proposal type in the list
- First set of core proposals

## Disperse Token Proposal

- Own page with all of the form fields required for disperse
- There will only be 1 vault to start
- Could be the DAO main vault or it could also be a minion vault (not sure when this will be in place)
- Could default to main treasury but user can select another
- Recipients select list will select between *Select Member* and *Input address*
- This may have a place in Summon or other spots in our apps
- **Funding Type**
- Dispersing the native token (such as xDAI) or an ERC20
- Custom can be a list of ERC20 tokens that are in the select vault
- Working on a pattern to unlock a token
- Something near the submit button to unlock if needed?

## Proposal Page Skeleton

- Displays while the data is loading, once loaded this will display the proposals

## Proposals Sponsoring

- Autosponsor could send proposals right into voting period
- If a proposal is taking a long time to load where do we send a user?

## Usability Testing

- Will start testing with users

## Individual Proposal View

- Rethought from the ground up and modeled after a proposal that was in grace period for the example
- Proposal data:
- Name
- Description (with a read more button)
- Submitted by
- Simplified version of the contract actions?
- Can pop open a viewer with the actual contract data for deeper dive
- "Target Contract" / "Integration"
- Link to the contract on the block explorer
- Can do these custom views on the proposals we're defining since we'll know what we'd need
- Add links / copy to the contract addresses in the detailed view
- Expand accordions via arrow for more details such as *Sponsor*
- Shows additional details about who/when sponsored
- Includes transaction links

## Proposal States

- **In voting**
- **Grace**
- **Needs Processing**
- **Expired**
- Can indicate when you want a proposal to expire
- Will be on every proposal -- can add this and we can default to *no expiration*
- **Voting Failed**
- **Voting Passed, but execution action failed**
- **Expired**
- If a proposal is expired you can't sponsor it
- Can also expire *before processing*
- Can make through voting but expire before processing
- **Action Failed**

## Vaults

- What do we call our main RQable vault?
- When we add other vaults besides the main vault we could consider naming, but right now we're unsure how we'll do multiple vaults -- could potentially use the first part of the address?
- "Treasury" could be name for the main vault
- Sorting:
- Most votes
- Action needed
- ACE Proposal Warning
- If unverified we won't be able to look at this at all -- we can look at the block explorer API to see what type of response we'd get
- We search for the ABI with the block explorer, but there are times when it is down/unverified so we can't encode anything
- We need a *bigger warning*
- Can link to it but won't be able to display functions or args -> "Come back later"
-