Hi, thanks so much for you response. I used the default template and just filled in the relevant info regarding my organization. I really am learning as I go, I don’t know much about how to set rules and just recently learned a moderate amount what a DAO is and the benefits of having one. Here are the rules I used based on the Aragon template.
Govern DAO: Default Agreement
Section 0. Background
The identifier of the DAO is [Shamayim], deployed on the [Blockchain Network: Ethereum] with the following URL identifier Aragon Govern - Optimistic Governance for DAOs hereinafter referred to as the “shuharicoin”.
The DAO is a “decentralized autonomous organization”, an unincorporated association of individuals, entities, associations and/or other persons or groups of persons.
This agreement exists to enumerate the shared mission, principles, and governance guidelines that bind the DAO’s members together as well as the operating rules of the DAO.
Section 1. RFC 2119 compliance
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.
Section 2. Immutable guidelines
The guidelines in this section SHALL NOT be amended. If any other guidelines in this Agreement conflict with these immutable guidelines, the immutable guidelines SHALL take priority for enforcement purposes. These guidelines apply to all proposals submitted to the DAO.
Proposals MUST be governed by this Agreement, or a future version of this Agreement as modified within the bounds of the Agreement.
Disputes over a proposal relying on this Agreement MUST be resolved by Aragon Court.
Proposals MUST NOT disproportionately benefit a majority of Token Holders voting on a proposal over the minority.
Section 3. Mutable guidelines
The guidelines in this section MAY be amended. These guidelines apply to all proposals put forth to the DAO.
Proposals MUST be accompanied by an accurate American English-language Justification for the proposal. Typos in the Justification SHALL be allowed if they do not substantially alter the meaning of the proposal. Each Justification MUST be referred to in the on-chain source code or transaction data of the proposal by the content-addressed location of the Justification on the public IPFS network, and the Justification MUST be accessible via the public IPFS network for as long as the proposal is open for voting and/or in effect. If a Justification becomes temporarily inaccessible via the public IPFS network, and its proposal is challenged under this guideline, then guardians SHOULD block the proposal if they have reason to believe the Justification was inaccessible at the time that the proposal was challenged. Alternatively, the Justification MAY be encoded directly into the on-chain source code or transaction data of the proposal so that the Justification remains human-readable and accessible as long as the Ethereum blockchain itself remains publicly available. The Justification MUST include the following information:
The name(s) and/or username(s) of the author(s) of the proposal. The author(s) SHOULD be the primary point of contact for any questions or comments regarding the proposal.
The author’s preferred contact method, in case anyone has questions or comments regarding the proposal.
An accurate summary of the proposal in 280 characters or less.
A rationale section detailing the author’s reason(s) for creating the proposal.
An accurate, long-form description of what the proposal will do if enacted.
A section acknowledging by title and author(s) any similar or related prior work known to the proposal author(s).
If the proposal amends one or more Network contracts, then a security audit report of the Network contract amendment MUST be included in the Justification. This security audit report MUST be produced by a third-party security auditor and remain publicly accessible for as long as the amendment is in effect. The third-party security auditor MUST NOT have any financial relationship to the proposal author(s) aside from their being hired to perform the security audit.
Proposal Justifications MUST NOT contain directly or by direct link any Non-consensual Imagery (NCI), Child Abuse Imagery (CAI), malware, spyware, or material that is owned via Copyright by someone other than one of the proposal authors (unless use of said Copyright material is permitted by the Copyright owner or otherwise protected under Fair Use standards).
Any transaction created in this DAO must have first been proposed in an Aragon Voice vote on https://voice.aragon.org/ and with the following approval criteria:
67% support of the participating Token Holders in the vote
Proposal duration of at least 3 days
Section 4. Definitions
Any words or phrases not explicitly defined here SHALL be defined by either the Merriam-Webster Dictionary (https://www.merriam-webster.com/) or the Merriam-Webster Law Dictionary (Merriam-Webster's Law Dictionary: Legal Terms in Plain English). In cases where a word or phrase appears in both the Dictionary and Law Dictionary, the Law Dictionary definition SHALL be used by the reader. In cases where a word or phrase is not explicitly defined here or in either of the dictionaries specified above, the definition most reasonable to the reader MAY be used.
Token Holders - The parties holding the native token of the DAO.
Govern Executor - An Aragon app that enables members of an Aragon organization to interact with other smart contracts on behalf of the organization, as if it were the organization itself performing the interaction. All transactions executed by the DAO are performed by this app.
Aragon Court - A smart contract-based dispute resolution system governed by ANT holders.
Ethereum blockchain - The blockchain referred to as “Ethereum” by the owner of the Ethereum trademark, the Ethereum Foundation (Stiftung Ethereum).
IPFS network - A peer-to-peer hypermedia protocol, whose project website is located at https://ipfs.io. The public network makes files accessible to any internet-connected device running a compatible implementation of the IPFS software.
Network contract - The computer-interpreted source code of a smart contract governed by ANT holders.
Network parameters - The current parameters of smart contracts governed by ANT holders, which can be modified without amending the source code of the smart contract itself.
Proposal - A proposal is any suggested amendment to the Network contracts, Network parameters, or the Agreement of the Aragon Network.
RFC 2119 - A technical standard for indicating requirement levels, the canonical version of which is located at rfc2119.
Smart contract - a software program deployed to the Ethereum blockchain.