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.

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. 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": "https://www.daostar.org/schemas",
  "type": "DAO",
  "name": "<name of the DAO>",
  "description": "<description>",
  "membersURI": "<URI>",
  "proposalsURI": "<URI>",
  "activityLogURI": "<URI>",
  "governanceURI": "<URI>",
  "contractsURI": "<URI>"
}

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.

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

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.

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.

Relevance to Caper

EIP-4824 is an Ethereum standard, expressed in Solidity and ERC-165, so Caper – which runs on the Radix network – does not implement its interface. 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.

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.
2. Ethereum EIPs repository. Add EIP-4824: Common Interfaces for DAOs (Pull Request #4824). GitHub.
3. DAOstar. metagov/daostar – standards and reference implementations. GitHub.
4. DAOstar. DAOstar documentation – Adopt EIP-4824 and contract reference.
5. DAOstar. DAO ID – the daoURI registry and lookup. daostar.org.
6. DAOstar. DAOIP-5: Grants standard. GitHub.
7. Ethereum. ERC-165: Standard Interface Detection and ERC-721: Non-Fungible Token Standard.