  NEP: 9999
  Title: DAO Contract Standard
  Author: DAO Builders Group  
  Status: Draft
  DiscussionsTo: <URL of current canonical thread>
  Type: Standards
  Requires: < ... >
  Created: <dd-mmm-yyyy>

DAO Contract Standard

This NEP is based on the open-source Sputnik DAO contract, developed and commonly used in the NEAR ecosystem. The ideas presented here come from ongoing collaborations with past contributors and various active members of the DAO Builders Community Group.

Summary

A standard interface for any decentralized autonomous organizations (DAOs) to support collective decision making with on-chain proposals, membership, and governance features.

This will provide a common set of functions and data structures that DAO contracts can use to implement their governance and decision making functionality. This will allow developers to build DAO contracts that are compatible with existing tooling. Also, would make it easier for users to participate in and understand DAOs in the NEAR ecosystem.

Motivation

What use cases does it support?

real-time “My DAOs” tab next to “My NFTs” in a Near Social profile or wallet
interoperability across platforms with common data schema of Project(s)
cohesive + decentralized governance systems for communities, near and far!

What is the expected outcome?

This development could spark new DAO contract implementations by projects integrating with Near Social. There is a need for a standard interface to facilitate coordination and ensure interoperability across the organizations built on NEAR.

Additionally, the open-source Sputnik DAO contract code may further evolve to support governance modules, which diversity and inclusion in the ecosystem.

This NEP is requesting review and comments by NEAR experts and other engineers involved with the Contract Standards Working Group.

Rationale & Alternatives

This explains the basic need for standardizing a DAO contract interface and why the Sputnik DAO code is well suited for this purpose.

Why is this design the best in the space of possible designs?

The Sputnik DAO contract code provides a solid foundation for a standard contract interface for DAOs on the NEAR blockchain.

Key Features:

proposals
membership
policies
upgradability
bounties

This modular contract design enables anyone to build clients / apps or integrations extending its capabilities.

Which other designs have been considered and what is the rationale for not choosing them?

Compare and contrast the Sputnik DAO contract code with other existing DAO contracts, highlighting its strengths and limitations

Outline the alternatives that have been considered and the reasons why they were not chosen.

DAOs are reaching the extent of their original design limitations. There might need to be a system for composability to allow innovative features or apps to interact in ways not possible today.

What is the impact of not doing this?

Potential benefits of standardizing the DAO contract interface:

ecosystem-wide interoperability
better alignment across projects
easier adoption by new builders

Not coordinating to develop this DAO contract standard may result in confusion and technical debt as we shift away from the Astro platform toward Near Social.

Example ~ Forum Post: "Creating a DAO Outside of Sputnik" (December 2021)

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

This contract is a Rust implementation for decentralized autonomous organizations (DAOs), meant to be used on the NEAR blockchain platform. Below is a detailed description of the structures and functions in the Sputnik DAO contract system, along with discussion of tradeoffs, limitations, and challenges.

Overall, the structure represents current DAO state. For example, the list of members and their voting power, as well as tokens the DAO has collected.

lib.rs (main DAO contract)

Main module of the DAO, which acts as the entry point for the contract system. Here is where to import and use the functionality defined in other modules, e.g., proposals.rs, types.rs, and policy.rs. It also defines the public interface of the contract, including methods that can be called by external clients to interact with the DAO.

Responsibilities of lib.rs include handling incoming transactions, state transitions, and updating the contract's storage. This module interacts with the storage and functions defined in other modules to implement the core functionality of the DAO:

creating and managing proposals, policies and members, along with processing votes and updating the state of the DAO as a whole.

The Contract struct stores configuration, policy, delegations, proposals, bounties, and more. Several methods are provided to interact with the DAO:

creating proposals
claiming bounties
delegating tokens

This module also has an implementation of an interface called ExtSelf that allows for callbacks after proposal execution.

Open question: should we ignore bounties, delegation, and upgrades for now?

Below is an abbreviated version of the code:

Which modules to include?

mod bounties;
mod delegation;
mod policy;
mod proposals;
mod types;
mod upgrade;

pub enum StorageKeys {
   Config,
   Policy,
   Delegations,
   Proposals,
   Bounties,
   BountyClaimers,
   BountyClaimCounts,
   Blobs,
}

pub struct Contract {
   pub config: LazyOption<Config>,
   pub policy: LazyOption<VersionedPolicy>,
   pub locked_amount: Balance,
   pub staking_id: Option<AccountId>,
   pub total_delegation_amount: Balance,
   pub delegations: LookupMap<AccountId, Balance>,
   pub last_proposal_id: u64,
   pub proposals: LookupMap<u64, VersionedProposal>,
   pub last_bounty_id: u64,
   pub bounties: LookupMap<u64, VersionedBounty>,
   pub bounty_claimers: LookupMap<AccountId, Vec<BountyClaim>>,
   pub bounty_claims_count: LookupMap<u64, u32>,
   pub blobs: LookupMap<CryptoHash, AccountId>,
}

