Proposal to Ratify Governance Charter v1.0

Reminder: objections mean you believe this proposal is not safe to try or good enough for now. This would mean enacting this proposal results in irreversible or significant consequences.

Consent Required

  • All Orcanauts
  • All Sonar Labs

By 11:59pm UTC on Monday, March 28th, please:

Consent by replying “I consent” to the post (using Discourse’s reply feature). Consenting to this Governance Charter means that you consent to adopting v1.0 of the Governance Charter (as written below) as the set of default processes and structures.

Object by replying “I object” with specific objections and suggested edit(s) that would make the Governance Charter safe to try and good enough for now (using Discourse’s reply feature).

A note on consent

Given that the number of people required to consent to this Charter is large, I propose that those who do not engage in consenting or objecting will be assumed to consent. This is effectively lazy consensus. While silence is not considered consent generally, I believe the number of people involved in this Charter warrants an assumption of consent.

In the future, it is possible that the Governance Charter will be stewarded by a pod (with members who have consent to modify and maintain the Charter), rather than requiring everyone’s consent for individual changes. This would require an independent proposal and consent from all pods.

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


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.



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.


I consent

I object!

I do so on two explicit points.

1. Pod duration maximum was elided from prior version with no explanation as to why.

Even outside of the Cryptoverse organizations do stale for not being up to date with the what and why of their aim and purpose. Durations exist not only for functional aims and purpose reasons, but to ensure that organizational aim and purpose are as relevant over time as much as at inception.

For a contemporary business organization, I would set that max duration at 4 years. Things move so fast in the Cryptoverse, I believe that max duaration should probably be 1 year. On thinking that others would likely deem this too short the explicit proposal made was for a 2 year max duration.

I am reluctant to let this be dropped or changed, without explicit and clear reasons for it. To me it is important enough to build in at the start, and not wait for circumstances to make it clear that a long running Pod needs to explicitly reassess itself. To that end I also propose that language expressing this point also be included in an amendment to this issue, similar to what was in the earlier version of the proposal.

2. I disagree with Member Steward being separated from the Pod Lead role

In my mind all functions of the Member Steward role were a part of Pod Leadership. Without explanation, I see no reason to add the complexity of another explicit role whose function would overlap so closely with what would most naturally be a part of Pod Leadership.

From the defintion of ‘Leader’ above:

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.

The leader would already have the most information to know and understand other members levels of participation and to maintain cadence of Pod renewal. The leader should be in touch with Members as they enter and depart Pods.

Except for the technical role of Pod Admin, I can’t even imagine why Membership Steward was created; possibly to have a title for off-chain Pods with a similar function? However, and maybe it is just me, the new role confuses rather than helps me understand, maybe because of my knowledge of the technical Pod Admin position.

In my view, unless a Pod is choosing to use a contract, their own vote, or that of a superior Pod, I am inclined to suggest that the Leader should be required to be Pod Admin unless there are good reasons to the contrary. This forces a certain amount of awareness on leaders to the entrance and exit of Pod members to the Pod which would hopefully be there anyways.

Point of difference

I have been willing to allow this issue to pass under Principle of Consent, however …

Sociocracy has very good reasons for separating the Leader and Delegate roles in its governance system. I personally think that the sentence, “Any member may fill more than one role, and roles may be combined,” should be elided.

I also strongly feel, but not enough to stop progress, that it should be explicitly stated that the Leader and Delegate must be held by different Members.

In addition I think it should be explicit that without documented extenuating circumstances, there should be at least three members in a Pod before it is created. Although I can imagine real reasons to start smaller Pods, I think it is best if those reasons be made explicit.

If this becomes the standard, then in those circumstances there should generally not be a need for an overlap of roles besides the Member role. From that it should be recommended that it is best if all non-Member roles are held by separate Members.

I have felt this way for sometime, but did not think it important enough to slow progress. Having to object to the current proposal, I bring it up to others for consideration.

I consent!

This is a great document that will support the governance foundation of Sonar Labs and the Orcanauts for a long while. Thanks to everyone who was involved and @chase especially for being our guide here.

@aia - also thank you for the thoughtful comments above and moving on the Principle of Consent. I’d love to chat some more about your objections in a different post/medium.

1 Like

I object
With a little suggestion to add some “mediation roles” to the Lead in the Social Roles aiming to balance the contribution of every member, giving voice and space in the discussions to newcommers and people with more descrete caracters (maybe through some speaking time per person or other techniques).
Unfortunately I don’t feel enough confident with my english to write a “suggested edit”.
also wanted to share my gratitude with @chase for the work being done since now. Governance Charter are so important to lay healthy foundation in democratic participation!


