EIP-4824, titled Common Interfaces for DAOs and published on Ethereum as ERC-4824, is a standard that gives any decentralized autonomous organization a single, tool-agnostic way to describe itself. It defines one on-chain function, daoURI(), that returns a link to a structured document listing the DAO's members, proposals, activity, governance, and associated contracts. It is the DAO analogue of the tokenURI that lets any wallet read an NFT without knowing which contract minted it.

The standard makes a deliberate distinction: it does not standardize DAOs, only the data about them. A proposal created in one framework becomes readable by an indexer, a voting front-end, or a rival tool built by someone who has never seen the original contract. EIP-4824 was authored through DAOstar, the standards body for DAOs, and is the founding member of that group's DAOIP series, where it carries the number DAOIP-2.

It has never been finalised. Four and a half years after it was created, the specification still carries the status Review – "in the process of being peer-reviewed" – and the canonical citation string Ethereum generates for it reads ERC-4824: Common Interfaces for DAOs [REVIEW]. The rest of this page treats that as the starting question rather than a footnote: the design is well made and the argument for it is sound, so what happened when it met the ledger?

The interoperability problem

DAOs multiplied faster than any agreement on how to represent them. A Aragon DAO, a Compound-style Governor, a Moloch guild, and a Safe multisig each store membership and proposals in incompatible ways – some keep an explicit on-chain member list, others derive membership from token balances, and many run their votes off-chain on Snapshot entirely. A tool that wants to read across this landscape has to hand-write an adapter for every framework it supports.

The EIP's motivation is that this fragmentation blocks the things a maturing ecosystem needs: discoverability of DAOs, legibility of their governance, simulation of proposals before they execute, and portability of members and history between tools. A shared data format is treated as a prerequisite for future DAO standards, the way tokenURI and ERC-165 interface detection became prerequisites for the NFT tooling that followed. Rather than force every DAO onto one governance model, EIP-4824 asks only that each one publish a description a machine can read.

The daoURI interface

The on-chain surface is intentionally tiny. A compliant contract implements a single interface, and signals that it does so through ERC-165 interface detection:

interface IERC4824 {
    event DAOURIUpdate(address daoAddress, string daoURI);

    function daoURI() external view returns (string memory _daoURI);
}

The daoURI() function returns a URI – typically an HTTP, IPFS, or data URI – pointing at the DAO's description document. Its selector is 0x7034731b, which makes conformance a one-call test against any address: a contract that implements the interface answers, and one that does not reverts. The DAOURIUpdate event lets indexers track changes without polling. The EIP recommends that contracts implement access control around updating the URI, so that changes follow the DAO's own governance rather than an arbitrary key, and that any field with no value be omitted rather than left empty or null. A DAO may implement IERC4824 directly in its governance contract or delegate it to an external registration contract, which lets already-deployed DAOs adopt the standard without migrating.

The DAO description document

The URI dereferences to a JSON-LD object. At the top level it names the DAO and points to five subsidiary documents:

{
  "@context": "http://www.daostar.org/schemas",
  "type": "DAO",
  "name": "<name of the DAO>",
  "description": "<description>",
  "membersURI": "<URI>",
  "proposalsURI": "<URI>",
  "activityLogURI": "<URI>",
  "governanceURI": "<URI>",
  "contractsURI": "<URI>"
}

That @context line is reproduced exactly as the specification writes it, and it is worth noticing that the specification does not write it consistently: the top-level DAO example uses http://www.daostar.org/schemas while every subsidiary schema in the same document – members, proposals, activity log, contracts – uses https://www.daostar.org/schemas, and the clause governing appended-URI fields makes the https form a MUST. The consequence shows up in the published corpus, discussed below.

Each subsidiary document may be linked by URI or embedded inline by dropping the URI suffix (writing members instead of membersURI), so a small DAO can ship everything in one file while a large one splits its data across services. The four data documents each describe one facet of the organization:

