? Liquidation Mechanics
When a Credit Account's health factor drops below 1.0, keepers rush in. Unlike Aave's simple collateral seizure, Gearbox liquidations must close live DeFi positions across Curve, Uniswap, and Yearn - atomically. Here's how it all works.
Credit Accounts
Isolated leveraged positions users control - how CAs work, fund, and interact with the Gearbox pool
Liquidation Mechanics
Health factors, liquidation thresholds, and how keepers clear underwater credit accounts
Connected Protocols
Curve LP, Uniswap v3, Yearn strategies - the DeFi primitives Gearbox routes capital through
GEAR Governance
How GEAR holders vote on protocol upgrades, fee parameters, and risk parameters
Health Factor Computation
Gearbox computes health factor across all open positions simultaneously. Each asset type has a collateral factor (CF) set by governance. The HF is recalculated after every block - every price tick matters.
? Liquidation Trigger Simulator
Set your collateral, borrowing, and strategy P&L to watch the health factor cross 1.0 in real time. Adjust the values to feel where the danger zones are for different asset classes.
Keeper Mechanics: Atomic Liquidation
Gearbox keepers are permissionless bots that monitor all Credit Accounts and execute liquidations atomically. They are the immune system of the protocol - and they compete fiercely for every liquidation opportunity.
? Aave vs Gearbox: Liquidation Comparison
Both protocols use health factor liquidation, but the mechanics differ substantially because Aave pools collateral while Gearbox must close individual DeFi positions.
| Dimension | Aave | Gearbox |
|---|---|---|
| Collateral model | Pooled (aTokens) - aggregated, fungible | Isolated (CA contract) - individual positions |
| Liquidation target | Partial collateral of pooled position | Entire Credit Account at once |
| What keeper closes | Flash-repay borrower's debt, seize collateral pool slice | Close actual DeFi positions (Curve LP, Uniswap NFTs, etc.) |
| Liquidation complexity | Low - single aToken transfer | High - must unwind protocol-specific positions |
| Keeper profit source | Collateral discount (5-10% penalty) | Liquidation penalty on entire CA value |
| Oracle dependency | Chainlink price feeds for all assets | Chainlink + protocol-specific oracle combos |
| Multi-position health | Single aggregated health factor | Aggregate across all CA positions |
| Permission to be keeper | Permissionless | Permissionless |
Liquidation thresholds vs collateral factors
Two numbers govern a Gearbox account's health: the collateral factor (CF) and the liquidation threshold (LT). They sound similar but serve different purposes. The collateral factor determines how much borrowing power your collateral unlocks - a 90% CF on ETH means you can borrow up to 90% of your ETH value. The liquidation threshold is the effective collateral value used in the health factor computation at the moment of liquidation computation. In Gearbox v2/v3, these converge to the same value, but in earlier versions or in risk-adjusted parameter sets, the LT might be set slightly below the CF - creating a small safety margin where HF > 1.0 doesn't mean you're safe from liquidation if the market moves fast.
Each asset has its own CF and LT set by GEAR governance. Volatile assets like ETH have lower CFs (80-90%); stablecoins like USDC have high CFs (95-100%). The gap between CF and LT can be thought of as the "liquidation buffer" - in Aave it's explicit; in Gearbox it's usually implicit in the parameter values.
Keeper economics and competition
Keeper profit on Gearbox = (seized collateral value liquidation penalty) ? gas costs ? slippage during position close. The liquidation penalty is typically 5-10% of the CA's value, set by governance. If a keeper seizes a $50,000 Credit Account, their theoretical profit at a 10% penalty is $5,000 minus gas and execution costs.
During market volatility - especially ETH price drops - multiple CAs can breach HF 1.0 simultaneously, and keepers compete in Priority Gas Auctions (PGAs) to be the first in the block. A keeper with superior infrastructure (low-latency oracle feeds, optimized tx construction, MEV-aware RPC) will consistently win more liquidations and earn more profit. This creates a natural selection pressure toward professional, well-capitalized keepers - which in turn makes the liquidation market more efficient.
The save: adding collateral to avoid liquidation
The most important user-side tool in the liquidation cycle is the addCollateral call. If your HF is trending toward 1.0, you can deposit additional collateral to push it back above safe levels. This is a legitimate risk management tool - not a workaround - and it happens constantly in active leveraged accounts.
The race dynamic is worth understanding: if your addCollateral transaction and a keeper's liquidation transaction both land in the same Ethereum block, the ordering matters. If yours executes first and pushes HF above 1.0, the keeper's liquidation reverts (the CM will reject it). This creates a mempool arbitrage dynamic where sophisticated keepers use "sandwich" techniques or high-gas bids to ensure their liquidation lands first. For most users, the practical lesson is: monitor your HF actively, and don't wait until it's close to 1.0 to act.
Frequently asked questions
- How is the health factor computed in a multi-position Credit Account?
- The health factor is computed as the sum of all position values (valued at current oracle prices) multiplied by their respective collateral factors, divided by the total borrows. For example, if your CA holds $20k of Curve LP (80% CF) and $10k of Uniswap positions (75% CF), with $28k of borrows: HF = (200000.80 + 100000.75) / 28000 = (16000+7500)/28000 = 23500/28000 = 0.84 - below 1.0, liquidatable. Each asset's collateral factor is set by GEAR governance based on liquidity and volatility risk.
- What is a liquidation threshold and how does it differ from a collateral factor?
- The collateral factor (CF) determines how much you can borrow against an asset. The liquidation threshold (LT) is the effective collateral value used in the health factor computation at the moment of liquidation. In Gearbox, the LT is typically equal to the CF (or slightly lower in some versions) but the key distinction is timing: the CF applies during normal operation, while the LT is applied when a keeper executes a liquidation. In practice, they often converge to the same value in Gearbox v2/v3, making them functionally equivalent for health factor computation.
- How do keepers detect and execute liquidations on Gearbox?
- Keepers are off-chain bots that continuously monitor all open Credit Accounts by querying the Credit Manager contract. They compute each account's current health factor using on-chain oracle prices. When an account's HF drops below 1.0, the keeper calls liquidateCreditAccount in a single atomic transaction: the keeper's bot seizes the CA's collateral positions, closes them at current market prices (via the whitelisted protocol integrations), repays the debt to the Gearbox pool, and keeps the liquidation penalty as profit. The atomic execution is key - it means the keeper closes all positions in one tx, preventing partial losses.
- What is the liquidation penalty and who receives it?
- The liquidation penalty is the discount at which keepers seize and purchase the collateral. Typically 5-10% of the account's value, it compensates the keeper for execution risk, gas costs, and the risk of price movement during the close. On Gearbox, the penalty is set by GEAR governance and varies by asset - more volatile assets may have a higher penalty to attract keeper participation. The keeper receives the difference between the seized collateral value (at oracle prices) and the repaid debt (at par).
- Is Gearbox's liquidation mechanism different from Aave's?
- Yes, meaningfully so. On Aave, liquidators repay the borrower's flash-borrowed short position and seize collateral in one transaction - but Aave's collateral is a fungible pool deposit (aTokens), so the liquidation closes part of a shared position. On Gearbox, the keeper must close actual DeFi positions (Curve LP tokens, Uniswap v3 NFTs, etc.) to extract the collateral. This makes Gearbox liquidations more complex - they require understanding how to unwind DeFi positions - but it also means the keeper closes the entire account atomically rather than just a tranche.
- Can you avoid liquidation by adding collateral at the last moment?
- Yes - this is called a "save" and is a legitimate part of the risk management cycle. If your health factor drops close to 1.0, you can call addCollateral on the Credit Manager to deposit more collateral before a keeper triggers liquidation. Since blockchain transactions are atomic, if your addCollateral transaction lands in the same block as a keeper's liquidation tx, the ordering matters - but generally, if your tx gets included first and pushes HF above 1.0, the keeper's liquidation will revert. This creates a race dynamic. Some traders deliberately operate near the liquidation threshold and add collateral reactively - a high-risk strategy.
- What happens to open DeFi positions during a Gearbox liquidation?
- The Credit Manager's liquidateCreditAccount function iterates through all open positions in the CA, closes them via the whitelisted protocol integrations (e.g., removes Curve LP, burns Uniswap v3 NFTs), and converts the proceeds to the collateral asset. All of this happens in one atomic transaction. The keeper then repays the debt and claims the collateral surplus plus the liquidation penalty. This atomic closure is more complex than Aave's because each protocol has different unwinding mechanics - Uniswap v3 NFTs require burning the liquidity position at specific ticks, which can have partial fills if gas is limited.
- Who can become a Gearbox keeper and what infrastructure is required?
- Anyone can run a Gearbox keeper - there is no permissioned role. In practice, keepers are automated bots run by professional DeFi marketmakers who have the infrastructure to (1) monitor all Credit Accounts, (2) compute HF in real time using on-chain oracle prices, (3) execute atomic liquidations across multiple DeFi protocols. The keeper needs gas capital to execute the liquidation transaction and needs to be able to estimate the liquidation profit accurately to avoid being outbid by other keepers in a Priority Gas Auction.