Strike Team #4
Last Edited Time
Apr 27, 2022
Created time
Dec 2, 2021
Participants
Created By
Type
Created
Dec 2, 2021
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, 🐱 Sam, 🍫 Ido, ⚫ Zargham, 👫 Eyal , Fabien 🌰 Pistachio, Connor 🍪 Cookie Dough, Selim 🍓 Strawberry, Prima 🍰 Tiramisu, Bill 🥜 Chocolate-Peanut Butter
Observers: Mehdi (Metagov), Lucia (Metagov), Keating (Ceramic)
Goals
- Membership
- Proposals/voting
Discussion Items
- Topic: Membership
- Topic Proposals
Minutes
Topic: Membership
- Zargham: deeper dive into URI-based, open-ended approach to membership list; "option 1". We should specify the format expected at the end for this membership list. Optional—norm to write the method in the smart contract without necessarily assuming that it gets called on-chain. Brief reference to content-addressed transformers as one option for implementing these kind of open-ended approaches.
- Sam: computing of a list of ERC-20 owners—getting this on-chain is really not possible. Has to be done off-chain, and there you have to crawl all the blocks to compute this in a proper way, or use some APIs from Etherscan which prepare the data for you.
- Fabien: for Snapshot we have strategies. Very flexible, but can be very complex. E.g. a DAO might make voting power in terms of stuff from multiple chains, multiple tokens.
- Fabien: what is membership though? what rights?
- Zargham + Sam: update on previous strike team discussion
- Selim: from my research: token- or wallet-based (whitelist) options. Wallet options require identity layer.
- Sam: there are many other ways of defining member.
- Eyal: maybe we should start focusing on affordances! +1 Zargham
- Decision: URI to flatfile of human-readable and URI to a (potentially off-chain) list of addresses or a method for calculating such a list (aka Snapshot strategy) + expected structure of the JSON, without any expectations of what sits at the end of that URI.
- Next step: write this section of the EIP
- Drop team: Bill, Ido, Sam, Josh, Zargham (editing)
- Produce an example of such flatfiles
- One integrated EIP
- We also need to build soem versioning
- Criterion of success: make Eyal's job really easy
Topic: Proposals
- Is this a critical / fundamental part of a DAO? Should it / can it be standardized?
- Zargham: depends. Are there things in the DAO that are not just do-ocracy? This where computable <> real-life.
- Sam: distinguish between proposal and the data of the proposal and the execution related to that proposal.
- Bill: think DAOs necessarily need to make decisions, and it's about what inputs are needed to make that decision. So "proposal" might be a bit of a limiting or loaded term, but there's always some statement that needs to be posed to the DAO.
- Sam: it's this statement that we can really standardize!
- Zargham: ++
- Selim: ++ also, maybe a little bit of metadata like title, proposers, summary, description, exteranl resources, tldr
- Zargham: this metadata could also be handled with (off-chain) pointers to things like forum posts, etc. Seems like a data structure design problem.
- Selim: what about proposal state. Discord → Forum → Google Docs → then finally enters a formal proposal system
- Zargham: this pattern could...
- Selim: DAO2DAO use-case, allowing proposals to get transferred across DAOs.
- Josh: would this suggest a lower-level, more rigid + normative standard for proposals
- Zargham: if one of those URI fields is process that requires a state-machine representation with (proposal, stage / state).
- Sam: ++ a proposal will have a state. Currently we have a highly inefficient way of dealing with proposals. The circus of decision-making starts. Then there's a small thing that's an issue, like just wording. What about mechanisms for changing a proposal versus always going back to the beginning?
- Selim: ++ forking of proposals?
- Zargham: TEC forking example—lots of forking, but to vote had to have a consolidation phase via Git. So it happened before voting!
- Bill: in majority of Moloch DAOs, it's not as well-organized, but there's always some process of social consensus via Telegram + forums. Proposal goes through an iteration in those discussions before it gets put up to vote.
- Zargham: So vote here is more of a ratification process.
- Bill: TEC example is a much better organized kind of discussion + proposal consideration process, but... it's still a circus.
- How do we make all this machine-readable!?
Action Items
For each framework/contract, (1) get the metadata names (title, description, etc.) for a single proposal, (2) how to pull the list of all proposals, and (3) a general description of how proposals are used, if at all
Moloch: Bill
Aragon: Sam + Selim
DAOstack: Ido
Snapshot: Fabien
Orca: JOSH ask Julia
Compound: CONNOR will ask Larry if can do it or suggest someone
Substrate: EYAL will put us in touch with someone
Tribute: JOSH ask David
NEAR: JOSH ask Jordan and Ilia
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
Previous Action Items
Moloch
Gnosis Safe
Aragon
Open Law
DAOstack
Snapshot
Colony
Compound
Josh + Zargham: summarize two options, simple + rigid vs. complex + loose for standardizing membership