Fee Structure

Diffusal uses a fee model that generates protocol revenue while incentivizing liquidity provision. Fees are collected on all trades executed through the order book and RFQ system.

Important: Fees are the only USDT transferred at trade time. Premium obligations are recorded as premiumBalance and settle at expiry—no premium changes hands when opening a position.

Fee Types

Fee Type	Description	Can Be Negative?
Maker Fee	Charged to order creators (limit order makers)	Yes (rebates)
Taker Fee	Charged to order fillers (market takers)	No
RFQ Fee	Charged on RFQ trades against registered MM signers	No

Fee Calculation

Notional Value Calculation

For each trade, the fee basis (notional value) is calculated from the price and fill amount:

\text{notional} = \frac{\text{price} \times \text{fillAmount}}{10^{18}}

Note: This notional value is used for fee calculation only. No premium transfers occur at trade time — premiumBalance is updated for both parties and settles at expiry.

Order Book Fees

The order book uses a maker/taker fee model where fees are expressed in basis points (1 BPS = 0.01%):

\text{makerFee} = \frac{\text{notional} \times \text{makerFeeBps}}{10000}

\text{takerFee} = \frac{\text{notional} \times \text{takerFeeBps}}{10000}

RFQ Fees

RFQ trades have a dedicated fee rate separate from limit order fees:

\text{rfqFee} = \frac{\text{notional} \times \text{rfqFeeBps}}{10000}

Maker Rebates

The maker fee can be negative, creating a rebate system that incentivizes liquidity provision:

Positive makerFeeBps: Maker pays fee to protocol
Negative makerFeeBps: Protocol pays rebate to maker

Example with makerFeeBps = -5 (0.05% rebate), takerFeeBps = 10 (0.10%):
  Trade notional: $1,000
  Maker receives: $0.50 rebate
  Taker pays: $1.00 fee
  Protocol receives: $1.00 - $0.50 = $0.50 net

Note: premiumBalance is updated for both parties; no premium transfer occurs at trade time.

Fee Flow

Order Book Fee Flow

Taker Fee (always positive): Taker pays feeCollector.

Maker Fee (can be negative): If positive, maker pays feeCollector. If negative, feeCollector pays maker (rebate).

Net Result: Protocol always receives positive net fees (guaranteed by the fee invariant).

RFQ Fee Flow

The RFQ fee is always paid by the taker to the feeCollector, regardless of trade direction. premiumBalance is updated for both parties, and net settlement is determined at expiry.

Fee Invariant

The protocol enforces:

\text{takerFeeBps} + \text{makerFeeBps} > 0

This ensures net positive protocol revenue even with maker rebates.

The feeCollector address receives all collected fees. It is a dedicated protocol wallet (EOA) separate from the insurance fund. The InsuranceFund exists solely for liquidation and settlement shortfall coverage — it does not receive trading fee revenue. Trading contracts expose this as a configurable address via setFeeCollector().

Typical Parameters

These are recommended deployment parameters, not hardcoded contract defaults. Fees are configurable via setFees() and set during contract initialization.

Parameter	Typical Value	Description
`makerFeeBps`	0	Maker fee in BPS (can be negative)
`takerFeeBps`	10	Taker fee in BPS (0.10%)
`rfqFeeBps`	10	RFQ fee in BPS (0.10%)

Fee Examples

Standard Fees

With makerFeeBps = 5 and takerFeeBps = 10:

On a $1,000 notional trade:

Maker pays $0.50 to the protocol
Taker pays $1.00 to the protocol
Total protocol revenue: $1.50

premiumBalance updated for both parties; actual net settlement determined at expiry.

Maker Rebate

With makerFeeBps = -3 and takerFeeBps = 10: