Upgrade Flow & Timelock

Code can, ​and sometimes must, ​change. However, MORE strives to keep these changes transparent. Here we walk through the vault’s publish-delay-commit cycle, showing how Multicall batches, a registry-level timelock, and a guardian veto combine to turn upgrades into fully observable, all-or-nothing events.

1. Prepare: A Manager assembles a diamondCut, optional parameter tweaks, and bundles them in a Multicall batch.

2. Publish: submitActions records the calldata and emits ActionsSubmitted, starting the optional vault-wide timelock (configured in the registry).

3. Observation Window: Depositors and monitors can replay the exact payload on a fork to verify intent.

4. Commit: After the delay, executeActions hands the diamondCut to DiamondCutFacet; selectors execute atomically.

5. Emergency Brake: Guardian may cancel, at any point during the timelock, with vetoActions. Otherwise, the batch becomes immutable.

The factory governs future vaults by storing the canonical DiamondCutFacet address; rotating it propagates hardened upgrade logic to every new deployment in one transaction.