Morpho Vault V2 Cap Changes: Increases, Cuts and Timelocks

Morpho Vault V2 cap increases require Curator submission and execution after the relevant function's timelock; a zero-second timelock still requires submission. The Curator or a Sentinel can decrease caps immediately. A decrease changes the allocation limit but does not withdraw existing assets or cancel queued increases. Check effective caps and each proposal's executableAt separately, because raising a timelock later leaves previously submitted deadlines unchanged.

Read effective caps and pending proposals separately

A cap describes how much exposure the vault may allocate to a risk identifier. A proposal describes a change that someone may execute later. Displaying the proposed cap as the current limit can therefore give a false account of the vault's permissions.

This explanation follows the parent VaultV2 contract at reference commit a0ba9df0ea69, checked on 29 October 2026. It does not establish the implementation or configuration at a live vault address. Vault V1's global timelock rules belong to a different implementation.

The official architecture overview describes adapters that hold positions for the vault and risk identifiers that group allocations. An absolute cap uses underlying asset units. A relative cap uses a fraction scaled by 10^18, called WAD. These controls sit above the direct lender accounting explained in Morpho Blue supply shares versus assets.

Morpho's Sentinel documentation separates the protective powers from the ability to introduce new allocations or propose higher limits. A Sentinel address can still relay an already approved, mature increase, just as any other address can. Its role does not independently authorize that increase.

Submission stores an exact call and a timestamp

The Curator submits the full encoded future call through submit(data). For a cap increase, the vault records the submission block's timestamp plus the timelock for that increase function's selector. Absolute and relative increases have separate selectors and can have different delays.

The pinned interface exposes three different kinds of lookup:

• timelock(selector) reads the configured delay for a function.
• executableAt(data) reads the timestamp for one complete proposed call.
• absoluteCap(id) and relativeCap(id) read effective limits for a hashed risk identifier.

Cap setters receive raw idData; the vault hashes those bytes to find the risk identifier. The cap idData versus hash walkthrough explains that encoding boundary. Passing a hash where raw data belongs can target a different identifier.

The pending key includes the function and every argument. A proposal to set an absolute cap to seven million units differs from a proposal to set it to eight million. Revoking one does not clear the other. The cap argument also specifies the new total ceiling: seven million replaces the previous cap; it does not add seven million to it.

To execute, a caller sends the originally submitted function call to the vault. Waiting alone changes no cap. A successful call consumes its pending entry. The execution checks require a nonzero pending timestamp, a block timestamp at least that large, and a selector that has not been abdicated. Abdicating an increase selector permanently blocks that increase function in this implementation.

The function's other checks must also pass at execution. If another completed increase has already raised the current cap above a queued proposal's target, that proposal fails its direction check. Maturity establishes when execution may be attempted.

Follow a cap increase and reduction through a checked timeline

This is an illustrative state example, using fictional token U with six decimals. All times below are stipulated block timestamps in UTC during 2026. For any allocation check discussed below, assume the transaction's firstTotalAssets reference is 10 million U. This is the total recorded after that transaction's first interest accrual. The recorded allocation under the selected adapter risk identifier stays at four million U. Other applicable risk identifiers have sufficient headroom. There are no transfers, interest changes or losses during the example.

The opening absolute cap is five million U and the relative cap is 50%. All selectors used below remain unabdicated. Configure these hypothetical delays:

• Absolute-cap increases: two days, or 172,800 seconds.
• Relative-cap increases: three days, or 259,200 seconds.
• The increaseTimelock function itself: zero seconds.

At 09:00 on 29 October, the Curator submits A, an absolute-cap increase to seven million U, and B, a relative-cap increase to 70%. A's new absolute cap is 7,000,000,000,000 raw U units; B's relative cap is 700,000,000,000,000,000 WAD units.

The opening submission timestamp is 1,793,264,400. Adding 172,800 gives A's executable timestamp, 1,793,437,200: 31 October at 09:00. Adding 259,200 gives B's timestamp, 1,793,523,600: 1 November at 09:00. An attempt one second before A's timestamp fails the time check.

At 10:00 on 29 October, the Curator submits and executes the timelock increase. The zero delay for increaseTimelock permits those calls without elapsed waiting time. The implementation explicitly preserves previously submitted execution times. A therefore remains executable on 31 October, even though new absolute-cap proposals now wait seven days.

