Proposal DAO constructor architecture

EVER DAO
#1

DAO constructor architecture

Type

Combined case

Short description

It is proposed to develop a DAO constructor to manage the expenditure of Treasury reserves (treasury) of the Everscale community.

General stages of proposal implementation:

  1. Approval of a proposal at set intervals per milestone.
  2. Allocation of coins from the treasury to the community’s multisig.
  3. Stage implementation.
  4. Progress report.
  5. Payment for the stage from the multisig of the proposal to the multisig of the team.
  6. Verification of profit distribution within the team.
  7. Payment for tasks from the team’s multisig to the wallets of the participants of the offer.

Below is a description of the proposed structure of a fairly universal tool for managing projects according to the principles of Agile and Waterfall

What is the Waterfall methodology?

The Waterfall Model is followed in sequential order, so the project development team only moves to the next phase of development or testing if the previous step has been successfully completed.

What is the Agile methodology?

In this model, development and testing activities are concurrent, unlike in the Waterfall model. This process allows more communication between customers, developers, managers, and testers.

Goal and Motivation

Main Goal: create for community needs a proposal builder that eliminates the risks of the Everscale community from wasting Treasury, as well as motivating proposal teams to achieve results and increase the value of the Everscale network.

Motivation: There is no system for controlling the spending of funds allocated from the Community Treasury. No way to return the community funds back. No DAO Everscale network management tool.

Description

1. Proposal “Set limits for Everscale DAO”

The following limits are proposed:

  • Proposal publishing >= 100,000 EVER;
  • The quorum for allocation of tokens to the multisig wallet specified in the proposal s>= 5,000,000 EVER;
  • The quorum to return tokens to the multisig wallet specified in the proposals >= 5,000,000 EVER.

Smart contracts should allow standard limit values to be set by voting on individual DAO proposals.

2. Proposal “Establish a pool for proposals among community members with 5k EVER entry”

As part of the creation of a smart contract, the DAO is proposed to create a pool for the proposal’s implementation. This will allow community members with less voting power to make proposals by adjusting the DAO, to make their proposals for the development of the network.

The minimum pooled stake proposed is 5,000 EVER.

3. Proposal “Template for proposals for smart contract DAO”

It is proposed to accept a template for creating proposals and contracts which are made by proposal creators to the community. A contract for automating a proposal to a smart contract.

Types of proposals:

  • Community management (DAO Everscale);
  • Core development;
  • Marketing;
  • Private product development;
  • Fund/Investor;
  • Cooperation;
  • Other proposal.

The template for smart contracts is discussed in this proposal: “Template for the DAO Smart Contract”.

Cases of fund allocation are discussed circumstantially in this proposal: “Principles of DAO Treasury spending”.

4. Proposal “Develop NFT-portfolio proposals”

The proposal DAO automatically generates and sends a TruNFT with event data to participants and tasks to the proposal’s multi-tasking address. It allows users to restore the history of roles in tasks and the purpose of tasks or discover the obligation of the participant or Everscale team.

A TruNFT is generated for each event with the following data:

  • Team name / Nickname
  • Address of team’s wallet / Participant
  • Type of event:
    • Payment;
    • Debt obligation;
    • Payment of a debt obligation;
    • Reward for team;
    • Reward for specified participant;
    • Claim to a team;
    • Claim against a team member.
  • Name of proposal
    • Name of proposal №N \ Stage №N \ Tasks №N
  • A short description of the experience with proposal №N \ Stage №N \ Tasks№N
  • The proposal’s address
    • Proposal’s address №N \ Stage №N \ Tasks №N

5. Proposal “sMerit reputation system”

The DAO Architecture Builder proposes the creation of sMerit to reward teams and individuals who complete the steps and tasks of proposals. This is an address reputation explorer.

The smart contract of those responsible for the implementation of sMerit should display the reputation based on the blockchain data, where the rating (card) of the team/responsible entity will be entered.

sMerit cannot be bought/sold.

Member profile structure:

  • Nickname/Name
  • Roles

their roles in the proposal.

  • Task Hierarchy:

    • Proposal
    • A brief description of the experience in relation proposal
      and/or
    • Stage name №N
    • A brief description of the experience in relation stage
      and/or
    • Task name №N
    • A brief description of the experience in relation task

  • Participant’s NFT portfolio address;

  • Links to social networks, messengers;

  • Wallet address, public key.

