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.3 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 draft 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.3.
The mechanism described in Sections 3 and 4 was not designed to be marginally better than Aave's at the same job. It was designed to be the only credible mechanism for collateral types that today's lending protocols structurally cannot serve.
This section makes that claim explicit. None of the use cases below are commitments to ship — they are illustrations of what becomes possible when liquidation stops behaving like a guillotine. Each one is a domain where industry discourse has been loud and execution has been roughly nonexistent.
This section describes what the design enables, not what we are promising to build next. Lending against prediction-market positions, illiquid real-world assets, or partial credit is technically and commercially hard for reasons beyond liquidation alone. We document this here so the design's distinguishing claim is on the record. We do not document it to set near-term expectations.
A YES share on a Polymarket-style binary contract trades smoothly between $0.00 and $1.00 until resolution, at which point it jumps to one endpoint. Standard lending liquidation engines assume continuous price paths — they're built around the implicit physics of an order book that moves in small steps. A position holding 100,000 YES shares at $0.62 has $62,000 of marketable value at any moment and a non-zero probability of going to $0 in a single block when the market resolves.
This is why no major lending protocol accepts PM positions as collateral despite the category having grown to roughly $9–11B in open interest. A standard hard-liquidation mechanism cannot price the discontinuity. A standard health-factor calculation has no place to put the resolution risk. The asset is functionally trapped at 0% utilization across all of DeFi.
The Federation's mechanism handles this case gracefully because the architecture separates position monitoring from liquidation execution. Specifically:
None of this makes PM-collateralized lending easy. It does mean the liquidation mechanism is not the blocker. The remaining blockers — oracle architecture for resolution events, position-size limits relative to market liquidity, the legal status of PM shares as collateral in various jurisdictions — are real and unsolved. We name them so the gap between "liquidation works" and "lending product ships" is honest.
Real-world asset tokens, locked staking receipts, and vested token allocations all share a property that breaks standard liquidation: the collateral cannot be sold into a deep market in a single block. A 50% close factor against an illiquid asset will, at best, fill at a 20–40% discount; at worst, it cannot fill at all.
The 25% partial-liquidation cap, combined with batched execution across blocks, is functionally a slow-liquidation mechanism. For collateral with limited daily liquidity, the cap can be lowered further per-market — a parameter governance can tune to match the actual depth of the secondary market for that asset. The design treats the time dimension of liquidation as a primary parameter, not an inconvenience.
This matters for the same reason it matters in TradFi: capital efficiency improvements for assets with constrained liquidity have historically been one of the largest sources of yield in the entire financial system. DeFi's near-zero utilization of these assets is the analog of a bond market that cannot accept any collateral except cash.
Undercollateralized lending is the longest-discussed unrealized opportunity in DeFi — the entire category sits at roughly 5% of lending TVL despite years of being called "the next phase." The reasons it hasn't shipped at scale are well known: identity, default-rate economics, and the absence of a privacy layer that would let creditworthy users prove solvency without publishing their financial position.
The Federation's roadmap commits to the privacy layer (Phase 03 — ZK proofs plus proof-of-humanity), and the liquidation spec is the second piece of the puzzle. A credit-based position requires a liquidation mechanism that can act on partial information, give the borrower a meaningful chance to cure the position, and not crystallize losses at the worst possible moment of a market move. That description matches the mechanism in Section 4 closely enough that the same engine handles both fully-collateralized and partially-collateralized positions, with credit risk expressed as additional parameters rather than a separate code path.
Whether this is the path that finally cracks credit-based DeFi is unknown. What we can say with confidence is that any team that ships credit-based lending without first solving the borrower-protective liquidation problem will produce a default cascade the first time the market moves hard. The order of operations matters.
The design's distinguishing characteristic is not "fairer to borrowers." Many designs claim that. The distinguishing characteristic is that it widens the set of collateral types the protocol can responsibly accept. Hard liquidation effectively requires deeply liquid, continuously-priced, transparently-valued assets. Almost everything outside that narrow set has been left to overcollateralized stablecoin pools or unsupported entirely.
Most of the trillions of dollars of capital that DeFi proponents have spent five years promising to unlock sit outside that set. Cracking it requires not just better protocols but the upstream design choice to build liquidation around borrower preservation rather than liquidator extraction. That is what this spec commits to.
The federation will not announce plans to ship lending against any of the collateral types described above on any specific timeline. The discipline of this spec is to commit only to what we have publicly designed and can defend. We name these use cases here because the mechanism was designed with them in mind — and because hiding that intent would be its own kind of dishonesty.
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.