V1.4 Aims and Domains

Posting aims and domains following up on Friday’s session (notes here).

Each pod is responsible for consenting to their respective aim and domain(s) by Friday, April 29th. Per the Governance Charter, Facilitators are responsible for stewarding the gathering consent process.

Facilitators: once you’ve gathered consent, please post consent, as well as any modifications made to aims and domains, in this thread.

Sonar Labs Aims & Domains

Orcanaut Aims & Domains

5 Likes

Thanks for the first pass at Aims and Domains @chase, it is really appreciated.

Although, the domains look fairly accurate, I would have to say the Aim is way off. It is a small subset, or even just another domain really.

The aim of Nav-naut is something close to the following. The BigJam was too unweildly for me to review well in my time before take off, so this is a stab at it from memory. The Nav-naut proposal only just occurred to me as another good place to understand the real aim of Nav-naut.

I type this now to do this work with @zkchun and @JonSimmons-dendrons async, since I will have time, but no idea of when before Friday.

The Aim of Nav-naut is to help contributors navigate well from Discord participant to core DAO contributor and every stage in between including simply more informed Discord participant if that is all they desire.

2 Likes

Thanks for this! This is great stuff!!! :sunglasses:

My 2 GWEI:

The aim outlined here for devnaut makes sense, although I’ll note on two things:

  1. Often devs come into governance hoping to work on or play with smart contracts / the stack that is not just web2 stack. There’s so much to learn and devs want to explore the capabilities. Perhaps adding in Domains: iterative experimentation with open-source orca code with interesting DeGov design mechanisms.
  2. Unsure if this will be a public domain thing, but researching DeGov designs and distilling it down so it is long-lasting reference material for the public (public good) would be cool too. In order to do #1, we need an understanding of cool DeGov mechanisms to even try with the smart contracts.

I support the idea of really not giving the keys and sudo access or anything close to that to the orcanauts devnauts pods on the smart contracts, unless that becomes a DAO decision in the future. These experiments are on open source code from SL and Orca already

3 Likes

I consent to the aims and domains of the SL protocol pod

2 Likes

think this makes alot of sense Steve. we tried to keep the protocol domain narrow to just the immediate protocol contracts, but i do think there is some interesting room for experimenting with how other governance tools can be used in conjunction with pods

5 Likes

I consent to the aims and domains of the SL Communications pod. Thank you so much for this diligent work everyone! Excited to move forward with this new level of clarity.

3 Likes

Love, love, love this! Thank you!

2 Likes

I love this, too, and it seems to have a strong overlap with what seems to be a Gov-naut responsibility. I wonder if a Gov-naut <==> Dev-naut conversation should be started on this topic in the not too distant future.

Although SL, has expressed resistance to it, I totally believe that within a years time we not only need solutions for ourself, but some strong “generic” options for some basic governance contracts. On/Off boarding from Pods is the most obvious example, but there are probably other generic governance actions that should be included.

I personally am less attached to whether actual voting mechanisms are on chain versus making sure that essential and basic functionality is easily implemented by anyone wanting to use Pods as one of their governance tools. That is integrating off chain voting mechanisms into Smart Contracts on chain taking care of essential and basic governance issues seems like something Orca should be offering to the world.

Steve, time commitments aside, do you think Dev-naut has much interest in doing this kind of work?

1 Like

After reviewing the gov-naut aims and domains both in the forum and on the gov-naut sync meeting on Thursday 28 April, and hearing no objections to their being good enough for now and safe enough to try, the gov-naut pod consents to these aims and domains.

2 Likes

I agree that this is worth discussing in the near future. We all still have much to learn about what DAOs need to sustain success and how to best enable them to achieve their full potential, and this is one area that seems promising.

Cheers John. Curious how the discussion will go today and onwards regarding these domain guide-rails for devnaut!

