Protocol Design

Diffusal is a decentralized options exchange where the protocol bears zero counterparty risk. This is achieved through a fundamental invariant: every option is created as a pair (long + short), and the sum of all longs equals the sum of all shorts system-wide.

Four-Instrument Model

Every trade creates four distinct positions, created in pairs:

Paired Creation:

1. Option pair: Long (+) for buyer, Short (-) for seller
2. Premium pair: Payer (-) for buyer, Receiver (+) for seller

This structure enables capital efficiency: a long call can offset some risk from a short put, and premium receivables offset premium obligations. It also ensures conservation: the sum of all positions is always zero.

Margin Requirements by Instrument Type

The four-instrument model separates option positions from premium positions. Each has distinct margin implications:

Option Short = Obligation to Pay Intrinsic

Short positions create obligations. Users holding short options MUST maintain sufficient equity to cover their potential payout obligations, or they will be liquidated.

Option Long = Right to Receive Intrinsic

Long positions have no obligations. They only receive intrinsic value if ITM at expiry. An OTM long simply receives nothing.

Premium Positions (Separate Instruments)

Premium positions are separate from option positions. A typical buyer holds BOTH an option long AND a premium payer position, but these are distinct instruments. Premium is already reflected in equity (reducing equity when negative), so it's not separately added to margin.

How Margin and Liquidation Incentives Guarantee Settlement

The margin system ensures short holders maintain sufficient equity. When they don't, liquidators are incentivized to close their positions before they become deeply underwater. Consider a short put with strike = $3000:

• At ETH $3000: $5,000 equity, healthy status, normal trading
• At ETH $2700: $3,500 equity, healthy status, normal trading
• At ETH $2400: $2,200 equity, warning zone
• At ETH $2200: $1,800 equity, unhealthy status → liquidated
• At ETH $1500: Would be insolvent, but never reached because already liquidated

Key insight: Liquidation triggers at 80% of initial margin, well before insolvency. Liquidators are incentivized with penalty profits (1-2%+) and bounties (5% of debt) to close undercollateralized positions promptly. This economic incentive ensures positions are closed before they become deeply underwater.

The Safety Layers

What This Means in Practice

1. Opening a short: User's post-trade equity must exceed initial margin (can be funded by profitable longs)
2. Holding a short: If the option moves against the user, equity decreases
3. Approaching danger: When equity < Maintenance Margin, liquidation triggers
4. Liquidation: Liquidators close positions at penalized price, earning penalty profits + bounty
5. At settlement: Only healthy short holders remain → all have funds to pay

Liquidators are economically incentivized to close undercollateralized positions before settlement. The protocol creates the rules; liquidators enforce them through economic incentives.

Settlement Readiness: Ensuring Cash Before Expiry

There's an important distinction between equity (used for ongoing margin) and cash (needed for settlement):

• Equity = Deposit + Option Value + Premium Balance (includes paper profits)
• Cash = Deposited USDT only

A user can have high equity from profitable long positions but minimal actual cash. When their positions expire, they need actual cash to pay obligations—paper profits won't settle the bill.

Example Problem:

The margin system sees a healthy portfolio (equity >> MM). But at settlement, the user needs $13,000 cash ($10,000 intrinsic + $3,000 premium) but only has $2,000.

Solution: Settlement Readiness Liquidation

One day before expiry, the protocol checks if users with expiring obligations have enough deposited cash to cover their worst-case settlement amounts. If not, liquidators are incentivized to acquire the user's liquidatable assets to raise cash using a waterfall approach:

1. Trigger: Positions expiring within 1 day with net obligations AND deposited cash < worst-case obligation
2. Waterfall Action:
   • Step 1: Liquidate non-expiring LONG option positions at penalized mark price
   • Step 2: If shortfall remains, liquidate premium receivables at a discount (default 5%, max 20%)
3. Result: User's paper profits convert to actual cash for settlement
4. Incentive: Liquidators earn penalty discount + 5% bounty on cash shortfall

Key constraints:

