Governance Charter v1.0

Governance Charter v1.0

Ratified: 2022-04-01T04:00:00Z
Proposal Link: Proposal to Ratify Governance Charter v1.0

How to Use the Governance Charter

The Governance Charter creates a set of default processes and structures for the Orca ecosystem. These agreements are intended to provide a template for decision making as minimum viable structures. If these agreements do not work for a given pod, the pod can choose to ratify a different set of agreements to govern themselves (so long as those agreements adhere to the principles of the organization).

Governance Principles

Principle of Pods

Pods are the atomic unit of the organization. Each pod has a set aim and domain, rules for engagement, and participation roles.

Principle of Consent

Pods make decisions using consent, where consent is defined as agreement that a proposal is safe to try and good enough for now. For a proposal to pass, it needs consent from members of all relevant pods.

Note: “relevant pods” refers to pods whose domain the decision falls within.

Principle of ‘Good Enough for Now’ and ‘Safe to Try’

The criteria to consent to any given proposal are “is this good enough for now?” and “is this safe to try?” Objections to a decision mean that a decision has harmful consequences with significant downside in its current state. See Gathering Consent for overview of process.

Principle of Transparency

Unless there are clear, unmitigatable downsides to doing so, records of decisions made and actions taken should be accessible to all Orcanauts to allow for learning, review, and improvement.

General Frameworks for Pods

Aims and Domains

Every pod must have an aim and domain.

Aim is defined as what the pod does; domain is defined as what the pod is responsible for and has authority over.

Forming Pods

All pods are created by or with the affirmation of one or more parent pods that house the larger domain a given pod sits within.

New pods are created through Pod Ratification Proposals and require the consent of the relevant parent pod (relevant meaning that the new pod’s domain is a subsection of the “parent” pod’s domain). See Template for Pod Ratification Proposals .

Adjourning Pods

Each pod has a duration (outlined in the pod’s Pod Ratification Proposal) which is not to exceed 12 months. At the end of a given pod’s duration, the pod can either be reinstated or adjourned. Both the duration of a pod and the decision process for reinstating or adjourning a given pod is outlined in the Pod Ratification Proposal.

A member of a parent pod or a member of the pod itself can create a proposal to adjourn a pod prior to the end of a pod’s duration.

On-chain and Off-chain Pods

On-chain pods are created when a group or initiative requires a multi-sig or membership represented on-chain via NFTs. Initiatives that do not require a multi-sig or on-chain membership are called off-chain pods. This distinction is made in the Pod Ratification Proposal and off-chain pods can become on-chain pods using a standard pod-level proposal (does not require another Pod Ratification Proposal).

All principles, general frameworks, roles, and decision-making processes outlined in this document apply to both off-chain and on-chain pods.

Pod Membership

Note: the term “Orcanauts” refers to individuals who are members of on-chain or off-chain pods (or both) and membership frameworks apply to both on-chain and off-chain pods.

Adding Pod Members

Members are added to pods by consent of existing pod members. Pod Lead is responsible for minting membership, assuming consent is given to do so.

Adjourning Pod Membership

Inactivity

Pod Leads are responsible for developing a monthly cadence to renew pod membership for active pod members and burn membership for inactive members. Level of activity required to retain membership is up to the pod’s discretion.

Voluntary Exit

A member can choose to adjourn pod membership by beginning the offboarding process, whereby the pod member shares their intent to adjourn membership and completes the offboarding process (decided at a pod-specific level).

Involuntary Exit

Any member of a pod can anonymously trigger the member review process by creating a proposal and using the Gathering Consent process, which the Pod Lead is responsible for facilitating (if the Pod Lead is the member being reviewed, the pod nominates another member to steward). The process must be completed within 30 days of initial proposal creation and the member being reviewed has the right to participate in the Review and React section of the process, but does not have objection rights in the Consent or Object process.

Gathering Consent

The consent process is made up of two key steps (loosely following this format ):

Review and React

  1. Present proposal and ask clarifying questions with presenter asking “is there anything you don’t understand about the proposal as is?” and “is it clear how this proposal moves us closer to Orca Protocol’s aim and mission?”
  2. Quick reactions round allowing pod members to share honest reactions to “how do you feel about the proposal?”; proposer does not directly respond or defend to reactions

After this step, the proposer is encouraged to modify the proposal based on clarifying questions and quick reactions.

