Liquidation Mechanics

Liquidations in Helios occur when a borrower’s collateral value is no longer sufficient to cover their loan (plus a safety margin). Given the adaptive LTVs, this threshold might move over time, but the fundamental process is similar to other DeFi platforms with some Bitcoin-specific enhancements:

• Trigger: If a loan’s current LTV exceeds the allowed maximum (i.e., collateral value/loan value falls below required ratio), it becomes eligible for liquidation. The allowed maximum LTV may have been adjusted dynamically just prior based on risk inputs. Helios likely computes this continuously as oracle prices update.

• Liquidation Process: Once eligible, a liquidator (which could be any participant or bot listening to Helios) can repay some or all of the loan on behalf of the borrower and receive an equivalent value of the collateral at a discount (the liquidation bonus). For example, if a user borrowed 1 BTC and put 1.5 BTC as collateral and now it’s underwater, a liquidator might pay back the 1 BTC (to the protocol/lenders) and in return receive, say, 1.1 BTC worth of the collateral – effectively buying collateral at 10% discount (that 10% is the bonus or penalty charged to the borrower).

• Bitcoin-Native Execution: The liquidation transaction itself would be a Bitcoin transaction possibly crafted via the MIDL instruction. The liquidator likely needs to supply BTC to repay the debt into the vault (or use existing funds in the system if they have any), and then the protocol transfers the corresponding collateral BTC to the liquidator’s address. Because both the debt repayment and collateral seizure are Bitcoin transfers, this can be atomic or done in a very short sequence to avoid any race conditions. Helios might also allow partial liquidations: liquidators could choose to clear just enough of the loan to bring it back to safety, rather than whole position – this prevents situations where huge positions have to be taken over all at once.

• Adaptive Incentives: As noted, Helios adjusts the liquidation bonus (penalty) dynamically. In normal conditions, the bonus might be small (e.g., 5%) to minimize cost to borrowers. In times of high congestion or risk, the bonus could increase (maybe 10% or more). This ensures liquidators are incentivized to act promptly even if it’s costly to do so (like paying high fees or taking on volatility risk in turbulent markets).

• Mempool Awareness: A unique twist – Helios’s risk engine might pre-emptively do “top-up liquidations” or require additional collateral if mempool conditions are degrading and a position is borderline. This is more of a preventive measure, effectively calling margin on a borrower before things get critical. If the borrower (or an automated system) can’t top up in time, a partial liquidation might be executed to reduce the loan size. This way, by the time a severe condition hits, many risky positions have already been de-risked. This is novel in DeFi, where usually liquidation is binary and reactive; Helios brings a proactive flavor to it.

• Liquidator Participation: Developers or arbitrageurs can run liquidator bots listening for Helios state updates (likely via the MIDL layer events or a validator-provided feed). They would monitor which loans are liquidatable and then create the appropriate Bitcoin transactions to seize collateral. Helios may see a set of specialized liquidators emerge, possibly including the validators themselves or third-party services.

• No Bad Debt Goal: The combination of over-collateralization, adaptive parameter tightening, and incentivized liquidations aims to ensure the protocol does not accrue bad debt (undercollateralized losses). In extreme scenarios (flash crashes, etc.), Helios’s dynamic adjustments and possibly an insurance fund would cover shortfalls. The whitepaper mentions the idea of an insurance pool funded by a portion of interest, to backstop any unexpected losses. This would further reassure lenders that even in edge cases they won’t lose principal.