Constitution of the Superfluid DAO

Governance
1

Superfluid DAO Constitution

January 2025

This document lays out the Constitution of the SuperfluidDAO.

Some of the rules and procedures of this Constitution will be enforced directly by smart contracts on a blockchain, and some will not. All rules are equally binding. Actions taken under this Constitution may be on-chain or off-chain actions. On-chain actions are those that are actuated directly by the governance smart contracts of the SuperfluidDAO as transactions on a blockchain. Off-chain actions are those that are actuated by other means.

This Constitution also includes some “recommended guidelines” which are non-binding but strongly recommended as good governance practice.

This Constitution describes the procedures by which it may be amended and lays out the governance framework of the SuperfluidDAO and The Superfluid Foundation.

Definitions:

  • SIP: A Superfluid Improvement Proposal
  • Constitution: This constitution of the SuperfluidDAO (as may be amended from time to time).
  • DAO Treasury: All SUP tokens held in a governance smart contract governed directly by the SuperfluidDAO and/or the Security Council of The Superfluid Foundation via on-chain or off chain voting mechanisms.
  • Foundation Articles: The Amended and Restated Memorandum and Articles of Association of The Superfluid Foundation (as may be amended from time to time)
  • Foundation Bylaws: The bylaws of The Superfluid Foundation (as may be amended from time to time).
  • Supported Deployment: Official support for operations and maintenance of the Superfluid Protocol provided on a designated chain by the DAO.
  • Votable Tokens: SUP tokens which have been allocated or distributed to individuals (such as ecosystem users, investors, team etc) and SUP tokens held by 3rd parties post any SUP token transferability event in the future, but excluding the following:
    1. SUP tokens held by The Superfluid Foundation Treasury or the SuperfluidDAO treasury, which SUP tokens have not been allocated or distributed to individual recipients; or
    2. SUP tokens held in trust without explicit consent to vote on a user’s behalf (e.g., such as SUP tokens held by centralized exchanges).

Section 1: Protocol "ownership"​

This Constitution describes the decision-making framework for the SuperfluidDAO governance. Once the SUP token generation event and subsequent creation of the SuperfluidDAO have occurred, “owner” privileges on the Superfluid Protocol would be given to both the SuperfluidDAO and the Security Council of The Superfluid Foundation.

