🛠️

Strike Team #5

Last Edited Time
Apr 27, 2022
Created time
Dec 12, 2021
Participants
Created By
Type
Strike Team
Created
Dec 12, 2021
Zoom Recording
Property
Property 1
Attendees: Zargham (chair), Eyal, Sam, Ido, Isaac, Bill, Selim, Mehdi, Lucia
Goals
  1. Schema for proposals
Discussion
Membership
  1. Isaac: we're building a taxonomy. Based on flexibility requirement, we should use JSON-LD, which has some advantages. We used it in the DID spec.
    1. +1 Zargham
 
Proposals
  1. Eyal: We can look at the Notion of "How Proposals Work".
    1. DeepDAO: how to normalize data from all the platforms? Collected and normalized based on combination of DAOstack, Aragon, Compound, and Snapshot.
    2. Need a unique ID. Better to have a universal (uuid)!!!
  1. Eyal: on requiring end dates— there are use-cases for votes that never end, e.g. curation lists
    1. Zargham: agree, there are use-cases that have no end-date
  1. Ido: let’s separate concerns and tackle this separately. The content of a proposal is a different dimension from status from execution path
    1. +1 Zargham
    2. Zargham: hard to describe the entire state machine of a DAO decision process
  1. Ido: we SHOULD try to standardize the way we talk about and report on-chain execution. This is necessary for DAO2DAO. We should NOT try to standardize the way we talk about and report off-chain execution. The justification for standardizing the off-chain actions is mainly for exploration + data analysis [namely, it doesn’t have a directly technical application.]
  1. Zargham: we should have nested or layered standards for describing both on-chain and off-chain paths, key application is allowing comparisons and diffs between execution strategies
    1. Eyal: disagree, we should be able to just have one standard schema
  1. Zargham: DAO2DAO communication and collaboration requires a lot of experience with different DAO frameworks!
  1. Eyal: the perfect DAO for producing this standard
    1. notion image
  1. Isaac: proposals in Moloch and how we use a DAO2DAO framework to support moloch extensions
    1. The basic operations in a Moloch DAO are purely for treasury (token+share) management. Minions extend proposals allow to external contract interactions; the Gnosis Safe gets attached to a Moloch contract which allows it to interact with arbitrary other contracts.
    2. Moloch DAOs that want to manage Balancer pools have to go through a translation contract. We’ve built all of these translating shims (?), using the Zodiac interface, which translates Moloch proposals into external actions.
    3. One use-case example: Smoke Signal, hosting a conference, move WETH to a separate, non-quitable Gnosis Safe called Bungalow
    4. One use-case example: iRobot (minion controls a Gnosis Safe, which is the admin of a Balancer pool)
    5. Is it still function and parameters? Yes. It’s all very easily indexable, using the Gnosis Multi-send Library.
    6.  
🛠️

Strike Team #5

Last Edited Time
Apr 27, 2022
Created time
Dec 12, 2021
Participants
Created By
Type
Strike Team
Created
Dec 12, 2021
Zoom Recording
Property
Property 1
Attendees: Zargham (chair), Eyal, Sam, Ido, Isaac, Bill, Selim, Mehdi, Lucia
Goals
  1. Schema for proposals
Discussion
Membership
  1. Isaac: we're building a taxonomy. Based on flexibility requirement, we should use JSON-LD, which has some advantages. We used it in the DID spec.
    1. +1 Zargham
 
Proposals
  1. Eyal: We can look at the Notion of "How Proposals Work".
    1. DeepDAO: how to normalize data from all the platforms? Collected and normalized based on combination of DAOstack, Aragon, Compound, and Snapshot.
    2. Need a unique ID. Better to have a universal (uuid)!!!
  1. Eyal: on requiring end dates— there are use-cases for votes that never end, e.g. curation lists
    1. Zargham: agree, there are use-cases that have no end-date
  1. Ido: let’s separate concerns and tackle this separately. The content of a proposal is a different dimension from status from execution path
    1. +1 Zargham
    2. Zargham: hard to describe the entire state machine of a DAO decision process
  1. Ido: we SHOULD try to standardize the way we talk about and report on-chain execution. This is necessary for DAO2DAO. We should NOT try to standardize the way we talk about and report off-chain execution. The justification for standardizing the off-chain actions is mainly for exploration + data analysis [namely, it doesn’t have a directly technical application.]
  1. Zargham: we should have nested or layered standards for describing both on-chain and off-chain paths, key application is allowing comparisons and diffs between execution strategies
    1. Eyal: disagree, we should be able to just have one standard schema
  1. Zargham: DAO2DAO communication and collaboration requires a lot of experience with different DAO frameworks!
  1. Eyal: the perfect DAO for producing this standard
    1. notion image
  1. Isaac: proposals in Moloch and how we use a DAO2DAO framework to support moloch extensions
    1. The basic operations in a Moloch DAO are purely for treasury (token+share) management. Minions extend proposals allow to external contract interactions; the Gnosis Safe gets attached to a Moloch contract which allows it to interact with arbitrary other contracts.
    2. Moloch DAOs that want to manage Balancer pools have to go through a translation contract. We’ve built all of these translating shims (?), using the Zodiac interface, which translates Moloch proposals into external actions.
    3. One use-case example: Smoke Signal, hosting a conference, move WETH to a separate, non-quitable Gnosis Safe called Bungalow
    4. One use-case example: iRobot (minion controls a Gnosis Safe, which is the admin of a Balancer pool)
    5. Is it still function and parameters? Yes. It’s all very easily indexable, using the Gnosis Multi-send Library.
    6.