• Long positions liquidated first — highest-value positions first to efficiently raise cash
• Premium receivables liquidated second — deterministic value at discount rate
• Only LONG option positions can be liquidated (shorts are obligations, not value)
• Only non-expiring positions can be liquidated (expiring positions must settle)

This ensures that by settlement time, users with obligations have actual USDT to pay.

See also: Liquidation - Settlement Readiness for detailed mechanics.

Core Invariants: Option and Premium Conservation

Option Balance Conservation

Options are always created in pairs. Every trade creates +amount long options (right to receive intrinsic value if ITM) for the buyer and +amount short options (obligation to pay intrinsic value if ITM) for the seller.

System-wide invariant:

Since option balances are signed integers (positive = long, negative = short), this invariant is maintained automatically.

Premium Balance Conservation

Premium obligations and receivables are always created in pairs. When a trade executes at price P for size S:

• Buyer: premiumBalance -= P × S (obligation to pay at settlement)
• Seller: premiumBalance += P × S (receivable at settlement)

System-wide invariant:

What one party owes, another party is owed. The system is always zero-sum.

Self-Cancellation Property

If a user holds both +N long and -N short of the same series:

• At expiry, intrinsic payouts cancel (they owe themselves)
• Premium balances also cancel (obligation = receivable)
• Net settlement = 0
• Net exposure = 0

This enables free creation: Anyone can create unlimited pairs because holding both sides creates zero net exposure.

Position Lifecycle

1. Creating New Options

Any user can create option pairs. In practice, this is primarily done by registered RFQ market makers and other active liquidity providers. When an MM creates 100 pairs, they hold +100 long and -100 short, resulting in net exposure of 0 and zero collateral required (since positions cancel).

2. Trading (Deferred Settlement Model)

When a trade executes, no premium is exchanged (only fees). Instead:

• Option balances are updated
• Premium obligations/receivables are recorded
• All cash flows happen at settlement

Key insight: Each trade ADDS to the user's premium balance. When closing at a better price, profit is locked in as a positive premium balance receivable.

See also: RFQ Market-Maker Position Lifecycle Example for a complete walkthrough of trading, closing positions, and settlement.

3. Settlement at Expiry (Net Settlement Model)

At expiry, settlement combines intrinsic value AND premium balance in a single event:

• If netSettlement > 0: party receives funds
• If netSettlement < 0: party pays funds

Key insight: The net settlement combines option and premium settlements (two separate instruments):

• Option Long (ITM): receives intrinsic payout (Option Long has no obligations)
• Option Long (OTM): receives nothing (Option Long still has no obligations)
• Option Short (ITM): pays intrinsic obligation
• Option Short (OTM): pays nothing
• Premium Payer: pays fixed premium (separate from option position)
• Premium Receiver: receives fixed premium (separate from option position)
• Net result: User pays or receives based on combined option + premium settlements

Conservation of value:

What one party pays, another receives. The protocol moves no funds of its own.

4. Closing Positions (Trading Out)

A user can close their option balance by trading out on the orderbook. Key insight: Closing a position does NOT trigger settlement. It:

• Sets optionBalance → 0
• Accumulates the closing trade into premiumBalance

The closed position's premium balance is settled at expiry along with everyone else.

5. Closing Positions (Pair Netting)

Users can close positions by acquiring the opposite side of the same option series. This is the mechanism for removing positions from your portfolio entirely.

How it works:

Key constraint: Positions must be netted in equal amounts. You cannot net 2 longs with 1 short—each long cancels exactly one short.

Example: You hold -50 short ETH-3500-CALL. To close:

1. Buy 50 longs of ETH-3500-CALL on the orderbook or via RFQ
2. Your optionBalance changes: -50 (short) + 50 (long) = 0
3. Premium balances from both trades remain and settle at expiry

What happens to premium balances:

• When you buy the long, you incur a premium obligation (premiumBalance decreases)
• The original short sale gave you a premium receivable (premiumBalance increased)
• Your net premiumBalance (original receivable + new obligation) settles at expiry
• If you closed profitably (bought cheaper than you sold), you receive the difference at settlement

