The thing that still surprises people about on-chain lending is how much it tells you before anything happens. A big Aave borrower does not have a hidden stop loss sitting on some exchange's internal book. Their entire liability is sitting in a public contract, and from that you can compute the exact collateral price at which a bot is allowed to seize their position and dump it. No inference, no guessing at where the pain lives. The number is right there, and it does not move unless the borrower does something about it.
I started paying attention to this because of a specific failure I kept seeing. Someone watches a token, the token looks fine, order books look normal, and then it drops fifteen percent in a few minutes for no news reason anyone can find. Half the time the cause was a wall of leveraged loan positions all clustered around the same collateral price, and once price touched that zone the liquidations fed on themselves. The information to see it coming was public the whole time. Nobody had assembled it.
What the health factor actually is
Most large lending protocols expose some version of a health factor, which is just a ratio. You take the value of a borrower's collateral, weight it by how much of that collateral the protocol is willing to lend against, and divide by the value of what they owe. When that ratio sits comfortably above one, the loan is safe. When it drops to one, the position becomes eligible for liquidation and a bot can repay part of the debt in exchange for a chunk of collateral at a discount.
The useful move is to stop thinking about the health factor as a number and start thinking about it as a price. Because the debt side is usually a stablecoin and the collateral side is usually a volatile asset, you can hold everything else fixed and solve for the collateral price that drives the health factor to one. That is the liquidation price for that specific loan. Below it, forced selling is on the table. Above it, the borrower is fine. You are converting a borrower's private risk tolerance into a public trigger level, and they published it for you the moment they opened the position.
A couple of things make this less clean in practice, and they matter. Borrowers add collateral or repay debt to push their liquidation price down, so any level you compute is a snapshot that can shift. Some collateral is itself a yield-bearing or wrapped asset whose price is not exactly the price of the underlying, so you have to use the same oracle the protocol uses, not the spot price on your favorite exchange. And liquidations are usually partial, so one loan hitting its trigger does not always dump the whole position at once. None of this breaks the approach. It just means you treat the numbers as a map of pressure, not a set of guarantees.
Building the map of trigger prices
The output I actually want is boring and useful. For a given collateral asset, I want a distribution of how much borrowed value gets liquidation-eligible at each price level below where we are now. Think of it as a histogram. The x-axis is collateral price, the y-axis is dollars of debt that come into play if price falls to there. Fat bars close to the current price are the ones that keep me up at night.
Here is the workflow I use to build it.
- Pull the set of open positions for the collateral asset you care about from the lending protocol. Focus on the large ones first, because a handful of big borrowers usually dominate the risk and you do not need to enumerate every dust-sized loan to see the shape.
- For each position, compute its liquidation price using the protocol's own liquidation-threshold parameters and its own oracle feed. Do not shortcut this with spot price. The oracle is what the contract checks, and small differences move the trigger.
- Bucket those liquidation prices into price bands, say every one or two percent below current price, and sum the debt in each band. Now you have your histogram.
- Mark the bands where the clustered debt is large relative to the asset's normal traded volume. A cluster that is small next to daily volume gets absorbed quietly. A cluster that is large next to daily volume is a cascade candidate, because the forced selling itself pushes price into the next band down.
- Watch current price against those bands and set alerts a little above the fattest clusters, not on top of them. You want warning before the zone, not confirmation as it detonates.
The step people skip is the fourth one, comparing cluster size to liquidity. A pile of loans that all liquidate at the same price is only dangerous if selling that much collateral actually moves the market. In a deep, liquid asset the same cluster is a non-event. So the map is only meaningful when you overlay it against how much that asset can absorb without slipping.
Why this beats watching leverage on exchanges
You can try to do the same thing with centralized exchange leverage, and people do, but you are working from aggregates and estimates. The exchange knows every trader's liquidation price. You get a smoothed heatmap at best, and it is their model of the risk, filtered through whatever they choose to show you. On-chain, the raw positions are the data. You are not reading someone's summary of the risk. You are reading the risk.
The other advantage is timing. A cascade in DeFi has a mechanical quality to it. Price crosses a level, bots race to liquidate, that selling pushes price into the next cluster, and the process repeats until it runs out of fuel or hits a band thin enough to absorb it. Because you built the map ahead of time, you already know where the fuel runs out. That lower edge, the price below the last meaningful cluster, is often where the reflexive selling exhausts itself, which is a very different piece of information from a generic feeling that a token looks weak.
Where this goes wrong
I have watched this signal fail in a few honest ways, and it is worth naming them so you do not over-trust it. Borrowers defend their positions. A whale staring at a cluster forming just below price will often top up collateral right before the level, and the whole zone you were watching evaporates. Second, oracles update on their own schedule, so a fast spot-price move does not always trigger liquidations at the instant you would expect, and the cascade can lag or not fire at all if price recovers before the oracle catches up. Third, correlated collateral is sneaky. If several large loans use the same volatile asset, a move in that one asset can light up clusters across multiple protocols at once, and a single-protocol map understates the real pressure.
So I treat the trigger map as a way to know where to point attention, not a trade by itself. When a fat cluster sits close to price and the asset is thin, that is when I actually watch order flow and the borrowers' wallets in real time, looking for whether they are defending or walking away. Most of the value is in the anticipation. You are not reacting to a fifteen percent candle after it prints. You are watching the fuel accumulate and deciding whether you want to be anywhere near it.
We fold a version of this into Blockcircle so the large lending positions and their trigger prices sit next to the whale wallet feeds and the market scorecards, which is roughly the set of screens I would want open anyway. But the core idea does not need any particular tool. If you can read a lending contract and do a bit of arithmetic, the liquidation prices are yours for the taking, and they are the rare kind of signal that is genuinely public and genuinely early at the same time.