Morpho Vault V2: Curator, Allocator and Sentinel

Morpho Vault V2 separates configuration from execution: the Curator proposes most risk and fee changes, the Allocator moves assets within enabled adapters and caps, and the Sentinel can lower caps, deallocate to idle and revoke pending changes. The Owner appoints the Curator and Sentinels. Roles do not inherit permissions, and protected changes follow function-specific delays.

Identify the vault and its actual role holders

A role label describes authority over a particular contract. Start with the chain, vault address and implementation, then read the accounts that hold each permission. An organization calling itself a curator may operate several addresses with different roles.

This explanation follows Morpho's VaultV2 implementation at reference commit a0ba9df, checked on 29 October 2026. The reference establishes the behavior discussed here; a live vault needs its own code and configuration check.

Vault V2 holds positions through adapters. A direct Blue lender's internal shares belong to another accounting layer, as the Morpho Blue supply-shares example explains. Avoid applying Vault V1's inherited role powers or Guardian model to V2.

Morpho's V2 role guide distinguishes one Owner, one Curator, and potentially several Allocators and Sentinels. Holding one role grants that role's permissions. An address can accumulate permissions through separate assignments, so four labels do not establish four independent operators. Inspect overlapping accounts and who controls their signers.

Compare Curator, Allocator and Sentinel permissions

The following matrix describes permissions granted by each role alone. A submitted action still needs to pass its parameter checks when executed.

The contract reference documents these entry points. The Owner also controls ownership, name and symbol. Owner status alone does not authorize allocation or cap decreases. Its ability to replace the Curator and Sentinels nevertheless makes the Owner's control important.

The Curator defines the permitted allocation universe and appoints Allocators through the protected change process. The Allocator chooses asset movements within those configured boundaries. The Sentinel has narrower intervention powers: it can pull available assets back to idle and restrict or cancel changes. It cannot use Sentinel status to allocate into a new position. The Sentinel tutorial makes that distinction explicit.

Allocation and reporting controls also differ. The Allocator sets maxRate, which limits recognized asset growth; that setting does not promise an earned return. The maxRate versus reported-growth guide follows that separate accounting boundary.

Read the delay attached to the exact proposed call

V2 has function-specific timelocks. A selector identifies a function; the complete encoded call also includes its arguments. For an allocator appointment, changing the account or the boolean produces different call data.

The Curator submits those complete bytes with submit. Read executableAt(data) using the identical bytes, then execute the original function with the same arguments after the timestamp. An unrelated keeper can execute it; the keeper does not become Curator. Morpho's role-configuration tutorial describes that sequence.

A zero-duration timelock can make submission and execution possible in the same transaction. The word “timelocked” therefore does not establish a useful waiting window. The timelock documentation also explains why shortening a function's delay waits through that function's existing delay.

Reaching the timestamp makes a call eligible. It does not execute itself. Revoking its exact bytes removes that pending authorization; a cap decrease changes a separate value. Changing the Curator likewise does not clear pending calls, and increasing a timelock does not postpone earlier submissions in the pinned authorization logic. Review proposals already in flight when reviewing a role replacement.

Follow a staged role and cap change

This hypothetical state timeline uses token U with six decimals. All table amounts are displayed U; 3,000 U means 3,000,000,000 raw asset units. It is a deterministic illustration of the checked branches, rather than a transaction on a live vault.

The vault starts with 10,000 U: 4,000 idle and 6,000 in one market through an enabled adapter. The market's absolute cap is 7,000 U. Every applicable relative cap is 100%; the other returned risk IDs have adequate positive absolute caps. Adapter reports are exact, and there is no interest, loss, fee, donation, deposit or user withdrawal during the example.

The Owner, Curator C, Allocator A1 and Sentinel S are different accounts. A2 initially has no role. The relevant selectors are not abdicated, and their timelocks remain fixed throughout.

At hour zero, C submits two calls:

Both submissions leave the asset balances and current cap unchanged. A2 cannot allocate merely because its appointment is pending.

A smaller cap leaves an existing position in place

At hour six, S immediately lowers the market cap from 7,000 to 3,000 U. The existing allocation remains 6,000 U. Lowering the limit does not redeem the position or erase half its value.

