Strike Team #3
Last Edited Time
Apr 27, 2022
Created time
Nov 23, 2021
Participants
Created By
Type
Created
Nov 23, 2021
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, 🐱 Sam, 🍫 Ido, 🎆 Isaac, ⚫ Zargham, 👫 Eyal, 🍇 Auryn
Observers: Luke
Zoom video: Josh forgot to hit record
Welcome Auryn, callsign Rum Raisin
Goals
- Survey membership models
- Define membership methods
- Divide presentation for Nov. 26
Discussion Items
- Summary / catch-up from the last meeting
- Review milestones
- Nail down membership this week / next
Minutes
- Review of decisions from last meeting
- Membership is fundamental
- Need at minimum a field for URI pointer for "meaning" of membership + other contextual information
- Isaac: Moloch membership
- Key distinction between shares vs. loot
- Only way to lower shares is via ragequit
- Membership is NOT directly query-able (by another contract on-chain), though there clearly is a list of members indexed and maintained through subgraphs. See Isaac's doc.
- It's just a data structures issue; just a kind of overhead.
- Zargham: is membership captured through a global state of membership to the DAO? seems not; it has to be built through the membership trajectory.
- Isaac: ref. Diamond DAO—has a similar has a background in deep data analytics, and they're trying to parse this membership trajectory across Moloch DAOs.
- Zargham: what if a DAO that had fuzzier boundaries, it might have to run off-chain analytics to surface what we're discussing here.
- Isaac: so you're proposing a URI of this DAO point to a procedure to compute the membership? Could the membership list be created through a URI approach? SO we don't impose too much stuff.
- One possible implementation (Zargham + Isaac): instead of a membership struct on chain, just a URI to a json list or even a process for computing.
- Ido: that's a very broad, but too broad? Strips you of the benefits that you get from standardization. Even making an automatic explorer of DAOs you can't do that. You have to read through each file and understand it.
- Zargham: how computationally intensive is it to save + update the membership directly on the contract?
- Eyal: additional metadata: affordances of membership, levels of membership, ability to leave.
- Josh: OpenLaw
- Sam: I don't think can be directly queried from the smart contract; the registry exists off-chain.
- Josh: this is not totally clear from the documentation; I haven't interacted with the contract itself. Let's table this until we get word back from David Roon then.
- Ido: DAOstack
- Auryn: Gnosis Safe
- Member = on the multisig
- getOwners function returns list.
- There's another tier of membership "delegates" to define addresses as delegates, more of a convenience function for front-end.
- Auryn: Zodiac
- Zodiac: extends Gnosis Safe using modules that additional logic
- Auryn: Colony:
- Any address can be assigned six permissions; maybe having a permission = being a member?
- Key idea: extension contracts, e.g. reputation
- Auryn: Snapshot
- Defined directly by a strategy document
- Zargham: membership is not monolithic and not solely a smart contract construct; e.g. consider org where Discord membership is the best representation.
- Eyal: membership without affordances + rights is structureless
- Sam: that's similar to our experience with optimistic gov on Aragon; membership has not been monolothic; need to focus on bridges. Objective oracle off-chain; subjective oracle on-chain (?).
- Sam: we want to standardize something that's very new, don't know which direction it will go. I'm sure we've missed a lot of good use-cases up to now.
- Josh: it feels like it's important for us to understand how DAOs interact with larger identity systems / oracles
- Sam: Aragon
- it's hard to break down membership in Aragon, esp. for v2, similar to v1. There's a freely composable and interoperable membership layer; you can define as many roles as you want, each role may trigger different events + actions. Membership means you can stack as many validations as you want. You can create a DAO where every person who interacts with Uniswap is a member (meaning potentially active). Permissions same.
- You can also have DAO permission validator based on existence in other DAOs. in the beginning we will provide BrightID NFT ERC20 validators, and then add more other validators depending on product direction / feedback.
- There are also voting/decision-making process primitives.
- Similar to how Zodiac is going.
- Josh: wow, this is pretty complicated / wide-ranging
- Sam: it's not easy, in society, to define a natural way of membership. And maybe that's a good thing
- Ido: standardizing membership is not as fundamental as we thought? Would proposals be more fundamental?
- Auryn: that's actually more important to us right now; how do we characterize the intentions of a module that's plugged into a safe?
- Zargham: before getting to proposals: right to submit a proposal has to come from membership! So we can't skip it... but we don't need to have really detailed specifications
- Proposal: here is a method for a DAO to publish a list
- Josh: okay, choose between (1) the simple straightforward option (struct with membership list) vs (2) the looser & more complex URI option that gives either a list or a process/index for generating a list
- Sam: second
- Zargham: second (its more general, doesn't preclude first)
- Eyal: emotionally, second. practically first.
- Ido: second
- Auryn: chickened out
- Isaac:
- Josh: Josh
- Answer, for each one:
- Does this support/hurt innovation?
- Are different folks incentivized to implement either?
- Zargham: elaboration of the URI idea: make the structures more readable computationally
- Sam: reference the hash of this document; enforce / incentivize all the DAOs to keep this information up-to-date?
- Sam: there are also risks to defining the membership
- Eyal: if we agree that data needs to be readable, then we're on the same page.
Action items from last time
Tell me how membership is actually defined in your framework / DAO. + the read process through which that is actually pulled out
Josh: Open Law / Tribute
Sam: Aragon v2
Isaac: Moloch v3
Ido: DAOstack
Auryn (?): Gnosis
Proposed milestones
- Nov. 25: present DAO parameter research
- Nov. 26: present initial research to roundtable
- Dec. 30: draft EIP
- Jan. 7: PRESENT EIP draft to roundtable
- Jan. 20: sample integration workflows for existing frameworks
- Jan. 27: minimal DAO contract live on testnet
- Jan. 28: present DAO contract to roundtable
- Thursday, Feb. 3: SUBMIT EIP DRAFT
Action Items
Moloch
Gnosis Safe
Aragon
Open Law
DAOstack
Colony
Compound
Josh + Zargham: summarize two options, simple + rigid vs. complex + loose for standardizing membership