---
# System prepended metadata

title: youves DAO - How it works
tags: [youves]

---

# youves DAO - How it works

### 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](https://github.com/Hover-Labs/murmuration) that was developed for the [governance process of kolibri.finance](https://governance.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](https://forum.youves.com/). 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:
1. the community will back the idea
2. the community has time to review the source code of the lambda and the lambda itself
3. 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](https://gateway.pinata.cloud/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_administrator`entrypoint.

```
{
    {
        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 `endVote`call

* 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](https://tezos.domains/), [Baking Bad](https://baking-bad.org/), [ECAD Labs](https://www.ecadlabs.com/), [Kukai AB](https://wallet.kukai.app/), [Madfish](https://madfish.solutions/), [Papers AG](https://papers.ch/en/) and [ubinetic AG](https://ubinetic.com/).

#### 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 `endVote`call 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](https://better-call.dev/mainnet/KT1UZcNDxTdkn33Xx5HRkqQoZedc3mEs11yV/storage) 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 | 20%                                  | 20% of the combined vote weight of all Yay and Nay votes |
| Vote Delay Period lenght                       | 17280 Blocks                         | roughly 72 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                                | TBD                              | TBD                                         |
| Quorum Cap Upper                               | TBD                                | TBD                                          |
| Quorum Cap Lower                               | TBD                                 | TBD                                          |
| 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](https://github.com/youves-com/youves-smart-contract/tree/main/contracts/dao).

### Security Audit

The youves DAO contract has been reviewed by [inference AG](https://inference.ag/). The final audit report will be published here: [inference AG report repo on GitHub](https://github.com/InferenceAG/ReportPublications).