• Members. An array of member objects, each identified by a CAIP-10 account (for example eip155:1:0x…), a Decentralized Identifier (did:…), or another URI. The URI-and-DID design is the reason the EIP chose JSON-LD over plain JSON: it accommodates members that are not Ethereum addresses and DAOs that span multiple chains.
• Proposals. An array of proposals, each with an id, name, a contentURI and discussionURI pointing at the text and the debate, a free-text status, and a list of calls describing the on-chain actions the proposal would execute. On-chain proposals use a canonical id of the form CAIP-10 address + "?proposalId=" + counter. The status is free text on purpose, because Aragon, Compound, DAOstack, Moloch, and Colony all enumerate proposal states differently.
• Activity log. An array of activities, each relating a member to a proposal – a creation, a vote, a dispute – so that the history of who did what can be reconstructed.
• Contracts. Every contract associated with the DAO, each with an id, name, and description. Publishing the full set lets an indexer audit a multi-contract or cross-chain DAO and, as the security section notes, guards against spoofing.

The governanceURI is deliberately looser: the EIP recommends a plain-text or Markdown file describing the DAO's rules and the rights its members hold – voting power, exit rights, veto powers – rather than an attempt to encode governance itself, which it considers too varied and too often off-chain to standardize.

Publishing and indexing

DAOstar defines three ways a daoURI can reach an indexer. A DAO can inherit IERC4824 directly in its governance contract; it can register through a factory or registration contract; or a trusted service provider can report it on the DAO's behalf through an attestation, following the companion standard DAOIP-3. The first two paths are covered by EIP-4824 itself (DAOIP-2); the third lets DAOs that will never upgrade their contracts still become discoverable.

To make registration observable, the EIP specifies an index contract that emits a DAOURIRegistered event. Permissionless registration checks that the target actually implements the interface before logging it:

function logRegistration(address daoAddress) external {
    if (!daoAddress.supportsInterface(type(IERC4824).interfaceId))
        revert ERC4824InterfaceNotSupported();
    emit DAOURIRegistered(daoAddress);
}

When the same DAO is registered more than once, the most recent registration and those published through a factory take precedence, giving indexers a deterministic rule for resolving duplicates. That event is also what makes the standard auditable from outside: because registration is deliberately observable, anyone can count it.

Design choices, compatibility, and security

The standard's central bet is to push complexity off-chain. On-chain proposal formats were judged premature given emerging patterns such as multi-DAO and "master–minion" proposals, and because proposal systems are tightly coupled to governance systems that vary widely. Storing the rich data behind URIs keeps the on-chain footprint to one function and makes adoption as easy as tokenURI was for NFTs, at the cost of trusting whatever service the URI points at to stay available and honest.

Because it adds rather than changes behavior, EIP-4824 is fully backward compatible: contracts that do not adopt it are unaffected, and those that do can adopt through an external registration contract with no migration. The security considerations flag three risks. URI updates should follow the DAO's governance, so a single compromised key cannot rewrite the DAO's public description. Indexers should be wary of executable code returned from a URI, which could do more than serve data. And because multiple addresses may report the same daoURI, the contractsURI list is the mechanism for detecting a contract that spoofs another DAO's identity. The specification is released into the public domain under CC0.

Adoption, as claimed

EIP-4824 was written in the open through DAOstar's roundtable series, with participants from Aragon, Compound, DAOstack, Gnosis, Moloch, OpenZeppelin, and Tribute, and refined across more than fifty biweekly community calls and sessions at Schelling Point, ETHDenver, and DAO workshops at Harvard and Stanford. That process is visible in who implements it.

On the tooling side, adopters include Snapshot and Snapshot X, Aragon, Moloch v2 and v3 via DAOHaus, Safe, DAOstack, DAODAO on Cosmos, KALI, Q, Power Protocol, and XDAO. Among individual organizations, the Optimism Collective, the Arbitrum Foundation, ENS DAO, 1inch, ShapeShift, Unlock, and Lodestar have published a daoURI. Optimism funded rounds of adoption work and the attestation framework, and DAOstar maintains a public registry so that any of these DAOs can be looked up through a single DAO ID interface.

