A public design specification for the liquidation mechanism in the forthcoming $GFOF lending protocol. Published before any smart contract code is written. Open to criticism, revision, and public challenge.
The $GFOF lending protocol is not live. No code is written. There is no contract to audit yet. The point of this document is to commit — in public, before we build — to how liquidations will work when the protocol does ship.
Most DeFi protocols ship liquidation logic as an afterthought. A position breaches a threshold, a bot grabs the collateral at a punitive discount, and the borrower absorbs the loss. This is mechanically efficient for the protocol. It is also, routinely, the single worst experience in DeFi.
The federation's stated thesis is that the best DeFi product hasn't been built yet. Liquidation design is one of the most visible places that thesis will be tested. We are publishing this spec first so that:
This document covers collateralized borrowing liquidation only. It does not cover stablecoin redemption, synthetic asset liquidation, insurance-fund design, or the oracle architecture the protocol will use. Those are separate specs that will follow.
It's worth being precise about what most lending protocols do today, because the phrase "liquidation" covers a wide range of mechanisms with very different effects on borrowers.
When a borrower's collateral value falls below the required loan-to-value ratio, any third party can call a liquidation function. The liquidator repays a portion of the borrower's debt and receives the borrower's collateral at a discount — typically 5% to 15%. The protocol gets a fee. The borrower loses the discount plus the liquidation penalty. In practice, at the moment of a market crash, borrowers can lose 10%–20% of their position in addition to whatever the underlying collateral was already doing.
Curve's LlamaLend replaces the instant hard liquidation with a gradual conversion: as the collateral price falls through the borrower's position band, the protocol algorithmically trades the collateral into the borrowed asset, gradually unwinding the position. This avoids the cliff-edge experience but can still crystallize losses, and requires a specific market structure (the collateral-to-borrowed pair must be deeply liquid on Curve).
Across both designs, three holder-hostile behaviors recur:
Any of the three is bad. All three together, which is the current norm, is what makes most DeFi users hesitant to borrow significantly. And that hesitance is the single largest reason lending TVL stays concentrated in stablecoin-collateral positions.
Before getting into the mechanism, here are the principles the design is measured against. These are public commitments. If a later version of this spec violates one, that violation must be called out explicitly in the revision history with a justification.
The design combines four components. Each one individually exists in isolated corners of DeFi; we have not yet seen a protocol combine all four, which is the design's distinguishing claim.
Every collateral market defines three thresholds, not one:
The gap between advisory and grace, and between grace and liquidation, are market parameters set by governance. For volatile collateral, the gaps will be wider to compensate for potential rapid price movement.
When a position enters the grace LTV band, a grace timer starts. During this window (initial proposal: 30 minutes for stablecoin-collateralized positions, 10 minutes for volatile collateral), the position is not liquidatable. The grace period exists to give the borrower time to:
If the position exits grace LTV during the window, the timer resets. If the position stays in grace and the window closes, the position becomes liquidatable — but only up to a partial amount (4.3).
If the collateral price drops below a catastrophic threshold (proposed: more than 30% below the liquidation LTV, in a single block), the grace period is bypassed and immediate partial liquidation is permitted. This prevents the mechanism from becoming a protocol-level risk during genuine market ruptures. This exception must never be used as a workaround to liquidate positions the protocol could otherwise protect — its use is logged on-chain and reviewed publicly after every event.
When a position is liquidatable, the maximum portion that can be liquidated in a single transaction is capped at 25% of outstanding debt, not 50%. This cap applies per-block. In practical terms this means:
The cap can be raised only if the catastrophic-drop exception (4.2) is active.
Liquidations are not claimable by any individual actor in the first block after a position becomes liquidatable. Instead, qualifying positions are batched into a dedicated per-block liquidation window, and the liquidator's reward is allocated proportionally among all actors who submitted valid liquidation transactions during that window. This removes the first-mover advantage, reduces liquidator fee burn, and — most importantly — removes the MEV incentive that drives aggressive price-feed manipulation around thresholds.
The specific mechanism for batched liquidation rewards is the most technically novel piece of this spec and is the place most likely to need revision after formal modeling. Proposed path: time-weighted reward distribution over a 1-block window, with a minimum stake requirement to submit to prevent spam. This will be quantified in v0.2 before any implementation work begins.
Let's walk through a concrete scenario to show how the mechanism behaves in practice. Numbers are illustrative, not committed parameters.
Setup. A borrower deposits $10,000 worth of SOL as collateral and borrows $5,000 of USDC. The market has an advisory LTV of 65%, grace LTV of 72%, and liquidation LTV of 78%. Initial LTV: 50%.
Event 1. SOL drops 20%. Collateral is now worth $8,000. LTV = 5000 / 8000 = 62.5%. Still below advisory. Position is healthy. No action taken.
Event 2. SOL drops another 8%. Collateral now $7,360. LTV = 5000 / 7360 = 67.9%. Advisory flag set. Borrower's wallet shows a yellow badge on the position. No penalty. No action permitted against the position.
Event 3. SOL drops another 7%. Collateral now $6,845. LTV = 5000 / 6845 = 73.0%. Grace LTV crossed. Grace period begins. Borrower receives push notification. 10-minute countdown begins (SOL is volatile collateral). Position is flagged grace-active but not yet liquidatable.
Event 4 — two paths.
Outcome of Path B. Borrower lost $62 to the liquidation bonus — not $625 as they would have in a standard 50%-seizure hard-liquidation protocol. They still hold most of their position. They have time to decide whether to close it voluntarily, repay more, or ride out the volatility. The protocol has done its job — preserving solvency — without taking 10x more from the borrower than necessary to do so.
This is a v0.1 spec. We are publishing it specifically because we don't have all the answers. Here are the open problems:
The grace-period mechanism assumes a borrower who can respond. If a borrower has clearly abandoned a position (no wallet activity for weeks, no response to multiple notifications), should the grace period still apply? Our current lean: yes, because the alternative is a heuristic that will be gamed. But this is a live debate.
If the oracle that feeds the collateral price is temporarily unavailable, the protocol can't tell whether a position is in grace. Two options: (a) pause liquidations entirely during oracle outages, risking bad-debt accrual; (b) fall back to a secondary oracle with larger deviation tolerance, risking oracle manipulation. We don't have a resolved answer. This is a separate spec.
An attacker could in theory attempt to force the market past the catastrophic threshold to bypass grace periods. We believe this is mitigated by the cost of moving a deep market that far in a single block, and by the public review of every catastrophic-exception event. But this deserves formal modeling.
With the 25% cap and a 5% liquidation bonus, the maximum loss per liquidation event is roughly 1.25% of the original position. That's the number we've committed to beating or explaining if we can't. (For comparison: at Aave's 50% close factor with a 7.5% liquidation bonus, the equivalent worst-case is roughly 3.75% per event.)
Our design deliberately reduces liquidator profit per event. If liquidators don't find it worthwhile to monitor positions, the mechanism stops working. The batched-reward design is meant to compensate by removing MEV bidding and improving predictability. Whether the math works out is an open question — one we will model in v0.2.
This spec is live for public criticism. If you see a flaw — a game-theoretic attack we missed, a parameter choice that won't survive contact with real markets, a scenario we haven't considered — we want to know. Send feedback to @WelksCrypto on X or to the admins in t.me/GFOF_SOL. All substantive public comments will be acknowledged in the revision log of the next version, with attribution unless the author requests otherwise.