· 8 min read
DeFi Vault Risk Tools Compared: Monitoring, Onchain Caps, and Verifiable Mandate Enforcement
How allocators can constrain covered curator actions after deposit and verify that agreed risk limits governed them.
TL;DR
After an allocator deposits capital into a DeFi vault, the useful distinction is which controls can block a covered curator action before execution and which provide evidence for review. The approaches can work together.
- Monitoring and independent valuation are best for reviewing positions, prices, and breaches. An alert alone does not block an action.
- Native vault caps are best for blocking allocations that exceed the vault’s onchain limits. Their scope follows the vault’s permissions and execution paths.
- Signed policy decisions are best for recording an issuer’s decision and can gate execution when integrated. A signature does not verify the underlying calculation.
- Inherence is best for enforcing allocator-approved rules on covered curator actions before execution. An outside allocator can verify the committed policy calculation without access to protected inputs encoded in the proof. Coverage is limited to actions routed through the defined enforcement path and evaluated against committed or attested inputs.
Controls after a DeFi vault deposit
An allocator’s ability to constrain a curator after deposit depends on the controls in the curator’s execution path. Contractual restrictions alone do not make an authorized vault transaction fail.
Audits and dashboards help an allocator assess positions or detect a breach. Required human approval can stop an action when the curator must obtain it before execution. A curator who can use a route without that approval may still execute the action before the allocator sees a warning.
The comparison asks whether each control can block an action before execution and what an outside allocator can verify. It also examines coverage, exceptions, external inputs, and privacy. A control may reliably block an allocation within the vault while providing no evidence about an offchain hedge. Those boundaries determine what protection remains after deposit.
Monitoring and independent valuation
Monitoring and independent valuation help an allocator review vault exposure after deposit. Position records show exposure changes, while prices and risk calculations can identify breaches of defined limits. The cited 1Token and Kaiko pages do not describe an allocator-approved gate for curator actions.
1Token (opens in a new tab) consolidates multi-vault positions and calculates NAV and PnL from position and transaction data. 1Token’s mandate and limit monitoring can generate alerts for breaches of predefined exposure rules. The cited page describes breach alerts, not a required pre-execution approval step. An allocator evaluating a blocking integration would need documentation of that separate enforcement path.
Kaiko (opens in a new tab) provides independent NAV calculations and auditable valuations using onchain and offchain data. Kaiko describes benchmark-provider and calculation-agent services. Kaiko describes historical data for backtesting and risk metrics that include Value at Risk. Those measures can inform an allocation decision, but the cited page does not describe Kaiko enforcing an allocator’s mandate before a curator acts. A published onchain NAV provides valuation evidence, not verification that a curator applied a committed policy.
Native vault exposure and permission caps
Morpho Vault V2 can block an allocation that breaches its onchain exposure limits. A curator can set absolute or relative exposure caps for the categories supported by Morpho Vault V2. The vault’s Allocator role directs assets through enabled adapters. Morpho Vault V2 checks applicable caps before executing an allocation. These controls restrict actions submitted through the vault’s Allocator role before execution. Morpho’s Vault V2 documentation (opens in a new tab) describes the caps and allocation path.
Morpho separates authority across roles (opens in a new tab). The Curator sets caps and manages adapter permissions. The Allocator moves assets among approved options but cannot add a new adapter or raise a cap. A Sentinel can immediately lower caps, deallocate assets, or revoke a pending timelocked change. The Curator can also lower caps immediately, while cap increases must follow the applicable timelock.
When a configured delay is greater than zero, a submitted timelocked change is reviewable onchain before execution (opens in a new tab). Morpho permits per-function delays of zero, so a timelocked function does not always provide a waiting period. These native controls govern actions submitted through the vault’s role, adapter, and timelock system. They do not, on their own, enforce an allocator-specific mandate layered over those controls or govern offchain legs.
Signed policy decisions
A signed policy decision can block a covered curator action before execution if the execution path requires an approving verdict. The gate must check that the verdict applies to the proposed action. Actions outside that path do not face the same check.
A signed verdict authenticates its issuer, not the correctness of the issuer’s policy calculation. An outside allocator can verify who signed the verdict and what it claims, but signature validity does not prove that the issuer calculated the allocator’s committed policy correctly.
The verdict may also depend on external price or position inputs that the signature cannot validate. Privacy depends on what the issuer receives and what the signed payload reveals.
Independently verifiable mandate enforcement
An allocator can require an approved risk limit to constrain covered curator actions after deposit. For example, the allocator could require a proposed allocation to stay below a concentration limit. Inherence (opens in a new tab) evaluates the covered action before execution and blocks it if the action fails the rule, provided the action passes through the defined enforcement path. Native vault caps can also block allocations. An allocator-approved rule serves a different purpose when the allocator needs a constraint beyond the vault’s native controls.
Privacy lets a curator accept allocator-approved controls without disclosing protected positions or strategy details to the allocator. For a covered action that passes the check, Inherence produces a receipt that an outside allocator can use to verify the defined calculation against the committed policy without seeing protected inputs encoded in the proof. The receipt provides independently verifiable evidence of the defined calculation for the covered action. A signed verdict, by comparison, authenticates its issuer but does not let an outsider check the underlying calculation.
Inherence provides evidence for covered actions routed through the defined enforcement path and evaluated against committed or attested inputs. The receipt does not independently establish the truth of every external input. It does not cover actions executed outside that path or by itself establish settlement.
Comparing the four approaches
A DeFi vault risk management tool may provide review evidence without an execution gate. A gate can block a covered action without establishing the accuracy of every input. The comparison below describes the documented scope of each approach.
Best for and approach | Can block a covered action before execution? | What an outside allocator can verify | Scope and exception boundaries | Reliance on external inputs | Privacy tradeoff |
|---|---|---|---|---|---|
Exposure review: monitoring and valuation | An alert alone cannot. The cited pages for 1Token (opens in a new tab) and Kaiko (opens in a new tab) do not document an execution gate. | 1Token’s reported positions and alerts; Kaiko’s independent valuations and NAVs | Coverage follows the monitored positions, data, and configured alerts. An execution gate would require a separate integration. | Position and market data must be accurate and current. | Reports may disclose positions or valuations. The cited pages do not establish strategy privacy. |
Protocol-level limits: native vault caps | Yes, for allocations governed by Morpho Vault V2 caps and adapters (opens in a new tab) | Onchain caps, permissions, and submitted timelocked changes | Native rules cover defined vault actions. Authorized roles can change caps under the applicable delay. | Onchain vault state and inputs used by configured adapters | Public rules and onchain activity limit confidentiality. |
Attributable approval record: signed policy decisions | Yes, if the execution path requires an approving verdict for the covered action. | The issuer’s signature and stated decision, not the correctness of the policy calculation | Coverage follows the actions gated by the integration and its exception rules. | The issuer’s evaluation and supplied inputs | Disclosure depends on what the issuer receives and publishes. |
Allocator-approved limits: Inherence (opens in a new tab)’s independently verifiable enforcement | Yes, for covered actions routed through Inherence’s defined enforcement path | A receipt supports verification of the committed policy calculation without access to protected inputs encoded in the proof. | Unrouted actions remain outside coverage. A receipt does not prove settlement. | The calculation uses committed or attested inputs. The receipt does not establish the truth of every external input. | The verifier need not see protected positions encoded in the proof. |
Combining vault controls
An allocator can combine monitoring and independent valuation with native vault caps and an enforcement layer. Monitoring and valuation help assess reported exposures. Native caps can block actions within the vault’s rules, while a separate enforcement path can apply allocator-approved rules to covered curator actions. An allocator should identify which curator actions must pass through a pre-execution gate. The allocator should also specify the evidence needed to review those actions.
Before deposit, the allocator can use the vault curator due diligence checklist (opens in a new tab) to identify records and control terms to request. For mandates involving onchain and offchain hedges, the hedge verification guide (opens in a new tab) addresses what can be checked without disclosing protected positions.
FAQs
What does a signed verdict prove compared with a verifiable policy receipt? A signed verdict authenticates its issuer and records a decision. A verifiable policy receipt lets an outside allocator check the defined policy calculation for a covered action without access to protected inputs.
Can onchain vault caps block a bad allocation? Yes. A vault can reject an allocation that exceeds its configured cap when the action passes through its native controls. Those controls do not automatically cover offchain actions or separate allocator-specific rules.
What are covered actions and committed or attested inputs? Covered actions pass through a defined enforcement path before execution. A commitment binds a value used in the policy check without necessarily revealing it. An attestation is a claim supplied by an identified source; it does not by itself establish that the claim is true.
Does monitoring or alerting count as a control? Monitoring can detect a breach and prompt a response. An alert alone does not block execution, although an integration could use monitoring signals to gate an action.
Does independent verification prove that a trade settled or that external data was accurate? No. A receipt supports verification of a defined calculation over supplied inputs. It does not establish the truth of every external input, cover actions outside the enforcement path, or prove settlement. The hedge guide (opens in a new tab) examines those input boundaries in more detail.
How can an allocator constrain a curator without seeing its positions? Inherence can enforce allocator-approved rules on covered curator actions before execution. Inherence’s receipt lets the allocator verify the committed policy calculation without access to protected positions encoded in the proof. This applies only to covered actions routed through the defined enforcement path and evaluated against committed or attested inputs.