October 15, 2026 · 11 min read

How to Vet a DeFi Vault Curator Before Allocating Capital: A Due Diligence Checklist

Assess whether allocator-approved limits constrain a vault curator after deposit, and what evidence verifies covered actions.

TL;DR

Before depositing into a curated DeFi vault, an allocator should ask what constrains the curator after capital leaves the account and what evidence shows the constraint held.
The allocator should request the deployed vault’s permissions map, including who can change limits, approved venues, and withdrawal rights. Morpho’s role documentation (opens in a new tab) illustrates why those powers need separate review.
The allocator should distinguish monitoring after execution, signed policy verdicts, and independently verifiable evidence that a defined rule was checked against bound inputs.
The allocator should identify which onchain and offchain actions the mandate covers and who authenticates external inputs.
The checklist identifies records to request before deposit. The comparison table distinguishes what monitoring, signed verdicts, and independently verifiable evidence can establish.

The question to answer before capital leaves the account

A curated DeFi vault is a vault whose appointed operators manage assets within its configured permissions. Before depositing, an allocator should establish which curator actions its mandate constrains after capital leaves the allocator’s account. A curator’s track record describes past decisions. It cannot show whether the vault will block a future action that exceeds an agreed limit.

Vault roles show why the question matters. In Morpho Vault V2 (opens in a new tab), the owner appoints the curator and sentinels. The curator sets risk parameters, approved adapters, and exposure caps. Morpho’s allocator role deploys vault assets within those configured routes and caps. Morpho documents one vault design, so a committee must check the permissions of the deployment it plans to use.

The committee should establish whether an allocator-approved limit blocks a covered action before execution or merely triggers an alert afterward. Before committing capital, it should request the deployed vault version, contract addresses, and change permissions. The curator should identify which actions pass through the check and provide evidence tied to the agreed policy. The committee must assess actions outside that path separately.

Mandate scope: what the vault's policy actually covers

A vault’s stated mandate only constrains the curator to the extent that the deployed contracts enforce it. An allocator should compare the written strategy with the permissions held by each role. The Morpho Vault V2 role definitions (opens in a new tab) illustrate the distinction between setting limits, allocating assets, and exercising emergency authority. Other vaults may divide those powers differently.

Change rights determine whether an allocator has time to respond before a mandate is altered. Morpho’s timelock documentation (opens in a new tab) distinguishes V2 delays set by function from the global timelock used in V1. A V2 function can also have zero delay. A notice period offers little protection if an owner or curator can make the relevant change immediately, or if the depositor cannot withdraw before a delayed change takes effect.

Before allocating, request the deployed vault version, contract addresses, and a permissions map tied to controlling keys. The map should identify who can replace role holders, add adapters, change caps, and invoke emergency powers. Request the delay and notice terms for each change, including zero-delay exceptions. Check whether withdrawal gates (opens in a new tab) or other exit conditions could prevent a timely withdrawal. A written strategy alone cannot establish what the deployed vault permits.

Pre-execution exposure and counterparty limits

A documented cap protects an allocator only if the vault checks it before a covered action executes. For example, a written $1 million venue limit does not prevent an allocation that would raise exposure to $1.2 million unless the execution path rejects it. Ask the curator for a failed-action test or other evidence showing whether a breach blocks execution or merely generates an alert.

Limits need precise definitions. An absolute cap sets a fixed amount, while a relative cap measures exposure against a specified base, such as vault assets. Approved adapters determine which routes a curator may use. Morpho Vault V2 (opens in a new tab) documents both kinds of cap and adapter approvals, but an allocator still needs to check the permissions and settings of the vault under review. Request the cap values, the base used for each relative cap, and the approved routes for each proposed counterparty exposure.

The committee should test each limit against a proposed action, including an action that would exceed the cap. Request the resulting rejection record and confirm that the same execution route cannot proceed without the check. Review change permissions and withdrawal timing under the mandate-scope checklist above.

Onchain and offchain coverage

A curator's mandate must specify which onchain and offchain actions its controls cover. A vault may lend through an onchain protocol while the curator maintains a hedge with a broker. An onchain lending cap does not constrain a hedge adjustment or an OTC trade unless the mandate covers those actions too.

