Should we ratify the source pod on-chain?

Brought this up at the first source pod call (12 May 2022). But since we have quite a few conversation topics on the backlog, I’d like to suggest that we come to an agreement on this asynchronously.

This proposal loosely follows the pod ratification proposal template, referred to in the governance charter.

Supporting roles (facilitator, secretary and recorder) are not mentioned, because this proposal only concerns the on-chain creation of the source pod; supporting roles are not exclusive to pod members.

Some points are things we already agree on, like its members and aim and domains. But some are not, which I’m prepending with a :point_right: :

  1. Pod name
  2. Who to require consent from to ratify this pod
  3. Pod admin
  4. Threshold
  5. Duration

Would love to get feedback by 2022-05-17T23:59:00Z so we can have this posted in time for Thursday’s source pod call.


Proposal: Source Pod Ratification
Authors: @zkchun
Date: 2022-05-20T15:00:00Z
Consent from: <consent required from>
Consent by: 2022-05-24T23:59:00Z

This proposal loosely follows the pod ratification proposal template, referred to in the governance charter.

Pod Name

:point_right: source-naut.pod.xyz

Pod Type (on-chain or off-chain)

On-chain pod

Situation / Tension Pod Addresses

We have decided on the off-chain structure of this pod, its members and supporting roles, yet still need to accurately reflect this on-chain.

Aim

The source pod exists to steward the flow of information and coordination across pods.

Domains

  1. Home finding - Supporting new initiatives in finding homes (in existing pods or spinning up new pods)
  2. Information Flow - Ensuring SL and ON have proper channels and support for information flow between and among pods

Relevant Parent Pods

None; the source pod is equivalent to the general circle in sociocracy.

Members and Roles

Pod Members

  • Orcanauts - Gov-naut
    • Appt Pupil (lead)
    • Cadena (delegate)
  • Orcanauts - Art-naut
    • PostArchitekt (lead)
    • Gaian (delegate)
  • Orcanauts - Nav-naut
    • dendrons (lead)
    • aia (delegate)
  • Sonar Labs - Communications
    • Julz (lead)
    • frogmonkee (delegate)
  • Sonar Labs - Protocol
    • Dan Wu (lead)
    • John (delegate)

Pod Admin

:point_right: None; without a pod admin, source pod membership can be managed through multi-sig transactions.

Threshold

:point_right: I propose a transaction threshold of 4 of 10.

Duration

:point_right: I propose we set a short review period to coincide with the review of the governance charter: 20 June 2022. This seems the safest to me as we can simply agree to extend the duration if no major concerns emerge.
(Unsure about this one, so very open to thoughts here. Trying to lean on the side of safety here, but also down to just set an arbitrary date.)

2 Likes
  • source.pod.xyz or OrcaSource.pod.xyz
  • agree on pod admin and threshold issues
  • seems reasonable to review along with the gov charter on June 20
    Thanks for writing this up @zkchun

I think Pod Name should be “OrcaSource.pod.xyz”

I think we should have a “Pod Admin” @zkchun or someone else, as I prefer a lower transaction threshold for economic decisions, but find it to be to low a quorum to double for governance decisions that should in my mind, require a quorum, of more than half the Pod actually explicitly voting.

Maybe, I am wanting too much convenience for economic transactions, and we should raise the transaction threshold to 6/10, which I think is a reasonable quorum for executing who is/isn’t added/removed from a Pod.

I have to admit in our organization I don’t think there will be a collusion of Pod members who decide to take over a Pod, but it would be harder see and to rectify than if similar actions are taken by an individual with the Admin role. Forcing some level of > 50% quorom through the Threshold level at least enforces a democratic level of governance to the execution of Admin privileges.

1 Like

Why do we need to “accurately reflect this on-chain”? The current consented domains are focused on the social layer. Besides continuity and for the sake of organization I don’t see the reasoning for this being on-chain.

This sparks an interesting conversation around what minimum criteria should be required to spin up on-chain pods. Ideally we keep this barrier semi-high.

2 Likes

Great point. I’m not entirely convinced it’s needed either.

If the source pod does not end up managing any funds, then I would see less need for it to be an on-chain pod.

Edit: this could be an agenda topic for Thursday potentially.

It’s a good question.

Per @chase’s Resource Allocation doc, on a quarterly basis, the Source Pod has been positioned to have explicit decision-making authority to:

  1. Determine whether new commissioned domains are spun up and funded from the “Orca treasury”
  2. Determine whether non-commissioned domains receive funding from the “Orca treasury”

However, as of now, it’s not clear where/what the “Orca treasury” actually is, and who has execution authority to allocate these funds. I think in actuality the “Orca treasury” right now is a multi-sig controlled by SL members. But need clarity here and should define current state.

If we actually want the Source Pod to have execution authority to allocate funds, we most definitely need to ratify on-chain. Other reasoning to ratify on-chain is to begin to play with interesting DAO tooling / integrations being spun up with pods.

Alternatively, if we are okay with SL member execution authority for capital allocation in these scenarios for now, then no real urgency to ratify on-chain.

I personally lean towards ratifying on-chain and working towards getting executive authority in the hands of the Source Pod.

I also like OrcaSource.pod.xyz :slight_smile:

From a threshold perspective, I kind of agree with @aia with something > 50% (e.g., 6/10) since the role Source Pod plays is so important. If actual execution of capital allocation only occurs quarterly, it shouldn’t be the biggest hurdle to get six Source Pod members to click a button ~four times a year (with a few ad-hoc allocations in between). We can always adjust!

1 Like

This is a good question. My initial assumption was that OrcaSource Pod would take over Orcanauts Pod, which has been the Orca community treasury to date.

So, I imagine funds going from SL to OrcaSource, to it’s children Pods as decided upon by OrcaSource. However, is the extra step needed? When the funding is simply SL to Orca execution Pods, I don’t think so.

However, it is very easy for me to imagine funds coming to the Orca community overall, as well as to specific Pods. At that point, it makes sense to have a general community treasury location, and I don’t know why that wouldn’t be OrcaSource since it is deciding on asset distributions.

1 Like

I interpreted Source Pod as a lever mechanism to enable the flourishment of corresponding pods.
A council of sorts.

Having SL on a council that determines how/when community funds get distributed makes sense today, not sure it does in the future

1 Like

That is exactly part of the reason we decided to maintain the Orcanauts Pod, no?

Do we feel good about orca-source.pod.xyz? Think capital casing generally is not going to show up as nice in URLs right?

Proposal here: Source Pod Ratification Proposal