Upgrade & Governance Flow

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.

Stage	Actor	On-chain hook	Purpose
Deploy	Factory admin	VaultsFactory.deployVault	Mints Diamond, injects genesis facets, registers vault. (see Core Protocol Components)
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.