• DAO discovery, e.g. via aggregators like Etherscan, DeepDAO, or Messari

• multi-DAO joint or conditional proposals,

• DAOs of DAOs,

• and other DAO-to-DAO interactions, e.g. Moloch DAOs using “minions” to operate a Gnosis Safe, or other forms of whole- or partial ownership.

pragma solidity ^0.4.20;

/// @title ERC-1234 DAOs
/// @dev See https://eips.ethereum.org/EIPS/eip-1234

interface ERC1234 {
    /// @notice A distinct Uniform Resource Identifier (URI) pointing to a JSON object following the "EIP-1234 DAO JSON-LD Schema". This JSON file splits into four separate URIs: membersURI, proposalsURI, interactionsURI, constitutionURI. The membersURI should point to a JSON file that conforms to the "ERC-1234 Members JSON-LD Schema". The proposalsURI should point to a JSON file that conforms to the "ERC-1234 Proposals JSON-LD Schema". The interactionsURI should point to a JSON file that conforms to the "ERC-1234 Interactions JSON-LD Schema". The constitutionURI should point to a flatfile, normatively a .md file. Each of the JSON files named above can be statically-hosted or dynamically-generated. 
    function daoURI() external view returns (string _daoURI);
}

{
"@context": "https://www.daostar.org"
"@type": "DAO"
"membersURI": "<URI>",
"proposalsURI": "<URI>",
"interactionsURI": "<URI>",
"properties": {
		"description": "<description>",
		"governanceURI": "<URI>"
	}
}

{
	"@context": {
		"@vocab": "http://daostar.org/"
	},
	"members": [{
			"memberId": {
				"@type": "EthereumAddress"
				"@value": "<address>",
			}
		},
		{
			"memberId": {
				"@type": "EthereumAddress"
				"@value": "<address>",
			}
		}
	]
}

{
	"@context": {
		"@vocab": "http://daostar.org"
	},  
	"@type": "Proposal",
	"metadata": {
		"@type": "proposalMetadata",
		"proposalId": "[CHAIN_ID][CONTRACT_ADDRESS][PROPOSAL_ID]",
		"title": "<title>",
		"contentURI": "<contentURI>"
	},
	"status": {
		"@type": "proposalStatus",
		"description": "<description>"
	},
	"executionData": {
		"calls": [
		{	
			"@type": "callDataEVM",
			"from": "<address_1>",
			"to": "<address_1>",
			"data": "<call_data_1>",
			"call_type": "<call or delegate call>",
			"value": "<call_value_1>"
		} ,
		{
			"@type": "callDataEVM",
			"from": "<address_2>",
			"to": "<address_2>",
			"data": "<call_data_2>",
			"call_type": "<call or delegate call>",
			"value": "<call_value_2>"
		}]
	},
}
	

An example of an ERC-1155 Metadata JSON file follows. The properties array proposes some SUGGESTED formatting for token-specific display properties and metadata.

{
	"@context": "https://www.daostar.org"  
	"@type": "ActivityLog",
	"proposalId": "<proposal_id>",
	"member": {
		"@type": "Member",
		"address": "<address>"
	},
	"interactionData": {
		"@type": "interactionDataBase",
		"description": "<description_text>"
	}
}

• Metadata: In many cases, a proposal will have some off-chain context (e.g. a forum post) which predates the actual proposal object. The meta-data includes description properties (e.g. the proposal title, URI of the proposal content and context), timing properties (e.g. start time, end time) and the submitter of the proposal.

• Status/state: A proposal will have a set of possible states and the current state indicates the status of the proposal (e.g. passed, executed).

• Governance: A proposal has some governance method attached to it. The governance defines the rules which control the transitions between the possible states of the proposal.

• Execution: A proposal may include some implied execution or may serve as a signal generator. In case the proposal implies execution (we refer to it as binding execution), the execution can be either an on-chain or an off-chain action.

Compound

1. Dilger, W. (1997). Decentralized autonomous organization of the intelligent home according to the principle of the immune system’. 1997 IEEE International Conference on Systems, Man, and Cybernetics. Computational Cybernetics and Simulation, 351–356. https://doi.org/10.1109/ICSMC.1997.625775

2. Buterin, V. (2013a). Ethereum whitepaper: A next-generation smart contract and decentralized application platform [White Paper]. https://blockchainlab.com/pdf/Ethereum_white_paper-a_next_generation_smart_contract_and_decentralized_application_platform-vitalik-buterin.pdf

3. JSON-LD Schema. https://json-ld.org/

4. ...

1. Use JSON-LD instead of JSON. Rationale: JSON-LD seems like it may be unnecessary overhead for the Ethereum/EVM use-case, since there is a centralized EIP process + standard for documenting the meaning of JSON objects. However, it may be useful for multi-chain use-cases. what will be the standards environment be there, will having context files be really useful / necessary if we imagine the ecosystem gets much more complicated. Further, if in 3 months when we are making a multichain standard and decide this would be really useful to have, then we can change the draft standard (since it will very likely still be in the EIP comment period at that time). If we end up going the JSON-LD route, we can host the schema file at daostar.org.

2. We will use addresses instead of DIDs; we MAY include DID as an optional field in the JSON. Rationale: DIDs are not yet a widely-adopted standard, and will not always be relevant or preferred for certain DAO use-cases. In the members JSON schema, DAOs can optionally include a DID reference. However, we believe that DID could benefit a substantial number of use-cases and MAY include it as an optional field in the members JSON.

3. Do we want to include a chainID property as mandatory in proposals or in the metadata extension?

4. The members URI should point to an off-chain JSON file or endpoint that returns a JSON schema, full-stop. But we will still provide 1-3 demo methods (incl. endpoints for Moloch, DAOstack, Aragon) that produce this JSON schema. Rationale: compared to alternatives below, this is more straightforward and substantially less risky than pointing to a piece of unsecured code and asking users to run it to obtain a members JSON. compared to a URI that points to a JSON file or a piece of code that returns a JSON, we expect many DAOs will subscribe to endpoints maintained by aggregators or framework providers.
What about on-chain membership data that is not queryable?
Alternative 1: membersURI should point to a JSON file or an arbitrary method that returns a JSON file (no guarantees)
Alternative 2: membersURI should point to a JSON file or an arbitrary method that returns a JSON file (no guarantees), and here are 1-3 demo methods as archetypes
Alternative 3: membersURI should point to a JSON file or an arbitrary method that returns a JSON file, and use this “universal resolver” that guarantees some of the computation.
A resolver or a driver is a piece of code that, in this case, takes as input the DAO address and outputs the members JSON. In between, it can run arbitrary code, including reaching out to external services and data sources. It guarantees that what you run will return a JSON-LD object.
NOTE: if you make it too easy to create resolvers / drivers, that might create bloat. Ref. explosion of DID methods.
If so, which examples of resolvers do we want to implement as examples?
• Parse graph index, return JSON
• Run arbitrary Rust code, return JSON

5. Are we focusing too much on data science use-cases and not enough on on-chain use-cases like DAO-to-DAO interaction? ...

6. Do NOT include a choices or options property in the JSON-LD schema, as below, since ...