Hey Dan!,

I just heard you on the Twitter talking about the importance of communicating the “Why” of decisions as a part of governance.

If you read my 1st objection closely, you could see that it was about the change happening with no explanation as to why, as much as any thing else.

This forum is the best forum, pun intended, for this discussion following the Principal of Transparency. At least until you communicate a “Why” that explains why not being in dialogue on the best organizational memory tool that Sonar Labs is is sharing with Orcanauts really doesn’t make sense.

1 Like

I love that you have taken the time to participate even as a Cadet.

I personally think Cadets should be living from the perspective of I am a full Orcanaut. Even as they recognize that their votes are only informational until they are part of an explicit Pod, or formally an Orcanaut.

I appreciate you!

1 Like

I object. I agree with the points @aia made in post 3 and those need to be addressed before we move forward. As I will be away when this is likely to be addressed, I’ll unofficially delegate to aia on my consent - consider my objection withdrawn when aia’s objection is withdrawn.


Wow! :exploding_head:

I am truly honored @Appt_Pupil, I have such massive respect for your clear experience as an intelligent and compassionate leader.

Enjoy your R&R!

P.S. @chase, in the position of proxy, I feel responsible for making sure we have discussion over my objections, so that a clear record is left as to why certain choices are being made. I know that is more work for you, but it seems like the only “right” thing to do from my perspective.

1 Like

Thank you for this thoughtful response! I appreciate you articulating your points of objection.

I understand why having no limit on pod durations could make the proposal not safe to try.

Since @zkchun and @itsdanwu are the only two people who have consented to the proposal as it stands, I propose we simply make this edit directly (rather than adding it as a conditional amendment for your consent ‒ as this would require another round of consent involving everyone) and assume that Dan and Chun consent (and if that is not the case, Dan and Chun, please express your objections).

Given the fast-moving pace of the industry and the fact that both you and @julz suggested that 1 year would be favorable, I’ll go ahead and make an edit stating that the maximum duration for a pod is 1 year.

I do want to clarify that I provided reasoning for removing the pod duration in the Google document. I know a Google Doc is not the best place to have these types of in-depth discussions and certainly does not make these types of things easy to track. In any case, clarity around changes (and the “why” behind them) is definitely something we can work to improve in the future.

Note: based on the Community Call discussion, this objection is now closed and @aia has now granted consent on the Membership Steward role.

I really appreciated our conversation in the Community Call discussing this concern (recording here, discussion about this objection around 29:00).

For those who were not able to attend (and in an effort to memorialize the “why” in an open forum), the Membership Steward role was added to ensure someone holds responsibility for processes around Pod Membership (including responsibility for facilitating the Involuntary Exit).

Separating the role of someone who helps steward membership processes and someone who holds the responsibilities of a Lead is very intentional, particularly to ensure power is not centralized into an individual person’s role without the consent of pod members. This does not mean that one individual cannot do both ‒ but the pod members must consent to each of these roles being delegated to that individual. This is a pattern borrowed from sociocracy.

Based on our conversation in the Community Call, it feels like the Charter could benefit from more clarity around this role. To add clarity, I’d like to change:


Since this does not change the role, but instead clarifies it, I’ll add this directly (rather than as an amendment).



This records changes made directly to the post. Original post is documented here.

Add pod duration limit of 12 months

Justification: Objection from @aia


Clarify Membership Steward role

Justification: Point of clarification raised by @aia


Merge Membership Steward responsibilities into Pod Lead role

Justification: Objection raised by @aia


Clarify Pod Admin delegation defaults

Justification: Objection raised by @aia


Clarify role combination guidelines

Justification: Objection raised by @aia


I am happy to hear you tried to communicate via Google Docs. I see no evidence of it now, but can believe it was there. Clearly Google Docs is not the best tool for getting notifications out to others about such changes. And, I think you yourself found the comments there less than ideal to use. Nav-naut has other tools in mind to recommend as the primary documentation tool, hopefully they will do these things better.

If I had known, you would have received immediate feedback from me in less than 24 hours.

I think 1 year is a fine max time, and because it is clear to me that not everyone even trys to think deeply about these kinds of things I think having a reasonable max is a very good idea.

