Aragon Protocol

Appearance

Registries and ENS names ​

For the ecosystem to enumerate and trust DAOs and plugins, there has to be a canonical onchain list of each. Two registries provide those lists 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. 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:

  • 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). It serves a different purpose from the two component registries:

  • The DAO and plugin registries register protocol components (contracts), share the InterfaceBasedRegistry base, and are permissioned. Only the official factories may add entries, which 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.

The two component registries share nearly the same design. For the separate identity registry, see member registry.

See also ​