This reputation system is very important for teams; it acts as a reward in case of fulfillment of obligations and as such serves as a measure of reputation management for unreliable teams.

6. Proposal “Phased allocation of funds for implementation of proposals”

It is proposed to make one post-payment transaction only in cases when the community gets the expected final result. In all other cases, coins can only be allocated in a few stages. Allocation of coins from the DAO multisig wallet can be stopped at any stage after a vote by the Everscale community.

It is proposed to set a limit on prepayment as an initial trust payment.

  • Step №0

    By decision of the Everscale DAO, the coins are transferred to the proposal multisig.

  • Step №1

    According to the timer, the smart contract transfers coins to the team’s multisig for Stage №N.

  • Step №2

    • Task №M1 (optional)
    • Task №Mn (optional)

    According to the timer, the smart contract transfers coins from the team’s multisig to the participants’ wallets.

  • Step №3 (optional)

    Step №1 and Step №2 are repeated from Step №N to Step №M.

7. Proposal “Develop DAO constructor architecture”

This proposal is based on the idea that each proposal should have a multisig under the control of the community from which the payment takes place via the smart contract for the work completed on the multisig of the team’s proposal (according to the stages of the proposal’s implementation). Payment for the work of team members is made from the team’s wallet, also via smart contract.

In other words, we have four types of wallets:

  • The exchequer;
  • The multisig of the proposal which is controlled by the community;
  • The multisig of the proposal which is controlled by the proposal’s team;
  • The private wallets of the participants.

The community will be able to initiate a proposal to stop smart contracts paying for stages (from the proposal wallet to a team wallet), while teams can vote to stop contracts distributing profits between participants (from a team wallet to a participant wallet).

Stages:

  1. Proposal
    1.1. Pending
    1.2. Voting
    1.3. Queued
    1.4. Execution Proposal
    1.4.1. Execution Stage №n “stage name”.
    1.4.1.1. Verification of Task №n “task name”.
    1.4.1.2. Verification of Stage №n “stage name”.
    1.4.1.3. Payment of Stage №n “stage name”.
    1.4.1.4. Payment of Tasks.
    1.4.2. Additional Proposal №n “proposal name”* (from point 1 to point 1.4.1.4).

  2. The cycle from point 1.4.1 to point 1.4.2 is repeated until the end of the proposal.

The community will receive a temporary interval to check the completed results of Stage №n “name of stage”.

Smart contracts should allow a standard limit value to be set by voting on individual DAO proposals.

The structure of proposal management:

  • Horizontal structure of proposal:

    • Stage №1
      • Task №1 (optional)
      • Task №n (optional)
    • Stage №M (optional)
      • Task №M1 (optional)
      • Task №Mn (optional)

  • Vertical Structure of Proposal Implementation Management:

    • Proposal
      • Initiator/curator
      • Person in charge of implementing the proposal
      • Auditors
      • Random roles (optional)
    • Stage №N (optional)
      • Person in charge of implementing stage
      • Random roles (optional)
    • Task №N (optional)
      • Person in charge of task implementation
      • Random roles (optional)

For each stage and task a deadline is assigned, as well as a second date for automatically receiving tokens for tasks.

Within a certain period after the deadline, the participant should present a report.

Everscale Communities, proposal team, can vote to:

  • Postpone deadlines;
  • Change the payment date to a later date;
  • Add a milestone or task;
  • Request to replenish the proposal budget;
  • Remove an obligation from any participant or change the proposal implementer;
  • Appoint additional community members;
  • Reward contractors;
  • Allocate additional coins from the Treasury.

Member profile structure:

  • Nickname/Name

  • Roles

  • list of roles in a proposal.

  • Task Hierarchy:

    • Proposal
    • A brief description of the experience in relation proposal
      and/or
    • Stage name №N
    • A brief description of the experience in relation stage
      and/or
    • Task name №N
    • A brief description of the experience in relation stage

  • Participant’s NFT portfolio address;

  • Links to social networks, messengers;

  • Wallet address, public key.