This mechanism, combined with the Self-Cancellation Property, ensures positions can always be exited as long as counterparty liquidity exists.

Pricing: Theoretical vs Market

There are two distinct pricing concepts in the protocol:

Mark Price (for Margin Calculations)

The mark price uses Black-Scholes as a theoretical reference for:

• Calculating unrealized PnL
• Determining margin requirements
• Triggering liquidations
• Computing stress scenarios

where:

• $d_1 = \frac{\ln(S/K) + (r + \sigma^2/2)T}{\sigma\sqrt{T}}$
• $d_2 = d_1 - \sigma\sqrt{T}$

Trade Price (Actual Premium)

The trade price is what users actually pay—determined by market forces, not Black-Scholes:

Why Trade Prices Differ from Black-Scholes:

Example: If Black-Scholes theoretical price is $50.00, a market maker might quote an ask of $51.50 (selling price, includes spread) and a bid of $48.50 (buying price). The spread represents the market maker's profit margin.

Portfolio Margin System

Cross-Margin Architecture

Users do not collateralize individual positions. Instead, all positions share a single collateral pool with deposited USDT and multiple option positions across different series. Using the four-instrument model, this enables capital efficiency through position netting.

Portfolio Equity Calculation

Option Value:

• Positive if long (optionBalance > 0)
• Negative if short (optionBalance < 0)

Premium Balance (obligation/receivable):

• premiumBalance > 0 → user is OWED at settlement (increases equity)
• premiumBalance < 0 → user OWES at settlement (decreases equity)

Key insight: At trade time (when mark ≈ trade price), equity doesn't change because option value and premium balance offset. As mark moves, equity changes.

Stress Testing

We test the corners of the risk space (4 scenarios combining ±30% spot moves with ±50%/−30% IV changes) to find worst-case portfolio loss. Only option positions are stressed; premium balances are deterministic.

See also: Margin System: Stress Scenarios for detailed scenario analysis.

Margin Thresholds

where:

• Stress Loss = Maximum option loss across all 4 stress scenarios
• Adverse PnL Buffer = Stress Loss × 0.05
• Notional Buffer = Total Notional × 15%

Key insight: Premium balance is NOT included in margin—it's already reflected in equity. Premium obligations are deterministic (fixed at trade time), and negative premium already reduces equity. Only option positions are stressed.

See also: Margin System for detailed margin calculations and worked examples.

Open Interest Tracking

Open Interest (OI) is tracked at the pair level (not per-series) to manage aggregate protocol exposure.

Key Concepts

• Separate Buckets: Calls and puts tracked independently per pair
• Long Positions Only: Only positive option balances count toward OI
• Conservation Law: Long OI = Short OI (every long has a counterparty short)
• Configurable Caps: Owner can set max OI per pair (0 = unlimited)

OI Caps

Caps prevent unbounded exposure from P2P trading:

Integration

1. User executes trade via OrderBook/RFQ
2. PositionManager updates user position
3. PositionManager calls seriesRegistry.updateOpenInterest(pairId, isCall, delta)
4. SeriesRegistry validates cap and updates aggregate OI
5. Emits OpenInterestUpdated(pairId, isCall, oldOI, newOI)

See also: DiffusalOptionsSeriesRegistry for implementation details.

Liquidation Mechanics

Trigger

A user becomes liquidatable when:

This can happen to any user regardless of position type:

• Long holders: Option values drop significantly
• Short holders: Option values rise significantly
• Mixed portfolios: Net losses exceed collateral buffer

Debt Calculation

If Debt > 0 and Equity < MM, the user is underwater and liquidation is triggered.

Process

1. Trigger: Keeper detects Equity < MM
2. Calculate: Determine debt and positions to close
3. Transfer Positions at penalized mark price:
   • Long positions: Liquidator pays user at mark × (1 - penalty%) and acquires the position
   • Short positions: User pays liquidator at mark × (1 + penalty%) to transfer the obligation