/// After payouts, allows a callback
#[ext_contract(ext_self)]
pub trait ExtSelf {
   /// Callback after proposal execution.
fn on_proposal_callback(&mut self, proposal_id: u64) -> PromiseOrValue<()>;
}

policy.rs

This module defines a struct named Policy that stores information about a specific policy within the DAO, such as the policy text and the current state of the policy (active or inactive). It also defines a Policies struct that serves as a collection of policies and includes methods for adding, updating, and retrieving policies.

Plus, the module contains functions for handling incoming transactions related to policies, such as creating a new policy, voting on a policy, and processing the results of a vote.

In summary, policy.rs enables the core functionality of managing policies within a DAO. It is responsible for transactions involving policies, updating state of policies, and providing information about policies to other parts of the system.

Below is an abbreviated version of the code:

pub enum RoleKind {
   Everyone,
   Member(U128),
   Group(HashSet<AccountId>),
}

impl RoleKind {
    pub fn match_user(&self, user: &UserInfo) -> bool {}
    pub fn get_role_size(&self) -> Option<usize> {}
    pub fn add_member_to_group(&mut self, member_id: &AccountId) -> Result<(), ()> {}
    pub fn remove_member_from_group(&mut self, member_id: &AccountId) -> Result<(), ()> {}
}

pub struct RolePermission {
   pub name: String,
   pub kind: RoleKind,
   /// <proposal_kind>:<action>
   pub permissions:
	HashSet<String>,
   pub vote_policy:
	HashMap<String, VotePolicy>,
}

pub struct UserInfo {
    pub account_id: AccountId,
    pub amount: Balance,
}

pub enum WeightOrRatio {
    Weight(U128),
    Ratio(u64, u64),
}

impl WeightOrRatio {
    pub fn to_weight(&self, total_weight: Balance) -> Balance { ... }
}

pub enum WeightKind {
    TokenWeight,
    RoleWeight,
}

pub struct VotePolicy {
    pub weight_kind: WeightKind,
    pub quorum: U128,
    pub threshold: WeightOrRatio,
}

impl Default for VotePolicy {
    fn default() -> Self {
        VotePolicy {
            weight_kind: WeightKind::RoleWeight,
            quorum: U128(0),
            threshold: WeightOrRatio::Ratio(1, 2),
        }
    }
}

pub struct Policy {
   pub roles: Vec<RolePermission>,
   pub default_vote_policy: VotePolicy,
   pub proposal_bond: U128,
   pub proposal_period: U64,
   pub bounty_bond: U128,
   pub bounty_forgiveness_period: U64,
}

pub enum VersionedPolicy {
    Default(Vec<AccountId>),
    Current(Policy),
}

pub fn default_policy(council: Vec<AccountId>) -> Policy { ... }