That paragraph is a summary of DAOstar's own materials, and every list of this kind should be read as a claim rather than a measurement. The standard is unusual in that its claim can be checked: the index contract exists precisely so registration leaves a public trace. The next section does the count.

DAOstar and the DAOIP family

DAOstar describes itself as the standards body of DAOs and is maintained by DAOstar One with support from the Metagovernance Project. It began as an alliance of the major players in the DAO ecosystem and now publishes a numbered series of DAO Improvement Proposals (DAOIPs), of which EIP-4824 is DAOIP-2 and the anchor the others build on.

The series extends the same daoURI pattern to new domains. DAOIP-3 defines an attestation format – developed under the name Voyager – that lets service providers vouch for DAO data and record member contributions, compatible with soulbound tokens, DIDs, and verifiable credentials. Later proposals add facets to the DAO document: DAOIP-5, for example, standardizes grant pools by adding a grantPoolsURI field, bootstrapping discovery of on-chain grants the same way membersURI bootstraps discovery of members. The through-line is a bet that legibility – a common language for reading organizations – is the layer on which DAO interoperability is built. Full contract and adoption documentation lives in the DAOstar docs and the metagov/daostar repository.

What the registry actually contains

The DAOURIRegistered event was specified so that registration would be observable without trusting anyone's list. DAOstar's subgraph manifest names the deployed index contract on each network, and reading each one's full log history gives the complete on-chain registry. Four of the eight named deployments are production networks; the rest are the Goerli, Optimism-Goerli, Arbitrum-Goerli, and BNB Chapel testnets.

Network	Index contract	DAOURIRegistered	First	Last
Ethereum mainnet	0x4f2c9028fE7107d9f1A8a9CFf34aa2d3F28600fa	4	9 Aug 2023	12 Feb 2024
Arbitrum One	0x18CbB356cd64193b1a0CA49911fc72CB3D02a5E4	19	17 Jan 2024	17 May 2024
Optimism	0x18CbB356cd64193b1a0CA49911fc72CB3D02a5E4	6	4 Sep 2023	22 Feb 2025
Gnosis	0x8180cbfBFFe59F54BF3Ea5d7DdbaE1232e2bB298	1	30 Apr 2023	30 Apr 2023
Total		30	30 Apr 2023	22 Feb 2025

Thirty registrations, and the most recent anywhere is more than a year old. The distinct-organization count is smaller still, because the registry contains duplicates, tests, and DAOstar's own house DAOs:

• Ethereum mainnet, 4. Two of them are the standards body registering itself – "DAOStar Devs SubDAO" (0xD14C…ed5b) and "MetagovDAO" (0x48D1…8104), both Safe multisigs, registered twenty-five minutes and four hours after the index contract was deployed, on the same August morning. The other two are genuine third parties: 1inch DAO (a Safe) and Unlock DAO (the UnlockProtocolTimelock contract).
• Optimism, 6. The Optimism Collective registered twice with the same document, alongside LXDAO and Tulip DAO – and two entries named "Test Treasure" and "Test OP Mainnet", left in the permissionless index alongside the real ones.
• Arbitrum One, 19, the largest deployment and the one DAOstar's checked-in subgraph indexes. Seven of the nineteen resolve to the identical Treasure document (CID QmYYep…VJCq), reached through four different URI spellings of the same file. Two more are 1inch, pointing at the same CID as its mainnet registration; two are Lodestar Finance. The remaining eight are placeholders – "Rose DAO", "Blue DAO", two documents both named "Orchid DAO" with the descriptions "Find beautiful rare orchids" and "sunflower", another "Test Treasure" – plus one contract whose daoURI() returns a bare Ethereum address, 0x5C0340AD34f7284f9272E784FF76638E8dDb5dE4, which is not a URI and cannot be dereferenced at all.
• Gnosis, 1. "DAO* Strike Team", DAOstar's own working group again, and its document ships "description": null – the exact shape the specification says SHOULD be removed rather than left null.