The fact of the matter is that modern high tech start ups are taught to do this kind of reevaluation at least this frequently, if not more as they pivot to achieve product market fit. It is also clear that from not doing it, or creating an organization able to truly be responsive that some large successful companies became much less relevant, or actually failed for lack of this kind of reassessment. Since the Cryptoverse is currently changing so fast, I think this kind of reassessment at least annually should probably be happening for all organizations in it, even if only by a group chosen for that purpose. In our case, Pods are small enough and the time required by active participants minimal enough that I think it is a good exercise for all Pods to participate annually as well.

With the consent of @zkchun and @itsdanwu I am happy to accept your method of making the change to the proposal.

I am also curious if you have actual reasoning behind not wanting a max time other than feeling confident that it would be addressed well in Pod ratification proposals. If so, you have more faith in people thinking deeply about these things than I do, or place a different value on the need for a Pod, or any organization, to do this self evaluation process. I am curious to understand your position better.

Thank you for your reply, and straightforward acquiescence to this issue. From the presumably Google Doc comments you posted, it looks like I was not the only one who thought going through an explicit aim and mission reevaluation was a good thing for all Pods to do regularly.

1 Like

With respect to the objection to Member Steward my response is the following.

I accept this change as stated, including the manner of making, barring absence of consent from @zkchun and @itsdanwu. Howeer, with the reasoning you are using of trying to follow Sociocracy, I am going to move my Point of Difference above to a formal objection.

If following Sociocracy is being explicitly used as a reason to add complexity and possible confusion to the number of Roles formally required in a Pod, than I can not accept the following statement that starts the Pod Member Roles section of the charter.

Any member may fill more than one role, and roles may be combined.

Sociocracy is very clear about recommending that Lead and Delegate roles not be the same person. And, as I mentioned in the audio referenced above from the community meeting, I think that is a very important point to be made. Not only for those two roles, but for all the roles. Even if one person can successfully handle many roles, for the greater resilience of the organization it is better if growth and learning takes place in more people to fulfill them.

To that end, I suggest that language like the following be used to start that section.

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.

I totally understand this point and appreciate you articulating this concern.

Just to clarify, following sociocracy is not the reason for the Membership Steward role, I referenced sociocracy to provide context, but the reason for this change is the logic I outlined here:

In terms of you moving this from a Point of Conern to an Objection, is there something about this that no longer feels good enough for now or safe to try?

I ask not because I don’t believe it is valid, but because I think it’s important that we uphold the principles of Good Enough for Now and Safe to Try when thinking about proposals. This also sets a precedent for using the amendment process to make changes that we feel would be useful (rather than trying to get it all right on the first try).

Definitely! I think we’re very aligned on the consistent re-evaluation of pods.

My only reasoning was having faith that proposals that proposed pod duration periods that were too long wouldn’t pass. But I think you’re right ‒ having a pod maximum duration feels much smarter! I’ve been convinced on this.

And I’m definitely looking forward to nav-naut implementing better feedback tools! I feel like a lot of this stuff gets lost in Google Doc comments that are very challenging to find. So really excited to see what nav-naut comes up with here :slight_smile:

1 Like

The reasons I stated. If adding the complexity of Membership Steward is seen as neccessary, when I and others feel that “good” leadership would natually fulfill it, that to me goes counter to Minimum Viable Structure and is more than enough for now, and has literally already caused confusion.

If Sociocracy comes as a justification at all, it makes me feel that the multiple times I have spoken to the group about the importance of Leads and Delegates not being the same Member weren’t really heard, because people are not only unfamiliar with Sociocracy, but have not lived in an organization where anything like this was practiced to witness it’s benefit. It feels unsafe to me with the current languaging because the current languaging falsely encourages people to feel comfortable with combining roles that really should not be.

The addition of Member Steward on the other hand seems like it is an addition that may have been added to Sociocracy because of pragmatic realities of experiences in poor leadership. However, I find the consciousness higher in Orca Protocol than many communities, and don’t see a practical reason to push that pragmatic fix on us. The reality is a good leader must overlap with a lot of the role of a Membership Steward, except the actual administrivia of the position. With Pods being the size they are that administrivia is small enough I think it should be just be handled by the Pod Lead.

So, my question to you becomes, if we leave Sociocracy out of it altogether, based on direct experience in Orca Pods do you feel we need to add the extra role Membership Steward, or could we be “good enough for now,” and “safe enough to try,” without it?

I totally understand the concern around Leads and Delegates not being combined, and I hear you. I think articulating that these should not be combined is smart.

1 Like

I consent. I think this charter is a great start to the Orca Protocol governance processes. Thank you @chase for leading the design on such a wonderful charter. I’m really proud to be a part of this community and this is definitely safe enough to try in my eyes.


I consent.
Great work, this is definitely safe enough to try for me.