🛠️

Strike Team #6

Last Edited Time
Apr 27, 2022
Created time
Dec 16, 2021
Participants
Created By
Type
Strike Team
Created
Dec 16, 2021
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, 🐱 Sam, 🍫 Ido, ⚫ Zargham, 👫 Eyal , 🍓Selim, 🎆 Isaac
Observers: Mehdi (Metagov), Lucia (Metagov)
 
Goals
  • Membership
  • Proposals/voting
Discussion Items
  • Topic Proposals
  • A list of the ingredients for making a proposal, voting on it, and executing on a proposal.
Minutes
Execution
  • Eyal: Important to have an understanding of how it looks to execute a DAO proposal What does the standard say about "what is being executed"? Is it calling a function? Should there be a quorum? This kind of resolution may not be suitable for htis draft. The standard should have some understanding of what it means to EXECUTE a DAO proposal needs to be there.
  • Eyal: What does it mean to vote on / make a decision on a proposal? Is this quantifiable or do we want to include decisions that are warm consensus without voting? We should have something quantifiable, since the non-quantifiable stuff will happen anyway.
  • Eyal: the metadata of the proposal is pretty straightforward; less interesting or controversial.
  • Ido: we should first address the execution part. 2 different dimensions. On-chain or off-chain execution that can be reflected in our standard. Can address it but address it later.
    • Selim: I would take out the execution part. The execution is so diverse. Examples: execution based on governance settings, membership, external contracts, internal contracts, etc.
      • Ido: the most generic thing is a call to some address, some data, some value. Perhaps the more generic thing is a batch call. If we want DAO2DAO interactions, it's crucial to standardize exactly this.
        • Zargham: we can start with binding vs. non-binding. Some votes are just communication. For binding: is it a call or not a call? Automated vs. not-automated.
        • Eyal: on execution—proposals can also be cancelled, delayed, executed in stage 1 or stage 2. Or proposals moved to another jurisdiction, moved to parliament, or to the larger population. The status of a proposal can be many, many things.
        • Zargham: feels like we don't have many good examples of "binding" decisions that are mainly binding in meatspace, i.e. non-automated. Most of our examples are binding AND automated. We want space in the data model to support binding & non-automated.
          • Eyal: agree with what you said, let's find a different word from automated.
  • Josh: what exactly is binding? Is it just a voluntary label?
    • Ido: if it's binding, you NEED either on-chain automation or off-chain execution.
      • Zargham: if you pick binding + on-chain automation, you will need more information. It's a nested structure.
      • Zargham: I still want to add some notion of accountability to the off-chain execution! The structured data of the proposal should sit next to a piece of plaintext.
        • Eyal: love the idea of the executor: nominate a person (not quite a police person) who is responsible for keeping the norm/proposal that we agreed on, even if the execution is off-chain.
  • Ido: can you have a proposal that has both on-chain AND off-chain execution?
    • Zargham: yes.
    • Selim: what would off-chain execution data fields look like?
      • Zargham: executor? Should be implicit in the proposal document. Possible an executor, or an address to someone.
        • Josh: what about a contract or wallet address? An address is either a person, or a DAO, or the DAO itself.
          • Eyal: the executor is almost an NFT, a "magic stick"?
          • Zargham: yes it should be an address representing an entity such as a person or a wallet or a DAO. Treating it like an NFT is really cool, to make it transferable.
            • Ido: if the task is executed, the NFT could have some specific value? The person who receives the NFT could then trade it in for that value.
            • Zargham: ultimately, that "NFT" might just look like, if you're assigned an on-chain address and an off-chain role, you use the on-chain address. So 1 or more DAOs pay into a fund with a scripted rule that pays distributions to a set. I.e. if you want to pay salaries in a largely on-chain way, you ratify proposals which assign stuff to a set of pots, then the pots then pay to a set of "operator" wallets (that can change over time) based on some rules.
              • Eyal: agreed; there's a difference between a fully on-chain and on-chain enforcement.
              • Zargham: our "executor" field here represents a mapping between a proposal and an address
              • Eyal: the executor could be "in this DAO we don't curse". Executor could also be responsible for moving 1 billion to a bunch of bridge builders, hiring people, a PM style person.
          • Ido: what if some entity does not have an address?
          • Josh: normative default is the DAO's own address?
    • Eyal: binding automated proposals are easy because we know how to describe that. On-chain off-chain hybrids are hard! So we're kind of delegating it. So I would NOT enforce as part of the standard any execution; just the address.
    • Zargham: could imagine
Action items
For two weeks from now:
Josh + Z: Membership + proposals first draft data model
Josh + Bill W + Ido: Membership draft
Josh + Isaac + Eyal: Proposal draft
Previous 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
 
 
🛠️