Consent or Object

  1. Consent round involves each pod member being asked “do you consent/object?”; if each pod member responds “I consent”, the proposal passes (members of all relevant pods must consent) See Principle of Consent and Principle of ‘Good Enough for Now’ and ‘Safe to Try’’
  2. Resolve Objections if pod member(s) have objections, each should be handled one at a time; there are four pathways to resolve an objection (pick the most promising option and repeat until resolved):
  3. Member(s) who object are responsible for suggesting amendments and collaborating with proposer(s) to make the proposal safe to try and good enough for now
  4. Group has timeboxed discussion to explore how the objection(s) may be resolved
  5. Proposers re-work the proposal with significant revisions, potentially bringing in different members to collaborate
  6. Abandon the proposal altogether
  7. Repeat consent round and repeat resolution steps as needed

Pod Member Roles

All roles are selected by the members of a pod using the consent-based role selection process outlined here . All active pod members hold the “Member” role. It is recommended that each non Member role be filled by separate Members. This is especially true of Lead and Delegate roles. However, any member may fill more than one role, and roles may be combined as necessary.

Social Roles

  1. Lead keeps the heart of the pod beating ‒ helping track work to be done, help members of a pod stay accountable for responsibilities, and ensure tasks required for the group are properly accounted for. Responsible for ensuring pod’s aim and domain is a reflection of the work the pod is doing (and what is needed). Pod Lead is also responsible for upkeep of pod membership, including stewarding processes for adding new pod members and adjourning membership (outlined in General Frameworks for Pods).
  2. Facilitator sets the agenda for pod meetings, runs pod meetings, and is responsible for stewarding the Gathering Consent process (outlined in General Frameworks for Pods).
  3. Secretary creates meeting notes, ensures proposals and other important content is distributed throughout the pod.
  4. Delegate is a pod member who is also a member of the parent pod (or subpod). Responsible for facilitating communication between the pod and the parent pod and representing pod interests in the parent pod.
  5. Members are active contributors to a pod, responsible for attending meetings, staying up-to-date on tasks and pod-wide initiatives, and collaborating with other pod members to fulfill the purpose of the pod. Members have the right to object in consent-based governance.

Technical Roles

(apply to on-chain pods only)

  1. Members make up pods, have the ability to introduce proposals, hold an ERC-1155 representing their membership, and are able to manage assets. Overview of technical implementation here .
  2. Pod Admin has the ability to add or remove members of a pod. The Pod Admin can be an individual, a smart contract, or another pod. By default, the Pod Admin of a pod is the parent pod (i.e., the pod whose consent was required for the creation of the pod). If a pod chooses to elect an individual as Pod Admin, the Pod Lead is the default holder of the Pod Admin role. Overview of technical implementation here.

Note: if the Pod Admin is not an individual, a smart contract, or another pod, minting and burning memberships is a responsibility of all pod members.

Decision-making

Proposals

Proposals are used to initiate decisions where consent is required (can be at a pod or DAO-wide level). See When Consent is Required for types of decisions that require consent.

Proposals are intended to be brief and modular (should not be longer than two pages). Pods may create a standard proposal format, or leave it up to the proposer’s discretion. Regardless of the format, proposals all follow the Gathering Consent Process.

See Template for Orcanaut Proposals .

When Consent is Required

The type of decision that requires consent is a “policy” decision. Decisions that do not require consent are “operational” decisions.

Policy decisions are general rules, frameworks, or policies that have ongoing implications (role creation and election, meeting cadence, workflows, compensation decisions, etc). These decisions require consent from members of relevant pods.

Operational decisions are operations and tasks, often where the decision applies once (not on-going). Operational decisions are made by individuals who have the role or responsibility to act within a given domain. These decisions do not require consent.

It is up to the discretion of pod members to find the balance between operational and policy decisions. For a full overview and examples of operational decisions and policy decisions, see this article .

How to Change the Governance Charter

General Process

Amendments to this Charter can be proposed at any time by any active member of an Orcanaut pod or Sonar Labs. Amendments must be applicable for DAO-wide agreements or general pod structures (i.e., no edge cases or specific agreements that do not apply to most pods – these amendments should be made at the pod level).

The process for making amendments uses the basic proposal format outlined in Decision-making and follows the Gathering Consent process outlined in the General Frameworks for Pods section. Consent from all pods is required.

Review Process

To facilitate constant evolution, this Governance Charter will have 3 month review cycles. A review cycle consists of:

  1. Discussion to surface anything that is not working or needs to be updated
  2. Proposals to amend the Charter using standard Gathering Consent process (not monolithic – each amendment should have an independent proposal)

Review of v1.0 of the Governance Charter is planned for the week of June 20th, 2022.

6 Likes