Executing A changes the absolute cap to seven million U. With the unchanged 50% relative cap and stipulated 10 million U reference, the relative ceiling remains five million U. Raising one cap has not removed the other constraint, and the four million U allocation has not moved.

The last attempted execution fails because B's exact pending entry has been cleared. Its original timestamp appearing in a historical submission event cannot make it executable again.

A zero timelock belongs to one selector

Vault V2 uses per-function timelocks. A zero delay for increaseTimelock says nothing about the delay for increaseAbsoluteCap, increaseRelativeCap, adding an adapter or another sensitive function.

If a cap-increase selector itself has a zero delay, the Curator must still submit the encoded increase. Someone can then execute it at the same block timestamp, subject to the other checks. Submission and execution can be included in a Curator's multicall. A zero delay provides no elapsed notice period; it does not remove the Curator authorization required to create the proposal.

Changing a delay has its own rules. Increasing a selector's delay goes through the increaseTimelock lifecycle. Decreasing a delay waits the current delay of the function being changed, as the official timelock guide explains. Applying V1's single-delay model or assuming a universal minimum would misread this V2 configuration.

For an existing proposal, read its stored executableAt. Recalculating a deadline from today's selector delay can produce the wrong answer.

Lowering caps leaves existing assets and other proposals in place

At 10:00 on 31 October, the Sentinel sets the absolute cap to two million U and the relative cap to 20%. Both changes take effect immediately. The latter corresponds to two million U against the stipulated 10 million U reference.

The allocation remains four million U, now two million above each illustrated ceiling. The cap-decrease functions check the new cap against the old cap; they do not require assets to be deallocated first. In this fixed state, an additional positive allocation would fail the reduced limits.

Caps constrain allocation calls rather than continuously rebalancing existing positions. Interest can increase exposure, and withdrawals can raise its percentage of vault assets, as the pinned cap comments explain. A cap does not insure against losses in an existing position.

Recovering assets requires a separate operation. Morpho's emergency procedure pairs cap reductions with deallocation of available liquidity and recognizes that an illiquid market may require staged exits. A smaller cap alone returns zero U to the vault's idle balance.

The liquidity-adapter guide examines ordinary deposit and withdrawal routing. It matters when evaluating what users can actually receive after a risk-control change. The Yearn idle-versus-debt ledger offers another concrete allocation reconciliation, although its accounting and management functions are different.

The pending B is also unchanged by the cuts. Without revocation, its later execution would raise the relative cap from 20% to 70%. The two-million-U absolute cap would still constrain this fixture. Nevertheless, the Sentinel's relative-cap reduction would have been reversed by an older authorization.

Morpho's emergency guide therefore calls for checking and revoking pending absolute and relative increases. Each requires its exact encoded call. Revocation can also clear a mature proposal while it remains unexecuted; it cannot undo an increase that has already executed.

Revocation does not permanently forbid another proposal. In a separate continuation, suppose the Curator resubmits A at 11:00 on 31 October. A was consumed on execution, so its key is available again. The new seven-day delay makes this fresh submission executable at 11:00 on 7 November. It needs its own review and, if appropriate, revocation.

Validate a cap change against one observed state

Retain the chain, vault address, implementation, block reference, risk identifier and underlying decimals. Keep the following records together:

1. Effective limits and allocation. Read both caps and the allocation for the intended identifier. Inspect every other identifier returned for the proposed allocation, because another cap can remain binding.
2. Exact pending calls. Retain submitted calldata and read its executableAt. Different amounts can produce several pending calls for the same identifier. Include both cap-increase functions in the review.
3. Execution conditions. Compare the observation timestamp with the stored deadline, check selector abdication and simulate the exact call against the intended state. A mature timestamp establishes only the time condition.
4. Confirmed consequences. After execution, reduction or revocation, reread the cap values and pending entries. If assets were meant to move, verify deallocation and the actual asset balance separately.

The named MorphoMarketV1AdapterV2 implementation also has its own timelock storage. Read the parent vault for vault cap proposals; inspect that adapter separately for its own administrative calls. Equal function names across contracts do not share a queue.

For the completed timeline, the record is an effective cap of two million U and 20%, a recorded allocation of four million U, neither A nor B pending, and zero U returned by the cap changes. Those separate values show whether a limit changed, a permission was cancelled, or assets actually became available.