Aragon Protocol

Appearance

Protocol Factory ​

The Protocol Factory brings OSx itself up on a new EVM chain. Where the DAO Launchpad deploys one DAO onto an existing protocol, this deploys the protocol: the whole framework, its ENS naming, the governing Management DAO, and the core plugin repos, wired together in one deterministic orchestration.

The problem it solves ​

OSx is a framework, not a single contract. Before anyone can create a DAO on a chain, that chain needs the entire framework live and correctly cross-permissioned: the DAO base implementation, the DAO and plugin registries, the PluginRepoFactory, the PluginSetupProcessor, the DAOFactory, an ENS setup for dao.eth and plugin.dao.eth, and the core plugins published so they can be installed. That is a large graph of contracts and permissions; wiring it by hand, transaction by transaction, is both error-prone and dangerous (each intermediate state leaves the protocol's control in flux). The factory makes standing it up a single, reviewable, deterministic event, so every chain gets the same canonical, correctly-owned deployment.

What it stands up ​

  • OSx framework — the registries, the DAOFactory and PluginRepoFactory, the PluginSetupProcessor, and the shared executor, deployed as proxies over their base implementations.
  • ENS naming — a registry + resolver and two subdomain registrars (dao.eth for DAOs, plugin.dao.eth for plugin repos), so registered DAOs and repos get resolvable names.
  • The Management DAO — the DAO that governs the protocol (below).
  • The core plugin repos — Admin, Multisig, Token Voting, SPP, and Lock to Vote, each published into its own PluginRepo owned by the Management DAO.

The Management DAO governs the protocol ​

The linchpin is the Management DAO: an ordinary OSx DAO, governed by a Multisig, that owns the protocol's shared infrastructure. It holds the permissions to register upgrades on the registries, operate the ENS subdomain registrars, and maintain the core plugin repos (publishing new versions). In other words, the protocol is self-governed by an Aragon DAO: changing a registry implementation or shipping a new core-plugin build is itself a governance action of the Management DAO, not a privileged key. OSx runs on OSx.

Deploy once, then read-only forever ​

The factory is also a permanent, tamper-proof record of exactly what was deployed. Its constructor takes the entire configuration, every implementation address, the ENS domains, each core plugin's (release, build) and metadata, the Management DAO's members and approval threshold, and freezes it. There is no owner, no admin, and no setter anywhere on the contract. You run the deployment to completion exactly once, and from then on the factory exposes just two reads:

  • getParameters() — the exact configuration the deployment used.
  • getDeployment() — every address it produced (the registries, the DAOFactory/PluginRepoFactory, the PSP, the ENS contracts, the Management DAO and its multisig, and each core plugin repo).

Nobody can touch it afterwards. So the factory is the canonical source of truth for that chain's OSx deployment: point anyone at its address and they can read, trustlessly and permanently, both the settings used and the addresses produced, no off-chain manifest to trust, nothing that can be quietly re-pointed later.

Split to fit chain limits ​

The full graph is too big for one contract in one transaction, so the factory works around two EVM limits, without weakening the deploy-once-then-frozen guarantees:

  • Code size (EIP-170's ~24 KB). The bulk of the deployment logic is offloaded to separate helper deployer factories, DAOHelper, ENSHelper, PluginRepoHelper, and PSPHelper, passed into the ProtocolFactory's constructor. Embedding it all in one contract would blow the bytecode cap.
  • Per-transaction gas. The run is split into five sequential phases: the deployer calls deployPhase() repeatedly until it reports complete, because doing it in a single transaction would exceed the gas limit on many networks.

So a real bring-up is multi-contract and multi-transaction. The frozen record (above) and the powerless-at-the-end guarantee (below) are unchanged; only the deployment path is chunked.

Correct from genesis ​

As it builds, the factory holds a temporary ROOT + EXECUTE handle on the Management DAO, wires every permission across the registries, registrars, repos, and the DAO's own multisig install, and then revokes both as the final step. When the deployment concludes the factory has no power over anything it created; the Management DAO's multisig is the sole authority. The deployed bytecode is verified against OSx's audited source, so the running protocol provably matches reviewed code.

This temporary-power-then-revoke discipline (and the deploy-once, atomic, on-chain-and-verifiable shape) isn't unique to this factory, it's the general Aragon factory pattern; the DAO Launchpad's one-shot factory applies the same at the scale of a single DAO.

Version parity across chains. When a core plugin's canonical version is a build > 1, the factory publishes placeholder versions for the earlier builds before the real one, so a plugin's (release, build) means the same thing on every chain.

A fresh OSx for building plugins ​

The factory doubles as a way to get a realistic OSx into a plugin's test suite. A ProtocolFactoryBuilder (Foundry) stands up a complete, fresh protocol, defaults or selectively overridden, and you read the results straight back:

solidity
ProtocolFactory factory = new ProtocolFactoryBuilder().build();
// ...run the deployment to completion...
ProtocolFactory.Deployment memory d = factory.getDeployment();  // daoFactory, PSP, repos, …

So a plugin author can fork-test against the actual framework instead of hand-rolled mocks, the very factory that ships OSx to a chain also spins it up in CI.

Keep in mind ​

  • This deploys the protocol, not a DAO. To create a DAO on an already-deployed protocol, that's the DAO Launchpad and the DAOFactory, not this.
  • The Management DAO is a real DAO, with real governance. Protocol upgrades and new core-plugin versions flow through its multisig; there's no separate admin backdoor.
  • The factory keeps no power. Its bootstrap ROOT/EXECUTE on the Management DAO is revoked as the final step, the deployment isn't "done" until the factory is powerless.

See also ​