Liquidations

DobDex implements an orderly liquidation system that allows RWA token holders to exit their positions at a controlled discount rather than dumping into an AMM and crashing the price. Liquidations are matched against liquidity nodes in FIFO order, with configurable penalty parameters that protect both sellers and LPs.

Why Orderly Liquidations Matter

In traditional DeFi, forced selling causes a destructive feedback loop:

Forced sell --> AMM price drops --> More positions underwater --> More forced sells --> Price crash

This is catastrophic for RWA tokens, where the underlying asset has a real, appraised value. A solar panel installation worth $50,000 should not trade at $20,000 just because several holders needed to exit simultaneously.

DobDex breaks this cycle by separating the exit price from market dynamics:

Forced sell --> Fixed penalty applied --> LP matched at discount --> Oracle price unchanged

The oracle price remains stable because it reflects the real-world appraisal, not the trading activity. The seller takes a known, bounded loss, and the LP receives tokens at a known discount.

Liquidation Parameters

An admin configures liquidation parameters for each RWA asset:

Parameter	Type	Description
penaltyBps	uint256	Liquidation penalty in basis points (100 bps = 1%)
isLiquidatable	bool	Whether the asset is eligible for liquidation
maxLiquidationAmount	uint256	Per-event cap on liquidation volume
globalLiquidationCap	uint256	Total liquidation volume cap across all events

Setting Liquidation Parameters

function setLiquidationParams(
    address rwaToken,
    uint256 penaltyBps,
    bool isLiquidatable,
    uint256 maxLiquidationAmount,
    uint256 globalLiquidationCap
) external onlyAdmin;

Typical configurations:

Asset Type	penaltyBps	Rationale
Low-risk infrastructure	500 (5%)	Stable assets, predictable revenue
Medium-risk devices	1500 (15%)	Some operational risk
High-risk early-stage	2500 (25%)	Unproven assets, higher discount needed to attract LPs

Liquidation Flow

Step 1: Seller Initiates Exit

A token holder decides to exit their position. They call the liquidation function with the number of tokens they want to sell:

function liquidate(
    address rwaToken,
    uint256 amount
) external returns (uint256 usdcReceived);

Step 2: Penalty Calculation

The system calculates the seller's proceeds after the penalty:

Oracle price:        $50/token
Tokens to liquidate: 100
Gross value:         100 * $50 = $5,000
Penalty (20%):       $5,000 * 0.20 = $1,000
Seller receives:     $5,000 - $1,000 = $4,000 USDC

The seller knowingly accepts the penalty in exchange for an immediate, guaranteed exit.

Step 3: LP Matching (FIFO)

The system iterates through the liquidity node queue to find LPs willing to absorb the tokens:

Liquidation: 100 tokens at $50 oracle price, 20% penalty

LP Queue (FIFO order):
  Node 1: Alice  | 3,000 USDC | minPenalty: 1500 bps | --> MATCH (2000 >= 1500)
          Alice buys 60 tokens at $40/token ($2,400 used, $600 remains)
  Node 2: Bob    | 5,000 USDC | minPenalty: 2500 bps | --> SKIP (2000 < 2500)
  Node 3: Carol  | 10,000 USDC | minPenalty: 1000 bps | --> MATCH (2000 >= 1000)
          Carol buys 40 tokens at $40/token ($1,600 used)

Each matched LP receives RWA tokens at the discounted price:

LP purchase price = oracle_price * (1 - penaltyBps / 10000)
LP purchase price = $50 * (1 - 0.20) = $40/token

Step 4: Settlement

Party	Receives	Pays
Seller	4,000 USDC	100 RWA tokens
Alice (LP)	60 RWA tokens	2,400 USDC
Carol (LP)	40 RWA tokens	1,600 USDC

The total USDC paid by LPs ($4,000) equals the amount received by the seller. The penalty ($1,000 worth of tokens) is the discount that LPs receive -- they paid $4,000 for tokens worth $5,000 at oracle price.

Reserve Hold

To prevent cascading liquidation events from draining all liquidity, the system enforces a reserve hold:

uint256 constant RESERVE_BPS = 3300; // 33%

33% of each LP node's capital is held in reserve and cannot be used for liquidation matching. This ensures that:

• Normal trading operations always have liquidity available
• A single large liquidation cannot consume all LP capital
• The system remains solvent even during stress events

Example

An LP deposits 10,000 USDC:

• Available for liquidation matching: 6,700 USDC (67%)
• Reserved for normal operations: 3,300 USDC (33%)

Even if every eligible liquidation is matched against this LP, 3,300 USDC remains untouched.

Liquidation Caps

Per-Asset Cap

Each asset has a maxLiquidationAmount that limits how many tokens can be liquidated in a single event:

require(amount <= liquidationParams[rwaToken].maxLiquidationAmount, "Exceeds per-event cap");

This prevents a single large holder from liquidating their entire position in one transaction, which could overwhelm the LP queue.

Global Cap

A globalLiquidationCap limits the total liquidation volume across all events for an asset:

require(
    totalLiquidated[rwaToken] + amount <= liquidationParams[rwaToken].globalLiquidationCap,
    "Exceeds global cap"
);

This provides a hard ceiling on total liquidation activity, giving the protocol time to respond to unusual selling pressure.

Partial Liquidation

If the LP queue does not have enough matched liquidity to cover the full liquidation amount, a partial liquidation occurs:

1. All matching LP nodes are consumed
2. The seller receives USDC proportional to the matched amount
3. Remaining tokens are returned to the seller
4. The seller can retry later when more LP liquidity is available

Requested: 100 tokens
Available LP matching: 60 tokens worth
Result: Seller receives $2,400 USDC + 40 tokens returned

This ensures that liquidations never fail entirely -- the seller always gets something, even if the full amount cannot be matched.

Comparison with Traditional Liquidation

Aspect	Traditional AMM	DobDex Orderly
Price impact	Proportional to trade size	Zero (oracle-based)
Cascade risk	High -- selling drops price, triggers more selling	None -- oracle price independent of trades
Seller certainty	Unknown final price	Known penalty percentage
LP returns	Subject to impermanent loss	Known discount on real assets
System stress	Can cause protocol insolvency	Bounded by caps and reserves
Recovery	Price may never recover	Oracle updates when asset value changes

Admin Controls

Liquidation parameters can be adjusted by the protocol admin to respond to market conditions:

Action	When
Increase penaltyBps	Asset becomes riskier; higher discount needed to attract LPs
Decrease penaltyBps	Asset proves stable; lower penalty encourages more exits
Disable liquidations	Emergency pause during abnormal conditions
Adjust caps	Scale limits based on LP depth and asset maturity

All parameter changes are on-chain transactions, providing full transparency and auditability.