Marginfi liquidations allow collateral seizure when maintenance health is zero or negative
Marginfi liquidations become possible when an account's maintenance health reaches zero or falls below it in the Solana program powering Project 0. Liquidators can seize collateral while reducing debt through classic or receivership liquidation. The trigger depends on oracle prices, accrued debt and configured risk weights. A failed new borrow doesn't by itself mean the account is liquidatable. The former Marginfi frontend was retired in mid-2026; its lending program continues to power Project 0.
Key takeaway: Successful repayment reduces a liability; a valid, fresh maintenance-health assessment determines whether the remaining account still faces liquidation.
When Can a Liquidator Seize Collateral?
A previously healthy loan becomes liquidatable when prices, accumulating interest or changed risk weights push maintenance health to zero or below. Eligibility lets a third party submit a liquidation transaction. The program still checks oracle data, account state and the proposed operation before collateral moves.
Borrowing Capacity Before Liquidation
Initial weights govern new borrowing, while maintenance weights determine liquidation exposure. An account can lose borrowing capacity before it crosses the liquidation boundary.
Collateral Seizure and Remaining Debt
A partial liquidation removes some collateral and reduces selected liabilities, leaving the remaining positions on the account. The collateral reduction also removes its contribution to account health. Further price movement can expose the remaining position to another liquidation, even after the first operation improves health.
Borrower-Controlled Debt Reduction
Repayment lowers debt, and an eligible collateral deposit can improve health before a liquidation lands. A wallet approval or submitted transaction doesn't alter on-chain balances. Ordinary withdrawals must satisfy initial health, so removing collateral isn't a general escape from an unhealthy loan. Operational restrictions can also limit the available response.
Confirming a Repayment Before Relying on It
A wallet-funded repayment reduces a selected liability only after the program executes it successfully. To track an account near the threshold, separate confirmed debt reduction from the fresh health reading needed to establish its remaining liquidation exposure.
- Select the existing debt balance and check the wallet can fund repayment, including accrued interest when closing it.
- Check the bank and protocol permit repayment, then sign the transaction with the account's required signer and submit it.
- Wait for successful confirmation of repayment; a submitted signature doesn't establish the updated debt balance.
- Reload the account's liabilities and request a fresh maintenance-health assessment with the required bank and oracle accounts.
- Check the assessment's oracle and engine status before using its maintenance-health value to identify continuing liquidation eligibility or a positive buffer at that check.
If required oracle data is stale, repayment may succeed while the health assessment records an oracle error, even when its instruction returns successfully. The confirmed liability reduction then proves only part of the change. It doesn't establish the account's new maintenance-health value, and an older health display can't fill that gap.
Maintenance Health and Oracle Valuation
Maintenance health uses weighted collateral and debt values across the account's active positions.
Maintenance health equals total maintenance-weighted collateral value minus total maintenance-weighted debt value.
For feeds with confidence intervals, the program discounts collateral prices and increases debt prices before applying weights. A wallet's raw asset total therefore doesn't establish liquidation eligibility. The program's health instruction,
lending_account_pulse_health
, supplies an assessment using the relevant bank configuration and oracle accounts.
Liquidation's maintenance-health checks use spot prices when an oracle supplies both spot and exponential moving average prices. New borrowing uses the moving average in that setup. Additional interest can increase liabilities even without another borrow. Efficiency Mode (Emode) also affects the applicable weights for configured asset pairings. A liquidation-price estimate must hold other inputs constant; changing liabilities or weights changes the estimate.
Classic Liquidation's Account Changes and Fees
Classic liquidation uses
lending_account_liquidate
to credit selected collateral to the liquidator's Project 0 account and debit its balance in the selected liability bank. The liquidator must have that account and meet the operation's risk checks. The borrower loses collateral as the protocol reduces the selected liability.
The Liquidator's Account Debit
The classic method's default liquidator fee is 2.5% of the collateral value used in the calculation. Under that configuration, the liquidator covers debt worth 97.5% of the seized collateral's conservatively priced value. The program uses any deposit in the selected liability bank first, then creates debt for the remainder. The borrower receives a debt reduction, not a token payment. A later withdrawal and swap can help unwind any resulting liability, but an executable route and sufficient liquidity still matter.
The Borrower's Debt Credit
With the additional default 2.5% insurance component, the borrower's debt credit equals 95% of that same collateral value. The gap funds the liquidator premium and insurance allocation. Program 0.1.10 introduced per-liability-bank liquidation-fee configuration, so these percentages aren't permanent terms for every pair. Applicable settings determine the collateral-to-debt conversion. On some high-leverage Emode pairs, the premium and insurance fee prevent classic liquidation from improving health; receivership can still liquidate those pairs.
Classic liquidation must strictly improve maintenance health without taking it above zero. A proposed seizure exceeding that boundary or fully repaying the selected liability fails the instruction.
Receivership Control and the Final Health Check
Receivership liquidation temporarily lets a liquidator withdraw and repay within the borrower's unhealthy account. The liquidator doesn't need a separate funded lending account, although transaction fees require SOL. The program compares final maintenance health with its starting value and rejects deterioration.
Permitted Operations Inside Receivership
Within receivership, the permitted Marginfi financial operations are withdrawals and repayments, including supported integration withdrawals. Swaps can run through an allowed external swap program between those operations. The liquidator can't open new positions. The start instruction follows only allowed setup instructions, such as compute-budget instructions, liquidation-record initialization and required venue refreshes; the end instruction comes last. Full withdrawals or repayments may leave balance slots active; those slots' oracle accounts remain necessary for the final check.
Final Health and Seizure Limits
Receivership rejects a final maintenance-health value below its starting value. Outside the small-account closeout exception, final health must also stay at or below zero, and the program caps seized equity relative to repaid equity. The relationship is
seized equity <= repaid equity * (1 + maximum fee)
. Equity valuation uses time-weighted prices when available and retains oracle-confidence adjustments. It applies no risk weights; isolated deposits contribute no value. The global fee administrator controls the maximum through
FeeState.liquidation_max_fee
; the effective percentage ceiling is the larger of that setting and 5%. Receivership also charges a flat lamport fee set by
FeeState.liquidation_flat_sol_fee
. Swap slippage affects available repayment and surplus, so the percentage ceiling doesn't establish a realized profit. An improved reading may still be negative, leaving the borrower exposed to another liquidation.
Oracle Freshness and Integration Withdrawals
Classic liquidation needs fresh prices for the seized collateral, the selected debt and the borrower's maintenance-health check. The liquidator's initial-health calculation can ignore unneeded stale collateral, although separate circuit-breaker checks may still require those prices. Switchboard pull feeds require a caller-supplied update. Pyth supplies external updates, while Scope's feed operator refreshes its entries. Each required oracle feed must satisfy its bank's configured maximum price age.
Kamino-backed collateral adds reserve and obligation refreshes to the operation's dependencies. Receivership places required refreshes before liquidation starts, and Kamino requires current reserve state within the same slot. A wrapped Kamino position also needs its integration-specific withdrawal instruction. Solana's transaction-size and compute constraints can prevent a proposed liquidation-and-swap combination from fitting one transaction.
Operational Stops and Continuing Exposure
Operational restrictions can block liquidation even when an account shows negative maintenance health. Program 0.1.10 added oracle circuit breakers that can halt borrowing, risk-increasing withdrawals and permissionless liquidation after sufficiently large price moves. During a breaker halt, receivership liquidation is blocked, while the group or risk administrator can still use classic liquidation. A global pause suspends financial operations across groups and banks. A Paused bank also prevents repayments, limiting a borrower's immediate response. A temporary execution stop doesn't itself cancel the outstanding liability or establish that the account has regained a health buffer.
Uncovered Debt and Depositor Losses
Bankruptcy settlement addresses residual debt once the account's recognized unweighted asset value is effectively exhausted. A partial liquidation doesn't itself establish bankruptcy; residual debt can still have collateral behind it. Receivership also has a closeout exception for liquidatable accounts starting with less than $5 in recognized unweighted assets, before subtracting debt. It permits full closeout without the usual zero-health ceiling or percentage fee cap. During bankruptcy settlement, the affected bank's insurance reserves absorb bad debt first. An insurance fund reduces that loss only to the extent it holds sufficient reserves.
If insurance can't cover the remainder, the program reduces the bank's asset share value and spreads the loss across remaining depositors. Exhausting both insurance and remaining liquidity can permanently disable the bank and set its asset share value to zero. The group administrator normally invokes
handle_bankruptcy
; a bank with
PERMISSIONLESS_BAD_DEBT_SETTLEMENT_FLAG
enabled permits anyone to invoke it. Liquidation premiums and insurance allocations don't provide complete deposit protection.
Practical questions about Marginfi liquidations
Does Reduce-Only Mode Prevent an Existing Position's Liquidation?
Reduce-Only mode allows liquidation to continue while disabling new deposits and borrows. Existing positions keep accruing interest, and the bank's risk parameters remain active. Repayments and withdrawals remain available within their applicable constraints. A bank's retirement process therefore doesn't remove an existing borrower's liquidation exposure or create a period without interest charges.
Can Zero-Weight Collateral Be Seized During a Marginfi Liquidation?
Classic liquidation can seize collateral with zero asset weight, while receivership cannot withdraw isolated zero-weight positions. Zero collateral weight removes borrowing capacity from that asset; it doesn't necessarily prevent seizure through the classic method. The classic liquidator must still reduce real debt under the operation's rules. Receivership also excludes withdrawals of positions priced at zero.
Will a Tiny Non-Preferential Debt Preserve Emode's Higher Collateral Weights?
Even a small non-preferential debt can remove Emode benefits because the protocol applies the least favorable treatment across borrowed assets. Debt size doesn't exempt that liability from the pairing rules. Adding it can reduce account health, while repaying it can restore an applicable boost. The precise effect follows the borrowing banks' configured Emode entries and the account's remaining liabilities.
Which SDK Version Supports Monitoring Banks With the New Oracle Setups?
Version 2.8.0 or later of @0dotxyz/p0-ts-sdk supports the oracle setups introduced by program 0.1.11. Older SDKs can fail while decoding a migrated bank and prevent client initialization, interrupting account monitoring. The legacy @mrgnlabs/marginfi-client-v2 package has been deprecated since March 15, 2026 and doesn't support those setups. One migrated bank can affect initialization across the entire group.
Why Can a Leveraged Loop Face Liquidation After Its Flash Loan Succeeds?
A successful flash loan satisfies its final initial-margin health check, while later price changes and interest can erode maintenance health. The atomic transaction protects the loop's execution boundary. It doesn't freeze collateral prices, debt balances or risk settings afterward. A leveraged position therefore retains liquidation exposure after its opening transaction completes, even if every instruction executed successfully.
Does a Receivership Liquidation Record Prove All Debt Has Been Repaid?
A receivership liquidation record stores event history and doesn't prove every liability has been repaid. Anyone can create the account's liquidation record before a liquidation; the record stores recent events after receivership completes. Current balances show the remaining collateral and debt. A fresh maintenance-health assessment describes current exposure; the historical record alone doesn't establish a positive buffer or a debt-free account.
Are Wrapped Kamino Liquidation Amounts Measured in Underlying Tokens?
Wrapped Kamino liquidation instructions use collateral-token amounts, which need conversion at the current receipt-token exchange rate. Underlying-token UI amounts accepted by SDK withdrawal helpers refer to another interface. The collateral-token quantity and redeemable underlying amount aren't interchangeable, even when both describe the same position. Interest changes their conversion rate, so stale conversion data can misstate what a seized position represents.
Updated -