The Guard Foundation Governance Document

Help & Resources
1

GOVERNANCE FRAMEWORK

Guard Foundation

INTRODUCTION

The governance mechanisms of decentralized protocols derive from the interplay of community participation, self-regulation, and policy management.

This document formally establishes the structure of a Decentralized Autonomous Organization (the “GUARD DAO”) governed by holders of GUARD tokens (the “GUARD Tokenholders”), a decentralized token that serves as the primary token for governing the GUARD DAO protocol and ecosystem, via GFPs (as defined below) (the “GUARD Tokens”) and shall be effective as of the date it is initially posted on the Foundation website.

PURPOSE

Guard Foundation, a Cayman Islands foundation company (the “Foundation”) serves the Community (as defined below) by facilitating decentralized and community governance and be governed by its Memorandum and Articles of Association (as amended from time to time) and Bylaws (as amended from time to time).

The GUARD Tokenholders have the power to submit proposals, vote on proposals, and bring those to fruition.

The core values of the Foundation are:

  • Unconventionality: We don’t shy away from weird.
  • Equality: One GUARD Token equals one GUARD Token.
  • Transparency: Processes and decisions are shared openly with the Community (as defined below).
  • Collective Momentum: We share a collective vision.
  • Velocity: We move with purpose and direction.

As we grow, our processes and strategies may change, but these guiding values will remain the same.

The Foundation aims to be the heart of the next era of new frontiers of human creativity, collaboration, and creation on the blockchain.

To achieve this, it is imperative that participating in idea submission, commentary, proposal submission, and voting is restricted to GUARD Tokenholders. Holding GUARD Tokens is the only requirement for membership in the GUARD DAO.

In alignment with the Foundation’s goal of transparency, all preliminary discussions, proposals, votes cast and outcomes will be publicly available to view.

PROPOSAL CRITERIA

  1. Every year, there is a GUARD DAO-wide vote to determine which GUARD DAO members will serve on a council on the Foundation (the “Council”). The purpose of the Council is to administer GFPs (as defined below) and serve the vision of the Community (as defined below).
  2. The total cost of implementation and any financial impact of its effectuation must be clearly defined in order for a proposal to go to vote.
  3. If a proposal is ratified which directly impacts GUARD DAO’s smart contracts, it must pass through a 72 hour timelock before implementation.
  4. All submittants must search through archived proposals to ensure they are not re-submitting a duplicate idea.
  5. To avoid concurrent proposals which directly conflict with one another, any idea that directly impacts a proposal that is currently under consideration should not be submitted or voted on until consensus has been reached on the initial proposal.
  6. A suggested proposal that directly conflicts with another approved proposal cannot go to vote for 90 days after the original proposal has been implemented to avoid wasting community assets.
  7. The Council will not consider or vote on proposals which advocate hate speech, illegal activity, explicit material, or are out of line with the Foundation’s mission and values.

COUNCIL

The Council plays a supporting and coordinating role for work contributed by the GUARD DAO ecosystem’s decentralized community of users (the “Community”). However, it is the Community’s responsibility to develop the GUARD DAO ecosystem and make proposals to guide the long-term strategy of the Foundation and the GUARD DAO.

COMPOSITION

Seven (7) persons appointed by a plurality vote of GUARD Tokenholders, pursuant to and evidenced by the Guard Improvement Proposal (“GFP”) process, and in the first instance, appointed by the sole director of the Foundation (“Council Members”).

TERM LIMITS

  • Initial Council Members will serve for an initial six (6) month term. Subsequently, the Council Members will be chosen annually by a vote of GUARD Tokenholders, pursuant to and evidenced by the GFP process. All subsequent Council Members will serve for a twelve (12) month term.
  • A Council Member may be removed and replaced prior to the end of the term pursuant to a 2/3rds majority vote of GUARD Tokenholders.
  • Any holder of a minimum of 1,000 GUARD Tokens may nominate a candidate to serve on the Council.

