After today’s working group session, Isaac and I came up with the following approach, featuring two approaches to registration:
- for pre-4824 DAOs, the standard registration contract approach that is already in the standard
- for 4824-native DAOs (deployed with the daoURI interface), a minimal registrationLog indexer
In addition to a slightly modified version of Isaac’s code above, here’s the expected addition to the standard:
When a 4824-native DAO factory deploys a 4824-native DAO, the DAO factory SHOULD incorporate a call to logRegistration as part of the DAO’s initialization. If the DAO is ERC-165 compliant, the factory can do this without additional permissions. If it is not, the factory SHOULD first obtain access control rights to the logRegistration contract and then call logRegistration directly with the address of the new DAO and the daoURI of the new DAO.
Any user, including the DAO itself, MAY call logRegistration and submit a registration for a DAO which is both 4824-native and ERC-165 compliant.
Note that we have revised the registration factory for pre-4824 DAOs to also call the minimal indexer contract.
See architecture diagram below.
Some remaining unresolved issues:
- If we need to implement a blacklist / deletions, should we implement that at the indexer level on-chain or at the subgraph level?
- What governance, if any, needs to be attached to the indexer? We probably do not need to specify that in the standard itself.
Just noting that, in the new draft PR, we have added a SHOULD recommendation for access control in the registration contract, without requiring OZ access control. We also added a slightly obvious condition, that a DAO inheriting the EIP4824 interface SHOULD implement a method for updating it.
Hi @thelastjosh ! Tim from OpenZeppelin here.
Few thoughts from my side:
Perhaps there is just a need for standard of SC URIs
daoURI is just being one of them:
- There are
tokenURI in ERC721
- OpenSea uses
contractURI for ERC1155 contract URI
- OpenZeppelin ERC1155Metadata specifies token URI’s in
uri function.
Besides that, there are also EIPs in different stages, including Last Call also specifying URIs:
-
*EIP-5169 with
scriptURI*
- Wallet connect discusses ERC-1328 with URI for WC, which also could be stored in SCs
-
*EIP-1046 proposes to add
tokenURI to ERC20/1155/721 tokens as a requirement*
Perhaps it would make sense to come up with standard for one and only one Smart Contract URI.
Such could potentially be written in a such way that it can point to on-chain data as well as off-chain
I believe that it is still very important to define schemas in a standard. ERC seems like way to go today however I’m wondering if there could be any way that we could define a maintainable registry of Ethereum schemas AND offload EIP registry from need to review these schemas (that would allow ecosystem to develop more quickly)
Few concerns regarding schema
Risks of centralization
Introducing single endpoint for proposalsURI brings in centralization risks. Right now in OpenZeppelin Governor, proposer can set his own proposal URI with IPFS link describing the proposal.
If there is single proposalsURI it brings in concerns of who controls that endpoint.
URI objects proposed should have block numbers
Objects such as membersURI proposed by this EIP can be out-of sync with blockchain state.
I can see in the discussion that this might be out of scope to keep as much DAO specific as possible.
However I would argue that Members object in my understanding can be only relevant to a particular time, as a constantly changing value.
As a potential use-case is ERC20Voting which implements snapshots, if there would be a block number appended to the membersURI it would allow DAO frontends to render voting power purely from URI object, without querying blockchain at all.
Thanks for the comment Tim! Just checking, but I believe we already share some Telegram channels, right? Would love to follow-up with your suggestions in the next engineering chat for 4824.
Perhaps it would make sense to come up with standard for one and only one Smart Contract URI.
I agree that it would be nice to have just a standard smart contract URI for any metadata that a smart contract needs to report. The question is what would you standardize exactly; just that the interfaces all have the same naming format, e.g. tokenURI, contractURI, scriptURI, etc.? Or that they should all share some common namespace so there isn’t conflict?
Note that EAS actually has a system set up to publish Ethereum schemas, at least for attestations (which are pretty generic).
Introducing single endpoint for proposalsURI brings in centralization risks. Right now in OpenZeppelin Governor, proposer can set his own proposal URI with IPFS link describing the proposal.
Interesting idea! I’m not sure this hits the mark though, because proposalsURI is really just an index of the existing proposals in the DAO; each of those proposals can publish an additional URI field that is controlled by the proposer (but this would require some sort of on-chain logic to verify, and proposalsURI is not on-chain). Yes, there is centralization, but that centralization is ultimately inherited from the DAO that controls daoURI.
However I would argue that Members object in my understanding can be only relevant to a particular time, as a constantly changing value.
Agreed.
As a potential use-case is ERC20Voting which implements snapshots, if there would be a block number appended to the membersURI it would allow DAO frontends to render voting power purely from URI object, without querying blockchain at all.
How does this work? Right now, we’re agreed that membersURI does not allow you calculate a member’s voting power without querying the blockchain. What would appending a single block number do to make this different?