Section 2: DAO Proposals and Voting Procedures (SIP Process)

  1. The following process governs the rules and procedures by which the SuperfluidDAO may propose, vote on and implement SIPs. No SIP may be in violation of applicable laws, in particular sanctions-related regulations.
  2. SIP call for voting (lasting 7 days): The SIP is submitted for discussion on Discourse (or other designated discussion forum) with a link to voting for the SIP in Snapshot (or other designated voting system). Each SIP must be labeled as Constitutional or non-Constitutional.
  3. A Constitutional SIP is a SIP that:
    • Process: Modifies the text or procedures of this Constitution and, so long as The Superfluid Foundation exists, the Foundation Articles and the Foundation Bylaws.
    • Superfluid Protocol Upgrade: Installs or modifies software of the Superfluid Protocol or the SUP token on any chain.
    • New chain Supported Deployment: Supports the operations and maintenance of the Superfluid Protocol on a new chain.
  4. Non-Constitutional SIP is a SIP that is not a “Constitutional SIP”, including:
    • Funding: Requests funds or grants or otherwise propose how to spend or allocate funds from the SuperfluidDAO treasury and, so long as The Superfluid Foundation exists, the Administrative Budget Wallet (as defined in the Foundation Bylaws).
    • Informational: Provides general guidelines or information to the community but does not otherwise propose a new feature or update.
  5. Recommended guideline: SuperfluidDAO members should vote against any SIP that is incorrectly labeled.
  6. Content: Each SIP as a recommended guideline, should include:
    • Abstract - Two or three sentences that summarize the SIP.
    • Type - specifying whether the SIP is Constitutional OR Non Constitutional
    • Motivation - A statement on why the Superfluid community should implement the SIP.
    • Rationale - An explanation of how the SIP aligns with the Superfluid community’s mission and guiding values.
    • Key Terms (optional) - Definitions of any terms within the proposal that are unique to the proposal, new to the Superfluid 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 SIP, including associated costs, manpower, and other resources for each step where applicable. For the avoidance of doubt, any SIPs involving transactions with third parties (such as grants) will need to ensure that applicable legal documentation and procedures are also included.
    • Timeline - Relevant timing details, including but not limited to start date, milestones, and completion dates.
    • Overall Cost - The total cost to implement the SIP.
  7. As a recommended guideline, the SIP author can add additional fields to any template if necessary to fully communicate the intentions, specifics and implications of the SIP.
  8. As a recommended guideline, resubmitted SIPs should also include:
    • A link to the original SIP;
    • Reasons such original SIP was not approved;
    • Changes that have been made and why it should now be approved; and
    • Any additional fields to any template if necessary to fully communicate the changes made and the intentions, specifics and implications of such resubmitted SIP.
  9. DAO votes on SIP, on Snapshot (lasting 14 days): A SIP passes if the below conditions are met:
    1. More Votable Tokens have casted votes “in favor” than have casted votes “against”; and
    2. In the case of a:
      1. Constitutional SIP, at least 5% of all Votable Tokens have casted votes either “in favor” or “abstain”; or
      2. Non-Constitutional SIP, at least 3% of all Votable Tokens have casted votes either “in favor” or “abstain”.
  10. The voting period ends 14 days after the start of voting. If the SIP fails to pass, the process ends. If the SIP passes, then:
    • If it is a Constitutional SIP, there is an additional 7 days waiting period before implementation.
    • If it is a Non-Constitutional SIP, there is an additional 3 day waiting period for actions related to the SuperfluidDAO treasury.

Section 3: The Security Council​

  1. The Security Council is a committee of 3 or 5 members who are signers of a multi-sig wallet, which has powers to perform certain Emergency Actions and Non-Emergency Actions (each as defined below), as delegated to it by the SuperfluidDAO and The Superfluid Foundation, and is responsible for upholding this Constitution.
  2. Through the submission, approval and implementation of a Constitutional SIP, the SuperfluidDAO is able to modify the Security Council’s powers or to eliminate the Security Council entirely.
  3. Equivalent “copies” of the Security Council multi-sig contracts exist, one on Ethereum and another on each chain where the Superfluid Protocol is deployed.
  4. Emergency Actions:
    1. The Security Council has the power to execute any software upgrade or perform other required actions with no delay in order to respond to a security emergency, should one arise (such actions, “Emergency Actions”).
    2. Performing any Emergency Action requires a simple majority of 2-of-3 or 3-of-5 (as the case maybe) approval from the Security Council.
    3. The Security Council must not use its power to perform Emergency Actions except in a true security emergency, such as a critical vulnerability that could significantly compromise the integrity, confidentiality, or availability of Superfluid Protocol on a chain which the SuperfluidDAO has Supported Deployment
    4. After performing any Emergency Action, the Security Council must issue a full transparency report (at an appropriate time after the security emergency has passed but in any case no longer than 7 days) to explain what was done and why such Emergency Action was justified.
    5. The SuperfluidDAO is able to curtail or eliminate the Security Council’s power to perform Emergency Actions via approval and implementation of a Constitutional SIP.
  5. Non-Emergency Actions
    1. The Security Council may also approve and implement routine software upgrades, routine maintenance and other parameter adjustments in a non-emergency setting (such actions, “Non-Emergency Actions”), which require a simple majority of 2-of-3 or 3-of-5 approval (as the case maybe) in order to take effect.
    2. Any Non-Emergency Action, after approval by the Security Council, may bypass steps of the SIP process to provide a delay before any Non-Emergency Action is deployed. The Security Council may optionally specify additional delays before deployment.
    3. The SuperfluidDAO is able to curtail or eliminate the Security Council’s power to perform Non-Emergency Actions via approval and implementation of a Constitutional SIP.

