Risk Engine & Liquidation System

The risk engine is responsible for calculating margin requirements, monitoring positions, and executing liquidations when necessary. Unlike opaque systems that treat risk formulas as proprietary, use.com publishes all risk mathematics, enabling traders to independently calculate their exact liquidation prices.

Published Risk Formulas

Maintenance Margin Requirement (MMR)

$MMR = \max(MM_{base}, k \times |Position\_Notional|)$

Where:

• MM_base: Base maintenance margin (e.g., 0.5% for BTC, 0.7% for ETH)

• k: Risk tier scaling factor (0.0001 for Tier 1, higher for riskier assets)

• Position_Notional: Position_Size × Mark_Price

Example (BTC):

• Position: 10 BTC at $50,000 = $500,000 notional

• MM_base: 0.5%

• k: 0.0001

• MMR: max(0.005, 0.0001 × $500,000) = max($2,500, $50) = $2,500 (0.5%)

Initial Margin Requirement (IMR)

$IMR = 1.5 \times MMR$

The 50% buffer above maintenance margin provides cushion before liquidation.

Liquidation Price

For long positions: $Liquidation\_Price = Entry\_Price \times \left(1 - \frac{MMR}{1 + Leverage}\right)$

For short positions: $Liquidation\_Price = Entry\_Price \times \left(1 + \frac{MMR}{1 + Leverage}\right)$

Example (Long Position):

• Entry: $50,000

• Leverage: 10×

• MMR: 1%

• Liquidation Price: $50,000 × (1 - 0.01/1.1) = $50,000 × 0.9909 = $49,545

The trader knows with certainty that liquidation begins at $49,545.

Mark Price Construction

Mark price is used for liquidations to prevent manipulation:

$Mark\_Price = \lambda \times Oracle\_TWAP + (1 - \lambda) \times Mid\_Book$

Where:

• λ: Oracle weight (0.6-0.9 based on liquidity)

• Oracle_TWAP: Time-weighted average from multiple oracle sources (Chainlink, Pyth, etc.)

• Mid_Book: (Best_Bid + Best_Ask) / 2

Rationale: Prevents attackers from triggering liquidations by manipulating the order book. Oracle weight increases for more liquid markets.

Liquidation Ladder System

Rather than liquidating entire positions at once, use.com employs a phased approach:

Phase 1 (Mark price reaches liquidation price):

• Liquidate 25% of position

• Fee: 0.5% to insurance fund

• Method: Limit order at liquidation price

Phase 2 (If price continues adverse):

• Liquidate additional 25%

• Fee: 0.75% to insurance fund

• Method: Limit order at worse price

Phase 3 (Final liquidation):

• Liquidate remaining 50%

• Fee: 1.0% to insurance fund

• Method: Market order if necessary

Benefits:

• Reduces market impact

• Gives position chance to recover

• Maximizes insurance fund contribution

• Minimizes auto-deleveraging (ADL) probability

Bankruptcy Price

$Bankruptcy\_Price = Entry\_Price \times \left(1 \pm \frac{1}{Leverage}\right)$

Where ± depends on position direction (- for long, + for short).

Example (10× Long):

• Entry: $50,000

• Bankruptcy: $50,000 × (1 - 1/10) = $45,000

The difference between liquidation price ($49,545) and bankruptcy price ($45,000) is the liquidation buffer that protects the insurance fund.

Insurance Fund Mechanics

Purpose: Cover losses when liquidation price is worse than bankruptcy price.

Target Coverage: $Coverage\_Ratio = \frac{Insurance\_Fund\_Balance}{Total\_Open\_Interest} > 5\%$

Funding Sources:

• Liquidation fees (0.5-1.0% of liquidated position)

• Funding rate contributions (when applicable)

• Initial allocation from treasury

Usage Priority:

1. Cover liquidation losses (when liquidation < bankruptcy)

2. Maintain target coverage ratio

3. Excess distribution (when coverage > 10% for 90 days)

Transparency: Real-time dashboard showing balance, coverage ratio, 24h inflows/outflows, and historical trends.

Auto-Deleveraging (ADL)

When insurance fund is insufficient to cover losses, ADL reduces opposing positions.

Priority Formula: $ADL\_Priority = Profit\_Percentage \times Leverage$

Ranking: Highest score deleveraged first.

Example:

• User A: +50% profit, 20× leverage → Score = 1,000

• User B: +30% profit, 10× leverage → Score = 300

• User C: +80% profit, 5× leverage → Score = 400

ADL Order: User A → User C → User B

Rationale: Most profitable + highest leverage = highest risk contribution to system.

Notification: Users in ADL queue receive warnings when coverage ratio falls below thresholds.

Risk Tiers

Assets are categorized into risk tiers affecting margin requirements:

Tier	Assets	MM_base	k	Max Leverage
Tier 1	BTC, ETH, USDT, USDC	0.5-0.7%	0.0001	100×
Tier 2	Top 20 alts	1.0-2.0%	0.0003	50×
Tier 3	Long-tail assets	2.0-5.0%	0.0010	20×

Dynamic Adjustment: Risk parameters can be adjusted within governance-approved bounds based on volatility and liquidity conditions.

Position Monitoring

Real-Time Checks (every 100ms):

• Calculate mark price

• Update unrealized PnL

• Check margin ratio

• Trigger liquidation if necessary

Margin Ratio: $Margin\_Ratio = \frac{Equity}{Position\_Notional}$

Where:

• Equity = Balance + Unrealized_PnL

• Position_Notional = Position_Size × Mark_Price

Liquidation Trigger: When Margin_Ratio < MMR

Risk Limits

Position Size Limits: Prevent excessive concentration

$Max\_Position = \frac{Insurance\_Fund \times Risk\_Factor}{Mark\_Price}$

Example (BTC):

• Insurance Fund: 100 BTC

• Risk Factor: 0.1 (10%)

• Mark Price: $50,000

• Max Position: (100 × 0.1) / 1 = 10 BTC per user

Open Interest Limits: Cap total open interest per symbol to manage systemic risk.

Stress Testing

Scenario Analysis: Monthly stress tests simulate:

• 20% price move in 1 hour

• 50% price move in 24 hours

• Flash crash scenarios

• Oracle failure scenarios

Insurance Fund Adequacy: Verify coverage remains > 5% under stress scenarios.

Conclusion

use.com's risk engine provides transparent, deterministic risk management through published formulas, phased liquidations, and real-time insurance fund monitoring. By enabling traders to independently calculate liquidation prices and verify system health, use.com eliminates the "black box" problem that has eroded trust in centralized exchanges.

---

Previous: ← Matching Engine & Order Book Design Next: Wallet Infrastructure & Custody Model →

Related Sections:

• Core Principles & Design Philosophy

• Solution Overview