7. Proposal “Add option to create a proposal to reward team and individual results”

A proposal to make a button to create an offer to encourage the team(s) with EVER coins, as well as a button to encourage individual participants in the proposal by the proposal team.

Limits:

  • Set a limit of N EVER coins to automatically create an offer to reward the team.
  • Teams independently vote for promotion of individual participants in the proposal.

Smart contracts should allow standard limits to be set through voting on individual DAO proposals.

9. Proposal “Add option to return funds allocated for the proposal implementation team”

To implement a DAO mechanism to forcibly stop allocation of coins from the multisig wallet of the proposal before the actual vesting during the period of checking the results.

Limits:

  • Set a limit of N EVER coins to stop the smart contract allocating coins / tokens from the proposal multisig wallet to the team multisig wallet through voting by the Everscale community;
  • Set a limit of N EVER coins for returning tokens from the proposal multisig wallet back to the Treasury through community voting;
  • Set a limit of N EVER coins to stop the smart contract allocating coins / tokens from the team’s multisig wallet to the participants’ wallets through voting by the proposal participants.

Smart contracts should allow standard limits to be set by voting on individual DAO proposals.

10. Proposal “Exclusion of teams/participants from the proposal”

To implement a DAO mechanism to forcibly remove teams from the implementation process.

Limits:

  • Set a limit of N coins on EVER withdrawals by the Everscale community for individual proposal team members.
  • Set a limit of N EVER coins when the entire Everscale community withdraws the entire proposal team.
  • Set a limit of N coins on EVER withdrawals by the proposal team for individual team members.
  • Set a limit of N EVER coins for self-exclusion of the proposal team from the proposal’s implementation.

Smart contracts should allow standard limits to be set by voting on individual DAO proposals.

11. Proposal “Open source DAO constructor”

As part of the implementation of the DAO constructor, it is proposed to release this DAO constructor in the open-source format of the product (open license is also possible).

The ability to deploy on the basis of a DAO – an independent platform constructor by third-party TIP 3.1 teams (grantees, community members) to manage their own projects for community needs.

Auditing access must be granted (via a license) through a decentralized marketplace (not GitHub).

12. Proposal “Launch a bug bounty program”

After the launch of the DAO constructor architecture, it is proposed to launch a bounty program to encourage testers to find bugs and be rewarded.
Encouragement can only be carried out by voting, citing the facts of the bug / vulnerability. The prize pool will be determined at the discretion of DeFi Alliance members.

13. Proposal “stEVER Implementation”

To encourage voting community members, it is proposed to implement the stEVER token issued in exchange for liquidity locked into farming, staking, or another activity.
stEVER is a non-tradable asset created solely to participate in DAO voting. It cannot be transferred to third parties.

Implementation

It is proposed to collectively develop a DAO constructor, requirements:

  • Intuitive UX and UI: UX designer and architect of at least senior level.
  • Relies on accepted proposals: for key proposals in a prominent place.
  • Contains hints and footnotes to instructions.
  • Contains search, filtering offers.
  • Allows management of treasury reserves by a decentralized community.
  • Allows decentralized teams to work on private projects.
  • Allows you to make projects public and hidden (the option is displayed in proposals).
  • The universal design is suitable for both Agile and Waterfall management methodologies.
  • Compliance with the Everscale brand book.
  • Auditing of smart contracts by an independent team (Pruvendo).
  • Solution must be open source (license).

Implementation stages:

Stage 1: DAO architecture design.

Stage 2: Prototype design - MVP.

Stage 4: Conduct public tests.

Stage 5: Finish development.

Stage 6: Conduct an audit of smart contracts.

Step 7: Publish smart contracts to create private forks.

Step 8: Implement Offer Event Browser (DAO Proposal Implementation History).

Step 9: Implement the Merit Address Reputation Explorer (a portfolio of DAO users).

Step 10: Form a legal framework for decentralized projects on the Everscale network.

Authors

Averyanov Evgeny (telegram @averyanova) - Initiator

Beko (telegram @astrosar) - Editor

Andrey Dementiev (telegram @dem_andrey) - Critic

Roman D (telegram @Dedicate_s) - Community expert

Alina (telegram @madonna_90) Translator

1 Like