Thanks for the thoughtful response here @aia! My responses to your thoughts in sequence:

  1. Gov-naut <==> Dev-naut convo on this would probably be quite helpful! I think the overlap of domains and aspect of public domains will be brought up in today’s chat. Probably good to follow-up after that appropriately.

  2. I think that your points have merit. Although, I am no expert in this, the aspect of off-chain integrations into on-chain functionality is typically a bit a pickle. :cucumber: Everyone lands on this in different spots on the spectrum, but I am a proponent (currently) of full decentralization (probably biased from my short time in crypto and vitalik posts haha). Ex.) bringing in off-chain oracle pricing, or some other form of off-chain aspect via merkle methods has been seen, but one has to wonder, are these off-chain techniques or their underlying infrastructure truly decentralized? Why does it matter? Again, not an expert but it just has a bunch of underlying possible attack vectors, the Graph infrastructure right now for example consists of so-many nodes, there probably still is a way to get some collusion going because they do not have as much decentralization as Ethereum does for example. I think there is hesitance in pushing out generic options for basic governance contracts because these things have a bunch of underlying thoughts and Orca/SL want to push forward carefully. The saying goes if you want numerous things, best to go slowly ← a lot of what I say in this big comment may not make sense (not an expert more just my morning thoughts as I try to understand things too), but the bolded statement here seems to land for me.

  3. Dev-naut would probably be interested in working on smart contract experimentation, so sure, if it was done in a way that lined up with Orca/SL/Orcanauts, then that would be fine. As my response to #2 shows though, I think it makes sense to take slowly and get the blessing of SL as they are a big stakeholder in painting the right perception for Orca protocol (not only as a protocol but also as a leader in DeGov). Pushing out too many tools too quickly may mislead certain parties and partnerships (other protocols) and that could lead to poor results. I’m not the devnaut lead so I can’t really speak for everyone in devnaut, but it seems the two notes I added earlier in this forum land well with what most devnauts are interested in

Just my 2 GWEI.

2 Likes

I appreciate very much not being in a hurry. On the other hand, this is the crypto space, where things move quite fast, furthermore things take time to develop especially if it is going to be done well.

As I stated even if only for use with our own Pods, unless I am mistaken, there is a need for contract on/off boarding members from a “vote.” Anticapture is more important than decentralization, and governance contracts support that. FWIW, you yourself speak to iterative research and development of DeGov code above.

I am exploring Dev-nauts interest in these issues, because I believe that is the correct Pod for the domain. However, Nav-naut will take responsibility for doing some of this work if Dev-naut is not interested, because it is also a part of DAO Contributor experience.

2 Likes

Nav-nauts have ratified this copy for our aims & domains:

Aim

Helping community members navigate the Orca ecosystem, ensuring a healthy contributor base, and empowering contributor mobility and success.

Domains

Contributor Experience

  • community and contributor onboarding
  • facilitate Member and Orcanaut education
  • facilitate contributor growth in responsibility and success
  • community building (not growth, but participation and cohesion)
  • document contributor’s reasons when off boarding

DAO Tooling

  • Research DAO Tooling that supports successful DAO functioning
  • Integrate tools to support successful DAO functioning
  • build tools to support successful DAO functioning, if necessary

Knowledge Management

  • define and track metrics to understand Contributor experience
  • choose tools and define processes to facilitate organizational memory
  • maintain and use research from an Orcanaut profile database

Service

  • based on all the above Domains, help other dOrgs/DAOs set up the technical infrastructure and social processes to do similar things for themselves.
3 Likes

Steve covered a lot of similar thoughts I had, but to expand on 2 & 3:

Governance contracts can be your best friend or your worst nightmare. Generic contracts for governance such as token weighted voting can be potentially dangerous to the org as it opens us up to flash loan gov attacks – which could drain assets from a DAO. On the other hand, a well implemented and thought-out system with checks and balances can sustain us for years to come and keep assets under the DAO’s possession safe. Working alternative models to pure token-based governance is something on the forefront of my mind in designing governance contracts.

Pushing out more tools is great, but keep in mind that it’s not something that can be done very quickly: in this field, one mistake in a contract can cost a hefty sum of money and should be first audited and tested ad nauseum. That being said however, modular designs will help reduce smart contract risk to a degree. R&D is super important in terms of the design and creation process of smart contracts, tooling, etc.

1 Like

We are already living “alternative models” to pure token-based governance, and could use support in contractual execution of it.

I don’t think anyone has ever suggested rushing anything. I have only suggested taking action on functionality we actively need ourselves for the time being, and never suggested that it be rushed, only that we start now, so that we can test first with ourselves, and then offer with confidence to others. If we wait 6 months or a year to start doing this, it does not server our own community now, and to produce what’s needed by users of our Pods will have to be rushed either by us, or them.

Furthermore, I have never felt that the actual voting needs to be online, but there is real functionality that should definitely be automated for execution whether voting is on chain or off chain. Doing so unquestionably increases anticapture resilience.