Governance

MORE Vaults use a two‑layer governance model. MORE DAO looks after the shared core and public registries, while each vault has its own local roles for day‑to‑day strategy management. This split keeps the global rules coherent yet lets vault creators move quickly inside their own sandbox.

Protocol Governance

• Scope. The DAO can upgrade the invariant core, set global parameters (strategist fee caps, max drawdown limits), and copy items from the permissionless registries into the DAO‑approved lists.

• Process. Any token holder may submit a proposal. After an on‑chain vote passes, a fixed timelock (e.g., 72 hours) delays execution so users can react.

• Execution tools. Upgrades call diamondCut() on the core, registry entries are added with approveFacet(), approveOracle(), or approveRouter(), and treasury actions move funds through the treasury multi‑sig.

• Transparency. All proposals, votes, and timelock queues are emitted as events that frontends can track in real time.

Vault Governance

Every vault deployed by the factory starts with three optional roles. The addresses can be changed by the vault owner at any time, subject to the vault’s own timelock.

Role	Powers
Vault Owner	Super‑admin. Can change fees, assign or revoke the other roles, upgrade strategy facets, and call emergency pause. Usually the wallet or multisig that created the vault.
Strategist / Curator	Adjusts allocations, harvests rewards, and proposes new strategy facets or routers. Cannot touch fees or guardianship.
Guardian	May veto a strategist‑initiated upgrade during the timelock window.

If a vault omits a role (sets the address to 0x0) the corresponding permissions do not exist.

Timelock on vault updates

All privileged actions including facet upgrades, fee changes, guardian swaps, etc. follow the same pattern:

1. Propose – Role holder calls the action, and the contract records it and emits ActionQueued(id).

2. Waiting period – A mandatory delay (e.g., 24 hours) gives depositors time to request withdrawals and gives the guardian time to veto if needed.

3. Execute or cancel – If the guardian has not vetoed, anyone can execute the action after the timelock has expired. A veto emits ActionCanceled(id) and the queue entry is cleared.

The timelock window is separate from the withdrawal request delay, so users can still exit even if a guardian is asleep.

Emergency path

• Pause. Owner may call pause() at any time. This disables new deposits and strategy calls but leaves withdrawal requests open.

• Unpause. Only the owner can lift the pause, subject to the standard timelock.