Remaining tasks:

• [x] UUID specification for proposals
  • [x] Not sure we can guarantee all proposals will fit into this.
• [ ] Writing
  • [x] Structure / rewrite optional extensions
  • [x] Use-cases - highlight discoverability/legibility, sensemaking, execution simulation
  • [x] rationale / discussion for why and why not proposal object that exposes current discussion to core devs in EthMagicians.
    • [ ] In asking for an off-chain JSON schema, we did so because (1) it is still unclear what the use-cases are for standardizing an on-chain proposal object, (2) there was a sense in the community that , but that frameworks would be unlikely to adopt Because ( comes down to the lack of use-cases for a standard on-chain proposal object; “the frameworks are not going to adopt the standard if we force them to represent proposal on-chain”. By the time we submit, it’s basically just the call since all the proposal-specific actions might have been taken care of through off-chain signatures.
    • [x] DAOs occupy a spectrum from on-chain to off-chain.
    • [ ] After today’s call, I think I don’t understand enough about the typical control flow of proposals in these DAOs, when things transition from off- to on-chain, to fully articulate the need & the use-cases for on-chain formalization of “proposals” as opposed to the base execution data.
    • [ ] We are fundamentally answering simple questions about what, who, how does it make decisions, what is it doing / what is its history.
  • [x] Lucia: create + pop-in table for all the proposals states of the contracts collected
  • [x] Lucia: create + pop-in a table for voting options
  • [x] Add MUST, SHOULD, MAY language to clarify different fields of proposalsURI.
    • [x] Zargham: The fact that the status field is free text may be a bit concerning, but the fact that the status types are coming from code is a bit easier.
    • [ ] Zargham: as a data scientist, I would want an index of types of status.
      • [ ] Possible status
  • [x] Write up rationale for why no back link in daoURI.
• [ ] Write Ethereum Magicians post: recommendation, DON’T BE SHY, BE BOLD, we want this NOW and exactly as it is, we don’t want to equivocate much. On proposal objects: this is out-of-scope.
  • [ ] Something to include in the EthMag rationale: learn from this standard before we project on-chain rigidity.
  • [ ] However, there is one use-case that we might want to focus on, e.g. on-chain signature/authorization of proposals, typically by other contracts.
  • [ ] Add “reporting standard” language.
• [x] Address in daoURI, choose one of:
  • [ ] Instead of “address”, should it be “@value”?
  • [ ] Include: more visible, very standard + intuitive, less dangerous than include as array
  • [ ] Include as array: explicitly support and name multiple contract addresses affiliated with the URI, makes sense given current contract architectures
  • [x] Not include: parsimony, can be inferred from context, allow multiple contract addresses mapping to the same daoURI
• [ ] Name decisions
  • [x] constitutionURI vs. governanceURI
  • [x] interactionsURI vs. activityLogURI
• [x] Isaac: moloch implementation
  • [x] Members
  • [x] Proposals (there are distinct proposal types)
  • [x] Activity log
• [ ] Implement JSON-LD context files and host them on daostar.org
  • [x] Where will the context live? Options: daostar.org, schema.org, ethereum.org, in-line (in EIP), etc.
    • [x] Choice: daostar.org
• [x] Re-organize all these decisiosn so we can hit them more efficiently for next time.
• [x] Optional metadata stuff.
• [ ] BY FEB. 4, PUBLISH TO ETHEREUM MAGICIANS
• [ ] BY FEB. 15, SUBMIT EIP DRAFT
• [ ] [Save for later, please.] Define userflows for how people will be able to publish extensions of the schema, e.g. via GitHub PRs.

Simple Summary

Standardized interfaces and behaviors for decentralized autonomous organizations (DAOs).

Abstract

Standardized interfaces and behaviors for decentralized autonomous organizations (DAOs) and related contracts, focusing on relating on-chain and off-chain representations of membership and proposals.

Motivation