4. Pay Bounty: Liquidator receives 5% of debt (insurance fund covers any shortfall)

Mark Price Liquidation (No Orderbook/RFQ)

Liquidations use the mark price (Black-Scholes theoretical price) directly—they do not go through the orderbook or RFQ system. This ensures liquidations can always execute regardless of market liquidity.

Position transfer model:

Cash flows:

• For longs: Liquidator pays = size × mark × (1 - penalty) (user receives cash)
• For shorts: User pays = |size| × mark × (1 + penalty) (liquidator receives cash for taking obligation)

Volatility-Adjusted Liquidation Penalty

The liquidation penalty scales with implied volatility to properly incentivize liquidators during market stress. Higher IV means faster position movement and more liquidator risk, so higher penalties ensure liquidators remain incentivized during stress.

See Liquidation: Volatility-Adjusted Penalty for the penalty formula and rate table.

Partial vs Full Liquidation

The protocol supports partial liquidation to give users a chance to recover.

Key insight: Margin requirements use stressed scenarios (±30% spot, +50% IV), but liquidation executes at current mark prices. This means:

• Transferring positions at current mark barely reduces equity (just the penalty)
• But it dramatically reduces the margin requirement (which was stress-based)
• So partial liquidation often restores health without destroying the user

Position Selection: Positions are sorted by expiry (longest-dated first) to prioritize positions furthest from expiry (most liquid, easiest for liquidators to hedge).

Notional-Based Liquidation:

The protocol supports partial position liquidation — a single position can be partially liquidated to hit the exact target notional (e.g., 4.9 of 10 contracts). This is more capital-efficient than rounding up to whole positions.

Process:

1. Trigger: Equity < MM
2. Sort: Order positions by expiry (longest-dated first)
3. First Attempt: Liquidate positions until target notional is reached, starting from longest-dated. Supports partial liquidation within a single position.
4. Re-check: Is user now healthy? (Equity ≥ MM) — If yes, stop and user retains remaining positions; if no, proceed to full liquidation (close all remaining positions)

After liquidation, the user retains any remaining equity and positions (if partial).

Liquidator Incentives

The bounty is always paid to incentivize liquidators:

• First drawn from user's collateral (after position transfers)
• Any shortfall is covered by the insurance fund

Liquidators receive:

1. 1-2%+ profit on positions (via penalized mark price, scales with IV)
2. 5% bounty on debt (guaranteed by insurance fund)

Total profit = penalty profit + bounty

After liquidation, the liquidator owns the acquired positions and can:

• Sell via limit orders on the orderbook
• Sell via RFQ to a registered RFQ market maker
• Hold the positions

Important: Liquidators must have deposited collateral and remain healthy (Equity ≥ MM) after acquiring positions.

This incentivizes keepers to monitor and liquidate promptly.

Insurance Fund

The insurance fund provides two types of coverage:

1. Bounty Guarantee: The 5% bounty is always paid to liquidators (insurance covers any shortfall)
2. Bad Debt Coverage: When user equity is still negative after all transfers

The insurance fund covers shortfalls to prevent protocol insolvency. It is funded through governance-managed deposits and liquidation penalty recoveries — not trading fee revenue (which flows to a separate dedicated fee collector wallet).

See also: Liquidation for worked examples and penalty calculations.

Registered RFQ Market Makers (isMmm)

The PositionManager can authorize one or more privileged RFQ signer addresses. These isMmm addresses are non-liquidatable, can sign RFQ quotes, and typically sit behind the public /api/rfq/request auction flow.

Why isMmm Addresses Are Non-Liquidatable

The liquidation check must:

1. First check if the user is an isMmm address
2. If yes, always return false (not liquidatable)
3. If no, proceed with normal margin checks (equity vs maintenance margin)

This means even if an approved liquidator attempts to liquidate a registered RFQ signer, it will always be rejected.

RFQ Market-Maker Responsibilities

RFQ Flow