Before allocating, an investment committee should request a map of execution venues, custody accounts, and authorized actors. For each leg, the curator should identify the applicable limit and whether a breach blocks the action before execution or triggers an alert afterward. An attested broker position can inform an onchain limit. That check does not constrain the broker trade unless the trade also passes through a defined enforcement path. The onchain and offchain hedge guide (opens in a new tab) examines hedge reconciliation in detail.

Monitoring, signed verdicts, and independently verifiable policy evidence

A vault’s monitoring records can show what happened after an action, but an allocator needs separate evidence if its mandate must constrain the curator before execution. 1Token’s vault-curator offering (opens in a new tab) aggregates positions and sends alerts when exposure rules are breached. Kaiko’s vault-risk offering (opens in a new tab) provides independent valuations and daily NAVs, with an option to write values onchain. Those described services support oversight and reporting. Neither cited page establishes that its service blocks a curator action under an allocator-approved rule.

A signed policy verdict provides a different record. When a verifier checks the signature and the data it covers, the verifier can identify who issued the verdict and which decision the issuer recorded. The signature alone cannot show that the issuer applied the committed rule correctly. An allocator should ask for the signed decision, its policy version, and the action and inputs bound to it.

Independently verifiable policy evidence lets a separate verifier check whether a defined rule produced the recorded result for specified inputs. It establishes pre-execution control only when covered actions must pass that check before execution. For a pre-execution control, the allocator should require a record that links the policy version, accepted inputs, proposed action, and execution record. The allocator should also ask how the vault prevents covered actions from bypassing that check.

Such evidence applies to 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 valid policy check also does not, by itself, prove that a resulting trade executed or settled as claimed.

Authenticated external inputs

A pre-execution check can enforce a vault mandate correctly while relying on an outdated price or an incomplete offchain position. The check shows how the rule handled the supplied inputs, not whether those inputs described the vault’s actual exposure. Chainlink’s data-feed guidance (opens in a new tab) recommends assessing input quality and availability, including stale values and upstream outages.

For each limit, request the source of every price, position, and counterparty record used in the calculation. Ask how the vault authenticates each source, records when each value was produced, and links the accepted value to the policy version and proposed action. For an offchain hedge, ask who attests the position and how often the attestation is refreshed.

The curator should document how the control handles a provider outage, conflicting sources, or a missing acceptable input. Ask whether the vault blocks the action, uses a documented fallback, or follows an authorized exception path. Require separate records for rejected inputs and rejected actions. Without them, an allocator may mistake a failed data check for a mandate breach or overlook a mandate check that used invalid data.

Privacy for curator positions and strategy

A curator may accept an allocator’s exposure limits without agreeing to reveal every position. Position-level disclosure can expose a curator’s strategy to competitors or other market participants. Privacy-preserving verification can let an allocator check that a covered action met an agreed limit without receiving protected inputs. The allocator must still confirm that the action could not bypass the enforcement check.

The allocator should ask which details the curator must disclose to apply the rule and which details a verifier can see. For example, a verifier may be able to check evidence that a covered action satisfied a committed exposure limit without seeing the positions used in the calculation. The allocator should also identify what the vault’s public transactions already reveal. Privacy in the evidence does not conceal information visible elsewhere.

An allocator should ask whether verification can protect the curator’s positions and strategy while revealing the policy decision. The allocator should separately assess the scope and input limits of that evidence. The Inherence section below describes one applicable approach.

Exception handling and emergency authority

Request an exception matrix before depositing into a curated vault. For every path below, the curator should identify the authorized key or role, any delay, the event record, and whether the action remains covered by the mandate’s enforcement path.

Condition	Decision the matrix must document
Rejected action	Can the curator retry through another route, or must the action stop?
Verification service unavailable	Do covered actions pause, or can someone authorize a bypass?
Stale or conflicting inputs	Which source can resolve the conflict, and when may execution resume?
Emergency deallocation or withdrawal	Who can act, and does the emergency route preserve policy checks?
Policy edit	Who can change a limit, when does the edit take effect, and what notice does the allocator receive?

