Upgrade & Governance Flow
Last updated
Last updated
Unlike “set-and-forget” staking contracts, MORE Vaults treat governance events such as facet upgrades, fee tweaks, strategy reallocations, etc., as first-class data flowing through the system. An upgrade is not just an owner()
call; it is a three-step, publicly observable process that starts at the social layer (a strategist’s proposal), propagates through on-chain timelocks, and ends in immutable bytecode.
This design ensures that every actor: depositors — managers, front-ends, risk frameworks — can consume the same canonical signals and react accordingly. The table below distills that life-cycle, mapping each governance action to its enforcing contract and trusted role, so builders can automate alerts, and users can decide where to anchor their trust assumptions.
Deploy
Factory admin
VaultsFactory.deployVault
Mints Diamond, injects genesis facets, registers vault. (see )
Propose change
Owner or Curator role¹
MulticallFacet.submitActions
Package a diamondCut
+ optional strategy tweaks; starts timelock.
Timelock window
Anyone
—
Users can monitor proposed selectors via DiamondLoupeFacet
.
Execute / Veto
Guardian (last-resort) or proposer
executeActions
/ vetoActions
Finalizes or cancels thhe waiting period.
Post-upgrade introspection
Indexers & UIs
facets()
Verify the new facet map and emit analytics.
¹ Roles are stored in AccessControlFacet
and enforced by library modifiers; they can be transferred but not bypassed.
Trust boundaries
Code-level immutability – Only diamondCut
can mutate logic; if a vault omits the cut facet, it is by definition immutable.
Time-delayed upgrades – The timelock in MulticallFacet
is protocol-wide, so users always get N seconds to react.
Registry backstop – A vault removed from the registry (e.g., emergency revoke) can be black-listed by front-ends immediately.