1. User/Liquidator sends an RFQ request to /api/rfq/request or another MM channel
2. The backend RFQ service collects bids from connected market makers
3. The winning signer returns an EIP-712 quote naming a single mmm address
4. User accepts quote
5. On-chain execution validates quote.mmm via isMmm, creates pairs, and updates option balances and premium balances (no premium exchange; only fees)

RFQ Market-Maker Position Lifecycle Example

The following diagram illustrates how positions flow between participants as trades execute:

┌───────────────────────────────────────────────────────────────────────┐
│                           Participants                                │
├─────────────┬─────────────┬─────────────┬─────────────┬───────────────┤
│ RFQ Market  │    Alice    │     Bob     │    Carol    │     Dave      │
│   Maker     │             │             │             │               │
│  (Signer)   │             │             │             │               │
└──────┬──────┴──────┬──────┴──────┬──────┴──────┬──────┴───────────────┘
       │             │             │             │
       │ Trade 1     │             │             │
       │ 100 longs   │             │             │
       │ @ $50       │             │             │
       ├────────────►│             │             │
       │             │             │             │
       │ Trade 2     │             │             │
       │ 50 longs    │             │             │
       │ @ $50       │             │             │
       ├─────────────┼────────────►│             │
       │             │             │             │
       │             │ Trade 3     │             │
       │             │ 100 longs   │             │
       │             │ @ $70       │             │
       │             ├─────────────┼────────────►│
       │             │             │             │
       │ Trade 4     │             │             │
       │ 80 shorts   │             │             │
       │ @ $25       │             │             │
       ├─────────────┼─────────────┼─────────────┼───────────► Dave
       │             │             │             │

Day 1: Fresh RFQ market maker with no positions and $50,000 USDT deposited.

Trade 1: Alice buys 100 ETH-3500-CALL via RFQ at $50/contract.

• RFQ market maker creates 100 pairs (+100 long, -100 short), transfers 100 longs to Alice
• Alice: optionBalance = +100, premiumBalance = -$5,000 (owes at settlement)
• RFQ market maker: optionBalance = -100, premiumBalance = +$5,000 (owed at settlement)

Trade 2: Bob buys 50 ETH-3500-CALL via RFQ at $50/contract.

• RFQ market maker creates 50 pairs, transfers 50 longs to Bob
• Bob: optionBalance = +50, premiumBalance = -$2,500
• RFQ market maker: optionBalance = -150, premiumBalance = +$7,500

Trade 3: Price rises. Alice closes by selling 100 longs to Carol at $70/contract.

• Alice: optionBalance = 0 (closed), premiumBalance = -$5,000 + $7,000 = +$2,000 (locked profit)
• Carol: optionBalance = +100, premiumBalance = -$7,000

Trade 4: The RFQ market maker offloads risk via limit order at $25/contract. Dave buys 80 shorts from that market maker.

• Dave: optionBalance = -80, premiumBalance = +$2,000 (receive at settlement)
• RFQ market maker: optionBalance = -70, premiumBalance = +$7,500 - $2,000 = +$5,500

At Expiry: ETH = $3,600 (options ITM, intrinsic = $100).

Key insights:

• Alice locked in $2,000 profit by closing at a higher price (premium accumulation)
• Net settlements sum to zero (conservation)
• Closed positions settle via premium balance only (no intrinsic exposure)

Why a Privileged RFQ Signer Must Never Go Underwater

Critical: If a privileged RFQ market maker becomes insolvent, protocol breaks.

Failure Cascade:

1. The RFQ market maker can't fulfill settlement obligations
2. Long holders can't get paid (the RFQ market maker holds shorts)
3. RFQ stops working (the RFQ market maker has no capital)
4. Bad debt accumulates across all users
5. Protocol insolvency

Prevention:

• Governance monitors privileged RFQ market-maker risk posture
• Rebalancing before risk thresholds hit
• Insurance-fund-backed mitigation if needed

Trust Assumptions

See also: RFQ Flow for detailed quote mechanics and Options Settlement for expiry settlement.

Risk Parameters