impl VersionedPolicy {
    pub fn upgrade(self) -> Self { ... }
    pub fn to_policy(self) -> Policy { ... }
    pub fn to_policy_mut(&mut self) -> &mut Policy { ... }

impl Policy {
    pub fn add_or_update_role(
        &mut self,
        role: &RolePermission
    ) { ... }
    pub fn remove_role(
        &mut self, 
        role: &String
    ) { ... }
    pub fn update_default_vote_policy(
        &mut self, 
        vote_policy: &VotePolicy
    ) { ... }
    pub fn update_parameters(
        &mut self, 
        parameters: &PolicyParameters
    ) { ... }
    pub fn add_member_to_role(
        &mut self, 
        role: &String, 
        member_id: &AccountId
    ) { ... }
    pub fn remove_member_from_role(
        &mut self, 
        role: &String, 
        member_id: &AccountId
    ) { ... }
    fn get_user_roles(
        &self, 
        user: UserInfo
    ) -> HashMap<String, &HashSet<String>> { ... }
    pub fn can_execute_action(
        &self, 
        user: UserInfo, 
        proposal_kind: &ProposalKind, 
        action: &Action,
    ) -> (Vec<String>, bool) { ... }
    pub fn is_token_weighted(
        &self, 
        role: &String, 
        proposal_kind_label: &String
    ) -> bool { ... }
    fn internal_get_role(
        &self, 
        name: &String
    ) -> Option<&RolePermission> { ... }
    pub fn proposal_status(
        &self, 
        proposal: &Proposal, 
        roles: Vec<String>, 
        total_supply: Balance,
    ) -> ProposalStatus { ... }
}

proposals.rs

This module defines a struct named Proposal that stores information about a proposed action, including the proposer, the proposal text, and the current state of the proposal (pending, accepted, or rejected). Also, it defines a Proposals struct that serves as a collection of proposals and includes methods for adding, updating, and retrieving proposals.

Additionally, it contains functions for handling incoming transactions related to proposals, such as creating a new proposal, voting on a proposal, and processing the results of a vote.

In summary, proposals.rs enables the core functionality for managing proposals within a DAO. It is responsible for transactions involving proposals, updating the state of proposals, and providing information about proposals to other parts of the system.

Below is an abbreviated version of the code:

pub enum ProposalStatus {
    InProgress,
    Approved,
    Rejected,
    Removed,
    Expired,
    Moved,
    Failed,
}

pub struct ActionCall {
    method_name: String,
    args: Base64VecU8,
    deposit: U128,
    gas: U64,
}

pub struct PolicyParameters {
    pub proposal_bond: Option<U128>,
    pub proposal_period: Option<U64>,
    pub bounty_bond: Option<U128>,
    pub bounty_forgiveness_period: Option<U64>,
}

pub enum ProposalKind {
    ChangeConfig { config: Config },
    ChangePolicy { policy: VersionedPolicy },
    AddMemberToRole { member_id: AccountId, role: String },
    RemoveMemberFromRole { member_id: AccountId, role: String },
    FunctionCall {
        receiver_id: AccountId,
        actions: Vec<ActionCall>,
    },
    UpgradeSelf { hash: Base58CryptoHash },
    UpgradeRemote {
        receiver_id: AccountId,
        method_name: String,
        hash: Base58CryptoHash,
    },
    Transfer {
        token_id: OldAccountId,
        receiver_id: AccountId,
        amount: U128,
        msg: Option<String>,
    },
    SetStakingContract { staking_id: AccountId },
    AddBounty { bounty: Bounty },
    BountyDone {
        bounty_id: u64,
        receiver_id: AccountId,
    },
    Vote,
    FactoryInfoUpdate { factory_info: FactoryInfo },
    ChangePolicyAddOrUpdateRole { role: RolePermission },
    ChangePolicyRemoveRole { role: String },
    ChangePolicyUpdateDefaultVotePolicy { vote_policy: VotePolicy },
    ChangePolicyUpdateParameters { parameters: PolicyParameters },
}

impl ProposalKind {
    pub fn to_policy_label(&self) -> &str {
        match self {
            ProposalKind::ChangeConfig { .. } => "config",
            ProposalKind::ChangePolicy { .. } => "policy",
            ProposalKind::AddMemberToRole { .. } => "add_member_to_role",
            ProposalKind::RemoveMemberFromRole { .. } => "remove_member_from_role",
            ProposalKind::FunctionCall { .. } => "call",
            ProposalKind::UpgradeSelf { .. } => "upgrade_self",
            ProposalKind::UpgradeRemote { .. } => "upgrade_remote",
            ProposalKind::Transfer { .. } => "transfer",
            ProposalKind::SetStakingContract { .. } => "set_vote_token",
            ProposalKind::AddBounty { .. } => "add_bounty",
            ProposalKind::BountyDone { .. } => "bounty_done",
            ProposalKind::Vote => "vote",
            ProposalKind::FactoryInfoUpdate { .. } => "factory_info_update",
            ProposalKind::ChangePolicyAddOrUpdateRole { .. } => "policy_add_or_update_role",
            ProposalKind::ChangePolicyRemoveRole { .. } => "policy_remove_role",
            ProposalKind::ChangePolicyUpdateDefaultVotePolicy { .. } => { "policy_update_default_vote_policy"  }
            ProposalKind::ChangePolicyUpdateParameters { .. } => "policy_update_parameters",
        }
    }
}

pub enum Vote {
    Approve = 0x0,
    Reject = 0x1,
    Remove = 0x2,
}

impl From<Action> for Vote {
    fn from(action: Action) -> Self {
        match action {
            Action::VoteApprove => Vote::Approve,
            Action::VoteReject => Vote::Reject,
            Action::VoteRemove => Vote::Remove,
            _ => unreachable!(),
        }
    }
}

pub struct Proposal {
    pub proposer: AccountId,
    pub description: String,
    pub kind: ProposalKind,
    pub status: ProposalStatus,
    pub vote_counts: HashMap<String, [Balance; 3]>,
    pub votes: HashMap<AccountId, Vote>,
    pub submission_time: U64,
}

impl Proposal {
    pub fn update_votes(
        &mut self,
        account_id: &AccountId,
        roles: &[String],
        vote: Vote,
        policy: &Policy,
        user_weight: Balance,
    ) { ... }
}

#[derive(Serialize, Deserialize)]
#[serde(crate = "near_sdk::serde")]
pub struct ProposalInput {
    pub description: String,
    pub kind: ProposalKind,
}

impl From<ProposalInput> for Proposal {
    fn from(input: ProposalInput) -> Self {
        Self {
            proposer: env::predecessor_account_id(),
            description: input.description,
            kind: input.kind,
            status: ProposalStatus::InProgress,
            vote_counts: HashMap::default(),
            votes: HashMap::default(),
            submission_time: U64::from(env::block_timestamp()),
        }
    }
}

impl Contract {
    pub(crate) fn internal_payout(
        &mut self,
        token_id: &Option<AccountId>,
        receiver_id: &AccountId,
        amount: Balance,
        memo: String,
        msg: Option<String>,
    ) -> PromiseOrValue<()> { ... }

