Liquidity Nodes

DobDex uses a permissionless liquidity node system where anyone can provide USDC liquidity to back RWA token trades. Unlike traditional AMM pools where LPs deposit into a shared pool and accept whatever the curve produces, DobDex LPs set specific conditions on their capital and are matched to trades through a FIFO (first in, first out) queue.

How Liquidity Nodes Work

A liquidity node is a single LP position with defined parameters. When an LP deposits USDC, they specify the conditions under which their capital can be used:

LP deposits 10,000 USDC with conditions:
  - minOraclePrice: $40/token    (won't back assets priced below $40)
  - minPenaltyBps: 500           (requires at least 5% discount on liquidations)
  - maxExposure: 50,000 USDC     (total exposure cap across all assets)

The LP's capital sits in the DobLPRegistry contract until it is matched to a trade or liquidation event.

LP Parameters

When creating a liquidity node, LPs configure the following parameters:

Parameter	Type	Description
amount	uint256	USDC amount to deposit
minOraclePrice	uint256	Minimum oracle price for backed assets (in USDC)
minPenaltyBps	uint256	Minimum liquidation penalty in basis points (100 bps = 1%)
maxExposure	uint256	Maximum total USDC exposure across all backed positions

Parameter Rationale

• minOraclePrice -- Protects LPs from backing very low-value or potentially worthless assets. An LP focused on infrastructure might set this to $1,000 to avoid micro-assets.
• minPenaltyBps -- Ensures the LP receives a meaningful discount during liquidation events. Setting 2000 (20%) means the LP only participates in liquidations where the seller takes at least a 20% haircut.
• maxExposure -- Caps the LP's total risk. Even if many liquidation events occur, the LP's capital at risk never exceeds this amount.

FIFO Matching

When a trade or liquidation requires liquidity, DobDex matches against LP nodes in FIFO order -- the earliest deposited node that meets the trade's conditions is matched first.

Liquidation event: 1,000 RWA tokens at $45/token, 20% penalty

LP Queue (FIFO):
  1. Alice:  5,000 USDC  | minPrice: $40 | minPenalty: 1500 | --> MATCH (meets all)
  2. Bob:    8,000 USDC  | minPrice: $50 | minPenalty: 500  | --> SKIP (price < minPrice)
  3. Carol: 20,000 USDC  | minPrice: $30 | minPenalty: 2500 | --> SKIP (penalty < minPenalty)
  4. Dave:  15,000 USDC  | minPrice: $35 | minPenalty: 1000 | --> MATCH (meets all)

Alice's position is matched first (FIFO). If Alice's 5,000 USDC does not cover the full liquidation amount, Dave's position is matched next for the remainder.

Security Parameters

The LP system enforces several security constraints to prevent manipulation and protect both LPs and traders:

MIN_BACKING_AGE (1 hour)

uint256 constant MIN_BACKING_AGE = 1 hours;

A newly deposited LP position cannot be used in liquidation matching for at least 1 hour. This prevents an attacker from:

• Depositing liquidity immediately before a known liquidation
• Capturing the liquidation discount
• Withdrawing immediately after

WITHDRAWAL_DELAY (24 hours)

uint256 constant WITHDRAWAL_DELAY = 24 hours;

After requesting a withdrawal, an LP must wait 24 hours before funds are released. This prevents:

• LPs from front-running known liquidation events by withdrawing
• Rapid deposit-withdraw cycles to game the FIFO queue position
• Liquidity crises from sudden mass withdrawals

RESERVE_BPS (33%)

uint256 constant RESERVE_BPS = 3300; // 33%

33% of an LP's deposited capital is held in reserve and cannot be matched to trades. This ensures:

• A liquidity buffer always exists for normal trading operations
• No single liquidation event can drain an LP's entire position
• The system maintains solvency even during high-activity periods

MAX_BACKERS (50)

uint256 constant MAX_BACKERS = 50;

A maximum of 50 LP nodes can back a single RWA asset. This is a gas optimization -- iterating over the LP queue during matching has O(n) gas cost, and capping n at 50 keeps gas costs predictable.

LP Lifecycle

1. Deposit

function depositLiquidity(
    uint256 amount,
    uint256 minOraclePrice,
    uint256 minPenaltyBps,
    uint256 maxExposure
) external returns (uint256 nodeId);

The LP transfers USDC to the DobLPRegistry and receives a nodeId that identifies their position. The position enters the FIFO queue but is not eligible for matching until MIN_BACKING_AGE has passed.

2. Active Backing

Once MIN_BACKING_AGE passes, the position is eligible for matching. When a trade or liquidation occurs:

1. The system iterates through the FIFO queue
2. Each node's conditions are checked against the trade parameters
3. Matching nodes have their USDC debited and receive RWA tokens at discount
4. The node's currentExposure is updated

3. Withdrawal Request

function requestWithdrawal(uint256 nodeId) external;

The LP signals intent to withdraw. A 24-hour countdown begins. During this period:

• The position is removed from the FIFO matching queue
• No new trades can be matched against it
• Existing exposure remains until resolved

4. Withdrawal Execution

function executeWithdrawal(uint256 nodeId) external;

After WITHDRAWAL_DELAY has passed, the LP can execute the withdrawal. Unreserved and unmatched USDC is returned to the LP's wallet.

Returns for LPs

LPs earn returns through liquidation discounts. When a liquidation occurs, the seller takes a penalty (e.g., 20%) and the LP receives RWA tokens at a discounted price:

Oracle price:       $50/token
Liquidation penalty: 20%
LP purchase price:   $40/token (50 * 0.80)
LP profit potential: $10/token if they sell at oracle price

The LP now holds RWA tokens purchased at a discount. They can:

• Hold the tokens and earn distribution income from the underlying pool
• Sell the tokens on DobDex at the full oracle price
• Hold long-term as the asset appreciates

Risk Factors

Risk	Description	Mitigation
Asset devaluation	RWA tokens received in liquidation may lose value	minOraclePrice parameter
Illiquidity	Received RWA tokens may be hard to sell	DobDex provides secondary market
Smart contract risk	Contract vulnerability could affect deposits	Audits, test coverage (77 tests)
Oracle risk	Incorrect oracle price leads to bad matching	DobValidator review process
Concentration risk	Over-exposure to a single asset	maxExposure cap per node