Component Interactions
Last updated
Last updated
A single MORE Vault is more than just a vault contract. It is the crux of a small ecosystem: the factory that mints it, the registry that vouches for it, the diamond proxy that hosts its logic, and the shared storage library that keeps every facet in sync.
Understanding how data and authority flow across those components is critical for auditors, integrators, and strategy creators. This section walks through the lifecycle of a call, from deposits via a front-end, through the factory, diamond, facets, and finally back to the user, highlighting where state is mutated, where security boundaries lie, and which contracts are purely informational.
Vaults Factory deploys a fresh Diamond, wires in an initial facet bundle, and emits VaultDeployed
.
The new vault registers itself in the VaultsRegistry
, making it discoverable and authenticatable.
MoreVaultsLib sits behind every facet, anchoring shared storage (assets list, fee config, selector map) at MORE_VAULTS_STORAGE_POSITION
. All facets read/write through this library, eliminating storage-collision risk.
MulticallFacet offers a batched submitActions → executeActions
flow with a built-in timelock, so managers can publish an upgrade plan and users can exit if they dislike it or a guardians can veto it.
Read-only tooling (dashboards, indexers) queries DiamondLoupeFacet
to paint a live picture of vault capabilities.