Unsheth Governance 101

Unsheth Governance Process 101

Authors: Seraphim

“Unsheth Governance Flow” is an all-in-one document for contributing to Unsheth DAO. This document will continuously be updated by Unsheth DAO contributors.

This document aims to provide an overview of the different roles and responsibilities, flows, and pathways for various stakeholders to participate in Unsheth DAO.

Contents

  1. Governance Roles

  2. Rules and Values

    1. Code of Conduct
  3. Governance Processes

    1. Proposals

      1. Types of Proposals
      2. Proposal Timelines
    2. Voting

      1. Proposal Voting
      2. Quorum
    3. Funding

  4. Changes to Governance

Rules and Values

Code of Conduct

Proposals that do not adhere to the proper format or timeline may be removed from Snapshot until they are amended or the appropriate amount of time has elapsed.

Governance Processes

The processes described in this section are an overview of the official ways to participate in Unsheth DAO, documenting the various paths for the lifecycle of a vdUSH holder, contributor, or curious individual.

Most governance discussions occur on the official Unsheth Forum

Proposals

There are three types of proposals, and two different timelines proposals can follow.

Types of Proposals

Request For Comment

The first stage of a formal proposal related to multi-chain deployment, risk parameters and protocol updates.

The RFC template proposals should follow can be seen here .

Unsheth Improvement Proposal (uIP)

Second stage of a formal proposal related to multi-chain deployment, risk parameters and protocol updates.

The template uIP proposals should follow can be seen here.

Grant Proposals

A request for funding from the DAO for an improvement task.

The template grant proposals should follow can be seen here.

Proposal Timelines

Normal Proposal Timeline
Ideation:

The first step of creating a proposal is to discuss the topic informally in telegram or Ideas section.

Request For Comment (RFC):

After informal discussion, the proposer should publish a formal draft of the proposal on the forum under the category for the appropriate proposal type and [RFC] Request For Comment category.

The proposal title and topic title should include the prefix [RFC] and should follow the template corresponding to the proposal type. The proposer also should specify the start and end date of the proposal using the calendar option on discourse.

The default duration for RFCs is 6 days. Still, if the proposer feels that they did not receive enough comments or wants to extend the discussion, they may add a comment in a reply post to the thread, with a maximum duration of an additional 7 days.

The proposal should include a poll option at the end of the proposal to serve as a community temperature check.

The poll should always contain 3 single-choice options:

  • Yes, in favor of the proposal
  • No, against the proposal
  • Modify the proposal

To be considered as “passing” the temperature check, the proposal’s poll should pass the following 2 criteria:

  1. gain >8 unique voters
  2. have more than 51% of total voters voting in favor

Once the temperature check has passed, it can proceed to the Formal Submission stage. (Please be mindful that any attempts to game the temperature check will result in the immediate delisting of the proposal from the forum.)

If there are any major proposal changes, another temperature check should be initiated.

Formal submission Stage:

The RFC proposal will be re-published as a new comment under the same forum thread with changes that reflect community feedback. The proposer will also change the proposal’s category to “Formal Submission”

The proposer will change the topic title and the new comment’s proposal title to include

  • the prefix corresponding to the proposal type (for eg [RFC] or [uIP]
  • a sequential number, e.g. change the title from “[RFC]: Include stETH into Unsheth” to “uIP 39: Include stETH into Unsheth”
    • Proposers should check the latest proposals to ensure they are attaching the correct sequential number to the proposal

This stage will last 2 days to allow a final review of the proposal. This period is extendable with the community’s or the proposer’s written request as a forum comment before it’s published on Snapshot for voting.

Off-Chain Voting on Snapshot

After the formal submission period ends, the proposal can be moved to off-chain voting on Snapshot.

To submit a proposal on Snapshot, the proposer must have a minimum of 500 vdUSH.

Those who do not have the required delegation can reach out to larger delegates on the forum and ask them to post the proposal on their behalf.

The proposal forum thread should then be changed to include

  • The category changed from “Formal Submission” to “Live Vote”.
  • A forum comment by the proposer to announce the Snapshot vote going live with a link to the Snapshot vote attached.

The Snapshot vote will last for 6 days, and the vote result will determine whether the proposal will be executed or not.

Post Vote

Once voting ends on snapshot, the forum proposal thread should be changed to:

  • The proposal subcategory should be changed from “Formal Submission” to “Voted Proposal”.
  • A forum comment should be made by the proposer under the thread to announce the result of the Snapshot vote and whether further actions will be made.

Successful Proposals:

Will be implemented by relevant Unsheth teams. A thread will be created in the main uIP category to provide updates on the status of proposals that have passed and those waiting to be implemented.

Failed Proposals:

There will be no further actions required for failed proposals.

If a proposal does not pass but still receives support from the community, it may be reintroduced no sooner than 10 days after the voting period for the original proposal has ended.

Fast Track Proposal Timeline

Fast-track proposals are urgent proposals that require a shorter lifecycle.

A fast-track proposal:

  • Lasts 24 hours
  • Does not go through the RFC stage
  • Will be published on the forum as a live proposal and Snapshot for voting simultaneously.
  • Voting results will be concluded after 24 hours (even though the snapshot proposal will stay open for 6 days)
  • Can only be proposed by Unsheth core contributors until a version of the Senior Delegates program is implemented.

The proposal category of a fast track proposal should follow the 3 default categories, with “[Fast track]” included in the proposal title. Here “[Fast track]” signals the urgent nature of the proposal and the application of 24h proposal lifecycle, while “uIP” means it’s an Unsheth Improvement Proposal related to protocol/asset parameter changes.

Voting

Proposal Voting

Voting power is equal to the amount of vdUSH holds.

Quorum

The Unsheth quorum on Snapshot is 10,000 vdUSH votes. Each Proposal has to reach the minimum quorum, even if it has a majority, for it to be considered a passed proposal.

Changes to the quorum requirements must be amended by the community through an uIP.

Funding

Unsheth grants program encourages developers to build on top of Unsheth protocol and help integrate it into the wider DeFi ecosystem. A portion of the Unsheth Treasury is allocated to the grants program to fund a culture of community-driven development, where individuals can make improvements to the Unsheth Protocol.

Grant proposals should be posted on the forum using the grants template under the grants category. Here it will follow the normal proposal timeline mentioned above. If the grant proposal makes it through the entire proposal cycle and receives the necessary votes on snapshot, it will be funded by the Unsheth treasury.

Changes to Governance

Any changes to the Unsheth Governance Process must be ratified by the community through a general proposal.

1 Like

Hi @seraphim,

10k vdUSH is a very symbolical number, pretty much like saying there is no quorum. It might pose a risk of passing proposals that are not fully vetted by the community.

The fact that we couple it with a “fast-track proposal” method of only 24 hrs, means that a small group of individuals could stealth-pass something actually harmful.

Am I getting this right?

thanks for your time.