Section 4: Security Council Elections​

  1. The Security Council has 3 or 5 members
  2. The members of the initial Security Council are detailed in a transparency report here (link to be inserted when ready)
  3. The first Security Council election is scheduled to begin on the [6 months later- to be inserted] 2025 or the earliest possible date. The date chosen for the first election will form the basis for all future elections. Every election should begin 6 months after the previous election has started and it will replace its respective cohort of 3 or 5 members.
  4. All Security Council members are expected to serve their term until the election is complete and the new Security Council members are installed.
  5. The following timeline governs an election that starts at time T:
    1. Contender submission (T until T+7 days): Any DAO member may declare their candidacy for the Security Council
    2. Nominee selection (T+7 until T+14 days): Each DAO member or delegate may vote for their declared contender. Each token may be cast for one contender. To the extent that there are more than 3 contenders, each eligible contender must be supported by pledged votes representing at least 0.2% of all Votable Tokens.
    3. Compliance process (T+14 until T+28 days): All candidates will cooperate with The Superfluid Foundation and complete the compliance process. The Superfluid Foundation is responsible for removing any candidates that fail the compliance process. In the event that fewer than 3 candidates are supported by pledged votes representing at least 0.2% of all Votable Tokens, the current Security Council members whose seats are up for election may become candidates (as randomly selected out of their cohort) until there are 3 candidates.
    4. Member election (T+28 until T+49 days): Each DAO member or delegate may vote for any declared candidate. At T+49 days: The process for replacing the cohort of Security Council members with the 5 candidates who received the most votes will be activated. The installation process must be executed via the on-chain governance smart contracts and it may take several days until the new security council members are installed.
  6. The Superfluid Foundation is allocated 14 days for the compliance process and it should be executed between the nominee selection and member election. The Superfluid Foundation has flexibility to update its compliance policy for every new election. This is required to allow The Superfluid Foundation to comply with Cayman Island laws. Furthermore, The Superfluid Foundation maintains the right to issue new procedures and guidelines for off-chain components of the Security Council election. All efforts should be made by The Superfluid Foundation to ensure an orderly, fair, and transparent election.
  7. As a matter of best practice for maintaining an independent Security Council, no single organization should be overly represented in the Security Council. In particular, there should not be more than 2 candidates associated with a single entity or group of entities being elected to the Security Council,
  8. Furthermore, no candidate with conflicts of interest that would prevent them from acting in the best interests of the SuperfluidDAO or The Superfluid Foundation should be elected to the Security Council. Potential conflicts of interest could be, but are not limited to, affiliations with direct Superfluid competitors, proven histories of exploiting projects and others.
  9. The SuperfluidDAO may approve and implement a Constitutional SIP to change the rules governing future Security Council elections, but the SIP process may not be used to intervene in an ongoing election.
  10. Security Council members may only be removed prior to the end of their terms under two conditions:
    1. At least 10% of all Votable Tokens have cast votes either “in favor” of removal or “abstain”, and at least 5/6 (83.33%) of all casted votes are “in favor” of removal; OR
    2. At least 3 of the Security Council members vote in favor of removal.
  11. The seats of Security Council members who have been removed prior to the end of their respective terms shall remain unfilled until the next election that such seats are up for appointment, unless otherwise replaced prior to such next election by a vote of at least 3 of the Security Council members, in which case such seat shall be up for appointment at the next such election. The Security Council may not re-appoint a removed member and they can only be re-elected via the election voting system.

Section 5: DAO Wallet

  1. The SuperfluidDAO shall have a multisig wallet for onchain execution of transactions approved by the SuperfluidDAO (DAO Wallet), relating to Non Constitutional SIPs, such as SIPs related to allocation and spending of SuperfluidDAO treasury funds.
  2. Until the SuperfluidDAO wallet is configured, the Foundation can execute these transactions onchain as voted for by the SuperfluidDAO.
1 Like