    fn internal_return_bonds(&mut self, policy: &Policy, proposal: &Proposal) -> Promise { ... }

    fn internal_execute_proposal(
        &mut self,
        policy: &Policy,
        proposal: &Proposal,
        proposal_id: u64,
    ) -> PromiseOrValue<()> { ... }

    pub(crate) fn internal_callback_proposal_success(
        &mut self,
        proposal: &mut Proposal,
    ) -> PromiseOrValue<()> { ... }

    pub(crate) fn internal_callback_proposal_fail(
        &mut self,
        proposal: &mut Proposal,
    ) -> PromiseOrValue<()> { ... }

    fn internal_reject_proposal(
        &mut self,
        policy: &Policy,
        proposal: &Proposal,
        return_bonds: bool,
    ) -> PromiseOrValue<()> { ... }

    pub(crate) fn internal_user_info(&self) -> UserInfo { ... }
}

impl Contract {
    #[payable]
    pub fn add_proposal(&mut self, proposal: ProposalInput) -> u64 { ... }
    pub fn act_proposal(&mut self, id: u64, action: Action, memo: Option<String>) { ... }
    #[private]
    pub fn on_proposal_callback(&mut self, proposal_id: u64) -> PromiseOrValue<()> {...}
}

types.rs

This module provides a centralized location for defining custom types used throughout the code, making it more readable, maintainable, and flexible.

types.rs includes the following:

AccountId: account identifier on the NEAR platform
Balance: balance of a particular account or amount of tokens in a DAO
ProposalIndex: index of a proposal within the DAO
VotingPower: voting power of a member within the DAO

Defining these types in a separate module gives a clear separation between custom types and implementation of the DAO logic. This makes it easier to understand how different parts of the code relate to each other, and it is easier to change the code, if necessary.

Below is an abbreviated version of the code:

pub struct Config {
   pub name: String,
   pub purpose: String,
   pub metadata: Base64VecU8,
}

pub enum Action {
   AddProposal,
   RemoveProposal,
   VoteApprove,
   VoteReject,
   VoteRemove,
   Finalize,
   MoveToHub,
}

impl Action {
    pub fn to_policy_label(&self) -> String {
        format!("{:?}", self)
    }
}

Reference Implementation

The Sputnik DAO contract code is available on GitHub:
https://github.com/near-daos/sputnik-dao-contract

User interfaces built on the Sputnik DAO contracts (oldest to newest):

https://old.sputnik.fund –> V1 contracts
https://sputnik.fund –> V1 contracts
https://v2.sputnik.fund –> v2 contracts
https://app.astrodao.com –> v2 contracts

< explain how Astro users deploy and interact with Sputnik DAO contracts >

Sputnik DAO Contract System (V2)

Factory:

DAOs:

sputnikdao2/src (code)
<dao_name>.sputnik-dao.near (mainnet)
<dao_name>.sputnikv2.testnet (testnet)

See all DAOs by calling:

near view sputnik-dao.near get_dao_list (mainnet)

near view sputnikv2.testnet get_dao_list (testnet)

Future Possibilities

Thanks to Trevor of CronCat for developing many of these ideas and inspiring this proposal!

The natural extension and evolution of this proposal would be improving the Sputnik DAO contract system to be more accessible, meaningful and useful. Ultimately, this may help drive adoption of such valuable, open-source technology for builders. Sputnik enables anyone to build clients or integrations extending its capabilities.

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`	在筆記中貼入程式碼
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.

DAO Contract Standard

Summary

Motivation

What use cases does it support?

What is the expected outcome?

Rationale & Alternatives

Why is this design the best in the space of possible designs?

Which other designs have been considered and what is the rationale for not choosing them?

What is the impact of not doing this?

Specification

lib.rs (main DAO contract)

policy.rs

proposals.rs

types.rs

Reference Implementation

Sputnik DAO Contract System (V2)

Future Possibilities

POSSIBLE EXTENSIONS

Considerations:

License

Appendix

Resources