DAOstar One (Internal)
DAOstar One (Internal)
/
🛠️
Strike Team #9
🛠️

Strike Team #9

Last Edited Time
Apr 27, 2022
Created time
Jan 13, 2022
Participants
Created By
Type
Strike Team
Created
Jan 13, 2022
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, 🎆 Isaac, Eyal, Isaac
Observers:
 
Zoom video:
Goals
  • Review last call takeaways
  • Review current EIP
  • Figure out next steps before release
 
Minutes
  1. Isaac will create an endpoint that points to a subgraph for an existing Moloch DAO, Metacartel, OG Moloch.
  1. Josh will do this for one of the Compound DAOs, probably Radicle.
    1. BalancerDAO
    2. Syndicate
  1. Ask Sam to implement one for Aragon, e.g. Aragon Network DAO.
  1. Ask Ido to implement one for DAOstack, e.g. Genesis.
  1. Josh will ping David Roon for Tribute, probably Flamingo, LAO, Neon
  1. Josh: ask Kei, Auryn about some Gnosis Safes.
  1. An NFT-based DAO, Links DAO.
  1. Ask FWB whether they call themselves a DAO.
  1. Eyal came in with an objection: did we neglect on-chain too much?
    1. We are aiming to be an EIP, it doesn’t make sense that all we put on-chain is an URI.
    2. If we leave everything off-chain, we are abandoning on-chain governance.
    3. We should pick some parameters to put on-chain. Fundamentally about transparency, and lack of transparency kills it.
    4. Ref. cite “Tyranny of structurelessness + invisible elite”.
  1. Candidates for on-chain:
    1. ERC-721 standards URI and events.
    2. proposalID → did we ever resolve this discussion? dependent on daoID. could the same proposal have many different IDs? ???
      1. Contract address can be upgraded, can be on different chains, can be forgotten after 17 versions of the same DAO, etc.
      2. maybe the proposal id should be execution-contract as the prefix with an incrementing suffix?
      3. look at opensea or rarible: default opensea transaction is useraddress + an incrementing ID. It’s all coming from a contract.
    3. Title. Rationale:
    4. Proposal creator. Rationale:
    5. Date_created. Rationale:
    6. contextURI. Rationale:
    7. Execution data. We’ve created a hash from the function name and params. The hash would then point you to a place where you can read these parameters.
      1. When we propose it, emit some events and store the hash on-chain, it’s inefficient to store all the execution.
      2. function [so really an array of JSON objects? ends up being quite big, but can be decoded. It’s a sequence of squished bytes. some calls are “internal”, but we can represent that state change somehow...]
        1. Do we need to distinguish internal contract calls? An internal only call. Encoded as if it was an external call.
        2. Pass a URI into an event? Effectively gets you the same thing, the exact same trust model. There’s no on-chain trust guarantee that what they put into a JSON is actually what they execute internally, you’re just asking them to describe it. You could SIMULATE it? Maybe we could pose it to an EVM expert on Tenderly, in what format do they store simulations, and could we encourage people to run a simulation and put a simulationURI on there.
          1. Find someone from Tenderly, or OpenZeppelin, that runs these simulations? Tenderly simulation platform.
      3. data
      4. value
  1. Isaac: by putting the proposals on-chain, is the issue that the URI approach is not trustworthy enough?
  1. Isaac: it seems like if we are overly prescriptive, you instantly get DAOs deciding not to adopt.
  1. Eyal: in DAOhaus, you already have all these parameters for proposals: creator, function, params. By itself, a multisig is not a DAO, it’s a treasury.
  1. Eyal: can we put end-date.
 
Action items
Isaac:
Josh: I have a lot of emails to write.
Previous Items
Josh + Isaac: Membership
Ido: Proposals
 
 
DAOstar One (Internal)
DAOstar One (Internal)
/
🛠️
Strike Team #9
🛠️

Strike Team #9

Last Edited Time
Apr 27, 2022
Created time
Jan 13, 2022
Participants
Created By
Type
Strike Team
Created
Jan 13, 2022
Zoom Recording
Property
Property 1
Attendees: 🌹 Josh, 🎆 Isaac, Eyal, Isaac
Observers:
 
Zoom video:
Goals
  • Review last call takeaways
  • Review current EIP
  • Figure out next steps before release
 
Minutes
  1. Isaac will create an endpoint that points to a subgraph for an existing Moloch DAO, Metacartel, OG Moloch.
  1. Josh will do this for one of the Compound DAOs, probably Radicle.
    1. BalancerDAO
    2. Syndicate
  1. Ask Sam to implement one for Aragon, e.g. Aragon Network DAO.
  1. Ask Ido to implement one for DAOstack, e.g. Genesis.
  1. Josh will ping David Roon for Tribute, probably Flamingo, LAO, Neon
  1. Josh: ask Kei, Auryn about some Gnosis Safes.
  1. An NFT-based DAO, Links DAO.
  1. Ask FWB whether they call themselves a DAO.
  1. Eyal came in with an objection: did we neglect on-chain too much?
    1. We are aiming to be an EIP, it doesn’t make sense that all we put on-chain is an URI.
    2. If we leave everything off-chain, we are abandoning on-chain governance.
    3. We should pick some parameters to put on-chain. Fundamentally about transparency, and lack of transparency kills it.
    4. Ref. cite “Tyranny of structurelessness + invisible elite”.
  1. Candidates for on-chain:
    1. ERC-721 standards URI and events.
    2. proposalID → did we ever resolve this discussion? dependent on daoID. could the same proposal have many different IDs? ???
      1. Contract address can be upgraded, can be on different chains, can be forgotten after 17 versions of the same DAO, etc.
      2. maybe the proposal id should be execution-contract as the prefix with an incrementing suffix?
      3. look at opensea or rarible: default opensea transaction is useraddress + an incrementing ID. It’s all coming from a contract.
    3. Title. Rationale:
    4. Proposal creator. Rationale:
    5. Date_created. Rationale:
    6. contextURI. Rationale:
    7. Execution data. We’ve created a hash from the function name and params. The hash would then point you to a place where you can read these parameters.
      1. When we propose it, emit some events and store the hash on-chain, it’s inefficient to store all the execution.
      2. function [so really an array of JSON objects? ends up being quite big, but can be decoded. It’s a sequence of squished bytes. some calls are “internal”, but we can represent that state change somehow...]
        1. Do we need to distinguish internal contract calls? An internal only call. Encoded as if it was an external call.
        2. Pass a URI into an event? Effectively gets you the same thing, the exact same trust model. There’s no on-chain trust guarantee that what they put into a JSON is actually what they execute internally, you’re just asking them to describe it. You could SIMULATE it? Maybe we could pose it to an EVM expert on Tenderly, in what format do they store simulations, and could we encourage people to run a simulation and put a simulationURI on there.
          1. Find someone from Tenderly, or OpenZeppelin, that runs these simulations? Tenderly simulation platform.
      3. data
      4. value
  1. Isaac: by putting the proposals on-chain, is the issue that the URI approach is not trustworthy enough?
  1. Isaac: it seems like if we are overly prescriptive, you instantly get DAOs deciding not to adopt.
  1. Eyal: in DAOhaus, you already have all these parameters for proposals: creator, function, params. By itself, a multisig is not a DAO, it’s a treasury.
  1. Eyal: can we put end-date.
 
Action items
Isaac:
Josh: I have a lot of emails to write.
Previous Items
Josh + Isaac: Membership
Ido: Proposals
 
Â