api3dao / api3-dao Goto Github PK

• review list & check nothing is missing in #77
• find commit of side bar, url verticalBar.
• global stylings before continue
• screens & components pending from mockups
• tackle list #77 when screens & components done

This includes general layout, sidebar and top bar component.

Currently, we make proposals to make arbitrary transactions through the Agent app, then push the transaction specifications to a repo, which other voters can verify.

This is not optimal because the majority of the voters will not be able to use this tool to verify the transactions. We need this to be built in to the dashboard so that all voters will be able to verify the specifications of arbitrary transaction proposals. Ideally, the specs would not have to be hosted on Github (on IPFS maybe?).

Actions/Functionalities:

• Deposit to API3 contract to able to stake API3.
• Stake API3 tokens after deposit.
• Withdrawal after staking
• Unstake after cooldown
• Delegates user tokens/vote weight/power to another address.
• Undelegate weight power & tokens.
• Vote
• Unvote/Change Vote
• Slideshow that shows tips of how to use the ui/app.
• Fetch Insurance pool information for Landing
• Cooldown Ends and it will enable users to unstake.

This limit can be one proposal per epoch or proportional to voting power, though that feels like over-engineering..

Values are not directly across the field they reference.

Implement logic for this proposal types, currently we can only create a vote proposal
Proposal Type:

• DAO governance
• Grant
• Arbitrary transactions

Although the insurance feature will not be implemented yet, the claims/IOU structure from the pool POC must be in place as a part of the pool contract for that to be implementable later on. I felt the need to clarify this in case those get omitted because the insurance feature won't be implemented now.

Users should be able to delegate voting power to each other. A version is implemented in the pool POC, but feel free to implement it elsewhere.
How it should behave when the person to be delegated has already delegated to someone else or delegates later will have to be decided.

As seen in the pool POC docs, we were planning to distribute revenue as a part of the staking rewards. In a recent update, we decided to burn all the revenue and only pay out inflationary staking rewards.

This means that large parts of the pool POC (related to revenue distribution) became obsolete
https://github.com/api3dao/api3-contracts/blob/0d2be165eb54a4eba0e83ee22cbd11ddeaa4386d/packages/api3-pool/contracts/StakeUtils.sol#L109-L123
https://github.com/api3dao/api3-contracts/blob/0d2be165eb54a4eba0e83ee22cbd11ddeaa4386d/packages/api3-pool/contracts/TransferUtils.sol#L108-L124
etc.