AUTHORITY & RESPONSIBILITIES

  • Fund transitions by the Foundation from the Treasury, including contractor/consultancy agreements, grants to support Community development and contractor/consultancy agreements.
  • Sign transactions from the Council Multisig (as defined in the Bylaws), once implemented, to ensure that an approved GFP receives sufficient signatures (even if the Council Member had voted “no” with respect to that GFP).
  • Attend weekly meetings, vote on GFPs, and attend unofficial Community events hosted by the Foundation and ecosystem members. Council Members may choose the frequency with which they perform these activities at their own discretion, bearing in mind that if they fail to adequately represent the Community due to infrequency of participation, they may be removed as a Council Member by other Council Members.
  • Pursuant to GFPs, perform adjustments to economic parameters with respect to the GUARD Token; provided that, in the instance of an Emergency Meeting as described below, the Council may perform adjustments to economic parameters with respect to GUARD Token pursuant to a majority vote of Council Members.
  • Coordinate Emergency Meetings on behalf of the Community, GUARD Tokenholders or the Foundation, pursuant to a majority vote of Council Members.
  • Enable the Council to rapidly respond to any imminent security threats to the GUARD DAO ecosystem.

KEY TERMS

  • DAO Administrator – The DAO Administrator shall provide operational support and project management support for the Foundation and GUARD DAO governance. Webslinger Advisors SEZC Inc. is the initial DAO Administrator and will serve an initial term of 12 months, pursuant the terms of the services agreement entered into by the GAURD Foundation, effective August 21, 2023.
  • GFP (GUARD Foundation Proposal) - a document proposing a new feature, project, activity, goal, piece of information, or change to any proposal that has already been implemented.
  • GFP Idea - the first step in the process of creating an official GFP, which will be presented to the Community for gathering informal feedback for a period of seven days.
  • GFP Draft - the second step in the process of creating an official GFP, which can only be submitted after the original GFP Idea has gathered feedback from the community for seven days in the proper channel. An GFP Draft must be submitted directly to a moderator via predetermined GFP templates.
  • GFP Template - the preset format for a GFP draft, which will vary slightly depending on the nature of the intended GFP.
  • GFP Author - the GUARD DAO member responsible for beginning the GFP, starting with presenting the idea to the community via the proper GFP Idea process. The GFP Author is responsible for incorporating relevant feedback, submitting the subsequent GFP Draft via the proper GFP Template to the moderator, and responding to questions or requests for clarifications from GUARD DAO members and moderators. A minimum of 100 GUARD Tokens are required to engage as a GFP Author.
  • GFP Categories - the predetermined classification system for organizing GFPs by their nature or intent. They are: Core Proposal, Ecosystem Fund Allocation Proposal (a subcategory of Core Proposal), Brand Decision Proposal (a subcategory of Core Proposal), Principles Proposal (a subcategory of Core Proposal), Process Proposal, and Informational Proposal.
  • Core Proposal - a proposal that would be considered the main activities of the GUARD DAO, with subcategories that can be expanded on over time via proposal submission.
  • Ecosystem Fund Allocation Proposal - a proposal about how the Ecosystem Fund should be spent. A subcategory of Core Proposals.
  • Brand Decision Proposal - a proposal about to whom the community wants to attach its name. This is different from an Ecosystem Fund Allocation Proposal in that it can have associated costs to implement but is not at its core a proposal about Ecosystem Fund Allocation. A subcategory of Core Proposals.
  • Process Proposal - a proposal about making a change to a process or proposing an implementation. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment of the GUARD DAO ecosystem or Foundation.
  • Principles Proposal – a proposal for establishing and/or updating the major principles behind the distribution of the GUARD Token and fees, including, but not limited to, staking, tokenomics and budget rules. A subcategory of Core Proposals.
  • Informational Proposal - a proposal that provides general guidelines or information to the community but does not propose a new feature.
  • Resubmission Proposal - a proposal that was previously submitted but did not pass either due to initial rejection by moderators or the Council, or by not passing a vote. All proposal categories have a special template for resubmission that the Author must link to the original proposal, clearly state why it did not pass, and clearly explain how the resubmission is different.
  • GFP Moderation - the act of reviewing a GFP to determine whether or not the GFP Draft meets the predetermined and GUARD DAO approved guidelines and therefore is eligible to move to the next step in the process. If a GFP passes GFP Moderation, it becomes a Pending GFP.
  • Pending GFP - the GFP status after it passes GFP Moderation.
  • Post-Moderation Tagging - the process of tagging all Pending GFPs that have successfully made it through the GFP Moderation phases. There are two tags given at this stage: 1. “Approved to Vote,” which is for any pending GFP where costs, content, and implications are considered to be straightforward and of no risk to the well-being of the GUARD DAO. 2. “Needs Administrative Review,” which is for any pending GFP with costs, content, or implications that are considered to be complicated or a potential risk to the well-being of the GUARD DAO and therefore must be reviewed by the Council of the GUARD DAO.
  • Administrative Review - the process of evaluating pending GFPs that have been tagged as “Needs Administrative Review” to determine whether they should be halted or sent to vote by the community.
  • Return for Clarification - a type of administrative classification that requires the GFP Author to clarify certain information regarding the Pending GFP. This classification would be given in cases such as cost to implement being unclear, proposing to utilize a larger percentage of the Ecosystem Fund than is justified based on the value it would provide to the community, or being in direct conflict with an active GFP.
  • Return for Reconstruction - a type of administrative classification that requires the proposer to restart the proposal submission process because the Pending GFP violates GUARD DAO-approved requirements, or in cases of violation of the law, reasonable suspicion of fraud or other misleading information, or the pending GFP being at odds with the mission, values, or well-being of the Foundation or GUARD DAO.
  • Weekly GFP Release - every Thursday at 9PM ET, when all GFPs that are ready to go live are released together in a batch.
  • Weekly Voting Close - when all GFPs in a Weekly GFP Release batch close for voting, which happens the following Wednesday at 9PM ET.
  • Live GFP - a GFP that has passed all required approval stages and is launched for the community to vote on it.
  • Final GFP - a GFP that has completed the voting process. There are two subcategories here: Accepted and Rejected.
  • Accepted Final GFP - a GFP that has met quorum requirements and received more than 50% of votes in favor of that GFP.
  • Implementation of Accepted Final GFP - the process of implementing a GFP that has been accepted by the community via a vote, based on the predetermined steps laid out in the GFP Draft/Template phases.

