Storage Liquidation Mechanism

All storage liquidation systems share core components:

• Collateralization: Providers must lock native tokens (e.g., FIL, SC, CRU).
• Verifiable Proofs: Cryptographic proofs (PoSt, PoA) that data is stored.
• Slashing Conditions: Pre-defined rules triggering penalty (e.g., fault, downtime).
• Automated Enforcement: Smart contracts or protocol rules execute liquidation without intermediaries.
• Data Repair: Healthy networks automatically replicate data from slashed nodes to new providers.

The primary purpose is to protect the lending protocol from bad debt by automatically triggering a sale of a borrower's collateral when their health factor or collateralization ratio falls below a safe level (e.g., 1.0). This process is executed by keepers or liquidators who are incentivized with a liquidation bonus.

• Trigger: Based on real-time oracle price feeds.
• Execution: Collateral is sold, often at a discount, to repay the debt.
• Outcome: Borrower's position is closed or reduced, and the protocol remains solvent.

A major systemic risk where multiple, large liquidations in a volatile market can create a downward price spiral.

• Mechanism: Forced sales of collateral depress its market price.
• Impact: This triggers further liquidations for other positions using the same asset as collateral, amplifying losses.
• Example: The "Black Thursday" event in March 2020 on MakerDAO, where ETH price drops triggered mass liquidations and network congestion, leading to zero-bid auctions and system debt.

The mechanism's integrity depends entirely on accurate price oracles. Attackers may attempt to manipulate the oracle price to trigger unjustified liquidations or to front-run liquidation transactions.

• Oracle Attack: Artificially lowering the reported collateral price to trigger a liquidation.
• Miner Extractable Value (MEV): Bots can pay higher gas fees to sandwich the liquidation transaction, buying the discounted collateral before the official sale and profiting from the spread, increasing costs for the borrower.

The practical execution of a liquidation faces market constraints that can lead to losses for the protocol or liquidators.

• Slippage: Large liquidation orders in illiquid markets can be filled at prices significantly worse than the oracle price, potentially leaving uncovered debt (bad debt).
• Keeper Incentives: If the liquidation bonus does not cover gas costs and slippage, keepers may not act, leaving risky positions open.
• Solution Patterns: Protocols use gradual liquidation curves, auction mechanisms (e.g., Dutch auctions), or dedicated liquidity pools (like stableswap pools) to improve efficiency.

Protocol governance must carefully calibrate key parameters, which themselves are a source of risk.

• Liquidation Threshold: Setting it too low increases protocol risk; too high makes users vulnerable to minor volatility.
• Liquidation Penalty / Bonus: This fee must incentivize liquidators without being overly punitive to borrowers.
• Health Factor Grace Periods: Some protocols add a liquidation grace period to give borrowers time to react, which introduces a trade-off between user protection and protocol security.

A recurring fee paid by users to the network for the persistent storage of their account state (e.g., smart contract code, data). It is the economic foundation that makes storage liquidation necessary. Failure to pay rent triggers the liquidation process.

• Purpose: Compensates validators for the cost of permanent state storage.
• Mechanism: Can be a continuous deduction or a periodic fee.
• Example: On Solana, accounts must maintain a minimum balance proportional to their data size, which acts as a form of rent.

The uncontrolled growth of the blockchain's historical state data, which increases hardware requirements for node operators and reduces network performance. Storage liquidation mechanisms are the primary defense against this.

• Cause: Accumulation of unused or abandoned account data.
• Consequence: Higher costs for node operation, potentially leading to centralization.
• Solution: Liquidation and eventual pruning of non-paying accounts reclaim this storage.

The event where a user's account is successfully liquidated, and its on-chain address (public key) becomes available for re-registration by a new user. This is the final step in the storage liquidation cycle.

• Process: After liquidation, the address enters a grace period before being recycled.
• Implication: Any funds remaining in the liquidated account are burned or sent to a community treasury; they are not recoverable by the original owner.
• Purpose: Enables the efficient reuse of the finite on-chain address space.

A minimum account balance threshold that, when met, exempts the account from periodic rent payments. This is a common design to simplify user experience for active accounts.

• How it works: Depositing enough lamports (SOL) or ether to cover the estimated cost of storage for two years typically grants exemption.
• Liquidation Trigger: If the account balance falls below this threshold, it becomes subject to rent collection and potential liquidation.
• Example: A key concept in the Solana and Ethereum (post EIP-1559) economic models.

A cryptographic proof that a specific piece of data is stored and accessible. In some blockchain designs, these proofs are required to avoid liquidation, linking storage to a verifiable claim.

• Function: Allows users to prove they are maintaining off-chain or sharded data, making them ineligible for liquidation.
• Related Systems: Found in data availability layers and scaling solutions like validiums.
• Contrast: Differs from pure on-chain state rent, as the cost is for proving availability, not for raw storage.

The process of permanently deleting old or liquidated state data from a node's active storage. Liquidation makes accounts eligible for pruning.

• Relation to Liquidation: Liquidation marks state as 'deletable'; pruning is the physical deletion.
• Node Operation: Archive nodes retain all history, while pruning nodes delete old state to save space.
• Network Benefit: Reduces the hardware burden for the majority of network participants, aiding decentralization.