Delegation of *-naut Pod Admin Role to an Individual

Context

I was concerned about @zkchun being the Pod Admin for all -naut Pods of the Orcanauts. My concern was that we are stuck if, God forbid, Chun gets hit by a truck and can’t get online for an extended length of time, or ever again. This concern was highlighted by the languaging used in our Governance Charter where it states, “the Pod Lead is the default holder of the Pod Admin role,” when that role is not being fulfilled by a smart contract.

Chun made it clear that on/off boarding of Pods was always possible by a Pod Threshold transaction, even with an individual assigned the Admin role to the Pod. I did not know this.

With the ability to continue business even if Chun is absent for an extended period, every Pod Lead was happy to delegate their PodAdmin privilege to Chun.

Proposal

It be adopted that since we do not have governance contracts as yet, and Pod Leads unanimously preferred to delegate PodAdmin privileges, that Chun be the offfical Pod Admin for art-naut.pod.xyz, gov-naut.pod.xyz and nav-naut.pod.xyz.

In addition each Pod Lead should be explicitly educated in how to execute on and off boarding by a successful m/n threshold transaction for a Pod. Ideally, this would happen as a single event to which all Pod Leads, and any Cadet, Orcanaut, or SL member could attend if interested.

1 Like

In addition each Pod Lead should be explicitly educated in how to execute on and off boarding by a successful m/n threshold transaction for a Pod.

Think this is important to highlight.

To that point, interacting with pods is important in gaining product expertise. If it is preferred, I’m totally okay with holding the admin key for now, but I do think it would be nice to have Orcanauts interact with on-chain transactions whenever possible for experience. So I would encourage pod leads and members to manage their pod’s memberships through multisig transactions if it’s convenient.

The Orca docs explain what a pod admin and pod member entails. Recommend people check that out to learn more. There is also a section about pod configurations, which is very interesting.

2 Likes

I agree that product expertise and interaction are a must for any on-chain member.

As a new addition to an on-chain pod, I’d like for there to be a much clearer onboarding experience. Onboarding as an on-chain Orcanaut is currently informal and very ad-hoc.

1 Like

Great point - this is critical to our ability to self-manage. Our inclination should be to do one-off work through multisig transactions and limit the use of your administrative talents to more complex items (and even then, we should probably do more teaching/training rather than “do this for me”). That will build up our skills and also allow you to focus on more important work.

Important Please Read

I am rescinding this proposal in light of the conversation in the OrcaSource Pod Sync today.

Based on @John_Sterlacci’s call out of anticapture resilience in having the Admin role be held by a “parent” Pod, I believe this is what we should actually adopt. It also sets a better example for the larger community about the safest use of Pods for governance in their organizations.

I don’t see a formal need for proposal for this, as it is actually how our Governance Charter is written.

This also suggest that Pods should get used to needing to Mint/Burn memberships using m/n threshold Gnosis Safe transactions based on their Pod settings after a vote has passed for On/Off boarding new Pod members. It was also pointed out that the Pod having to do this provides good direct experience for ON having direct experience in using Orca Protocol trustware technology.

As an aside, if meetings typically have most members in a Pod in attendance, than maybe having m/n thresholds that are at least a majority of Pod members should be a strong recommendation. Executing actions after a vote should be easy, and as soon as the next meeting following a vote, if not as a part of the same meeting where the vote took place, or shortly their after.

2 Likes