Across all four networks that leaves roughly eight distinct third-party organizations: 1inch, Unlock, the Optimism Collective, LXDAO, Tulip DAO, Treasure, Lodestar, and the Gnosis entry. Two names from the claimed list are absent from every index deployment. Calling daoURI() directly confirms it: the selector reverts on ENS DAO's Governor (0x323A…b7E3) and its timelock (0xFE89…44b7), and on both of Arbitrum's governors, core (0xf07D…95B9) and treasury (0x789f…e5a4). It also reverts on Optimism's GovernorV6 – the Collective is a real adopter, but through the external-registration path, not by inheriting the interface.

Two caveats keep this honest. The index is one of three publication routes, so a DAO that implements daoURI() in its own contract without registering leaves no event, and a DAO reported by a third party under DAOIP-3 leaves none either; the same applies to a Snapshot space carrying the field off-chain. And no registration contract on any of the four networks has ever emitted a second DAOURIUpdate – the event designed to let indexers track changes has never once fired twice. Whatever these organizations published, none of them has revised it.

The pointers outlived the data

EIP-4824's explicit trade was to keep the chain small and put the substance behind a URI, "at the cost of trusting whatever service the URI points at to stay available". The registry is now a controlled experiment in what that costs.

The description documents themselves are fine. Every IPFS-hosted daoURI in the registry still resolves through a public gateway, returns the JSON it returned on the day it was pinned, and is byte-for-byte immutable by construction. What has failed is the layer below – the membersURI, proposalsURI, and activityLogURI those documents point at, which is where the members, proposals, and activity actually live:

• services.daostar.org no longer exists. It has no A record and no CNAME at Cloudflare, Google, or Quad9 resolvers. Every mainnet registrant and the Gnosis registrant routes its members and proposals through that host; so does Treasure, the most-registered DAO on Arbitrum. The pointer resolves, the payload does not.
• api.daostar.org resolves but does not answer. It has an A record (174.138.59.179) and then times out on both port 80 and port 443. That host is Unlock DAO's entire daoURI on mainnet and six of the nineteen Arbitrum registrations, so for those the failure is one level higher – the DAO description document itself is unreachable.
• proposalsuri.daostar.org returns 503. That is the Optimism Collective's proposalsURI, and the hostname reads like the placeholder it evidently was.

The pattern is worth naming because it is not the failure anyone designs against. Nothing was hacked, no key was compromised, no DAO revoked anything. The immutable part stayed immutable and the operational part quietly stopped being operated, and because the standard's whole promise is follow this pointer to read the organization, an unreachable second hop empties the standard out while every on-chain check still passes. A registry that reports thirty conforming DAOs and cannot return a single current member list is conforming and useless at the same time. This is the same decay the wiki has documented in DeSci's shared reference layer, arriving from a different direction.

Where the published documents diverge from the specification

Reading all thirty registrations' documents against the specification turns up a second, quieter problem: near enough none of them conforms, and the divergences are systematic rather than sloppy.

• The @context is written four different ways. The corpus contains <http://www.daostar.org/schemas>, http://www.daostar.org/schemas, and https://www.daostar.org/schemas, sometimes across documents published on the same day by the same tool. The first form is the worst: angle-bracket delimiters are Turtle and N-Triples syntax, not JSON-LD, and a processor reading @context as an IRI string will not resolve it. Both spellings 404 in any case – there is no schema document at daostar.org/schemas. For a standard whose one job is machine-readability, the field that tells a machine how to read the document is the field least reliably written.
• Three fields in wide use are not in the specification. issuersURI, contractsRegistryURI, and managerAddress appear in most published documents and zero times in the text of ERC-4824. They are tooling conventions that hardened into the corpus without passing through the standard.
• contractsURI is absent everywhere. The specification's security section makes it the anti-spoofing mechanism – "all DAOs adopting this specification SHOULD publish through contractsURI the address of every contract associated to the DAO" – precisely because multiple addresses may report the same daoURI. Not one registration publishes it. Where the intent survives at all it is as contractsRegistryURI pointing into a JSON file in DAOstar's own GitHub repository, which relocates the anti-spoofing claim from the DAO to the standards body.
• Empty strings where the specification asks for omission. ERC-4824 states that a field with no value "SHOULD be removed rather than left with an empty or null value". 1inch, Unlock, the Optimism Collective, and Treasure all ship ""; the Gnosis registrant ships null.
• Two on-chain values are not URIs. One Arbitrum registration stores its daoURI with the JSON quote characters baked into the string, so the value a caller receives is "https://ipfs.io/…" including the quotes; another returns a bare Ethereum address. Both passed the index's supportsInterface check, because that check tests for the interface, not for whether the string it returns means anything.
• Where the machine-readable document points at a web page. The Optimism Collective's activityLogURI is https://gov.optimism.io/, a forum homepage; the DAOStar Devs SubDAO's is a Safe web-app URL with a query string. The specification defines the activity log as an array of activity objects. What was published is a link a human can click.

