Strike Team #2
Last Edited Time
Apr 27, 2022
Created time
Nov 18, 2021
Participants
Created By
Type
Created
Nov 18, 2021
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, 🐱 Sam, 🍫 Ido, 🎆 Isaac, ⚫ Zargham, 👫 Eyal
Goals
- Resolve discussions around scope + "minimal DAO"
- Identify target milestones
- Prepare presentation for Nov. 26
Discussion Items
- Summary / catch-up of the last meeting
- Proposed milestones
- Next week! Parse DAO contracts, put into a spreadsheet. See this example for Gnosis Safe.
- Continue discussion: what are the minimal features of a DAO?
- Membership?
- Check incentives for adoption
- What constitute a MVDAO? What is DAOness?
- (Do we need) a proposal for DAOstar DAO?
- What to present on Nov. 26 (15 minutes)
Minutes
- Sam + Isaac: v2 Aragon, v3 Moloch coming out very soon—do some mutual code review?
- Organizational infrastructure for DAOstar DAO? Extrinsic vs. intrinsic motivations.
- Zargham: Josh should join ConstitutionDAO
- Josh: let's not discuss this today
- Eyal: what's the authority that the community has over the treasury. In an Aragon DAO that's pretty clear. In ConstitutionDAO, it's not. The community can decide something, and the multisig holders can decide something else. That relationship has to be EXPLORED, even if it is not STANDARDIZED.
- Zargham: this question has NOT been answered, but several folks are working on it
- Eyal: beyond the tools, there has to be transparency. Doesn't mean you know my name + id, but it means you have my history.
- Zargham: what about persistence of identity? For activity histories. How easy is it to fracture your activity across multiple actors? What about requiring some human legwork to level up in a community? I want to incentivize more activity on a single on-chain address. Feels like it's important to have a persistent history, but it works against the grain of people's best-practices in obscuring activities.
- Parameters:
- Membership
- Use-case: persistence of identity + activity history
- Use-case: deep skills / reputation
- Use-case: proposals + votes.
- Use-case: ability to create profiles? Even a username. Eyal
- In example of ConstitutionDAO: who are these multisig people? Knowing their history is really important, in evaluating a project
- Sam: membership is fundamental to a DAO.
- Objections?
- Josh: what's the relationship between membership and ownership?
- Zargham: Ownership is NOT base to a DAO. Too tied to complex. +Ido +Josh.
- Sam: DAO = doesn't allocate ownership
- Eyal: owning tokens is an ownership kind of thing, and moving into a new DAO often means owning tokens. But ownership should be a subset of membership. I think membership implies agency, social capital, etc. It gives you RIGHTS. It has to come with something!
- Eyal: membership implies agency. It has to come with some rights! Especially rights in decision-making.
- Ido: every DAO should define what it means to have a member. You should be able to have different types of members.
- Josh: what about right to leave a DAO
- Sam: ragequit is an internal process, and we can't define it.
- Zargham: only thing we can + should do is create a standard read process for membership; memberValidator. Should have some easy composable functions so folks can define their own processes for leaving+entering+tracking. +1 Sam
- Sam: not to have a standard inside the DAO framework; allow easy way for DAOs across frameworks to interact with each other e.g. by defining memberships. See https://alpha.guild.xyz/create-guild
- Eyal: membership needs to provide rights.
- Ido: but how do you standardize?
- Zargham: how does the DAO represent itself to the outside world? vs. how does the DAO represent its own data to itself.
- Ido: in order to standardize this, we would have to standardize the meaning of governance, and that's too large.
- Sam: what a member can do inside a DAO is not standardizable?
- I agreed with the above statement from Ido (Sam) :-)
- Eyal: standard needs to say, in some way, what are
- Zargham: Clarity of membership: could it even be just a text, put it in a field in the DAO? Like "license.md" or "governance.md" in a repo. etc. Standardized language to define what membership means. A field, like a URI, to an IPFS hash hosting a text file.
- + Isaac: this alone throws a blanket over something hard to see. That type of DAO URI would alone be very significant!
- Ido: but how do you correlate it with the membership object? They seem different.
- Zargham: if the DAO has a metadata with the URI; normatively, the membership should have "agreed" to this constitutional text (?)
- Ido: if you have 2 types of members, with different voting powers, then will the differeing relationship be reflected i that doc?
- Z: normatively, yes.
- + Eyal: throwing a blanket is a good idea, it's also what happens in the real world. we can get into the relationship + details + affordances.
- Ido: is membership a binary thing? Or do we need some other metadata?
- Sam: we need to define a membership interface
- Josh: we should support multiple sets of members?
- Decision-making (and membership rights)
- Eyal: this is fundamental to a DAO.
- Ido (from last time): method to get all proposals in a DAO?
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
Tell me how membership is actually defined in your framework / DAO. + the readprocess through which that is actually pulled out
Josh: Gnosis Safe
Josh: Open Law / Tribute
Sam: Aragon v2
Isaac: Moloch v3
Ido: DAOstack
Eyal: ??
Modules, super-users
Write-up use-cases for the standard?
?
Add to reading list
Next week: identify team needs (incl. resource needs)