Aragon Protocol

Appearance

Registries and ENS names ​

For the ecosystem to enumerate and trust DAOs and plugins, there has to be a canonical on-chain list of each. Two registries provide exactly that, and give every entry a human-readable ENS name:

  • DAO Registry (DAORegistry) — the canonical list of every DAO the framework creates. The DAOFactory registers each one (optionally as <name>.dao.eth); it's the "is this a genuine framework DAO?" index.
  • PluginRepo Registry (PluginRepoRegistry) — the canonical list of every published plugin repo. The PSP will only install from a repo registered here, so registration is the trust boundary.

One shared pattern: InterfaceBasedRegistry ​

Both registries extend InterfaceBasedRegistry, an abstract base that enforces one rule: only contracts that advertise the right ERC-165 interface can register, and none can register twice. DAORegistry requires registrants to be IDAO; PluginRepoRegistry requires IPluginRepo. This is what stops arbitrary contracts from masquerading as DAOs or repos in the canonical lists.

The base is a UUPS proxy governed by a Management DAO (via DaoAuthorizable): registration itself is permissioned (REGISTER_DAO_PERMISSION_ID / REGISTER_PLUGIN_REPO_PERMISSION_ID), held by the DAOFactory and PluginRepoFactory respectively, so only the official factories can add entries.

ENS subdomains ​

Each registration can claim a subdomain under a protocol-owned ENS parent (e.g. myorg.dao.eth, myplugin.plugin.dao.eth). The ENSSubdomainRegistrar mints these:

  • It keeps ownership of every subnode itself and only sets the resolver's address record to point at the DAO or repo. So names can't be transferred away from the protocol, they always resolve to the registered contract.
  • Subdomain characters are validated (a-z, 0-9, -) by RegistryUtils.isSubdomainValid.
  • It requires off-chain setup: the registrar must be made owner/operator of the ENS parent node before it can mint children.

Whether a name is required depends on the registry and the release, so this bites in practice:

  • DAOs, always optional. DAORegistry registers the DAO whether or not you pass a subdomain; an empty one just skips the ENS step.
  • Plugin repos, version-dependent. Through v1.3.0 a subdomain was required, an empty one reverts EmptyPluginRepoSubdomain. v1.4.0 relaxed it to optional. So on older deployments a name is mandatory; treat providing one as the norm regardless. (PluginRepoFactory still carries a stale @dev comment claiming empty reverts, a leftover from the v1.3.0 rule.)
  • Duplicates always revert (AlreadyRegistered): a subdomain can be claimed once, and a contract can't register twice.

A third registry, deliberately separate ​

A MemberRegistry also mints ENS names (Aragon's binds to aragon.eth, so alice.aragon.eth), so it's tempting to file all three together. It's kept apart on purpose, because it isn't the same kind of thing:

  • The DAO and plugin registries register protocol components (contracts), share the InterfaceBasedRegistry base, and are permissioned, only the official factories may add entries, which is exactly what makes them a trust boundary.
  • The member registry gives members an optional, free ENS handle (a fallback for those who don't want to buy one), is permissionless (anyone self-registers), and is built on a different base entirely (no InterfaceBasedRegistry). It shares only the ENS subnode-custody pattern.

So the grouping is two near-identical component registries plus one identity registry that merely rhymes with them, which is why this page covers the first two and the member registry stands alone.

See also ​