THE PROCESS

Phase 1: GFP Idea

  • A GFP Idea is submitted as an idea via Discourse (forum.guardfdn.com) and must receive confirmation from the Council Members to ensure it complies with GUARD DAO-approved guidelines before it appears to the community.

  • A minimum of 100 GUARD Tokens is required to engage as an GFP Author.

  • Pursuant to approval, Council Members will tag the GFP Idea with the appropriate proposal category and make the post viewable to the public.

  • The person or people submitting the GFP Idea will be referred to as the “Author” or “Authors”.

  • Multiple members can work together on an GFP Idea, but it should be submitted only once.

  • The GFP Idea informally gathers upvotes and/or comments via Discourse interface over a seven (7) day period.

  • A minimum of one (1) GUARD Token is required to engage as a GFP commenter.

  • At the end of the seven day cycle, the pending GFP Ideas will be categorized as “Approved to Vote” or “Needs Administrative Review”.

  • Pending GFP Ideas flagged for Administrative Review must be reviewed by the Council and sub-categorized as “Not Planned,” “Return for Clarification,” “Return for Reconstruction,” or “Approved”.

Phase 2: GFP Draft

  • Once the seven-day feedback cycle has concluded, the GFP Idea will be archived. Pursuant to approval, a moderator will provide the eligible GFP Author with the appropriate template to submit to the DAO Administrator as a formal Snapshot proposal.
  • A proposal typically includes:
    • Abstract - Two or three sentences that summarize the proposal.
    • Motivation - A statement on why the GUARD Community should implement the proposal.
    • Rationale - An explanation of how the proposal aligns with the GUARD Community’s mission and guiding values. Consideration of second, third and subsequent order consequences.
    • Key Terms (optional) - Definitions of any terms within the proposal that are unique to the proposal, new to the GUARD Community, and/or industry-specific.
    • Specifications - A detailed breakdown of the platforms and technologies that will be used.
    • Steps to Implement - The steps to implement the proposal, including associated costs, manpower, any legal documentation (if applicable) and other resources for each step where applicable.
    • Timeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.
    • Overall Cost - The total cost to implement the proposal.
  • The Author will fill out the template based on the original GFP Idea, incorporating any feedback provided by the community that helps the idea better serve the GUARD DAO, including, but not limited to, lack of specificity in the proposal.
  • The Author can add additional fields to the template if necessary to fully communicate the intentions, specifics, and implications of the GFP Draft.
  • Proposals that did not make it through the initial Snapshot governance process and are being resubmitted should also include:
    • Link to original proposal
    • Reason it was not approved
    • Changes that have been made and why it should now be approved
  • Category options:
    • Core: Ecosystem Fund Allocation
    • Core: Ecosystem Fund Allocation (Resubmission)
    • Core: Brand Decision
    • Core: Brand Decision (Resubmission)
    • Core: Principles
    • Core: Principles (Resubmission)
    • Process
    • Process (Resubmission)
    • Informational
    • Informational (Resubmission)
  • The Council Members may then continue communication with the Author to inform them of any incorrect or missing information that needs to be changed—or clarifications that need to be made—in order for the GFP Draft to comply with the GUARD DAO-approved guidelines and move to the next step.
  • If the Author does not respond to a moderator’s request to change, update, or make clarifications on the GFP Draft within seven (7) days, the GFP Draft will be automatically rejected as having failed to comply with the GUARD DAO-approved guidelines.
  • When the Council Members confirms that a GFP Draft complies with the GUARD DAO-approved guidelines, they assign a number to the GFP for identification purposes throughout the rest of the process. From this point on, the GFP is referred to as “GFP-#: (Name) - (Category)”.

