[spalen0]

Closes #434

What

Curator actions that can write off vault funds now send a HIGH alert for any non-zero amount. Each goes out as its own 🚨 POTENTIAL VAULT LOSS message on the morpho channel, and is re-alerted once within 24h of its execution time. An operation first seen with nothing at risk escalates to this alert as soon as funds arrive.

Vault	Operation	HIGH when	Detected via
V1	submitMarketRemoval	the vault still supplies the market	config.removableAt + Morpho Blue position/market
V2	removeAdapter(adapter)	the adapter holds assets	GraphQL pendingConfigs + adapter assets
V2	decreaseTimelock(removeAdapter, …)	any adapter holds assets	GraphQL pendingConfigs
V2 adapter	burnShares(marketId)	the adapter holds that market	on-chain executableAt(burnShares(id))

Other changes:

• V1 timelock: the alert now reads Timelock decrease: 3d → 1d, with the execution time and a countdown. It used to say just "Timelock is changing".
• V2: other decreaseTimelock calls and abdicate stay MEDIUM. removeAdapter(...) names the adapter again.
• V2 adapter: a drop in timelock(burnShares) sends MEDIUM, and a burnShares on a market with no shares sends LOW. The first run seeds the timelock cache silently.
• V1 empty-market removals stay MEDIUM.

How burnShares is detected (batched eth_call only)

The Morpho GraphQL API has no adapter-level timelock data, so each MorphoMarketV1AdapterV2 is read on-chain: executableAt(burnShares(id)) for every held market → HIGH with the amount at risk, plus a reminder within 24h. A drop in timelock(burnShares) → MEDIUM. Valuation calls run only when a burn is pending.

TODO: a burn submitted with non-canonical calldata (canonical + trailing bytes) is not detected. Solidity ignores the extra bytes, but executableAt is keyed by the exact calldata, so the key can't be derived. Catching it needs the adapter's Submit events, which the Morpho API does not expose. It can be added once an indexer provides them.

Amounts come from stored shares and Morpho Blue market totals, never the IRM (it can revert), and the loss alert follows shares. On V1, totalAssets() is best effort, so a broken IRM only drops the "% of vault" figure.

Robinhood had no RPC in the env or in PUBLIC_RPC_URLS, so I added its official public RPC (rpc.mainnet.chain.robinhood.com, listed on chainid.network) as a fallback.

The added GraphQL fields pushed first: 200 past Morpho's 1M complexity limit (1,151,000). The page size is now 100 (575,500), passed as a variable, and a test checks that the configured vaults fit.

Testing

• ruff, ty, and the full test suite pass (1945 tests). New tests cover severity classification, standalone delivery, reminder-once logic, timelock decrease, and adapter executableAt reads. The fake client in the adapter tests rejects .call() outside a batch context; that is the bug the first live run caught.
• Mainnet fork (anvil): confirmed the non-canonical calldata gap (the padded submit executes while the canonical key reads 0). It's documented as the TODO above.
• Live dry run of both monitors against real chains, with alerts printed instead of sent and a temporary cache. Every chain passes, and the only RPC methods used are eth_blockNumber and eth_call. No pending loss operations exist today. The Katana Yearn OG USDC weETH/vbUSDC removal (no supply) correctly came out as MEDIUM. Every adapter returns timelock(burnShares) of 3d or 7d.

Rollout notes

The loss alert is tracked on its own cache key, so removals and removeAdapter operations that were already pending (and already alerted at MEDIUM) before this deploys get the HIGH loss alert on the first run if they still have funds at risk.

🤖 Generated with Claude Code

[gjwang]

Could you add a zero-to-positive shares transition test for the same pending burn?

At d14ab1d3, lines 233–237, the dedup check only remembers executable_at. If a zero-share burn first sends MEDIUM at T−72h, then has positive shares at T−48h, the unchanged timestamp takes the early continue: no CRITICAL until the reminder window. Tracking whether a critical alert was delivered for that pending operation would distinguish escalation from duplicates.

I reproduced that sequence with the extracted function and mocked cache, clock and delivery; a clean-cache positive-share control sends CRITICAL. I have not run the full suite or a live-chain test. The existing tests cover zero and positive shares separately; the transition would catch this gap.

[spalen0]

Could you add a zero-to-positive shares transition test for the same pending burn?

At d14ab1d3, lines 233–237, the dedup check only remembers executable_at. If a zero-share burn first sends MEDIUM at T−72h, then has positive shares at T−48h, the unchanged timestamp takes the early continue: no CRITICAL until the reminder window. Tracking whether a critical alert was delivered for that pending operation would distinguish escalation from duplicates.

I reproduced that sequence with the extracted function and mocked cache, clock and delivery; a clean-cache positive-share control sends CRITICAL. I have not run the full suite or a live-chain test. The existing tests cover zero and positive shares separately; the transition would catch this gap.

thanks, good catch. Fixed in a8fa3a3.

It wasn't just the adapter burn. V1 submitMarketRemoval and V2 removeAdapter had the same problem, it only remembered the deadline, so an operation first alerted with nothing at risk didn't escalate when funds arrived. It only got the 24h reminder.