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 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, add/remove facet on registry, add/remove oracle on registry), and flags protocols as DAO‑approved.

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

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

Vault Governance

Every vault deployed by a Vault Factory starts with one required role and two 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 and harvests rewards and add assets. Cannot touch fees or guardianship.
Guardian	May veto a strategist‑initiated or owner-initiated upgrade during the timelock window. Cannot veto a change in Vault Owner, Curator or Guardian.

If a vault does not set a role for Curator or Guardian (sets the address to 0x0) the corresponding permissions do not exist.

Timelock on vault updates

All privileged actions including fee changes, change of Curator or Guardian, etc. follow the same pattern:

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

2. Waiting period – A delay set by the Vault Owner in the vault configuration (e.g., 48 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, the Vault Owner or Curator can execute the action after the timelock has expired. A veto emits ActionsVetoed(messageSender, ids[]) and the execution queue entry is cleared.

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

Emergency path

• Pause. Vault Owner, Guardian or the DAO via Vault Factory, may call pause() at any time. This disables new deposits and strategy calls but leaves withdrawal requests open.

• Unpause. Only the Vault Owner or Guardian can lift the pause, subject to the standard timelock. In the case the DAO paused a vault because of a compromised facet, unpause() can only be called after the affected facet is removed or upgraded.