Phase 3: GFP Moderation

  • The GFP is reviewed by the Council Members, and will either be approved or not approved based on whether it adheres to the DAO-approved guidelines.
  • If an GFP is approved as complying with DAO-approved guidelines, it becomes a Pending GFP.
  • If an GFP fails to comply with DAO-approved guidelines, it is eligible for resubmission unless in cases of violation of the law or reasonable suspicion of fraud or other misleading information.

Phase 4: Post-Moderation Tagging

  • Pending GFPs that have passed GFP Moderation will then either be tagged as “Approved to Vote” or “Needs Administrative Review” as each term is defined and described in this Proposal.
  • The “Approved to Vote” tag is given for any pending GFP whose costs, content, and implications are considered to be straightforward and of no risk to the well-being of the GUARD DAO.
  • The “Needs Administrative Review” tag is given for any pending GFP whose costs, content, or implications are considered to be complicated or a potential risk to the well-being of the GUARD DAO. Any Pending GFP that is tagged as “Needs Administrative Review” must go through Phase 5.

Phase 5: Administrative Review

  • This phase is only for Pending GFPs that have been tagged with “Needs Administrative Review.”
  • When this happens, the Council, serving in an administrative capacity, will determine whether further action is required prior to a Pending GFP proceeding to Phase 6.
  • Pending GFPs that the Council determines do not require additional action will be tagged as “Approved to Vote” and proceed to Phase 6.
  • If the Council decides to return a Pending GFP for further clarification or action, they must provide a clear explanation of why and tag it as either “Return for Reconstruction” or “Return for Clarification.”
  • Reasons to tag as “Return for Reconstruction” or “Return for Clarification” may include but are not limited to:
    • Cost to implement unclear/not able to be calculated (tagged as “Return for Clarification”)
    • Proposes to use more than 5% of the Ecosystem Fund (tagged as “Return for Clarification”)
    • Conflicts with another proposal (tagged as “Return for Clarification”)
    • Proposal is at odds with the mission/values of the GUARD DAO (tagged as “Return for Reconstruction”)
    • Proposal is at odds with the well-being of the GUARD DAO (tagged as “Return for Reconstruction”)
    • Violations of law, or against advice of counsel for the Foundation (tagged as “Return for Reconstruction”)
    • Reasonable suspicion of fraud or other misleading information (tagged as “Return for Reconstruction”)

Phase 6: Live GFP

  • Drafts that have passed their respective approval processes will become a Live GFP on Snapshot (Snapshot) during the next Weekly GFP Release, which is when new GFPs are released in batches every Thursday at 9PM ET.

  • DAO Administrators are the only ones that can post GFPs to Snapshot because they must ensure that each one has gone through the correct approvals process.

  • All GFPs released to vote will undergo a 24hr delayed “warm-up phase,” in which the GFP is submitted to Snapshot for public view, but is not yet committed to the blockchain or eligible for voting. This affords the Author, Council and/or Admin a supervisory window to correct any errata before the proposal details are rendered immutable. The warm-up phase only provisions for typographical or numerical errors and not for significant changes to the GFP content itself.

  • Once live on Snapshot, Live GFPs are open to voting until Weekly Voting Close, which is when all Live GFPs from a given batch close for voting at 9PM ET on the Wednesday following their release.

  • The voting options are “In favor,” “Against,” and “Abstain.” Voting “In favor” means the voter is in favor of implementing the GFP exactly as-is. Voting “Against” means the vote is against implementing the GFP exactly as-is — voters may vote “Against” to encourage the Author to resubmit the GFP after making changes. Voting “Abstain” means the votes are counted towards quorum but are neither “In Favor” or “Against” of implementing the GFP.

  • The quorum requirement for a Live GFP will be 10% of the circulating supply of GUARD Tokens. Once quorum has been met, a Live GFP may only be passed with greater than 50% of votes cast “In favor”. A Live GFP which has not received greater than 50% of votes cast “In favor” will not be passed. A Live GFP which has met quorum and achieved greater than 50% of votes cast “In favor” will be deemed an Accepted Final GFP.