Protocol Fee System

Trading fees generate protocol revenue and incentivize liquidity provision through maker rebates. Fees are collected on all trades executed through the order book and RFQ system, and are directed to a configurable fee collector address — a dedicated protocol wallet (EOA) separate from the insurance fund.

See Fee Structure for fee types, calculations, and examples.

Security Invariants

Protocol-Level

1. Option Balance Conservation: For every seriesId, sum of all optionBalance = 0
2. Premium Balance Conservation: For every seriesId, sum of all premiumBalance = 0
3. No Protocol Obligation: Protocol never owes users from its own funds
4. Collateral Sufficiency: All healthy users have Equity ≥ MM
5. Settlement Balance: At expiry, sum of all netSettlements = 0

User-Level

1. Position Updates: Only via trade execution, liquidation, or settlement
2. Collateral Access: Withdrawable only if post-withdrawal Equity ≥ IM
3. Premium Accumulation: Premium balance updated atomically with option balance on each trade

Summary

The Diffusal protocol achieves zero counterparty risk through:

1. Paired creation — Options always created as long + short pairs; premium as payer + receiver pairs
2. Deferred settlement — Only fees exchanged at trade time; premium settles at expiry
3. Four-instrument model — Option long, option short, premium payer, premium receiver
4. Premium accumulation — Users set their own prices; profit locks in via premium balance
5. Portfolio margin — Users collateralize net exposure, not individual positions
6. Incentive-driven liquidation — Liquidators are rewarded with penalty profits + bounties to close undercollateralized positions
7. Settlement readiness — Pre-settlement check ensures users have actual cash before expiry (waterfall: non-expiring LONG option positions first, then premium receivables)
8. Insurance fund — Backstop for any remaining bad debt
9. Privileged RFQ market makers — Non-liquidatable signer addresses keep RFQ liquidity available
10. Theoretical vs Market pricing — Black-Scholes for margin/liquidation, market forces for trading

Participant Summary

Regular Users: Trade via limit orders or RFQ; subject to margin requirements; liquidatable if equity < maintenance margin; pay/receive market prices (not Black-Scholes).

Third-Party Market Makers: Provide limit order liquidity; subject to the same margin/liquidation rules; compete with RFQ market makers on pricing.

Privileged RFQ Market Makers (isMmm): Authorized to sign RFQ quotes; public RFQ requests may be auctioned across multiple connected signers; NOT liquidatable by protocol; subject to governance controls; can offload shorts to other users.

Keepers: Monitor user health; execute liquidations; receive bounty for successful liquidations.

The Trust Model

Trustless (Protocol-Enforced):

• Option balance conservation (longs = shorts)
• Premium balance conservation (payers = receivers)
• User margin requirements
• User liquidation triggers
• Settlement calculations (net settlements sum to zero)
• Collateral flows via vault

Trusted Assumptions:

• Privileged RFQ market-maker solvency management
• Privileged RFQ market-maker availability
• Oracle price feeds (Pyth/Chainlink)

The protocol is purely administrative: track positions, enforce margins, coordinate liquidations. All value transfer happens between users (including privileged RFQ market makers). The protocol itself holds no option positions and bears no payout obligations.

Contract Implementation

The protocol is implemented across several smart contracts:

Related

Protocol Documentation

• Margin System — Detailed margin calculations and stress testing
• Liquidation — Liquidation mechanics and penalty calculations
• Options Creation — Series creation via lazy registration
• Options Settlement — TWAP settlement at expiry
• Order Book — Limit order trading mechanics
• RFQ Flow — Request-for-quote trading with registered signers

Math Documentation

• Black-Scholes Model — Pricing formulas and Greeks
• Margin Calculations — Mathematical stress testing formulas

Contract Documentation

• DiffusalOptionsQuoter — Main pricing entry point
• DiffusalOracle — Unified oracle for price and volatility
• DiffusalOptionsPositionManager — Position tracking and registered signer management
• DiffusalCollateralVault — Collateral deposits and margin enforcement