· 9 min read
How Can an Allocator Verify a Vault Curator’s Emergency Actions?
Map a vault curator’s emergency powers before funding, then verify the authorization, policy, inputs, and settlement behind each covered action.
TL;DR
- Emergency powers may bypass a vault’s ordinary limits. Before funding, an allocator should identify who can use each power, what triggers it, how long it lasts, and which controls it bypasses.
- An allocator can require defined constraints before a covered emergency action executes. Those constraints can specify authorized actors, permitted exposure changes, and the applicable policy version.
- After an emergency action, an outside reviewer should match the action to its approval, policy version, attested inputs, and settlement record. Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish external-input truth or cover actions outside that path.
- The related guides cover withdrawal approval (opens in a new tab), curator due diligence (opens in a new tab), and cumulative risk limits (opens in a new tab).
The post-deposit control problem
After an allocator deposits capital, a vault curator may be able to use emergency powers without the allocator’s approval. In Morpho V1’s documented emergency procedure (opens in a new tab), a curator can immediately set an unsafe market’s supply cap to zero. An authorized allocator role can reallocate available liquidity. Illiquid positions may remain. Those protocol permissions do not establish that an intervention satisfies an allocator’s mandate.
Emergency powers need a separate diligence track because they may operate outside the vault’s ordinary change controls. Before funding, an allocator should identify who can invoke each power, what triggers its use, how long it can remain in effect, and which exposure or counterparty rules still apply. The allocator should also identify any route that bypasses a required approval or policy check.
The allocator can then require defined constraints on emergency actions routed through a covered enforcement path. After an intervention, an outside reviewer can check whether the recorded action matched its authorization and applicable policy version. The review should also establish which inputs the check used and which settlement record corresponds to the action.
Mapping the vault's actual emergency powers
An allocator should map emergency powers against the specific vault contract and its current role addresses before committing capital. The inventory should identify which actor can change a cap or move assets. It should separately identify who can alter a withdrawal route, replace a role holder, or disable a gate. For each action, the allocator should record its permitted trigger, applicable delay, expiry condition, and cancellation authority. The inventory should also show whether the action can bypass ordinary approval, exposure limits, or counterparty rules.
Morpho V1 assigns distinct powers to the Owner, Curator, Allocator, and Guardian (opens in a new tab). The Owner inherits the other roles’ powers and can replace the Curator immediately. A Curator can lower a market supply cap immediately, while a cap increase requires a timelocked proposal. An Allocator can reallocate within curator-set caps and change the supply and withdrawal queues. A Guardian can veto certain pending changes, including cap increases, but cannot veto a pending fee change. The diligence question is which of these roles the deployed vault has assigned, and whether an authorized actor can use another role’s powers.
Emergency responses can leave an allocator exposed even when they follow the protocol’s procedure. In Morpho V1’s procedure for an unsafe but functioning market (opens in a new tab), a Curator can immediately set its cap to zero, and an Allocator can move available liquidity and prioritize withdrawals. Illiquid positions may remain. If a market reverts, a Curator or Owner can submit a timelocked forced removal. After the delay, an Allocator can remove it from the withdrawal queue. The allocator should ask who authorizes that step under its mandate and whether the removal could strand assets or recognize losses.
Morpho V2 distributes emergency powers differently (opens in a new tab). Its Owner does not inherit the other roles. A Curator can lower absolute or relative caps immediately, while a Sentinel can lower caps, deallocate from enabled adapters, and revoke pending timelocked Curator actions. Curator proposals can also change adapters, gate contracts, and other settings after their applicable delays. The allocator should identify who controls each route and who can revoke a proposed change.
A timelock label alone does not establish a waiting period. Morpho V1 uses a global delay that can be zero during initial configuration, while V2 assigns delays by function and can set a function’s delay to zero (opens in a new tab). The allocator should check the deployed version, configured delays, role history, and pending actions rather than relying on a general description of the vault’s emergency policy.
Setting mandate-bound constraints before execution
Before committing capital, an allocator should ask whether the vault can enforce an emergency mandate before covered actions execute. The mandate defines which interventions the curator may take after capital leaves the allocator’s account. It cannot constrain a contract call that bypasses the defined enforcement path.
The first diligence question concerns authority. Which addresses or roles may invoke an emergency action, and does the enforcement path check that authority? The allocator should also ask what event permits each action and which committed or attested input supplies evidence of that event. For example, an attestation may report a market disruption. Checking the attestation does not establish that the disruption actually occurred.
The mandate should specify how long emergency authority lasts and what it permits during that period. Can the curator add a counterparty, raise an exposure limit, or suspend an ordinary rule? Each permitted change needs a defined bound and an expiry condition. The allocator should also ask which policy version governs an action if the curator changes the policy during an emergency.
Before relying on these constraints, the allocator should map every route that can execute an emergency action. Inherence can evaluate covered actions against formalized policy rules before execution, but a vault-specific integration remains proposed until its routing and enforcement are validated. Any uncovered route requires separate restrictions or an explicit acceptance of the remaining risk.
What to check after an emergency action
After an emergency action, an outside reviewer should check authorization, policy, inputs, and settlement separately. A valid policy receipt alone cannot establish that an approved action settled.
- Action-to-approval binding. The reviewer matches the executed action’s identifier and terms to a specific authorization. If the approval was valid for one use, the reviewer checks whether it was reused or applied to a different action. The withdrawal approval guide (opens in a new tab) explains approval binding for withdrawals.
- Applicable policy version. The reviewer checks which committed mandate version governed the action when the policy evaluated it. An approval evaluated under an expired or unapproved version does not establish that the action met the applicable mandate. The cumulative-risk guide (opens in a new tab) covers version changes across sequences of actions.
- Input attestations. The reviewer identifies the attestations used for the emergency trigger and any relevant exposure or counterparty checks. The evidence can establish which inputs the policy evaluated, but it cannot independently establish whether an external report was true. The curator checklist (opens in a new tab) covers questions about input sources before deposit.
- Settlement association. The reviewer matches the authorized action to its execution record. The reviewer then checks whether a settlement record identifies the resulting asset movement. An approved deallocation request may remain pending, so approval alone does not establish where assets ended up.
Any Inherence vault integration for emergency actions remains proposed until its routing, receipt fields, and settlement associations are validated.
Comparing what each control can establish
Each emergency control can prevent or document a different part of an intervention. An allocator should check which routes it covers before relying on its records.
Control | What it can prevent before execution | What an outside reviewer can establish afterward | Remaining gap |
|---|---|---|---|
Timelock | A configured timelock (opens in a new tab) delays an operation on a covered route until its minimum waiting period expires. | Contract events and operation status can connect the scheduled call to its execution. | Delay does not establish that the emergency trigger was genuine. An uncovered route may execute immediately. |
Multisig or threshold approval | A configured signer quorum can stop a covered transaction until enough authorized signers approve it. | Wallet records and chain history can identify the signers, threshold, and executed payload when those records are available. | Signatures establish approval of a payload, not compliance with an allocator’s separate exposure limits. Another execution route may bypass the wallet. |
Operator logs | Logs alone cannot stop an action. | Available histories can show requests, policy triggers, approval decisions, and recorded actions. | A reviewer must establish that the records are complete and correspond to the execution route. A recorded decision does not independently verify every calculation behind it. |
Independently verifiable policy enforcement | A proposed vault integration could reject covered emergency actions that fail a defined mandate check before execution. | A receipt could let a reviewer verify the check against a committed policy version and committed or attested inputs, if the integration binds the receipt to the executed action. | The reviewer must verify that execution depended on the check and that settlement matches the approved action. The receipt cannot establish the truth of an external trigger or cover another route. |
A vault’s control inventory should therefore name the emergency functions and administrative paths behind each row. For example, Morpho documents per-function timelocks (opens in a new tab) that may have zero-second delays. The presence of a timelock does not establish a waiting period for every emergency action.
Where the evidence stops
Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path. A receipt can show that a covered action passed a defined check against an attested emergency signal. It cannot establish whether the reported event occurred.
An allocator should identify every emergency route that bypasses the defined enforcement path. A curator may have a separate contract permission or manual route that produces no policy receipt. The allocator needs separate authorization and execution records for actions taken through those routes. Any proposed vault integration requires validation before an allocator can treat its emergency actions as covered.
For related checks, see the withdrawal approval guide (opens in a new tab) for withdrawal-specific authorization and the curator due-diligence checklist (opens in a new tab) for pre-deposit permissions. The cumulative risk limits guide (opens in a new tab) addresses exposure across multiple actions.
FAQ
Is a timelock enough to authorize an emergency action?
No. A timelock can establish that an action waited for the configured delay, but it cannot establish that the emergency trigger met an allocator’s mandate. An allocator should also check the deployed function’s delay because Morpho V2 permits a zero-delay setting (opens in a new tab).
Do operator logs prove that an emergency was justified?
No. Logs can record what an operator reported and when an action occurred, but they cannot independently establish the truth of a reported trigger. The allocator needs the trigger criteria and the inputs used to evaluate them.
Which policy version applies if the mandate changes during an emergency?
The mandate should specify how a policy change affects pending actions before an emergency occurs. An outside reviewer can then check each action against the approved version applicable at evaluation and confirm how the mandate treated any action still pending when the version changed.
What evidence connects an emergency approval to settlement?
The reviewer should match the approval’s action identifier and terms to the executed action, then check the separate settlement record. A valid approval alone does not establish that the action settled. The withdrawal approval guide (opens in a new tab) explains approval binding for withdrawal actions.
Can a receipt cover every emergency route?
No. A receipt applies only to an action routed through the defined enforcement path and evaluated against committed or attested inputs. It cannot cover an action executed through another route.
Conclusion
Before committing capital, an institutional allocator should determine whether a curator can bypass ordinary approval or exposure controls during an emergency.
A defined mandate can constrain covered emergency actions after capital leaves the allocator’s account. The allocator should require a map of actions routed through enforcement and actions that remain outside it. Before funding, the allocator can then decide whether the uncovered routes need separate restrictions.