None of this is an argument against the design. It is an observation about what a SHOULD buys you when nothing validates: the interface was adopted, the schema was not, and the index cannot tell the difference because the only thing it checks is ERC-165. A conformance suite run at registration time – rejecting a malformed @context, an empty string, a missing contractsURI – would have caught every defect on this list at the moment it entered the registry. It is a cheap lesson for anyone specifying the next metadata standard: the data is only as good as the gate.

From "the DAO standard" to "the DAO metadata specification"

DAOstar has been quietly candid about all of this in the one place a standards body cannot avoid being candid: its own repository. On 12 August 2025, a commit titled archive daoip2 rewrote the daostar.org homepage headline from "The DAO standard" to "The DAO Metadata Specification", commented out the "Attestations for DAOs" call to action, and commented out both the "The DAO Standard" explainer section and the "Governed by DAOstar One" roundtable section that listed the alliance's member organizations. A follow-up commit four minutes later finished the navigation: the top-level "Standard" link became "Specification", and "Research" was removed.

The new headline is the more accurate one, and the page said as much from the beginning – EIP-4824 standardizes the data about DAOs, not DAOs. What changed is that the standards body stopped claiming the larger thing. It is rare to be able to date a repositioning to a commit hash, and rarer for the correction to move toward candour rather than away from it.

The rest of the repository tells the same story about where the effort went. The only substantive DAOIP commits in 2025 are to DAOIP-5, the grants standard, and the docs site now leads with OpenGrants rather than daoURI. The last push to metagov/daostar was 31 October 2025. On the Ethereum side, EIPS/eip-4824.md in the EIPs repository is now a stub carrying status: Moved, pointing at ethereum/ERCs, where the specification's own front matter still reads status: Review. The pull request that added it, #4824, was merged on 4 September 2022 and the status has not advanced since.

Read together, the honest summary is that EIP-4824 is a well-designed interface that solved a real problem and was never adopted at the scale its framing implied, whose sponsoring body has since narrowed both its claim and its focus. That is a more useful thing to know about a standard than a list of logos, and it is knowable only because the standard was built to be counted.

Relevance to Caper

EIP-4824 is an Ethereum standard, expressed in Solidity and ERC-165, so Caper – which runs on the Radix network – implements neither the daoURI() view nor ERC-165 detection. It does publish the other half of the standard: the DAO description document those interfaces exist to point at. What it shares is the problem the standard exists to solve. Every caper is a DAO, and the facets EIP-4824 works to expose for legacy DAOs – its members, its proposals and votes, its activity, and its treasury and contracts – are recorded natively on the Radix ledger and surfaced on the caper's own page. Where EIP-4824 retrofits legibility onto DAOs that were built without it, a caper is legible by construction.

Every caper serves that document at /capers/<CASHTAG>/dao.json – $CAPER's is a worked example – carrying @context: https://www.daostar.org/schemas, type: DAO, and the five subsidiary fields. Members are identified by their explorer URI rather than a CAIP-10 address, since Radix accounts fall under no registered CAIP-2 namespace and the specification allows "another URI identifier" for exactly this case. Proposals carry their status verbatim, the execution transaction where one exists, and the payout, invest and divest calls they authorise. The document is generated from ledger and platform state on each request rather than stored, and the site's agent card publishes the daoUriTemplate that builds its URL from any cashtag. Reading it alongside the rest of the machine-readable surface is covered on Querying a caper from an AI agent.