Emergency authority may permit an action outside the ordinary enforcement path. The committee should establish whether that authority can reduce exposure without bypassing required policy checks. In Morpho Vault V2, a Sentinel can reduce caps, deallocate, or revoke a pending change (opens in a new tab). Morpho also documents function-specific timelocks (opens in a new tab), which can have zero delay. Those mechanics offer one model, not a default for every vault. The allocator should verify the deployed vault’s permissions and test whether an emergency action produces a record under the claimed enforcement path.

Questions to put to curators and infrastructure providers

Mandate. Can you provide the deployed vault version, contract addresses, and written allocator-approved mandate?
Mandate. Can you provide a permissions map showing who can change roles, approved venues, limits, and withdrawal rights?
Mandate. Can you provide the applicable change delays and identify any functions with no delay?
Limits. Do exposure and counterparty limits block covered actions before execution? Please provide the policy specification and a rejected-action record.
Limits. Can you provide the applicable absolute and relative caps for each approved venue, including the base used to calculate any relative cap?
Coverage. Can you provide a map of onchain and offchain actions covered by the mandate, including hedges and custody movements?
Coverage. Can a curator execute any mandate-relevant action outside the enforcement path? Please identify those actions.
Evidence. Can you provide a sample record linking one action to its policy version, applicable inputs, decision, and execution record?
Evidence. Can an independent party verify that the committed policy produced the recorded decision, or can it verify only a signature on the decision?
Inputs. Can you provide an inventory of external input sources, authorized attestors, update intervals, and freshness thresholds?
Inputs. Does the policy reject actions when required inputs are stale, missing, or contradictory? Please provide a test record for each case.
Privacy. Can you identify which positions, strategy details, and inputs remain private during verification?
Privacy. Can you provide the public verification statement so the committee can assess what the evidence reveals?
Exceptions. Can you provide an exception matrix covering rejected actions, verification outages, stale inputs, emergency deallocation, policy edits, and withdrawals?
Exceptions. Does the matrix identify the authorizer, applicable delay, activity record, and enforcement-path coverage for each case?
Exceptions. Can you provide a test showing whether an allocator can withdraw before an adverse policy change takes effect?

Comparison checklist: retrospective monitoring vs. signed verdicts vs. independently verifiable evidence

Evidence tier	What it shows	Legitimate use	What it does not establish	Example category
Retrospective monitoring and valuation	Observed positions, calculated values, or alerts after activity occurs.	Portfolio oversight, independent valuation, investigation, and reporting.	Whether an allocator-approved limit blocked a proposed action before execution.	1Token’s vault monitoring (opens in a new tab) and Kaiko’s valuation services (opens in a new tab).
Signed policy verdict	An identified issuer signed a decision tied to a specified payload.	Authenticating the issuer and preserving its decision record.	Whether the committed policy calculation produced the signed decision.	A signed approval or rejection record.
Independently verifiable policy evidence	A separate verifier can check a defined policy calculation against bound inputs.	Testing whether a covered action satisfied the accepted policy.	Whether external inputs were truthful, actions outside the defined path were checked, or a trade settled as claimed.	A verifiable policy receipt tied to an action.

For each proposed DeFi vault, request an example record that identifies the action, policy version, applicable inputs, and execution record. A verifier also needs the stated scope of the evidence. A valid policy calculation cannot establish what happened outside that scope.

Where Inherence fits

Vault-native caps constrain allocations within a vault's configured permissions. Inherence (opens in a new tab) lets an allocator's agreed rule constrain covered curator actions after capital leaves the allocator's account, when those actions are routed through the defined enforcement path. For example, an allocator could agree a counterparty exposure limit with the curator. A covered action that breaches the committed limit would be blocked before execution.

For a covered action that passes, Inherence produces a receipt that an independent party can verify against the committed policy and accepted inputs. The allocator can check that the policy produced the recorded decision without seeing protected inputs encoded in the proof. The allocator should also confirm that the receipt names the expected policy version and connects to the action that executed.

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. Before depositing, an allocator should request a map of covered onchain and offchain actions, the policy-change permissions, and the sources of external inputs.

Conclusion

Before a first deposit, an investment committee should request a failed-action test and a sample record connecting a covered action to the policy version, accepted inputs, decision, and execution record. It should confirm which curator actions can bypass that path and who can change the policy. If the curator cannot demonstrate those controls, the written mandate remains a stated rule rather than a demonstrated constraint.