[docs] dao (#196)

YOLOing because this only puts back what was already approved. Adds DAO content.

documentation/pages/_meta.json

@@ -1,5 +1,6 @@
 {
     "index": "SuiNS Documentation",
+    "dao": "SuiNS DAO",
     "developer": "Developer",
     "user": "User",
     "node-operator": "Node Operator",

documentation/pages/dao.mdx

@@ -0,0 +1,70 @@
+# 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 may 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. Thus, this process is designed to ensure that all decisions reflect the collective will of the community, maintain the integrity of the protocol, and foster sustainable development.
+
+## Article I – Proposal submission
+
+1. **Eligibility:** SuiNS Foundation and Members will both eventually have the ability to introduce and submit proposals for consideration and pass proposals with sufficient DAO support as outlined below. 
+1. **Proposal Requirements:** Proposals should include a clear and concise description of the issue, potential or definitive solutions, and the desired outcome. Supporting documents and evidence should be attached where relevant. Proposals should clearly state which category the proposal fits within as well as the implementation timeline and any other pertinent details. 
+1. **Proposal Categories:** Proposals should be classified into one of four main categories:
+  - **Technical Proposals**, including changes to the protocol or technical aspects of the SuiNS system. These types of proposals will have to include definitive code changes/updates.
+  - **Parameter Proposals**, including those that would change parameters in the contract but not the essence of the code. For example pricing, expirations, temporary discounts, etc.
+  - **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 will have the ability to increase/decrease quorum requirements based on user activity.
+1. **Voting Period:** Each proposal will have a variable time length where the smallest voting period cannot be less than 24 hours and the maximum cannot be greater than 14 days. This period can be extended or shortened with community approval.
+1. **Voting Mechanism:** Voting will be conducted on designated SuiNS governance platforms. Each token represents one vote, and votes can be cast in favor, against, or abstain.
+1. **No Violation of Laws:**  Approved votes that could result in a violation of SuiNS Foundation directors’ fiduciary duties or applicable law may be vetoed by the SuiNS Foundation directors by a vote of a majority of the directors seated.   
+1. **Majority requirements:**
+    - **Simple Majority:** Regular proposals require a simple 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 fundamental rules are only changed with broad consensus.
+      1. **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.
+      1. **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 will have 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 competing proposal is proposed while an existing proposal is under consideration, the subsequent competing proposal should not be voted on until voting for the initial proposal has been completed.  
+1. **Community Discussion:** Proposals should be open for community discussion for at least seven days before voting begins. 
+
+## Article IV – Implementation of approved proposals
+
+1. **Implementation Timeline:** Approved proposals will be implemented according to a predefined timeline. Immediate, short-term, and long-term actions should be specified as part of the proposal.
+1. **Responsible Parties:** Proposals should also include a set of responsible parties who will be implementing and taking action that affects the outcome of the proposal. These members should be included in the Team section.
+
+## 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 may file an appeal through the community forum. The appeal will be reviewed by a council of community members (“Community Council”). 
+
+## Article VI – Amendment of governance rules
+
+1. **Amendment Process:** Changes to these governance rules can be proposed through the standard proposal process.
+1. **Approval Requirements:** Amendments to these governance rules will be deemed a constitutional amendment, and require a two-thirds majority vote.
+
+## Article VII – Proposal template
+
+A proposal shall include:
+- **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 will benefit 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, and/or industry-specific.
+- **Platforms and Technologies:** A detailed breakdown of the platforms and technologies that will be used.
+- **Steps to Implement & 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:** Where funds should be received 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:** On-Chain address which can approve of completion of proposal requirements. Can be a community member/multisig wallet but will initially be a SuiNS Foundation wallet.
+- **Code Packet:** On-chain 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 will have the following capabilities over the protocol and governance rules for the first two 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, as deemed necessary by at least a majority of the Community Council members. 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 will be able to appropriate protocol treasury funds towards supporting operations.

documentation/public/suins.css

@@ -53,4 +53,8 @@ li :is(ul, ol) {
 
 li > p, li img {
     @apply !m-2
+}
+
+ol ul ol {
+    @apply !list-[lower-roman]
 }