While the suited thought leaders migrated back from the Wyoming mountains, a lesson was brewing in onchain markets.

Risk management, a sleepy term thought to be reserved for balding professionals, is quickly exposing itself as underestimated among builders in digital assets. Almost every day a new exploit, hack, or financial event reaches the headlines. Some are conventional smart contract exploits. Others are a compromised private key and weak governance.

This article covers another category: a lack of proper risk management considerations (well, it's all the same right?) with the benefit of hindsight. Plenty of articles have been written about what happened. We will focus on what could be done to prevent this in the future.

The industry is right to scream and shout. Blockchain can be complicated, and desgining the right risk mitigation in an environment with seemingly endless levers and edge cases is a daunting task. At Webacy, we don't shy away from a challenge. The hard problems are usually the ones worth solving.

reUSD liquidations on Morpho

On August 25, roughly $36 million of loans were liquidated in Morpho markets using PT-reUSD as collateral.

What happened?

PT-reUSD is a Pendle principal token representing the right to receive the underlying reUSD at maturity. It has a complementary yield token (YT-reUSD) which represents the right to the yield generated before maturity. When demand for YT rises (the market's implied yield increases), the PT price falls.

One wallet bought YT-reUSD, pushing the pool's implied yield up. This caused PT-reUSD's market price to fall. Borrowers operating close to the liquidation threshold were pushed below it, and liquidators began unwinding their positions. ~$36mm of debt was repaid in ~15 minutes.

"$36 million liquidated" does not mean $36 was stolen or lost. The protocol forcibly closed $36 million of loans. Lenders were made whole. Pendle and Steakhouse confirmed the process created no bad debt and lenders suffered no shortfall.

How did this happen?

At the time of the event, consider the following figures:

A relatively small pool was being used to determine the value of collateral securing a much larger lending market.
Note: pool liquidity is not the same as executible exit liquidity.

The question that needs to be asked at this point (earlier would have been better) is: how much PT-reUSD could be sold under stress before its price moved enough to liquidate borrowers? In this case we found out. Roughly $320,000 of trading activity moved the oracle-linked price enough to trigger a much larger liquiddiation cascade.

This explanation is simplified, as there are many great write-ups out there, but there were additional risks accumulating in this event:

• Excessive looping and leverage
• Less than 3% liquidation headroom for the riskiest positions
• A large lending market dependent on a small trading pool
• An oracle that transmitted (as designed) a market price that was economically cheap-ish to move

Was it an attack?

Maybe, but this was not a conventional exploit.

To answer the question, you have to look at who benefits from the event. You have to look for connections between the major liquidator and the YT buyer. Onchain researchers continue to publish, and some estimations place the manipulated earnings at $1.3mm.

One thing to consider is whether or not the economic benefit of forcing liquidations is greater than the cost of moving the price used by the oracle. If yes, the market may need to be treated as insecure. More on this in the "how to fix this" section.

Better risk design for a better future

What could have been designed differently? In this section, we propose improvements for better risk mitigation, specifically for this example.

1. Improve the pool to market ratio

A sensible risk policy would cap lending exposure according to how much PT-reUSD could actually be sold without moving its price materially (under stressed conditions).

A few ways to improve this:

• Measure the price impact of selling 5%, 10%, 20% of outstanding collateral
• Limit borrowing or vault allocations when liquidation exposure exceeds executable liquidity
• Reduce caps automatically when Pendle liquidity falls
• Aggregate every market relying on the same PT into one combined exposure

Good risk design is not the enemy of high yield for properly architected markets. Beware of laziness.

Morpho Vault V2 supports absolute and relative caps across dimensions like collateral, markets, and oracle configurations. Use them~!

2. Use deterministic PT valuation instead of the live pool price

A linear-discount oracle calculates that value without allowing every Pendle trade to immediately alter collateral valuations. Pendle now recommends this design for money markets because it is much harder to manipulate than an AMM-derived price.

Deterministic pricing won't solve everything on its own.

In a situation where reUSD develops real a solvency or redemption problem, an oracle based only on time-to-maturity could value PT-reUSD too highly. Borrows could extract good USDC against impaired collatral, leaving lenders with bad debt.

To build a safer system, you should consider combining:

• deterministic PT pricing during normal conditions
• Independent monitoring of reUSD NAV, redemption performance, liquidity, and solvency
• A conservative adjustment when the underlying asset shows impairment
• No direct dependence on a small PT Trading pool

Risk strategies should change as the situation changes.

3. Add guardrails to "lower price always wins"

(in reference to the oracle design in this scenario) Choosing the lower of a market price and a model price sounds conservative, and for lenders it usually is. Declines are recognized quickly. But if the market price is cheap to move (in this example) the same design cohice gives traders a path to forced liquidations.

Potential guardrails:

• Require the market price to remain below the model price for a longer confirmation period
• Limit how far the oracle value can move within an hour
• Ignore large deviations unless a second source confirms them
• Applying liquidity- and volume-weighted confidence checks
• Compare the PT price with reUSD NAV, redemption value, and implied-yield range

For example if implied yield jumps from 11% to 20% without any change in reUSD's fundamentals, the system could enter a "potentially unreliable market" mode. It should not instantly use that change to reprice milliions of collateral.

Importantly, a delay should pause risk expansion, not just postpone recognition. When a deviation threshold is crossed, new borrowing should be reduced or stopped while existing positions have heightened monitoring. If independent evidence can confirm that there is genuine impairment, then the oracle should be able to adjust fast enough to protect lenders.

The key word is "potential" and none of these are magic solutions on their own. Each has tradeoffs if poorly implemented, but the right design can allow these to be healthy guardrails to defend against events like this.

4. Lower the liquidation LTV

The market's liquidation LTV was 91.5%. $91.50 could be borrowed against $100 of collateral before the position reached the liquidation threshold.

This is aggresive for an asset who's valuation depended on a small AMM.

An LLTV of 80% to 85% would have created more room for ordinary price movement. LLTV should also reflect more than historical volatility. It should incorporate oracle-manipulation cost, liquidity concentration, redemption uncertainty, position concentration, and the amount of recursive leverage already in the system.

5. Treat recursive looping as system-level exposure

Sophisticated users will find a way to bypass any kind of UI warnings or blockages in the search of looping gains. Risk mitigation has to go deep.

A few useful controls to consider:

• set maximum leverage or loop limits
• require higher collateral for recursively acquired collateral
• set borrow caps for related addresses or positions
• Set risk-adjusted interest rates that rise with aggregate leverage
• throw warnings or block transactions when certain health factors fall below a threshold
• Curators can set policies that limit exposure when a large share of collateral originates from looped borrowing

The bigger lesson

Onchain finance is a young financial system. It's culture has rewarded high risk high return strategies, and composability makes it possible to build complicated positions faster than the industry develops mature methods for governing them.

Every event like this is an opportunity to improve it.

Public markets, with transparent positions and programmable controls give us tools that traditional finance often doesn't have. We can observe leverage in real time. We can model the price impact of liquidiations before they occur. We can reduce caps automatically, pause borrowing when data becomes unreliable, and alert users while there is still time to respond.

Risk doesn't live in one oracle, one contract, or one protocol. Risk lives in the relationships between them. Onchain risk systems must be built to see those relationships early enough to support better decisions before capital moves.

Webacy is a risk intelligence company for onchain finance. We automate due diligence, monitor assets and positions, and conduct real time due diligence for digital assets. If you'd like to learn more, please get in touch. This article is for educational purposes only and does not constitute investment, legal or financial advice. Figures reflect public reporting and onchain analysis available as of August 26, 2026.