Phase 7: Final GFP

  • If by the Vote Close Time the Live GFP has not received any votes or is tied, it will be tagged as “Stalled” and be eligible for Resubmission.
  • In all other cases, after the Vote Close Time, Live GFPs are moved to Final GFPs.
  • There are two subcategories for the Final GFP status: accepted and rejected.
  • Rejected Final GFPs will have the chance to be resubmitted via the appropriate Resubmission Template if the Author contacts a moderator to initiate this process.
  • Accepted Final GFPs will move into implementation.

Phase 8: Implementation

  • For Accepted Final GFPs, implementation will begin based on the steps outlined in the GFP template.
  • The project management team engaged by the Foundation is responsible for making sure this happens, but is not necessarily responsible for doing it themselves.
  • The GFP implementation is administered by the Foundation. Implementation may be immaterially or materially altered to optimize for security, usability, to protect GUARD holders, and otherwise to effect the intent of the GFP. Any material deviations from an GFP, as initially approved, will be disclosed to the GUARD Tokenholders.

SPECIFICATIONS

  • GUARD DAO Hub: The Foundation website (guardfdn.com), which will provide an interface to educate GUARD DAO members on the governance process and provide easy access to the channels described below in order to streamline the GUARD DAO’s operation and enhance its utility.

  • Communication Channel: Discourse - forum.guardfdn.com (Phase 1)

    • GUARD Tokenholders must go through a wallet authentication process to post ideas or give feedback to ideas via comments.
    • GFP Idea posts must be approved by a moderator to ensure they meet all predetermined guidelines and template requirements.
    • All posts and comments will be regularly monitored by both a team of moderators & administrators engaged by the Foundation and by the Community themselves. There will be zero tolerance for hate speech anywhere on this platform.
    • The Author of an idea via a post in forum.guardfdn.com cannot edit the original post. If the Author wants to propose changes to the original idea, the Author must do this via the comments.
    • Seven (7) days after it has been posted, GFP Ideas are closed to community feedback and will be locked by a moderator or the Council Members.

  • Process for Draft Submission via Template: (Phase 2)

    • Once an idea is approved in forum.guardfdn.com after the seven-day community feedback cycle, a moderator will contact the Author to provide the appropriate template.
    • The Author should then submit an official GFP Draft to the Council Members using the template.
    • The Council Members may then continue communication with the Author to inform them of any incorrect or missing information that needs to be changed—or clarifications that need to be made— for the GFP Draft to move to the next step.
    • If the Author does not respond to Council Members’ request to change, update, or make clarifications on the GFP Draft within seven (7) days, the GFP Draft will be automatically rejected.

  • Platform where Live GFPs are Hosted: Snapshot - Snapshot (Phase 6)

    • GUARD Tokenholders must go through a wallet authentication process to vote on Snapshot.
    • Council Members are the only ones allowed to launch GFPs on Snapshot as they must ensure each GFP has gone through the correct approval process.
    • The voting mechanics shall be:
      • New proposals that meet the required guidelines will be launched in batches every Thursday at 9PM ET.

  • User balance of GUARD Tokens will be referenced by block height at proposal launch.

  • There will be a 24 hour “warm-up” period in order to allow a final review period for any superficial errors, as well as to encourage maximum voter engagement.

  • The voting options for a Live GFP are “In favor”, “Against”, and “Abstain”. Voting “In favor” means the voter is in favor of implementing the GFP exactly as-is. Voting “Against” means the vote is against implementing the GFP exactly as-is – one may vote “Against” to encourage the Author to resubmit the GFP after making changes. Voting to “Abstain” means the vote is neither In Favor nor Against implementing the GFP, but the vote weight still will be counted towards quorum.

  • The voting for each proposal in each weekly batch will be open for voting for five (5) days, closing at 9PM ET on the following Wednesday.

  • A vote must reach greater than 50% of votes cast “In favor” in order to pass.

  • Furthermore, a vote must meet a quorum of 10% of circulating GUARD Token supply, to be determined at current block height when vote is initiated.

  • Proposals that are approved by the GUARD Tokenholders of the requisite number of GUARD Tokens are moved to the Foundation for implementation.

6 Likes