We will need an authoritative way to match addresses to names and vice versa for voting power delegation and keeping track of compensations. Having this maintained by the DAO like the first-party oracles (#25) feels like an overkill, but making it self-served enables shenanigans like registering with similar names to others. Would like your input about this.

To view thru a UI: https://app.gleek.io/diagrams/spKaUKClhs3lFs4Q0quG_w

User:actor

/g Navigation
	Navigation Bar:class
		Connected wallet
	Connect Wallet:queue

/g Governance
DAO Governance:note
	Voting dashboard (minimum share required to vote, account vote share)
	Governable parameter values & descriptions
	Create proposal
	View proposals
	Vote on proposals
Create Proposal:service
	Only available if vote share high enough
View proposals:oval
Vote on proposal:queue
View proposer profile:queue

New Proposal Editor:class
	DAO Governance Proposal
	Grant Proposal
	Arbitrary Transaction
Submit or Cancel New Proposal:diamond

Dashboard:note
Account dashboard (total API3 tokens, tokens staked, withdrawable tokens, locked rewards, tokens locked for collateral)
Global dashboard (Staking APY, total API3 tokens, tokens staked, % staked, staking target, epoch number, time to next epoch)

/g Staking
	Staking:note
		Staking APY, withdrawal and withdrawal request waiting periods
		Account staking information (including time until next possible withdrawal and request)
		Deposit API3 tokens
		Withdraw API3 tokens
		View locked inflationary rewards & vesting dates
	Stake:service
	Withdraw:service
	View locked rewards:oval

	Deposit tokens:class
		Deposit amount
	Submit or Cancel Deposit:diamond

	Request Withdrawal:class
		Enter withdrawal amount
		Shows cooldowns, tokens approved for withdrawal
	Subimt or Cancel Request:diamond
	Claim Withdrawal:service
		Available if request approved and time requirement met

/g Claims and IOUs
	Claims and IOUs:note
		View claims for tokens locked as collateral
		View amount of own tokens locked for each claim
	View claims:oval
	Redeem IOU:queue

User --> Dashboard

Navigation Bar --> Connect Wallet --> Navigation Bar
Navigation Bar -- Dashboard
Navigation Bar -- Staking
Navigation Bar -- Claims and IOUs
Navigation Bar -- DAO Governance

Staking --> Stake --> Deposit tokens --> Submit or Cancel Deposit
Staking --> Withdraw --> Request Withdrawal --> Subimt or Cancel Request --> Claim Withdrawal
Staking -- View locked rewards
Claims and IOUs -- View claims
View claims --> Redeem IOU --> View claims

DAO Governance --> Create Proposal
DAO Governance -- View proposals
View proposals --> Vote on proposal --> View proposals
View proposals --> View proposer profile
Create Proposal --> New Proposal Editor --> Submit or Cancel New Proposal

In the Airnode protocol, an API provider is represented by an ID (bytes32), which is derived from the API provider private key and is identical for all chains. API providers announce their providerIds over public channels (Twitter, API docs, etc.) which should allow people to match the two. Instead of having to do this all the time, the DAO keeps a registry that matches providerIds to API provider name/URL pairs. The DAO interface should allow proposals to update the registry.

• change text below the countdown box.
• create a container/box for when time is up
• vertical Line in Sidebar that indicate what page user is at is missing when users is in landingpage "/"
• “how it work”” is a full screen overlay when user clicks the “how it works” text in WalletConnected Dashboard
• overlay for screens 1024width.
• boxes should not grow on larger screens but it should decrease in smaller screens.
• replicate https://app.compound.finance/ scalability/responsiveness of boxes size.
• implement global stylings
• add progress animation based on percentage number
• background linear gradient like current api3.org landing page.
• create reuseable Modal
• disable auto-carousel.
• make the linear gradient border for whom you voted(ProposalItem)
• added button disable styling when the Counter is active.
• font size don’t match in insurance pool “total staked”
• missing triangle icon next to wallet address. onClick should disconnect wallet?
• missing carousel arrows
• avoid navigating to dashboard if user has not connected wallet

General

• change to global styles
• Some numbers should have animation of increasing until the real number.
• Missing Footer
• Missing Linear gradient background
• Overlay for screens 1042width
• Boxes should not grow on larger screens but it should decrease in smaller screens
• missing button style when is disabled
  Header
• Triangle Icon missing when the wallet is connected
• Connected to _ is not 300 font weight

LandingPage/Dashboard

• “how it work”” is a full screen overlay when user clicks the “how it works” text in WalletConnected Dashboard (Figma screen missing).
• Change the style of the arrow on the carrousel
• Carrousel shouldn't auto slide
• Font size don’t match in insurance pool “total staked”

Proposals

• Change the Triangle Icon with the amount of voters.

This is a breakdown of the pieces needed to implement UI styling from Mockups.

Figma: https://www.figma.com/file/NiDnUxkSucJmdbHbo9UrAC/API3-DAO?node-id=327%3A432
Video Walthrough: https://drive.google.com/file/d/12m5hljkkB92ZcWCbA3o-SBs8NRbpJCH8/view

Actions/Functionalities:

• Deposit to API3 contract to able to stake API3.
• Stake API3 tokens after deposit.
• Withdrawal after staking
• Unstake after cooldown
• Delegates user tokens/vote weight/power to another address.
• Undelegate weight power & tokens.
• Vote
• Unvote/Change Vote
• Slideshow that shows tips of how to use the ui/app.
• Fetch Insurance pool information for Landing
• Cooldown Ends and it will enable users to unstake.

List of Screens/Pages:

• UserDashboard
• Landing
• Proposal Details

List of Components:

• Header/Top Navbar
• Proposals Count
• ConnectWallet Button
• DelegateVotes Button
• Vote Button
• Direct Vote(For & Against) skip VotePopout.
• AccountInfo
• Horizontal/Vertical/ Navigation/menu bar it shows a number of proposals be recently created.
• Slideshow
• Insurance Pool box to be reused in several pages
• Number Components(Percentage, Formatted decimals and corresponding styling)
• Popout for proposal creation and other actions(Deposit,Withdrawal, Vote, Stake, Unstake, etc) with same layout.
• Confirm Popout as well
• Countdown
• List Proposals
• Proposal item in list, display info:date, number, address, duration time(counter of days hours minutes), status, etc
• Proposal item horizontal progress bar(percentage) changes color depending of proposal status.
• Proposal Details Content: Counter remaing time of proposal, Vote Button, User's Voting weight, Delegate Votes Button, status(active, rejected, passed, etc), Summary & link for discussion forum.
• Icons for actions & statuses.
• Help icon hover display small box with text

In the pool POC, rewards are vested at once at a specific epoch. Instead, we want them to be vested continually, epoch by epoch. See this where tokens are vested continually as an example of the same pattern.

Create automated tests to ensure functionality works as expected

Making a proposal should require a minimum voting power percentage that is governable. Delegated voting power should count towards that.

The DAO has a list of governable parameters that the members should be able to make proposals to update (this was talked about in the call)
unpoolRequestCooldown

UI needs to fetch following data:

• annual rewards APY
• annual inflation rate
• total API3 staked
• API3 staking target

State variables

• uint256 public minApr = 2500000; // 2.5%
• uint256 public maxApr = 75000000; // 75%
• uint256 public stakeTarget = 10e6 ether; // 10M API3
• uint256 public updateCoeff = 1000000;

Getter functions

• minApr()
• maxApr()
• stakeTarget()
• updateCoeff()
• currentApr()

The pool POC implements a fixed inflationary schedule. We have decided to replace this with an inflation rate that floats with respect to the difference between the total staked amount and the stake target that is set by the DAO. See more details here. The exact implementation will require further exploration.

The founder/partner/investor API3 tokens are timelocked in a contract that unlocks them block by block. When the pool contract is deployed, we want these tokens to be transferable to the pool contract, while remaining timelocked (through this method).

The continuation of the timelock will be implemented by depositing them to the pool contract as a vesting that releases tokens epoch by epoch, as described in #18
The pool contract and its interface must be implemented in a way that is compatible.

The current poc-v2 contracts should be updated to:

• Pay out claims through share devaluation rather than burning
• Implement a single governable wait period for unstaking and claim resolution (payout or release) - initial value 4 weeks
• Simplify unneeded state and update logic (claim payouts, voting)

Currently, epoch indices count up from 1 starting at firstEpochStartTimestamp
This is mostly from Kyber's DAO contracts
https://github.com/KyberNetwork/smart-contracts/blob/e4d3ae21e063bfd65c4621197687334527eb54dc/contracts/sol6/Dao/EpochUtils.sol
I saw that Gnosis Protocol simply divides the timestamp to epochPeriodInSeconds, which makes conversions very convenient
https://github.com/gnosis/dex-contracts/blob/d3efeacc8bd2bc3054602140a6211c38c7625716/contracts/EpochTokenLocker.sol#L151
So consider using that instead. This is mostly a suggestion.

Currently, the user requests to unpool an specified amount

(This was talked about in the call) Currently, there are three states a user can be in:

• Unpooled: No rewards, no voting power, no insurance risk
• Pooled: No rewards, no voting power, insurance risk
• Staked: Rewards, Voting power, insurance risk

A pooled user has to stake each epoch to receive voting power and staking rewards in the next epoch. This was done for three reasons (as far as I can remember):

1. We don't want to distribute revenue to people who have lost access to their pooled funds
2. We don't want people to hit-and-run (stake an hour before the epoch ends, collect the reward and unstake)
3. Each staking update by the user acts as a snapshot that allows us to query the voting power of a user at an epoch (the DAO contract we were planning to use did not have this built-in)

(1) is solved because we are no longer distributing revenue.

(2) can be solved by using a non-zero unpoolWaitingPeriod (we were planning to wait for insurance to be implemented before to set it to a non-zero value).

Voting power snapshots will be taken by MiniMe, so (3) is no longer needed (correct me on this).

Then, we can merge the pooled and staked states into one, and pay out rewards to all pooled users without requiring them to make a transaction to renew their stake each epoch.

Landing page before user connects their wallet.

Balance number is 0 as placeholder since user has not connected their wallet.

It has been pointed out that we may want to do sandbox deployments on testnets to train newcomers, or let others do deployments on other chains. To enable these, we need end to end deployment instructions both for the contracts and the front end (assuming it wouldn't be too difficult).