When a collateral price feed stops updating, vaults do not automatically stop allocating. The entire mechanism depends on the curator and allocator actively monitoring and taking manual or semi-automatic actions—not an automatic "circuit breaker."
The root of this issue lies in Morpho's design philosophy: it provides infrastructure without imposing any mandatory requirements on oracle updates. Which oracle a curator uses is entirely up to them, and Morpho does not intervene. So when the price feed stops, the vault doesn't "know" it has stopped; it just continues working with its existing configuration.
Step 1: Identify Why the Price Feed Stopped Updating
Determine whether it's a "push delay" or an "oracle revert"—the two affect the vault completely differently. Check the oracle address and the timestamp of the last successful update on the blockchain. If no update has occurred for more than 3–5 blocks, it is a push delay. If calling the oracle function returns an error (revert), it is an oracle revert. This makes the problem type clear.
Situation A: Push Delay (Push-Based Oracle Latency)
This is the problem that occurred in the Re7 vault cbETH incident in March 2025: Pyth's cbETH/USD price feed froze without an update for nearly an hour, while ETH/USD kept updating. This caused the ratio between the two feeds to drift, and liquidation bots executed liquidations based on this "fake price." Pyth's stance was clear: their price was accurate, but the integrator (vault curator or user) did not run an additional scheduler to actively trigger price updates. Marc Tillement, Director of the Pyth Data Association, publicly stated afterward: if the vault manager had run a scheduler to trigger price updates, this problem could have been completely avoided.
Situation B: Oracle Revert (Reverting Oracle)
When an oracle reverts because the underlying price source has been deprecated or similar, the situation is more serious. According to Morpho's official documentation, after an oracle revert:
-
Operations such as deposit (supply), withdraw, and repay do not require a price, so they can still execute normally.
-
However, borrowing and withdrawing collateral will be blocked—unless the borrower happens to have exactly zero outstanding borrow shares.
-
Liquidators cannot execute liquidations, because the liquidation function also depends on the oracle price.
Risk Warning: When the oracle reverts, your deposits can be withdrawn normally (as long as the market has enough available liquidity). But if you are a borrower in that market, trouble is big. You can only retrieve your collateral by fully repaying all borrows down to exactly zero shares. Even 1 share remaining will cause the withdraw collateral transaction to revert due to a failed health check. Morpho's official recommendation: curators should prioritize oracle providers with a clear deprecation policy—ideally, a deprecated feed should return a stale price instead of reverting outright, giving users a time window for an orderly exit.
Step 2: Check if the Curator Deployed Monitoring and Auto-Response Mechanisms
Confirm whether the curator has prepared for an oracle outage. You can check the vault's official documentation or on-chain configuration. KPK's public documentation shows that their monitoring system (Agents) tracks multiple indicators in real time, including "Oracle Health" and "Price Deviation from Reference Exchanges." When conditions change, they can respond "within seconds" by "reducing or shutting down allocations to a certain market" and "increasing idle funds." This lets you see whether the curator has a similar mechanism and whether it can trigger an automatic response when the price feed stops.
If the curator has an auto-response mechanism, the allocation bot will detect price deviations and automatically withdraw funds from that market and shut down allocations.
If the curator relies entirely on manual judgment, after the price feed stops, nothing will happen until someone notices and manually intervenes. During that time, the vault may continue allocating funds to that market.
Step 3: Verify Whether the Curator Runs an Extra Scheduler
This step directly targets push-type oracle (such as Pyth) issues. Check whether the curator has configured an active update mechanism. Look at the curator's public technical documentation or on-chain transaction history for regular oracle update transactions coming from the vault address or curator-controlled addresses. This confirms whether the vault relies on a passive mode—where prices update only when someone borrows—or has an independent active scheduler guaranteeing updates.