Held to the same checklist as the thirty registrations above, the result is mixed, and it is worth stating plainly rather than claiming conformance. Caper publishes contractsURI – the anti-spoofing field not one registered DAO publishes – and enumerates every on-ledger component that constitutes the organization: its DAO component, its treasury account and treasury component, its governance-token and vote-token resources, and its founder and treasury-admin badges, with a vote-executor badge joining the list where the DAO has one. It writes @context in the one unambiguous form. Against that, it commits the same omission error as 1inch, Unlock and the Optimism Collective, in array rather than string form: a DAO with no members or proposals yet ships members: [] and proposals: [], where the specification says a field with no value SHOULD be removed. It carries both the membersURI and the embedded members form, where the specification's embedding rule renames the field instead of duplicating it – the URI variants address fragments of the same document, so a consumer following either lands on the same data. And its governanceURI resolves to an HTML page, where the specification asks for a flatfile, "normatively a .md file".

One structural difference outranks all of those. Nothing on the Radix ledger announces where the document lives, so no indexer can discover a caper the way the DAOstar index discovers an Ethereum DAO – by watching a registration event. That is the mirror image of the failure documented above. Thirty registrations left an immutable on-chain pointer to an off-chain document that eventually stopped answering; a caper publishes an off-chain document over an on-chain record that keeps answering either way. Were caper.network to stop serving dao.json tomorrow, the membership, the proposals and the treasury would all still be on the ledger. What would be lost is the common interface that lets a stranger read them without knowing Caper's contracts – which is precisely the thing EIP-4824 was written to provide, and precisely the thing that turns out to be nobody's job to keep alive.

The failure mode documented above is the sharper lesson, and it is not about which chain anyone chose. It is that a description behind a hostname needs someone to keep paying for the hostname. A caper's proposals, its ballots, its participant list, and its treasury are component state on the ledger – there is no second hop to a service that can quietly stop answering, and nothing to re-host when a grant ends. That is a narrower guarantee than the one EIP-4824 set out to provide, since it says nothing about DAOs on other networks, but it is the part of the promise that has proved hardest to keep.

The DAOstar effort is worth reading precisely because it names what makes a DAO usable to the wider world: not the framework it was built with, but whether an outsider can read its membership, follow its decisions, and audit its holdings. That is the standard against which any launchpad's transparency, Caper's included, is fairly judged.

References

1. Joshua Tan, Isaac Patka, Ido Gershtein, Eyal Eithcowich, Michael Zargham, and Sam Furter (2022). ERC-4824: Common Interfaces for DAOs. Ethereum Improvement Proposals, no. 4824. Status: Review.
2. Ethereum. erc-4824.md in the ethereum/ERCs repository (the specification's current home), and Pull Request #4824, merged 4 September 2022.
3. DAOstar. metagov/daostar – standards and reference implementations. GitHub.
4. DAOstar. Subgraph networks.json – the index contract address and start block on each deployed network.
5. DAOstar. Commit archive daoip2, 12 August 2025, and its navigation follow-up.
6. DAOstar. DAOstar documentation – Adopt EIP-4824 and contract reference, and DAO ID – the daoURI registry and lookup.
7. DAOstar. DAOIP-5: Grants standard. GitHub.
8. Ethereum. ERC-165: Standard Interface Detection and ERC-721: Non-Fungible Token Standard.
9. W3C. JSON-LD 1.1 and RDF 1.1 Turtle – the two syntaxes whose @context conventions the published corpus mixes.
10. Registry census (9 August 2026): full DAOURIRegistered and DAOURIUpdate log histories of the index contracts on Ethereum mainnet, Arbitrum One, Optimism, and Gnosis, read via public block explorers; daoURI() (selector 0x7034731b) read by eth_call against each registered address and against the ENS, Arbitrum, and Optimism governance contracts; each resulting document fetched from its stated URI.