Registries
Registries are simple on‑chain catalogues.
Types of Registries
There are three registries included in the protocol:
Vaults are registered on the Vault Factory of each chain;
Whitelisted protocols and their corresponding facets are registered on the Vault Registry;
Oracles are registered on the Oracle Registry.
A registry never blocks a contract call. It only stores information that front‑ends, analytics, and governance can consult to verify the trustworthiness of the component.
Permissionless Vaults
A vault can be created as a permissionless vault upon deployment. If it is flagged as permissionless, calls to any protocol or facet are never blocked by registry checks. Because no review is required, builders can deploy a new strategy facet and reference it in a live vault on the same day. Permissionless vaults are meant to be hidden by default, and shown only when a front-end or user explicitly opts‑in to "unreviewed code".
Permissioned Vaults
When an item has been audited and a DAO vote confirms the findings, the identical identifier (the address and list of selectors) is copied into the DAO‑approved registry. From this moment on nothing about the contract itself changes. However, if an item is upgraded, it must be re-approved to be updated in the registry. The DAO‑approved registry therefore acts as an overlay that labels items as verified.
The goal of this approach is three-fold:
Innovation without delay. Developers can experiment freely in the permissionless track, gathering real‑world data before seeking formal approval.
Clear safety signals. Users and integrators receive a binary indicator, approved or not, without having to parse audit reports on their own.
Seamless upgrades. Passing from permissionless to DAO‑approved status involves a single registry write. Vaults and shares are unaffected, so liquidity never migrates.
This arrangement keeps the core protocol fully permissionless while still giving frontends, dashboards and institutional users a straightforward filter for risk.
Last updated