Fees

Phasis charges fees at two points in the trade lifecycle: on fills (taker and maker) and on liquidations. Settlement itself is free.

Fee schedule

"Notional" throughout this section means premium notional — the option premium paid or received — not the notional value of the underlying. Phasis trades options priced in USDC; a 1-contract BTC call trading at $0.05 has a notional of $0.05 per unit, not $65,000.

Fee formula

fee = notional × bps / 10_000

where notional = qty × price

In protocol fixed-point:

• qty is in contract units (raw: 1 contract = 1,000,000 = 1e6)
• price is in UD30×9 (raw: $1.00 = 1,000,000,000 = 1e9)
• notional (raw) = qty × price / 1e9 → USDC with 6 decimals

Worked example

Sell 1 contract at $0.05 (taker order that fills immediately):

qty      = 1 contract  (1_000_000 raw)
price    = $0.05       (50_000_000 raw, UD30x9)

notional = 1_000_000 × 50_000_000 / 1_000_000_000
         = 50_000_000 raw USDC  =  $50.00

Taker fee   = $50.00 × 30 / 10_000  =  $0.15 USDC
Maker rebate = $50.00 × 5 / 10_000  = $0.025 USDC

The taker (the seller in this example) pays $0.15. The maker whose resting bid was filled receives a $0.025 rebate from the protocol fee pool.

Fee accrual and the fee pool

Fees are computed and deducted inside apply_fill in trading.move at the moment a fill is reconciled. They accumulate in a shared fee_pool dynamic field on the registry object.

• Taker fee: deducted from the taker's Account.balance_quote at fill time.
• Maker rebate: paid from fee_pool into the maker's Account.balance_quote. If the fee pool is depleted, makers receive zero rebate (the pool never goes negative).
• Liquidation fee: charged to the underwater account and paid to the liquidator's address. If the account balance is insufficient, the shortfall is drawn from the fee pool as bad debt.

Governance

The fee configuration is stored as a FeeConfig object on the registry. Admin can update it via:

auth_entry::set_fee_config(
    registry,
    taker_bps,
    maker_bps,
    maker_is_rebate,
    settlement_bps,
    liquidation_bps
)

Changes apply to fills that occur after the transaction confirms. Existing open orders and positions are not retroactively affected.

The fee pool balance is withdrawable by the admin via auth_entry::drain_fee_pool. Protocol revenue from taker fees accumulates here and is used to fund maker rebates and cover liquidation shortfalls before being withdrawn.

Note on fill-price approximation

The current implementation uses the order's limit price as a proxy for the actual fill price when computing fees for aggressive IOC orders. In most cases this is exact (limit orders fill at their stated price). For market-taker IOC orders that sweep multiple price levels, the fee may be slightly over-charged relative to the true average fill price. This is a known approximation tracked for correction in a future protocol version.