Skip to main content

SuiNS DAO Proposals and Voting Procedure

The Sui Name Service DAO (SuiNS DAO) aims to provide a fair, transparent, and effective governance structure. The following process governs the rules and procedures by which members of the DAO propose, vote, and implement improvement proposals. These proposals usually go through cycles of refinement and consensus, with the purpose of facilitating increasing community engagement in connection with each iteration. This process ensures that all decisions reflect the collective intent of the community, maintain the integrity of the protocol, and foster sustainable development.

info

Read the SuiNS DAO Constitution on vote.suins.io.

Article I – proposal submission​

  1. Eligibility: SuiNS Foundation and Members both eventually have the ability to introduce and submit proposals for consideration and pass proposals with sufficient DAO support as outlined below.
  2. Proposal requirements: Proposals should include a clear and concise description of the issue, potential or definitive solutions, and the desired outcome. Authors should attach supporting documents and evidence where relevant. Proposals should clearly state which category the proposal fits within as well as the implementation timeline and any other pertinent details. For the fields a proposal must include, see the proposal template in Article VII; for where to post a proposal, see Article III.
  3. Proposal categories: Authors should classify proposals into one of 4 main categories:
  • Technical proposals, including changes to the protocol or technical aspects of the SuiNS system. These types of proposals must include definitive code changes or updates.
  • Parameter proposals, including those that would change parameters in the contract but not the essence of the code, for example pricing, expirations, and temporary discounts.
  • Financial proposals, including allocation of revenue, community-designated NS tokens, and budget approvals.
  • Governance proposals, including changes to the governance structure, rules, or constitution amendments.

Article II – voting process​

  1. Quorum requirements: For a vote to be valid, at least 1% of initial circulating tokens (1.5M) must participate in the voting process. For the first 6 months following the token generation event, the Community Council (a council of community members; see Article V) has the ability to increase or decrease quorum requirements based on user activity.
  2. Voting period: Each proposal has a variable time length where the smallest voting period cannot be less than 24 hours and the maximum cannot be greater than 14 days. Community approval can extend or shorten this period.
  3. Voting mechanism: Voting takes place on designated SuiNS governance platforms. Each token represents one vote, and members can vote in favor, against, or abstain.
  4. No violation of laws: The SuiNS Foundation directors can veto approved votes that could result in a violation of their fiduciary duties or applicable law by a vote of a majority of the directors seated.
  5. Majority requirements:
    • Basic majority: Regular proposals require a basic majority (>50%) of votes cast to pass.
    • Supermajority: Constitutional amendments or critical changes require a two-thirds majority (66%) of votes cast. The types of proposals that would fall into the supermajority category include:
      1. Constitutional amendments: Changes to the Sui Name Service governance rules or core governing principles require a supermajority. This ensures that the DAO only changes fundamental rules with broad consensus.
      2. Major protocol changes: Significant changes to the protocol or its operations, such as upgrades or modifications to critical contracts, changes to pricing or subscription expirations.
      3. Tokenomics adjustments: Decisions that affect the issuance or allocation of the $NS token, which could have long-term impacts on the community and ecosystem.

Article III – proposal evaluation​

  1. Initial review: Any member has the ability to post proposals on the community discussion forum for further consideration by the community. Only those proposals that meet the basic requirements set forth above should be subject to a community vote. If a member submits a competing proposal while an existing proposal is under consideration, the community should not vote on the subsequent competing proposal until voting for the initial proposal ends.
  2. Community discussion: Proposals should be open for community discussion for at least 7 days before voting begins.

Article IV – implementation of approved proposals​

  1. Implementation timeline: Responsible parties implement approved proposals according to a predefined timeline. The proposal should specify immediate, short-term, and long-term actions.
  2. Responsible parties: Proposals should also include a set of responsible parties who implement and take action that affects the outcome of the proposal. The Team section should include these members.

Article V – dispute resolution​

  1. Appeal process: If a community member disagrees with the outcome of a vote or the implementation of a proposal, they can file an appeal through the community forum. A council of community members (Community Council) reviews the appeal.

Article VI – amendment of governance rules​

  1. Amendment process: Members can propose changes to these governance rules through the standard proposal process.
  2. Approval requirements: Amendments to these governance rules count as constitutional amendments and require a two-thirds majority vote.

Article VII – proposal template​

A proposal includes:

  • Abstract: A brief summary outlining the proposal.
  • Team description: A brief introduction to the author and the team (required if requesting funding), and those responsible for implementing the proposal if approved.
  • Benefit to SuiNS ecosystem: An explanation of how the proposal benefits the SuiNS ecosystem, and how it aligns with the SuiNS Community’s core mission and values.
  • Key terms (optional): Definitions of any terms within the proposal that are unique to the proposal, new to the SuiNS Community, or industry-specific.
  • Platforms and technologies: A detailed breakdown of the platforms and technologies the proposal uses.
  • Steps to implement and timeline: An outline of the steps to implement the proposal, including associated costs, key performance indicators, personnel requirements, any expectations of the SuiNS Foundation, and other resources needed for each step where applicable. This section also provides relevant timing details, including the project’s start date and key milestones.
  • Overall cost: A summary of the total budget associated with implementing the proposal.
  • Wallet address: The address that receives funds for completion of the proposal tasks.
  • Up-front funding amount: Amount and currency of up-front payment required to facilitate proposal.
  • Completion funding amount: Amount and currency of completion payment when proposal outcomes have completed.
  • Moderating party: Onchain address that can approve completion of proposal requirements. Can be a community member or multisig wallet but is initially a SuiNS Foundation wallet.
  • Code packet: Onchain representation object of code upgrade required to make additions or changes to the SuiNS protocol.

The author can add additional fields to any template if necessary to fully communicate the intentions, specifics, and implications of the proposal.

Article VIII – emergency powers​

To help bootstrap the SuiNS protocol and allow it to move quickly and make important decisions without delay to protect the safety of the users and the nascent decentralized protocol, the Community Council has the following capabilities over the protocol and governance rules for the first 2 years after the NS Token Generation Event:

  • Critical protocol changes: Ability to update the protocol contract to make critical changes to the protocol under exigent circumstances to protect the protocol, when at least a majority of the Community Council members deem it necessary. Any changes should stay in line with the spirit of the SuiNS Constitution.
  • Critical funding operations: Should the SuiNS Foundation and those supporting the protocol be in a situation that requires ceasing services for lack of funding, the SuiNS Foundation with an approval of a majority of the directors then seated can appropriate protocol treasury funds toward supporting operations.