youves DAO
Introduction#
The youves DAO process is a decentralized governance process implemented by the youves DAO contract. The youves implementation is build upon the Murmuration DAO that was developed for the governance process of kolibri.finance. The youves DAO contract is set up as the administrator on all youves-related smart contracts. As an administrator, the DAO contract has the right to change parameters and values on existing smart contracts.
Anyone can submit a proposal in the form of a piece of Michelson code (a lambda), which changes parameters and values on already deployed contracts.
Users who hold one or more stakes of YOU in the Unified Staking contract (Earn>You Staking) are eligible to vote with their stakes. The weight of their vote is determined by the stake size and age. During the vote period, the stake is transferred to and locked in the DAO contract.
When the vote ends, it is determined whether the proposal has reached the predefined quorum and supermajority. If this is the case, the proposers will be able to execute the lambda attached to the proposal. This execution will then set new values in other contracts, as specified by the lambda's code. If quorum or supermajority is not reached the proposal will be rejected.
This is how the youves DAO is intended to work:
0. Discuss idea, let it review and reach social consensus#
Publish the idea and let people discuss#
Ideally all youves proposals (YIPs) start in the youves governance forum. Proposers should always publish their idea there first. The post should explain the proposal in all facets, including:
- What is the proposed change?
- What is the goal of this change?
- What is the rationale behind it? (incl. calculations, projections etc.)
- What is the code (the lambda) that will be executed (as source code and compiled to Michelson)?
- What is the SHA256 hash of the lambda that will be executed?
- Will new smart contracts be connected to youves by executing this lambda?
- If yes, what is the code (source and compiled) and what is the address of these already deployed contracts?
The information should ensure:
- the community will back the idea
- the community has time to review the source code of the lambda and the lambda itself
- if new smart contracts are wired in, these also need to be properly reviewed and audited by the community (and the youves team which is part of this community).
Make sure code can be reviewed#
At the end of this first period (which has no defined length), the community should have had time to properly discuss and review the proposal and the proposers should be confident that their proposal will reach a substantial amount of yay votes.
Reach social consensus#
Later, when submitting a proposal, the proposers will have to pay an escrow amount. A parameter in the DAO contract defines a minimum percentage of accepting votes a proposal needs to reach in order to get the escrow amount back at the end of the vote. It is in the interest of the proposers to reach social consenus that their proposal is worthy of being submitted to the DAO.
If the community does not vote on the proposal or rejects it, the escrow amount will be sent to a community fund address. If the proposal is able to attract more yay votes than defined in min_yes_votes_percentage_for_escrow_return the escrow will be returned, even if the quorum is not reached at the end of the voting period.
Once the proposers are sure to have a proper proposal ready and social consensus is given, they can then move forward and submit their proposal:
1. Submit a proposal to the DAO contract#
The proposer now submits a proposal, either by interacting with the governance frontend or by interacting directly with the smart contract. We recommend to use the governance frontend. A proposal is usually a piece of text that explains the proposal, including rationale, and a piece of Michelson code (a lambda), which, once executed, will change parameters of existing smart contracts.
A youves DAO proposal must always include:
title: The title of the proposal
descriptionLink: A link to a file that contains all the necessary information of the proposal, published on IPFS. Limited markdown can be used to write this file, and the content will be rendered in the proposal entry on the governance frontend page. Supported markdown includes h1,h2 etc., text formatting tags like italic or bold as well as tables, links and embedded images.
descriptionHash: The description hash is the SHA256 hash of the lambda. The frontend will calculate the hash and submit it, or it can be calculated and submitted directly to the smart contract. The aim is that any user should be able to compare the submitted lambda to the hash and to previously submitted hashes (e.g. in the youves forum)
proposalLambda: The executable lambda itself (must be compiled to Michelson).
A markdown template of a proposal can be found here: ipfs://Qmaig1q1ey4Xst9rAGoEVnsPWrVjAFHnh5UrTQ7i1W9e89
Example Lambda: The following short lambda would add the address tz1burnburnburnburnburnburnburjAYjjX to the list of administrators on the contract KT1J4CiyWPmtFPXAjpgBezM5hoVHXHNzWBHK (which is the YOU token contract on Ghostnet), by calling the set_administratorentrypoint.
{ { DROP; NIL operation; PUSH address "KT1J4CiyWPmtFPXAjpgBezM5hoVHXHNzWBHK"; CONTRACT %set_administrator (pair address nat); IF_NONE { PUSH int 253; FAILWITH } { }; PUSH mutez 0; PUSH (pair address nat) (Pair "tz1burnburnburnburnburnburnburjAYjjX" 0); TRANSFER_TOKENS; CONS }}Wiring in of new smart contracts#
A proposal could also include additional smart contracts which the proposer had to deploy before submitting the proposal (eg. a new youves engine) and which the proposer would wire into the youves network of smart contracts by executing the proposal's lambda. The youves community also needs time to verify and audit these smart contracts, which could take considerable amounts of time.
Proposal escrow#
When a proposal is submitted, the proposer needs to pay an escrow amount in YOU tokens. The amount needed is defined in escrow_amount. If the proposal fails to reach the percentage of vote weight defined in min_yes_votes_percentage_for_escrow_return, the escrow amount is sent to the address defined in community_fund_address. The community can decide on how to use those funds by submitting a proposal (eg. move it into the unified staking contract, or use it as a reward for a proposal etc.).
The proposal has now been submitted by the proposer and the DAO contract has successfully registered it:
2. The first waiting period starts (Vote Delay Period)#
When a new proposal is submitted, the process starts with a waiting period, the Vote Delay Period.
The parameter voteDelayBlocks defines how many blocks have to pass before the voting starts. This is the last chance of the community to make sure the proposal is properly reviewed and does exactly what was said it would be doing (and nothing else eg. in a malicious part of the code).
Once the Vote Delay period has run down:
3. The voting period starts (Voting Period)#
The parameter voteLengthBlocks defines how many blocks the proposal is open for votes. Currently, only youves users who have staked YOU tokens in the YOU staking pool are allowed to vote. A user can choose to accept or decline the proposal or to abstain from the vote. As a user can have more than one YOU stake, the user can choose to only vote with some of his YOU stakes. As long as the voting period runs, a user can change already given votes or add more stakes to vote with.
It is important to note that during the vote the used YOU stakes will be locked in the voting contract: Upon voting, they are transferred (like an NFT) to the DAO contract. This means these YOU tokens cannot be withdrawn from the vote contract or from the unified staking pool until the vote ends. They will also not be visible on the youves frontend and will not count towards the Total Estimated Value of a user, because technically they are not owned by the user's account during the voting lock up period.
After the voting period ends, a user needs to claim back his vaults. A one-click action on the frontend can be used for this.
4. The vote ends (End Vote)#
Once the blocks defined in voteLengthBlocks have passed, voting is not possible anymore and anyone can call the endVote entrypoint.
The endVotecall
- ends the current voting period
- does the necessary calculation of the final results
- frees up the locked stakes so they can be claimed by the voters again
- returns the escrow amount to the proposer or forwards it to the community fund address
- recalculates the quorum for the next proposal
- initiates the next phase:
5. Proposal end or timelock period starts (Timelock Period)#
If the proposal was not accepted, things will simply end here. If the proposal was accepted, quorum and supermajority were reached, the timelock period starts. As defined in blocksInTimelockForExecution a certain amount of blocks needs to pass until the proposer (and only the proposer) can execute the lambda that is attached to the proposal. It is during this time the Break Glass Guardian can step in by using the Break Glass Contract to veto and immediately cancel the proposal before it can be executed. Read more about the Break Glass Guardian below.
Once the timelock has run down, the proposer can execute the lambda:
6. Execution period starts (Execution Period)#
Once the timelock has expired, the proposer can execute the lambda by calling executeTimelock: the lambda will be executed and the intended change will happen.
After the execution period ran for enough time to execute the proposal, the cancellation period starts:
7. Cancellation period starts (Cancellation period)#
There may be cases where the proposer does not execute the lambda due to various reasons. To address this, a time window for cancellation of the proposal opens. When the number of blocks defined in blocksInTimelockForCancellation runs down, anyone can cancel the proposal by calling the cancelTimelock entry point. This will immediately end the proposal and remove it from the timelock, even if a vast majority of voters had accepted it.
The cancellation period starts with a delay to the beginning of the execution period to give the proposer enough time to execute the proposal before anyone can cancel it. However, the two periods overlap. During the cancellation period, the proposer can still execute the proposal if it has not yet been cancelled.
Additional information#
Break Glass Guardian#
The initial deployment of the youves DAO contract will include a separate break glass address, defined in the break_glass_contract parameter of the DAO contract. The Break Glass Guardian will initially be set to the address of the current youves keyholders multisig contract. The Break Glass Guardian can intervene during the Execution period and veto against a running proposal. This veto will immediately terminate the proposal, without giving the proposer the possibility to execute its lambda. This means that the Break Glass Guardian can halt a proposal even if it was approved by a majority of the YOU stakeholders.
The Break Glass Guardian is also allowed to call the set_governance_params entrypoint. This gives it the ability to change any governance parameters on the DAO contract without another DAO proposal.
We believe that the Break Glass Guardian is a useful tool and a necessary measure of last resort during the transition from the current governance model to the fully autonomous and decentralized governance model.
Possible Break Glass scenarios#
The Break Glass Guardian could be used e.g. in a scenario, where an urgent change on a youves contract needs to be executed in order to prevent or mitigate possible damage through a new exploit or previously undiscovered bug. In such a case, the Break Glass Guardian can change the parameters of the DAO contract in order to e.g. shorten waiting periods or the voting period and then propose a change for vote in order to get it through the voting process and let it be executed as fast as possible. Of course, any of such actions executed by the youves keyholder multisig will be communicated to the community as it will also need their vote to be executed.
Removal of the Break Glass Guardian#
Once the effectiveness of the new governance process has been demonstrated, the youves community and keyholders can decide to vote on a new proposal to remove the break glass address from the DAO contract or to change it to a different, community run multisig address. This would disable the current youves keyholders' ability to veto or accelerate proposals.
Current youves keyholders#
As stated above, the Break Glass Guardian will initially be set to the youves keyholder multisig contract. This multisig contract is controlled by group of keyholders who have an interest in the success of the platform. Youves keyholders don’t have access to user assets. The keyholders include two members of the developer team and five external parties independent of the developer. Any transaction caused by the keyholder multisig contract needs to be approved by four of the seven members. This includes changing the configuration of the multisig itself. The youves keyholders currently are: Agile Ventures, Baking Bad, ECAD Labs, Kukai AB, Madfish, Papers AG and ubinetic AG.
Amendments to the DAO contract itself#
The DAO process can also be used to change the DAO contract itself. An example could be a proposal which reduces or extends the number of blocks of any of the defined waiting periods. Or a proposal that change the escrowAmount. And as pointed out above it can also be used to remove the Break Glass Guardian.
Proposal escrow#
A proposer is required to pay an escrow amount when submitting a proposal. This escrow amount is defined on the DAO contract as escrowAmount. The escrow amount will be returned to the proposer upon endVote if the percentage of 'yay' votes surpasses or is equal to the percentage defined in minYayVotesPercentForEscrowReturn.
If the proposal does not reach that amount of acceptance, the escrow amount will be sent to the address defined in communityFundAddress, which will be set to the unified staking contract upon launch of the DAO contract. It will be possible to change this in future proposals as well.
The use of an escrow amount is designed to ensure that proposers seek community support and consensus before submitting proposals, and also serves as a spam protection measure against malicious actors who may attempt to spam the governance system.
Locking of YOU stakes during Voting period#
To prevent duplicate votes, YOU stake holders participating in voting must lock up their YOU stakes in the DAO contract during the voting period. Think of YOU stakes as an NFT that is transferred to the DAO contract when a user votes with it. These stakes continue to accrue YOU rewards from unified staking, but they cannot be withdrawn or unlocked from the DAO contract as long as the endVote operation has not been executed.
Implications of locking the YOU stakes#
As mentioned earlier, this also means that the YOU stakes will not be visible on the youves frontend during the lockup period and their value will not be accounted for in the Total Estimate Value on a user's dashboard or the YOU staking detail view. During the lockup, users can also not unstake their YOU tokens. If a user intends to unstake their YOU stakes while a new proposal is coming up, we advise them not to use those stakes for voting to avoid locking up those funds.
Claiming back the YOU stakes#
Once endVote has been called, users must actively claim back their YOU stakes from the DAO contract to transfer them back to their account. Only then will they be able to unstake these stakes, see them on the youves frontend, or use them for the next vote.
Quorum#
The quorum refers to the minimum of combined vote weight to participate in a vote for the result to be considered valid. In other words, it's the minimum level of participation required for the vote to count.
For example, a quorum of 50% means that at least half of the eligible vote weight must participate in the vote for it to be considered valid. If the quorum is not met, the vote will be rejected even if the supermajority was reached.
Quorum adjustments#
On the youves governance contract the quorum is dynamically adjusted dependent on the participation in the last vote (similar to quorum in the Tezos governance process). The endVotecall calculates the new quorum and stores it in the quorum parameter. In order to avoid a quorum that is impossible to meet, which would esentially block the DAO, an upper and lower quorum_cap limits the quorum to be set in the next proposal.
Supermajority#
The youves governance process requires a supermajority for a vote to pass. The required amount of accepting vote weight is defined in super_majority_percentage. If the supermajority was not reached, th eproposal will be rejected, even if the needed quorum was reached.
Vote Weighting: calculation of the Voting Power#
The voting power of a YOU stake is represented in it's stake weight. The stake weight calculation on the youves DAO takes into consideration that a stake has 1) a certain amount of YOU tokens locked and 2) a certain age which entitles the stake to an amount of YOU token rewards which accrued in the Unified Staking contract since the creation of the stake.
The youves DAO uses two values from the Unified Staking contract to determine the stake weight:
stake represents the size of the stake, dependent on the amount of YOU tokens locked in the Unified Staking contract.
discount_factor is a global value on the Unified Staking contract which is used to calculate the current time-weigthed value of a stake.
Because the amount of YOUs a user is entitled to can vary during the voting period, we use the stake value from the Unified Staking contract as the vote weight and, at the end of the voting period, we multiply it with the discount_factor in order to calculate the absolute amount of YOU a user's stake is entitled to. By this method of calculating the vote weight, it is ensured that a user always votes with the entire amount of YOUs that stake is entitled to when endVote is called.
Start parameters of the youves DAO contracts#
The youves governance contract was deployed with the following start parameters after careful consideration of their impact:
| Parameter | Value | Comment |
|---|---|---|
| Escrow Amount and currency | 500 YOU tokens | Escrow amount to be paid by the proposer |
| Minimum of yes votes for escrow to be returned | 30% | 30% of the combined vote weight of all Yay and Nay votes |
| Vote Delay Period lenght | 11520 Blocks | roughly 48 hours at 4 blocks per minute |
| Voting Period lenght | 40320 Blocks | roughly 7 days at 4 blocks per minute |
Execution Timelock start after endVote | 11520 Blocks | roughly 2 days after endVote at 4 blocks per minute |
Cancellation Timelock start after endVote | 23040 Blocks | roughly 4 days after endVote at 4 blocks per minute |
| Quorum at start | 1'235'000'000'000'000'000 | 1'235'000 YOU |
| Quorum Cap Upper | 3'744'000'000'000'000'000 | 3'744'000 YOU |
| Quorum Cap Lower | 800'000'000'000'000'000 | 800'000 YOU |
| Supermajority percentage | 80% | 80% of the combined vote weight of all Yay and Nay votes |
| Community Fund Address | KT1UZcNDxTdkn33Xx5HRkqQoZedc3mEs11yV | Unified Staking pool |
| Break Glass Guardian | KT1Q8yKdJaU5VcBL8JcxUT9PU99m53ubERk4 | The youves keyholder multisig contract |
These parameters can be changed by the Break Glass Guardian or by a DAO proposal.
Code#
The code of the youves DAO contract can be found on the youves GitHub.
Security Audit#
The youves DAO contract has been reviewed by inference AG. The final audit report was published in the inference AG audit report repo on GitHub.
Deployed contract#
The youves DAO was deployed Tezos mainnet. This happened at block level 3'471'614 in operation oo1BPHfDvUVDvJuow7dAhrirdmwoJkbccyhRFEwRwAe8MJ2iLQ7 on May 4, 2023.
The youves DAO's address is: KT1C3T98TqCm38cHPauZ4SopkQ4torCsxgab.