> For the complete documentation index, see [llms.txt](https://delpho.gitbook.io/delpho-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://delpho.gitbook.io/delpho-docs/how-delpho-works/liquidations.md). # Liquidations Delpho's USDC/USDT collateral side uses 80% initial LTV and 90% liquidation threshold. A user at the maximum 80% has **roughly 11% of headroom** on the underlying asset before liquidation occurs. The protocol layers two distinct mechanisms: **auto-deleverage**, an opt-in protection that fires *before* the threshold, and **treasury-absorbed liquidation**, which fires once the threshold is crossed. {% hint style="info" %} For current LTV, liquidation threshold, fees and caps, see [Parameters](/delpho-docs/parameters.md). {% endhint %} ## Example A user deposits $100,000 of USDC and mints $80,000 of USDV (max LTV, 80%).
USDC moves toCollateral valueCurrent LTVWhat happens
$100,000 (entry)$100,00080%(no event)
$95,000 (−5%)$95,00084%Position still safe; health-factor warning visible
$88,889 (−11.1%)$88,88990%Liquidation threshold reached; treasury absorbs the position
{% hint style="info" %} If auto-deleverage is enabled, the protocol begins reducing LTV before this point. {% endhint %} ## Why this design, not cliff-edge auction Most lending protocols use cliff-edge liquidation. When the collateral ratio crosses the liquidation threshold, the position is auctioned to third-party liquidators at a discount, and the discount is paid by the borrower. The MakerDAO Black Thursday case in March 2020 is the canonical reason this design is fragile: bids of zero on liquidation auctions during a fast crash, and the protocol absorbing the bad debt directly. Delpho keeps liquidation economics inside the protocol. When a position crosses its threshold it becomes liquidatable, and the treasury, not a third-party auction, absorbs it. There is no external auction and no liquidator cascade feeding on itself during a fast move. ## Auto-deleverage: the progressive layer Auto-deleverage is the primary user protection, and it sits one step ahead of liquidation. Stakers opt in, and the protocol automatically unstakes a user's sUSDV and repays their USDV when their position's LTV rises toward the liquidation threshold. This trades a slice of yield for staying out of liquidation entirely. For a user who does not want to actively manage a position through a volatile market, auto-deleverage is what keeps them out of liquidation in the first place. It is the only progressive layer in the design; the liquidation itself, when it fires, is discrete. ## Liquidation: hard but bounded If a position crosses the liquidation threshold for its collateral without sufficient auto-deleverage capacity to bring it back, the `liquidate` function becomes callable. * The function is **permissionless**. Anyone can call it for a small reward. * Once called, the **treasury absorbs the position programmatically onchain**: the treasury buys out the debt with its own USDV and takes on the collateral. * The borrower **pays a total liquidation penalty of about 10%**: 9% to the treasury, a capped 1% to whoever calls the permissionless liquidate function. The borrower keeps the rest of their collateral. * If the treasury cannot absorb a position, the remaining debt is shared across other positions rather than left as bad debt. This is a hard liquidation, but a bounded one: the borrower's loss is the \~10% penalty, not the cliff-edge discount of an external auction. ## Treasury as liquidator Delpho's liquidation backstop is the protocol treasury rather than a user-funded stability pool. The stability-pool approach depends on third-party depositors being present at exactly the moment of stress, capital that can withdraw exactly when it is most needed. The treasury acquires the liquidated collateral at a discount using USDV when liquidations occur, and the resulting position is managed through the same hedging mechanism as the rest of the protocol's collateral, so liquidated collateral continues to earn funding rather than being transferred out to liquidators. ## Why CoreWriter matters here Because the `liquidate` function is permissionless and once called the treasury absorbs the position programmatically onchain, no privileged off-chain operator has to decide whether to act in the worst seconds of a fast market, which is exactly where external liquidation systems have historically failed. Because Delpho can read margin balances on HyperCore and adjust them from HyperEVM in a single atomic operation, there is no cross-venue race condition during a stress event. ## What this looks like to the user A user near the threshold receives: * Health-factor warnings in the UI. * Auto-deleverage applied automatically if enabled. * A discrete liquidation event if the threshold is crossed without sufficient auto-deleverage capacity. For the user-facing flow, see [Manage your borrow position](/delpho-docs/using-delpho/manage-your-borrow-position.md).