Skip to main content
This page is reference material for anyone quoting, hedging, or building tools on top of Fairground. For deeper protocol behavior, check the links under Related protocol topics at the end.

​
Fees, rebates, and matching context

​
Where fees go after a match

Each matching cycle collects fees from executed flow. That pool is then allocated across:
  • Minority-side rebates - paid to positions on the thinner side of the book, proportional to size where applicable
  • The insurance fund
  • A protocol remainder
How much flows toward rebates depends on imbalance entitlement E: it scales with executable imbalance up to configured caps. When the book is balanced in that cycle, E = 0 and the rebate-oriented slice does not apply in the same way.

​
Executable imbalance (why the “sides” matter)

Executable notional is constrained by oracle thresholds:
  • Opening long and closing short require threshold ≥ oracle price
  • Opening short and closing long require threshold ≤ oracle price
The matcher aggregates long-side depth L = openingLong + closingShort and short-side depth S = openingShort + closingLong, then uses I = |L − S| as the imbalance input that feeds into entitlement and allocation.

​
GetPositionFeeInfo (fees and rebates per position)

GetPositionFeeInfo returns consolidated fees and estimatedRebate for one open position, keyed by address, positionId, and marketId. Use it from the REST API or Python SDK when you want position-level economics for dashboards, quoting, or reconciliation.
  • REST: GetPositionFeeInfo — see the API reference for base URL and calling conventions.
  • Python: the same RPC is wrapped on PerpetualsClient as get_position_fees, get_position_rebate, and the underlying get_position_fee_info call — see the generated reference for the async client or sync client.