Strike Team #6

Last Edited Time
Apr 27, 2022
Created time
Dec 16, 2021
Participants
Created By
Type
Strike Team
Created
Dec 16, 2021
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, 🐱 Sam, 🍫 Ido, ⚫ Zargham, 👫 Eyal , 🍓Selim, 🎆 Isaac
Observers: Mehdi (Metagov), Lucia (Metagov)
 
Goals
  • Membership
  • Proposals/voting
Discussion Items
  • Topic Proposals
  • A list of the ingredients for making a proposal, voting on it, and executing on a proposal.
Minutes
Execution
  • Eyal: Important to have an understanding of how it looks to execute a DAO proposal What does the standard say about "what is being executed"? Is it calling a function? Should there be a quorum? This kind of resolution may not be suitable for htis draft. The standard should have some understanding of what it means to EXECUTE a DAO proposal needs to be there.
  • Eyal: What does it mean to vote on / make a decision on a proposal? Is this quantifiable or do we want to include decisions that are warm consensus without voting? We should have something quantifiable, since the non-quantifiable stuff will happen anyway.
  • Eyal: the metadata of the proposal is pretty straightforward; less interesting or controversial.
  • Ido: we should first address the execution part. 2 different dimensions. On-chain or off-chain execution that can be reflected in our standard. Can address it but address it later.
    • Selim: I would take out the execution part. The execution is so diverse. Examples: execution based on governance settings, membership, external contracts, internal contracts, etc.
      • Ido: the most generic thing is a call to some address, some data, some value. Perhaps the more generic thing is a batch call. If we want DAO2DAO interactions, it's crucial to standardize exactly this.
        • Zargham: we can start with binding vs. non-binding. Some votes are just communication. For binding: is it a call or not a call? Automated vs. not-automated.
        • Eyal: on execution—proposals can also be cancelled, delayed, executed in stage 1 or stage 2. Or proposals moved to another jurisdiction, moved to parliament, or to the larger population. The status of a proposal can be many, many things.
        • Zargham: feels like we don't have many good examples of "binding" decisions that are mainly binding in meatspace, i.e. non-automated. Most of our examples are binding AND automated. We want space in the data model to support binding & non-automated.
          • Eyal: agree with what you said, let's find a different word from automated.
  • Josh: what exactly is binding? Is it just a voluntary label?
    • Ido: if it's binding, you NEED either on-chain automation or off-chain execution.
      • Zargham: if you pick binding + on-chain automation, you will need more information. It's a nested structure.
      • Zargham: I still want to add some notion of accountability to the off-chain execution! The structured data of the proposal should sit next to a piece of plaintext.
        • Eyal: love the idea of the executor: nominate a person (not quite a police person) who is responsible for keeping the norm/proposal that we agreed on, even if the execution is off-chain.
  • Ido: can you have a proposal that has both on-chain AND off-chain execution?
    • Zargham: yes.
    • Selim: what would off-chain execution data fields look like?
      • Zargham: executor? Should be implicit in the proposal document. Possible an executor, or an address to someone.
        • Josh: what about a contract or wallet address? An address is either a person, or a DAO, or the DAO itself.
          • Eyal: the executor is almost an NFT, a "magic stick"?
          • Zargham: yes it should be an address representing an entity such as a person or a wallet or a DAO. Treating it like an NFT is really cool, to make it transferable.
            • Ido: if the task is executed, the NFT could have some specific value? The person who receives the NFT could then trade it in for that value.
            • Zargham: ultimately, that "NFT" might just look like, if you're assigned an on-chain address and an off-chain role, you use the on-chain address. So 1 or more DAOs pay into a fund with a scripted rule that pays distributions to a set. I.e. if you want to pay salaries in a largely on-chain way, you ratify proposals which assign stuff to a set of pots, then the pots then pay to a set of "operator" wallets (that can change over time) based on some rules.
              • Eyal: agreed; there's a difference between a fully on-chain and on-chain enforcement.
              • Zargham: our "executor" field here represents a mapping between a proposal and an address
              • Eyal: the executor could be "in this DAO we don't curse". Executor could also be responsible for moving 1 billion to a bunch of bridge builders, hiring people, a PM style person.
          • Ido: what if some entity does not have an address?
          • Josh: normative default is the DAO's own address?
    • Eyal: binding automated proposals are easy because we know how to describe that. On-chain off-chain hybrids are hard! So we're kind of delegating it. So I would NOT enforce as part of the standard any execution; just the address.
    • Zargham: could imagine
Action items
For two weeks from now:
Josh + Z: Membership + proposals first draft data model
Josh + Bill W + Ido: Membership draft
Josh + Isaac + Eyal: Proposal draft
Previous 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