Only 2,500 U is currently available from the underlying position. S deallocates that exact amount successfully. Idle rises to 6,500 U and the tracked allocation falls to 3,500 U. The allocation remains 500 U above its new cap, yet the deallocation succeeds. Caps constrain allocation calls; reducing exposure does not require first getting the position below its cap.

This case uses an absolute market cap to isolate permissions. The absolute versus relative caps guide explains the additional constraints when several returned IDs bind at once.

Revocation closes the earlier route to a higher cap

At hour seven, S revokes the exact 9,000 U increase submitted at hour zero. Its executableAt(data) becomes zero. The separate A2 appointment stays pending.

Without that revocation, lowering the cap to 3,000 U would leave the old proposal eligible at hour 48. Raising 3,000 to 9,000 would still satisfy the increase-direction check. The operational difference is substantial: a dashboard showing today's lower cap can omit a queued route back to a larger one. Morpho's emergency procedure treats revoking increases, lowering caps and withdrawing available assets as separate steps.

The new Allocator still meets the current limits

At hour 24, an unrelated keeper executes A2's submitted appointment. A2 now passes the Allocator permission check. No U moves when that role flag changes.

At hour 25, A2 attempts to allocate another 1 U into the market. The resulting allocation would be 3,501 U against a 3,000 U cap, so the call reverts. Its attempted movements do not become a completed allocation.

At hour 30, another 1,000 U becomes withdrawable. S deallocates it, leaving 2,500 U allocated and 7,500 U idle. At hour 31, A2 allocates 400 U successfully: the position becomes 2,900 U, within the 3,000 U cap. This represents a later allocation decision within the chosen limit, not a recommendation to reopen an unsafe market.

At hour 48, trying the revoked cap increase fails because its pending authorization is absent. The final total is 2,900 + 7,100 = 10,000 U. The net 3,100 U returned to idle is an internal movement. The Yearn idle-versus-debt ledger demonstrates why that movement needs separation from profit, using Yearn's own accounting.

Check response powers without assuming a guaranteed outcome

The Sentinel's privileged deallocate returns available underlying to the vault. It does not send that amount to the Sentinel's wallet. A separate permissionless forceDeallocate path can burn penalty shares from the specified user and still requires a subsequent exit to pay that user. Burning another user's penalty shares requires sufficient share allowance to the caller; withdrawal gates also apply. The force-deallocation tutorial and pinned penalty-withdrawal path distinguish those flows. Neither path creates underlying liquidity that borrowers have not returned.

Cap reductions also need the correct scope and encoding. Setters accept raw idData; getters use its Keccak-256 hash. Keep both in the record. The adapter-configuration guide explains those arguments and the separate adapter-level timelocks. A vault's role matrix does not describe every administrative action available inside its adapters.

Removing an Allocator goes through the same protected setIsAllocator function as adding one. A nonzero delay can therefore leave the existing account active while removal waits. A Sentinel may instead restrict relevant caps and revoke pending increases within its own permissions. That response still needs successful transactions and available liquidity.

Role separation supplies inspectable controls with defined limits. A Sentinel can interrupt allocations or delay intended configuration by revoking proposals. Independent signers can fail to respond. Enabled positions still carry market, adapter and valuation risk.

Validate one proposed action against one recorded state

For an operational review, retain a compact record that another reader can reproduce:

1. Identify the subject. Save chain, vault address, observation block, underlying asset and decimals. Match the deployed code to the implementation being explained.
2. Resolve authority. Read Owner, Curator and the relevant Allocator/Sentinel flags. Record overlapping accounts and the caller that will actually reach the vault.
3. Decode the proposal. Save the original function, arguments and exact calldata. Read its pending timestamp, selector delay and abdication status. Include queued changes that could alter the intended limit.
4. Check the resulting state. For allocation, evaluate every returned risk ID and available idle assets. For deallocation, use an executable exact amount. Simulate with the intended caller against a fresh state.
5. Verify confirmation. Check the role flag, cap, pending entry or actual asset balances that the call should change. Retain the corresponding events alongside those reads.

In this example, the closing record contains three independent facts: A2 is an Allocator, the market cap is 3,000 U, and the earlier 9,000 U proposal has no pending authorization. Add 2,900 U still allocated and 7,100 U idle. Together, those facts explain both the authority to act and the boundary the next allocation must satisfy.