Why deliberately leave a gap between LTV and the Liquidation threshold instead of just using the same number for both?
If LTV and the liquidation threshold were the same number, the moment you borrowed the maximum amount the protocol allows, your position would already be sitting right on the liquidation line — any slight unfavorable price movement, even normal intraday noise, would immediately trigger liquidation. Take ETH as an example: over the past year, days with a price move greater than 2.5% accounted for nearly half of all trading days. Without a safety Margin between LTV and the liquidation threshold, that means on nearly half of all trading days, a user who just finished borrowing could see their position instantly pushed toward liquidation.
That gap is essentially the protocol deliberately sacrificing some capital efficiency (letting you borrow slightly less than the theoretical maximum) in exchange for buffer room so a position doesn't get wrongly killed by ordinary market noise. The size of the gap isn't arbitrary either — the more volatile an asset, the larger a gap protocols tend to leave, because it needs more buffer room to withstand normal price noise without being misjudged as genuinely undercollateralized.
Between risk service providers (like Chaos Labs) and protocol governance, who actually holds more decision-making power?
Procedurally, final authority rests with governance, not the risk service provider. The provider's role is to supply quantitative analysis and recommendations — they simulate borrower positions using historical on-chain data, test how much risk the protocol would face under extreme conditions with different parameter settings, and package the conclusions into concrete parameter-adjustment proposals for governance to discuss. But for that recommendation to actually take effect, it still has to go through a formal governance proposal, executed on-chain via a community vote or a governance-appointed role.
In practice, risk provider recommendations tend to pass at a high rate — not because governance is ceding its decision-making power, but because the provider offers professional, quantified, model-backed analysis that most governance participants lack the equivalent expertise to challenge, so they tend to simply adopt it. That's also a potential weakness in this system: governance theoretically retains final veto power, but whether governance members actually have the capability and willingness to question a risk provider's model assumptions determines how much substantive meaning that "theoretical checkpoint" still holds in practice.
How exactly does Aave's Isolation Mode "isolate" risk?
The core design of Isolation Mode is to place a new asset into a separate, borrow-capped small Liquidity Pool, rather than letting it directly share the same risk pool with every other asset in the protocol. Once an asset is designated as an isolated asset, after a user deposits it as collateral, both the type and total amount of assets that can be borrowed against it are restricted to a pre-set cap — even if that asset's price later crashes and the collateral becomes worthless, the maximum loss is locked within that isolated pool's cap and doesn't spread to other liquidity pools in the protocol that have nothing to do with this asset.
The practical problem this mechanism solves is that a new asset typically lacks a long enough market history for a risk provider to accurately assess its true volatility and liquidity depth right from the start. Isolation Mode lets a protocol find a middle ground between two extremes — "reject the new asset entirely" and "immediately grant the new asset full, unrestricted collateral status" — using a scope-controlled sandbox that lets the asset undergo real market testing for a period, and only considers removing the isolation restriction once enough data has accumulated to support a proper risk assessment.
Before using a lending protocol, how do I actually check whether an asset's LTV and Liquidation threshold are set reasonably?
The first step is to check the protocol's official interface or developer documentation directly for that asset's current LTV, liquidation threshold, and whether it falls under Isolation Mode or an E-Mode category — most major protocols (like Aave) publish these parameters right on the asset detail page, no extra tools required. Once you have the numbers, compare them against the asset's market cap, 24-hour trading volume, and actual liquidity depth on major exchanges and on-chain DEXs. If an asset has a relatively high collateral factor but noticeably thin market liquidity, that combination alone is a signal worth taking seriously — it's exactly the situation TONIC was in during the Tectonic incident.
The second step is to check whether the protocol retains a professional risk service provider for regular parameter reviews, and to pay attention to whether the protocol's own native Token is held to the same rigorous review standard as external assets. If you can't find any discussion of native-token risk assessment in the protocol's blog, governance forum, or audit reports, that usually indicates this part of the review is relatively weak — something worth adding to your own risk checklist before deciding whether to put funds into that protocol.
You deposit 1 ETH into a lending protocol, and the interface tells you the maximum you can borrow against it is worth 80% of that value. That 80% isn't calculated by the market, and it isn't automatically generated by code — it's a loan-to-value ratio (LTV) set individually for each asset by protocol governance, through a risk assessment process. That number looks like a mere technical parameter, but it's actually the first line of defense for the entire lending protocol — it directly determines how much cascading damage an asset can cause if something goes wrong with it. In August 2026, Tectonic, a lending protocol on Cronos, suffered a roughly $75 million exploit, triggered by the fact that the protocol had assigned a 20% collateral factor to its own extremely illiquid Governance Token, letting an attacker manipulate the price with a small amount of capital and borrow assets far exceeding what the Token was actually worth. This incident dragged an issue nobody normally pays attention to into the light: who actually sets this number, and how?
Take Aave as an example — every asset has two related but distinct parameters. LTV determines the maximum you can initially borrow; the liquidation threshold determines when your position gets classified as undercollateralized. For WETH, LTV is typically set around 80%, while the liquidation threshold sits at 82.5% — that intentional 2.5% gap is a safety Margin built in by protocol governance, designed to prevent a user's position from already brushing up against the liquidation line the moment they finish borrowing, before the asset's price has even had a chance to move. These two numbers typically diverge based on the asset: a low-volatility asset like USDC might have an LTV and liquidation threshold of 80% and 85%; a more volatile asset like WBTC might only get 70% and 75% — the less stable an asset, the more conservative the safety margin a protocol tends to set.
In an on-chain governance protocol like Aave, whether an asset can be added to the collateral list, and what its LTV, liquidation threshold, and other parameters should be, theoretically requires passing through an Aave Governance Proposal, or execution by governance-appointed Asset Listing Admins. In practice, though, most DAO Governance participants aren't risk-modeling experts, so large protocols like Aave and Compound retain specialized third-party risk service providers (like Chaos Labs) to continuously monitor market conditions and asset liquidity, providing regular recommendations for parameter adjustments. These risk providers typically simulate borrower positions using historical on-chain data, testing how much risk the protocol as a whole would face under extreme conditions if a given parameter were adjusted, then submit quantified recommendations for governance to debate. In other words, the percentage you see on the interface is the output of a full pipeline: risk provider simulation → governance proposal → community vote → on-chain execution — a process most users never encounter when they deposit or borrow.
The Tectonic incident is worth singling out because it exposed an easily overlooked blind spot in the risk review process: a protocol's own native token. Tectonic's official documentation had explicitly warned that low-liquidity assets are prone to price manipulation, and the team had genuinely made dynamic adjustments to other assets in May and June of 2026, reducing borrowing limits — evidence this risk review mechanism was actually functioning under normal circumstances. But TONIC's own 20% collateral factor clearly wasn't brought under that same review. This isn't a rare situation: adding a protocol's own token to its collateral list often carries the motivation of giving the token more real-world use and boosting demand for it — a motive that serves a different goal than the risk judgment of "is this asset actually safe enough to use as collateral," and a gap in governance rigor tends to open up between the two.
Facing the dilemma of "a new asset wants to be listed, but its risk hasn't been sufficiently validated yet," Aave V3 introduced Isolation Mode: letting higher-risk or newer assets get added to the collateral list, but restricting them to only being used to borrow specific, capped-supply assets, without exposing the safety of the protocol's other liquidity pools. It's effectively letting that asset undergo market testing "in a small room" first, rather than sharing risk with the entire protocol's capital from day one. Conversely, for groups of highly price-correlated assets (multiple USD stablecoins, or ETH and its Staking derivatives, for example), Aave V3's E-Mode (Efficiency Mode) lets users obtain a higher LTV within that same category, because these assets' prices move together closely and their probability of blowing up simultaneously is relatively concentrated, meaning a smaller safety margin can be tolerated. These two mechanisms point in opposite directions but share the same underlying logic: risk parameters aren't a one-size-fits-all constant — they need to dynamically adjust to an asset's actual liquidity, volatility, and correlation.