# GetMarketConfigs Source: https://docs.fairground.fi/api-reference/markets/getmarketconfigs /developers/api-reference/openapi.yaml post /market_service.v1.MarketService/GetMarketConfigs Returns the full configuration for one market, resolved by numeric `market_id` or by `market_symbol`. # GetMarkets Source: https://docs.fairground.fi/api-reference/markets/getmarkets /developers/api-reference/openapi.yaml post /market_service.v1.MarketService/GetMarkets Returns the full configuration for every active market, ordered by `market_id` ascending. # GetMarketSummary Source: https://docs.fairground.fi/api-reference/markets/getmarketsummary /developers/api-reference/openapi.yaml post /market_service.v1.MarketService/GetMarketSummary Returns a live trading summary for one market: open interest, 24h price change and volume, executable order-book depth at the current price, rebate indicators, and whether the market is currently open for trading. If computing executable depth fails internally, the request still succeeds with `executableDepth` left at zero rather than failing outright. # GetOrderBook Source: https://docs.fairground.fi/api-reference/orderbook/getorderbook /developers/api-reference/openapi.yaml post /orderbook_service.v1.OrderBookService/GetOrderBook Returns a simulated aggregated order-book depth for one market: bid and ask price levels, each bucketed by `tickSize` and sorted toward the best price. Resolved by `market_id` or `market_symbol`. # GetOrder Source: https://docs.fairground.fi/api-reference/orders/getorder /developers/api-reference/openapi.yaml post /order_service.v1.OrderService/GetOrder Returns the current stored state of one order, identified by the composite key `order_id` + `market` + `reduce_only`. Order IDs are not globally unique: the same numeric ID can exist as both a position-opening order and a reduce-only order in the same market, so `reduce_only` must match the kind of order you're looking up. # GetOrders Source: https://docs.fairground.fi/api-reference/orders/getorders /developers/api-reference/openapi.yaml post /order_service.v1.OrderService/GetOrders Returns the latest stored state of each order associated with `address`, optionally filtered to one market. Results include position-opening and reduce-only orders across active and terminal statuses. This endpoint does not return order lifecycle events or individual fills. # GetPortfolio Source: https://docs.fairground.fi/api-reference/portfolio/getportfolio /developers/api-reference/openapi.yaml post /portfolio.v1.PortfolioService/GetPortfolio Returns an aggregated portfolio snapshot for one wallet: margin, PnL, volume, fee, and equity totals, plus the wallet's currently open positions and open orders. NOTE: `positions` and `orders` are open-only — closed positions and terminal-status orders are folded into the aggregate totals but are not listed individually here. All totals are recomputed fresh on every request (not cached), so this endpoint is heavier than a single-position or single-order lookup. # GetOpenPositions Source: https://docs.fairground.fi/api-reference/positions/getopenpositions /developers/api-reference/openapi.yaml post /position_service.v1.PositionService/GetOpenPositions Returns all currently open positions for one wallet, across all markets. `address` is required (matched trimmed and case-insensitively). Results are ordered by timestamp descending, most recent first. Unlike the portfolio path, associated orders are loaded as lightweight references only — see `associatedOrderIds` on the `Position` schema, not `associatedOrders`. # GetHistoricalPrices Source: https://docs.fairground.fi/api-reference/prices/gethistoricalprices /developers/api-reference/openapi.yaml post /price_service.v1.PriceService/GetHistoricalPrices Returns OHLC candlestick data for one market over a time range. Unlike most other endpoints, `market` only accepts the numeric `market_id` form of `MarketSelector`. # GetPrice Source: https://docs.fairground.fi/api-reference/prices/getprice /developers/api-reference/openapi.yaml post /price_service.v1.PriceService/GetPrice Returns the current oracle price for one market, along with a signed price payload suitable for on-chain submission. # GetUserFills Source: https://docs.fairground.fi/api-reference/trades/getuserfills /developers/api-reference/openapi.yaml post /fill_history_service.v1.FillHistoryService/GetUserFills Returns individual trade-history records (fills) for one wallet, optionally scoped to a time range. Results are ordered oldest first (ascending by block time). `limit` defaults to 100 and is capped at 500. # API Reference Source: https://docs.fairground.fi/developers/api-overview Integrate with Fairground via REST API Build on Fairground using our REST API ConnectRPC-based REST API for orders, positions, markets, and more. # Introduction Source: https://docs.fairground.fi/developers/api-reference/introduction Fairground API reference and integration guide ## Overview We've built the Fairground API to support your backend data needs. Use it to look up markets and prices, and track a wallet's orders, positions, and trade history. ## Services Endpoints are grouped into seven services, listed in the sidebar under their own sections: | Service | Covers | | ------------- | -------------------------------------------------------------------------- | | **Trades** | Individual trade/fill records for a wallet | | **Markets** | Look up market configuration, list markets, and retrieve a live summary | | **Orderbook** | Simulate aggregated bid/ask depth for a market | | **Orders** | Look up one order or list a wallet's orders | | **Portfolio** | Aggregated per-wallet snapshot: margin, PnL, equity, open positions/orders | | **Positions** | List a wallet's open positions | | **Prices** | Current oracle price and historical OHLC candles | ## Making requests Every endpoint, including reads, is a `POST` request with a JSON body, following the ConnectRPC convention: ```text theme={null} POST /package.ServiceName/MethodName ``` ## Base URL | Environment | URL | | ----------- | --------------------------- | | Production | `https://api.fairground.fi` | ## Authentication Authentication will be introduced in future API versions. ### Example ```bash cURL theme={null} curl -X POST https://api.fairground.fi/market_service.v1.MarketService/GetMarketConfigs \ -H "Content-Type: application/json" \ -d '{"market": {"marketSymbol": {"assetSymbol": "BTC", "quoteSymbol": "PERP"}}}' ``` ```json Response theme={null} { "marketConfig": { "marketId": "1", "marketName": "BTC-PERP", "minLeverage": 1, "maxLeverage": 20, "tickDecimals": 1, "sizeDecimals": 8 } } ``` Each endpoint page documents its own request fields, response fields, and one populated example, use those, not this generic one, for the exact shape of a specific call. ## Common patterns A few conventions repeat across most endpoints: Most endpoints that take a market accept either form: ```json theme={null} {"market": {"marketId": "1"}} // or {"market": {"marketSymbol": {"assetSymbol": "BTC", "quoteSymbol": "PERP"}}} ``` `GetHistoricalPrices` is the one exception. It only supports the `marketId` form. Check the endpoint's own description on its specific behavior. Wallet address fields are matched case-insensitively and trimmed of surrounding whitespace server-side. Endpoints that paginate use `limit`/`offset`. Defaults and caps vary per endpoint, check each endpoint's description. ## Errors Errors follow the [Connect error format](https://connectrpc.com/docs/go/errors/#http-representation): ```json theme={null} { "code": "invalid_argument", "message": "market selector must contain a non-zero market_id or a valid asset symbol" } ``` The codes you'll actually encounter across these endpoints are: | Code | Meaning | | ------------------ | ------------------------------------------------------------------------------------------ | | `invalid_argument` | Request failed validation (missing required field, malformed selector, out-of-range value) | | `not_found` | The requested resource (order, position, market, price) doesn't exist | | `internal` | Server-side failure — retry or report if persistent | # Error Selector Reference Source: https://docs.fairground.fi/developers/error-selector-reference Decode on-chain revert reasons from their 4-byte hex. On-chain contract calls can revert with a **4-byte error selector** (error signature). The table below maps each selector to a human-readable message. | Signature | Message | | ------------ | ------------------------------------------------------------------ | | `0x00eb943e` | Margin to extract exceeds PnL | | `0x01735734` | Cannot open opposite side order while position exists | | `0x0313b285` | Market already exists | | `0x0428f2af` | Position must be filled to reduce | | `0x0490d80a` | Invalid max IF fraction | | `0x05baf701` | Margin to reduce exceeds initial margin | | `0x075d545b` | Margin cannot be zero | | `0x09ee12d5` | Not a contract | | `0x0a62b8f3` | No position found | | `0x0a8ed92c` | Denominator is zero | | `0x0ae3681c` | Cannot add selectors to zero address | | `0x0db557d4` | Trade fee overflow | | `0x0dc149f0` | Position already initialized | | `0x0dfa289a` | Invalid side | | `0x0e7186fb` | Oracle data required | | `0x11d7116c` | Fill size exceeds open order position size | | `0x1265b6c8` | Invalid shock factor | | `0x14abe8cd` | Executable queue size cannot be zero | | `0x1602e9e9` | Invalid seizure threshold | | `0x16d402d1` | Only fully filled orders can be added to | | `0x192105d7` | Initialization function reverted | | `0x1d351536` | Stale manual reduce order pointer | | `0x20cada95` | New position size is zero | | `0x21511763` | Batch array lengths must be equal | | `0x21c35dd1` | Reduce order does not belong to position | | `0x23d88bc0` | No pending open order to release | | `0x25153723` | Stop loss order already exists | | `0x25e2f413` | Order must be pending or partially filled to cancel | | `0x2683d346` | Total reduce size exceeds available size | | `0x29d842c0` | Only trader can cancel their order | | `0x2b870c24` | Maximum leverage must exceed minimum leverage | | `0x321794aa` | Not protocol admin | | `0x358d9d1a` | Cannot replace function with the same function from the same facet | | `0x3728b83d` | Invalid amount | | `0x37668688` | Native token not accepted | | `0x376ab111` | Array too large | | `0x3789a26b` | Size is zero | | `0x38be0951` | Notional value overflow | | `0x39060dc5` | Reduce order must be in terminal state | | `0x396476ce` | Invalid stop loss or take profit prices | | `0x3e43f616` | Margin to extract exceeds available margin | | `0x3ee5aeb5` | Reentrancy guard reentrant call | | `0x43898c0a` | Duplicate order ID | | `0x46361ddd` | Scale factor result overflow | | `0x48a4298b` | Not in matching session | | `0x4aeccc1b` | Lambda exceeds one | | `0x4c3cbf04` | Not proposed protocol admin | | `0x4d2acfe8` | Trade size must be multiple of lot size | | `0x4e23d035` | Index out of bounds | | `0x520300da` | Cannot replace immutable function | | `0x52313c09` | Insurance fund allocation overflow | | `0x5274afe7` | SafeERC20 operation failed | | `0x5416eb98` | Function not found | | `0x581a7f65` | Net balance should be negative | | `0x59caa480` | Price threshold cannot be zero | | `0x5c86708f` | Margin operations not allowed on pending position | | `0x5cddff42` | Cannot replace function that does not exist | | `0x5ce28caf` | No position or pending order found for stop loss/take profit | | `0x5d706033` | Invalid order ID | | `0x5dc35903` | Initial margin must be greater than zero | | `0x60f8f321` | Eth not accepted | | `0x6223f681` | Take profit price must be better than mark price | | `0x651a6fee` | Position must be partially or fully filled | | `0x66634bf7` | Facet call returned no data | | `0x69b1189f` | Only fully filled orders can be extracted | | `0x6fafeb08` | Cannot remove immutable function | | `0x71303cf3` | Entitlement percentage exceeds BPS scale | | `0x71ec6e28` | Position in liquidation | | `0x741df939` | Market is paused | | `0x7451ecdf` | Pending orders on opposite side | | `0x76028bdf` | Reduce size exceeds available size | | `0x7a08a22d` | Cannot remove function that does not exist | | `0x7b67157c` | Minimum leverage too low | | `0x7d92e766` | Order book is full | | `0x7e86a579` | Maximum pending reduce orders exceeded | | `0x7fe9a41e` | Incorrect facet cut action | | `0x806c8697` | Lot size cannot be zero | | `0x80e54607` | Market has open positions | | `0x82b42900` | Unauthorized | | `0x84540995` | Facet has no code or has been destroyed | | `0x8568428e` | Reduce size must be greater than zero | | `0x85de96b8` | Invalid oracle price data | | `0x89af5fc3` | Invalid market ID hash | | `0x8d1665da` | Trader liquidation corrupted | | `0x919834b9` | No bytecode at address | | `0x91f63592` | Queue overflow | | `0x93a4b908` | Reduce order size exceeds open order position size | | `0x94280d62` | Invalid ERC20 spender | | `0x96c6fd1e` | Invalid ERC20 sender | | `0x9dba39bc` | Revenue overflow | | `0xa6429e9f` | Notional cannot be zero | | `0xab77128e` | Take profit order already exists | | `0xad6857d1` | Manual reduce order already exists | | `0xad9757f4` | Invalid stop loss price | | `0xaf31444f` | Open interest exists across markets | | `0xb036286e` | Fill size exceeds remaining reduce order size | | `0xb04f990b` | Market scale factor is zero | | `0xb0cfa447` | Market does not exist | | `0xb113638a` | Value does not exist | | `0xb1eecba4` | Matching oracle price mismatch | | `0xb3215542` | Margin extraction would exceed maximum leverage | | `0xb419e811` | Trade size out of allowed range | | `0xb50b6422` | Merged position would be underwater | | `0xb61fbe34` | Position scale factor snapshot is zero | | `0xb6c49a15` | Open interest is zero | | `0xb6f63d65` | Empty name not allowed | | `0xbb33e6ac` | Value already exists | | `0xbe543a82` | Only trader can reduce their order | | `0xbf36e93f` | Market IF fraction too high | | `0xc541a95b` | Open order has zero size, cannot reduce | | `0xc8444e18` | Insurance fund has existing position | | `0xcb64ae8d` | Leverage must be whole number | | `0xcbd5b1d2` | Margin to add must be greater than zero | | `0xcc6595f7` | Invalid ADL threshold | | `0xccd52fbc` | Pointer out of bounds | | `0xcd98a96f` | Cannot replace functions from facet with zero address | | `0xcf4ce7bc` | Invalid take profit price | | `0xd060c572` | Open order must be partially or fully filled | | `0xd091bc81` | Remove facet address must be zero address | | `0xd36d8965` | Order not found | | `0xd8eadcb5` | Only trader can update their order | | `0xd92e233d` | Zero address not allowed | | `0xda177f42` | Leverage exceeds max allowed | | `0xda5f1a6a` | Leverage out of allowed range | | `0xe1140add` | Filled size overflow | | `0xe450d38c` | Insufficient ERC20 balance | | `0xe570110f` | SafeERC20 failed to decrease allowance | | `0xe602df05` | Invalid ERC20 approver | | `0xe672ee91` | Fill size must be greater than zero | | `0xe6e66ac8` | Order must be pending to update | | `0xe73ffde8` | Position must be decreased | | `0xe767f91f` | No selectors provided for facet for cut | | `0xe7d507dc` | Invalid max size | | `0xeb4f513d` | Shock percentage is too high | | `0xeb6ba048` | No selectors given to add | | `0xebb8ab27` | Position must be increased | | `0xebbf5d07` | Cannot add function to diamond that already exists | | `0xec442f05` | Invalid ERC20 receiver | | `0xed0cfdf0` | Stop loss price must be worse than mark price | | `0xed732d0c` | Tree is full | | `0xefac47f8` | Market name cannot be updated | | `0xf4d678b8` | Insufficient balance | | `0xf4dcf37e` | Invalid maintenance margin ratio | | `0xf5c787f1` | Price overflow | | `0xf9b42874` | Price oracle not set | | `0xfab43128` | Liquidation order not in queue | | `0xfb3ab2be` | Opposite side open interest is zero | | `0xfb57fb37` | Margin addition would overflow | | `0xfb8f41b2` | Insufficient ERC20 allowance | | `0xff4127cb` | Not contract owner | # Overview Source: https://docs.fairground.fi/developers/overview Integrate with Fairground Are you ready to build against the Faiground protocol? The sections below cover the REST API and how to decode on-chain revert selectors. ## REST API The Fairground API is built with **ConnectRPC**: JSON over HTTP. Endpoints, base URLs, protocol shape, and links to interactive Swagger. ## On-chain revert reasons Transactions that interact with Fairground **smart contracts** can revert with a **4-byte error selector**. Check the reference table to find the plain language explanation of the returend hex code. Decode on-chain revert reasons from their 4-byte hex. # Market Makers / LPs Source: https://docs.fairground.fi/earn/market-makers-lps For liquidity providers and integrators 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](#related-protocol-topics) at the end. ## Fees, rebates, and matching context ### Where fees go after a match Each [matching cycle](/trading/advanced/order-matching) 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](/trading/advanced/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. ## Related protocol topics * [Order matching](/trading/advanced/order-matching) * [Liquidation](/trading/advanced/liquidation) * [ADL](/trading/advanced/adl) * [Insurance fund](/trading/advanced/insurance-fund) * [XP program](/earn/xp-program) # XP Program Source: https://docs.fairground.fi/earn/xp-program ## Overview The XP program recognizes active participation on Fairground through trading. Trading activity is measured across weekly epochs, with XP distributed from a pool that is fixed *within* each epoch and may be adjusted between epochs. The more you participate in trading, the more opportunities you have to qualify for XP. XP accumulates over time and contributes to leaderboard standings. To maintain a fair environment, activity identified as Sybil behavior, self-trading, or similar manipulation may be excluded from XP calculations. All activity takes place using testnet funds. Testnet funds hold no monetary value. ### What is XP? XP is a points system used to track participant activity on Fairground and contributes to leaderboard rankings. XP may accrue through eligible activities, including but not limited ot trading performance, bug reports, surveys, and feedback submissions. *XP is a promotional participation metric and may be modified, adjusted or discontinued at any time at the sole discretion of Fairground. Participation in XP and testnet activities does not confer any rights to tokens, digital assets, compensation or future rewards. XP has no monetary value and is not transferable or redeemable, and participation in XP or testnet activities does not create any entitlement or confer any rights to tokens, digital assets, compensation, or future rewards.* ### What is an epoch? An epoch is a one-week participation period during which eligible activity may result in XP being awarded. XP received based on your activities during each epoch contributes to your Season 3 standing. ## Season 3 Epoch Schedule | Epoch | Start | End | XP distribution | | ----- | ---------------------------- | ---------------------- | ------------------- | | 1 | Thursday Aug 27th 16:00 UTC | Sept 3rd 15:59:59 UTC | Sept 3rd 19:00 UTC | | 2 | Thursday Sept 3rd 16:00 UTC | Sept 10th 15:59:59 UTC | Sept 10th 19:00 UTC | | 3 | Thursday Sept 10th 16:00 UTC | Sept 17th 15:59:59 UTC | Sept 17th 19:00 UTC | ## How the XP Program Works XP is designed to recognize active participation across Fairground. The exact XP formula is not shared publicly and may include a combination of factors, including: * **Trading activity** - placing orders that fill (opening and/or closing positions) during each epoch may contribute to XP * **PnL** - profitable trading and fees generated through eligible trading activity may contribute to your XP, but it is one of several factors considered. You do not need to be profitable every day to continue qualifying for XP. * **Rebates** - rebates earned from holding positions on the minority side of an imbalanced market. * **Contribution XP** - eligible feedback submissions, bug reports, and product suggestions may qualify for bonus XP. At the end of each weekly epoch:
\~ Trading activity is evaluated
\~ XP is distributed from a fixed pool
\~ The leaderboard is updated ## Qualifying for XP ### **What behaviors does XP reward?** XP rewards active and authentic trading on the platform. XP is distributed after each epoch based on overall trading activity relative to other participants during that period. ### **What activities count toward XP?** XP is designed to recognize active participation across Fairground. The exact XP formula is not shared publicly, but Season 3 XP may reflect a combination of factors, including trading activity, PnL, rebates, and eligible non-trading contributions. Placing orders that fill during each epoch, and higher trading activity may contribute more to your overall total. Profitable trading may also contribute to XP, but it is only one of several factors considered. You do not need to be profitable to continue qualifying for XP. Liquidity rebates from providing depth may also contribute to XP. Eligible feedback submissions, bug reports, and product suggestions may qualify for bonus Contribution XP. Traders who provide feedback, identify issues, suggest improvements, or help us refine the trading experience may be eligible for discretionary promotional XP or other promotional rewards subject to applicable eligibility criteria and separate program terms. ### **Do I need to be profitable to earn XP?** No, profitable trading may contribute to your XP, but it is one of several factors considered. You do not need to be profitable every day to continue qualifying for XP. ## XP Distribution ### **How are XP points distributed?** * Each weekly epoch distributes XP from a fixed pool. * XP is allocated proportionally based on activity within each epoch * XP accrued weekly contributes to your cumulative Season 3 XP and leaderboard ranking XP is allocated proportionally based on a participant’s trading activity relative to other traders during that period. The distribution resets every epoch, creating a new opportunity to earn XP each week. ### **Is the XP formula public?** No. The exact formula and weighting used to calculate XP are not publicly disclosed. ### **Is XP capped per wallet or per period?** XP is not capped per wallet. Instead, XP accrued within each activity category may be subject to per-epoch caps, meaning certain limits apply during each weekly epoch. These limits help support a more balanced distribution of XP across participants and may be adjusted during the program. ### **Is XP transferable?** XP has no monetary value and is not transferable or redeemable. Participation in XP and testnet activities does not confer any rights to tokens, digital assets, compensation or future rewards. ## Leaderboard The leaderboard ranks participants based on XP accumulated during the current season. Each season starts fresh with a new leaderboard. Participants can track: * Total XP earned in the current season * Relative ranking based on the current season XP * XP accrued during the most recent epoch * XP accrued during previous epochs in the XP Earning History tab * Eligible XP received in prior seasons carries forward on your account Leaderboard updates occur after each epoch once XP has been processed. ## XP Tracking ### **Can I see my XP in real time?** XP is not updated in real time. XP is calculated after each weekly epoch ends. The leaderboard and personal XP dashboard update once XP has been processed, with XP processing expected around 19:00 UTC. ### **Can I lose XP?** Yes. Certain actions or violations of platform rules may result in XP adjustments or account actions. The Fairground team reserves the right to review and correct XP allocations where necessary to maintain a fair experience for all participants.   *\* XP is a promotional participation metric that may be modified, adjusted, or discontinued at any time. XP has no monetary value, is not transferable or redeemable, and participation in XP or testnet activities does not create any entitlement or confer any rights to tokens, digital assets, compensation, or future rewards.* *Fairground may modify, suspend, reset, or discontinue XP, leaderboard rankings, participation metrics, or related promotional programs at any time.* ## Troubleshooting XP may not appear if: * The current epoch has not yet completed. * XP processing is still underway * No qualifying activity has occurred, such as placing an order during the epoch * Your wallet was recently approved and has not yet received its initial allocation If XP does not appear after multiple epochs of qualifying activity, please contact support via [Discord](https://discord.com/invite/uspz7RghvS). # XP Program Terms Source: https://docs.fairground.fi/earn/xp-program-terms Fairground XP is a participation-based scoring system operated by Forte Foundation metric, with no monetary value. Faiground XP are discretionary and subject to the program criteria. XP may be adjusted, reduced, or revoked at any time, including retroactively. Participation is subject to eligibility and review for manipulative or exploitative behavior. By participating, you agree to the XP Program Terms. ## **Program Terms** (testnet) ## 1. Overview The Fairground XP Program (the “Program”) is a discretionary, promotional initiative made available in connection with the Fairground testnet platform (the “Services”) and operated by Forte Foundation. “XP” is a non-transferable points metric used solely to allocate points based on user participation and activity within the Program. XP has no monetary or financial value, rather XP is a non-transferable points metric used to reflect user participation and activity within the Program. These XP Program Terms (the “Program Terms”) govern participation in the Program and supplement any applicable Terms of Use governing access to the Services, including those available at [https://fortefoundation.io/terms-of-service](https://fortefoundation.io/terms-of-service). In the event of any conflict, these Program Terms control with respect to the Program. ## 2. Eligibility Participation in the Program is subject to approval and ongoing eligibility requirements determined by Forte Foundation in its sole discretion. By participating, you represent and warrant that: * you are using the Services in good faith and in accordance with their intended functionality; * you will comply with all applicable terms, policies, and guidelines; * you will not engage in any activity designed to exploit, manipulate, or interfere with the Program or its operation; and * you are not located in, organized in, or a resident of any jurisdiction subject to applicable sanctions or legal or regulatory restrictions, including without limitation Iran, North Korea, Cuba, Syria, the Crimea, Donetsk, or Luhansk regions, or any jurisdiction in which the offering or use of the Services would be restricted or prohibited under applicable law, including China. Forte Foundation (in connection with Fairground) may approve, deny, suspend, or revoke participation at any time, with or without notice. ## 3. Testnet Environment All Program activity occurs in a testnet environment using simulated assets. You acknowledge and agree that: * all testnet assets have no real-world value; * such assets are non-transferable, non-withdrawable, and non-redeemable; * balances may be modified, reset, or removed at any time; and * participation is provided solely for testing, evaluation, and promotional purposes. ## 4. Eligible Activity XP may be awarded based on activity that Forte Foundation (in connection with Fairground) determines, in its sole discretion, constitutes eligible participation. Eligible activity includes, without limitation: * bona fide use of platform functionality; * trading activity conducted in good faith; and * contributions such as feedback, testing, or bug reporting. Without limiting the foregoing, activity will be deemed ineligible if it involves, or is reasonably suspected to involve: * wash trading, self-trading, or circular trading; * coordinated, collusive, or manipulative behavior; * artificial or non-economic activity designed to influence Program or XP outcomes; * Sybil behavior; * exploitation of system mechanics, unintended functionality, or vulnerabilities; or * any other activity that undermines the integrity, fairness, or intended purpose of the Program. Forte Foundation shall determine, in its sole discretion, whether any activity constitutes eligible or ineligible activity. ## 5. XP Calculation and Distribution XP may be distributed periodically, including on a per-epoch basis, from a fixed or variable allocation pool. XP allocations are determined in Forte Foundation (in connection with Fairground) sole discretion and may take into account, without limitation: * relative levels of participation; * trading activity and interaction with the platform; * market participation characteristics; and * qualitative or quantitative contributions to the Services. The methodology used to calculate XP: * is proprietary; * may not be disclosed; and * may be modified at any time without notice. XP may be subject to caps, limits, weighting adjustments, and other constraints. XP is not calculated or displayed in real time and may be subject to delays or corrections. ## 6. Review, Validation, and Disqualification All participation and XP accrual are subject to validation, verification, and review. Forte Foundation (in connection with Fairground) may, at any time and in its sole discretion: * review and audit participant activity; * determine that any activity is ineligible or non-compliant; * exclude activity from XP calculations; * disqualify any participant from the Program, Season 0, or any future programs, campaigns, or initiatives. Participation in the Program does not guarantee eligibility or continued participation. ## 7. XP Adjustment, Reduction, and Revocation All XP is provisional and subject to adjustment. Forte Foundation (in connection with Fairground) reserves the right, at any time and in its sole discretion, to: * adjust, reduce, or remove XP; * recalculate XP based on updated determinations; * apply caps, limits, or re-weighting; and * nullify XP associated with activity deemed ineligible or non-compliant. Any such action may be taken retroactively, including after XP has been displayed, accrued, or relied upon by the participant. Forte Foundation (in connection with Fairground) may take any action it determines, in its sole discretion, is necessary or appropriate to preserve the integrity, fairness, intended purpose, or lawful operation of the Program. ## 8. No Obligation; Errors and Corrections Forte Foundation has no obligation to award, maintain, or continue XP or the Program. Without limiting the foregoing, Fairground reserves the right to: * correct any errors or inconsistencies in XP calculations, allocations, or displays (including leaderboard rankings); * modify or reverse XP outcomes resulting from technical issues, anomalies, or system behavior; and * make any adjustments it determines appropriate in connection with the operation of the Program. ## 9. No Entitlement; No Value; No Expectation of Rewards XP: * has no monetary or financial value; * does not constitute property, ownership, or any legal interest; * is non-transferable and non-redeemable; and * cannot be exchanged for any asset, right, or benefit. Participation in the Program: * does not guarantee any reward, token allocation, airdrop, compensation, Season 1 access, future program access, or future benefit; * does not create any expectation of an airdrop, distribution, or compensation; and * does not give rise to any form of accrued benefit, expectancy, or claim of entitlement. Participants should not rely on XP, leaderboard position, or participation in the Program for any purpose. ## 10. Reservation of Rights Forte Foundation reserves the right, at its sole discretion, to: * interpret and apply these Program Terms; * determine eligibility, participation status, and Program outcomes; * modify, suspend, or terminate the Program (in whole or in part); * change XP allocation, distribution, or calculation methodologies; * reset XP balances, rankings, or participation metrics; and * take any action it determines necessary for compliance, risk management, or Program integrity. All determinations made by Fairground in connection with the Program are final and binding. ## 11. No Guarantee of Continuity The Program may be modified, suspended, or discontinued at any time, with or without notice. XP balances, leaderboard rankings, and participation status may be altered, reset, or eliminated at any time. # Market Design Source: https://docs.fairground.fi/faqs/market-design ### How does trading work without funding rates/fees? Fairground has no periodic funding payments. Instead of requiring recurring payments to maintain a position, traders pay a fixed trading fee when positions are opened, increased, reduced or closed. Fairground also uses part of trading fees to fund upside-only rebates when market flow becomes imbalanced. Eligible positions can accrue positive rebates when they help balance long and short exposure. ### Are there hidden fees or costs without funding rates? Fairground charges a fixed trading fee when positions are opened, increased, reduced or closed. There are no periodic funding payments. Eligible positions may also accrue upside-only rebates when they help balance long and short exposure. ### What are upside-only rebates? Fairground offers positive rebate opportunities when your position helps balance long and short exposure. Eligible positions can accrue positive rebates while they remain open when they help balance long and short exposure. Rebates are always positive, never negative, so being on the other side of the market does not create an additional rebate-related charge. Rebate eligibility and amounts depend on market conditions and are not guaranteed. ## Pricing ### Where does the mark price come from? Fairground uses a proprietary oracle built in-house to determine the market price. The protocol operates on a single oracle price, meaning there is no separate distinction between mark price and order book price. ### How often is the mark price updated? The oracle price updates whenever activity occurs on the protocol, such as order submissions, trade matching, liquidations, or other on-chain actions. There is no fixed update interval - the price refreshes dynamically as the market operates. ### Are trading fees different for makers and takers? No. Fairground does not distinguish between maker and taker fees. All trades pay a single flat fee based on trade size. Your net trading cost may vary depending on market balance, as a portion of trading fees may be rebated to traders on the less crowded side of the market. These rebates can reduce trading costs but never increase them. ## Risk & Liquidation ### How is my liquidation price calculated? Your liquidation price is determined by your entry price, margin, leverage, and position direction. It is the price at which your remaining margin falls below the maintenance margin requirement, making the position eligible for liquidation. ### Can my position be liquidated as soon as the liquidation price is reached? Yes. If the oracle price places your position within the liquidatable range when a keeper submits a liquidation transaction, your position may be liquidated. There is no grace period or buffer. ### What happens if my position is liquidated? Will I lose all of my margin? Not necessarily. If your position is liquidated while there is still margin remaining, the unused portion of your margin is returned to you after losses are settled. If the position’s margin has fallen below a defined threshold at liquidation, the remaining margin may be transferred to the Insurance Fund. ### Can profitable positions be auto-deleveraged (ADL)? Yes. Auto-deleveraging (ADL) may reduce positions on the profitable side of the market, since they are the counterparties to liquidated positions. It is a last-resort mechanism that only occurs if the Insurance Fund cannot cover liquidation losses. ## Orders ### How are orders matched? Orders are matched using price-time priority. The best available price is matched first, and orders at the same price are filled in the order they were received (FIFO). This is the same matching model used by traditional exchanges. ### How is my entry price calculated if my order fills across multiple price levels? Your entry price is the size-weighted average of all fill prices. If part of your order fills at one price and the rest fills at another, those fills are combined proportionally so your entry price reflects what you paid across all fills. ### What does “partially filled” mean? If there isn’t enough opposing order volume to fill your entire order, the portion that can be matched executes immediately. The remaining size stays open in the order book until more opposing orders become available. ### Can I cancel my order? Is there a cancellation fee? Yes, you can cancel your open order at any time, and there is no cancellation fee. ### Can I update my order price or size after it has been submitted? Yes. As long as your order has not been filled, you can update both the price and size. ## Positions ### Can I have both a long and short position open on the same market at the same time? No. Each wallet can hold only one position per market. To switch direction, you must first close your existing position. Support for multiple positions will be introduced in future releases. ### Does Fairground use cross margin or isolated margin? Fairground uses isolated margin, meaning each position has its own margin. A liquidation on one position does not impact your other positions. ### Can I add or remove margin from an open position? Removing margin will move your liquidation price closer to the current market price. However, the protocol prevents margin from being removed if doing so would cause the position to be immediately liquidated. ### Can I close part of my position? Yes. You can close any portion of an open position. ### Are there limits to how much I can trade? Yes. Each market has a minimum and maximum trade size, which may vary by market. ## Product ### Will there be a mobile app? Yes, a mobile app is in the works, but it will not be available during the first few seasons. # Overview Source: https://docs.fairground.fi/faqs/overview ### What is Fairground? Fairground is a decentralized perpetuals exchange with no periodic funding payments. Traders can take leveraged long or short positions across crypto and real-world markets. Orders execute at a single reference price, removing the visible bid/ask spread from the execution model. By removing periodic funding payments, Fairground simplifies the economics of holding a perpetual position and gives traders greater visibility into the costs of maintaining their exposure. ### What is a good trade to place on Fairground? Fairground is designed for trades where you want leveraged market exposure without periodic funding payments impacting the economics of your position. That can be particularly useful when: * **Funding costs elsewhere would work against your trade.** If the market view makes sense but recurring funding payments would add an ongoing cost to the position, Fairground removes that variable. * **You want to take a directional long or short position.** There are no periodic funding payments, so funding does not add an ongoing cost while the position remains open. * **You want to hold a position without being penalized over time.** Whether the trade is open for a short period or longer, there is no recurring funding payment simply for maintaining the position. * **You are using Fairground as one leg of a hedge.** Removing periodic funding payments can make the economics of maintaining that exposure more predictable, particularly when a hedge needs to remain in place. * **Your position helps balance the market.** Fairground offers upside-only rebates when your position helps balance long and short exposure. Rebates are always positive, never negative, so eligible positions can accrue rebates while they remain open without creating an additional charge. Fairground removes periodic funding payments as a variable in leveraged trading, while creating the opportunity for positive rebates when a position helps balance the market. # Fairground Referrals Source: https://docs.fairground.fi/faqs/referrals ## Access & Mechanics ### Are referrals open to everyone? No, referrals are currently available only to eligible wallets that have been pre-selected and notified. ### How do I find/access my referral link? Eligible users can access their personal referral link on the [Referrals page](https://fairground.fi/421614/referrals) after connecting their eligible wallet. ### Where can I see how many referrals I have remaining? Your [Referrals page](https://fairground.fi/421614/referrals) shows how many of your 5 referrals you’ve used and how many remain. Once all 5 have been used, you’ll see that you’ve reached your referral limit. ## Eligibility & Restrictions ### Do referral links expire? Yes. Referral links are valid through the end of Season 3 or until all 5 referrals have been used ### **Can I unlock referral access through trading activity or volume?** No. Referral access is currently limited to pre-selected eligible wallets. There is no activity or volume threshold that will unlock access during Season 3. ### Can I refer another wallet I control, or could that disqualify me from referral rewards? No. Self-referrals are prohibited under the program terms. Wallets identified as bots, sybils, or self-referrals will be excluded from the XP program. ## **XP Referral Rewards** ### **When are referral XP rewards credited?** Referral XP is credited at each weekly epoch settlement alongside your base XP. ### Does the XP boost apply to all XP earned during the season? The 2% boost applies to all *base XP* earned through trading activity during Season 3. It does not apply to bonus XP, such as XP earned from feedback or surveys. The referrer’s 4% reward is calculated on the same basis. ### Does referral XP count toward my Season 3 XP total and leaderboard position? Yes. Referral XP is included in your total Season 3 XP and contributes to your leaderboard position. ### Is there a cap on how much XP I can earn from referrals? No. There is currently no cap on the total XP you can earn through referrals. # Season 3 Source: https://docs.fairground.fi/faqs/season-3 ## Overview ### How long will Season 3 run? Season 3 is scheduled to begin August 27, 2026 at 16:00 UTC, ending September 17, 2026. Access will be granted to participants from previous Fairground seasons. Season 3 is expected to run for at least three weeks. However, the duration may be adjusted based on testing needs, platform performance, and participant feedback. ### Will I need to use real funds to participate? No. Participation uses Fairground Testnet USDC tokens, not real funds. Testnet USDC is deposited into participant wallets at the start of each epoch for trading. Eligible participants are allocated 1,000 Testnet USDC each day at 16:00 UTC. ## Participation + Access Season 3 is open to participants who previously registered through a Fairground waitlist or registration program. If you did not previously register for the Fairground waitlist, you will not be admitted into Season 3. If selected, you will receive an email from [access@fairground.fi](mailto:access@fairground.fi) with access instructions. Additional participation opportunities may be available in future seasons. ### How do I join Season 3? Season 3 participants are selected from individuals who previously registered through Fairground waitlist and registration programs. If you have been selected, you will receive an email via your registered waitlist address with access details and instructions on how to participate. Once approved, your Testnet USDC deposits will arrive at the start of each epoch. Additional participant admissions and future testing opportunities may be announced at a later date. ### Is my private data collected? Participation in the testnet requires providing an email address and wallet address. Wallet age and certain on-chain activity indicators may also be reviewed to support participant selection and testnet operations. User data is retained for up to 12 months in accordance with security and compliance requirements. All information is automatically deleted after this period. ## Season 3 Trading ### What markets are available in Season 3? During Season 3, Fairground supports the following perpetual markets: * Crypto - BTC, ETH, SOL, HYPE, XRP, ZEC, LIT, NEAR * Commodities - Gold, Silver * FX Pairs: EUR/USD, GBP/USD, JPY/USD, AUD/USD Available markets may change over time, especially during the testnet phase. Fairground may add, remove, or update supported markets at its discretion, including in future seasons. ### What order types are supported in Season 3? Season 3 supports market, limit, stop loss, and take profit orders. Market orders allow users to execute immediately, while limit, stop loss, and take profit orders allow users to set specific price levels for entry, exit, and risk management. For more details, you can review the [Orders](/trading/orders) section in the Fairground docs. ## Testnet funds Season 3 uses Testnet USDC for all trading activity. * For Season 3, 1,000 Testnet USDC is distributed daily at 16:00 UTC * Balances accumulate over time, allowing traders to build larger positions throughout the season * Testnet USDC cannot be withdrawn or transferred between wallets * A small amount of Testnet ETH is also provided to cover gas costs * Testnet USDC has no real-world value This structure ensures participants have funds available to remain active and continue testing the platform throughout the season. Testnet USDC is non-withdrawable, non-transferable, and has no monetary value. It is provided for participation in the Fairground testnet. ## Deployment ### What chain is Fairground deployed on? Arbitrum Sepolia. ### Why was Arbitrum chosen? Arbitrum was selected for its fast block times, low transaction costs, and mature infrastructure. ## Next Phase ### What happens after Season 3 ends? After Season 3 concludes, the Fairground team will review trading activity, platform performance, and participant feedback to help inform future development, testing priorities, and broader release planning. Additional testing phases and participation opportunities may be announced in the future. Participants may also be invited to complete surveys or share additional feedback as we continue improving the Fairground experience and working toward broader availability. # XP Program Source: https://docs.fairground.fi/faqs/xp-program The XP program recognizes active participation on Fairground through trading. Trading activity is measured across weekly epochs, with XP distributed from a pool that is fixed *within* each epoch and may be adjusted between epochs. The more you participate in trading, the more opportunities you have to qualify for XP. XP accumulates over time and contributes to leaderboard standings. To maintain a fair environment, activity identified as Sybil behavior, self-trading, or similar manipulation may be excluded from XP calculations. All activity takes place using testnet funds. Testnet funds hold no monetary value. ### What is XP? XP is a points system used to track participant activity on Fairground and contributes to leaderboard rankings. XP may accrue through eligible activities, including but not limited ot trading performance, bug reports, surveys, and feedback submissions. *XP is a promotional participation metric and may be modified, adjusted or discontinued at any time at the sole discretion of Fairground. Participation in XP and testnet activities does not confer any rights to tokens, digital assets, compensation or future rewards. XP has no monetary value and is not transferable or redeemable, and participation in XP or testnet activities does not create any entitlement or confer any rights to tokens, digital assets, compensation, or future rewards.* ### What is an epoch? An epoch is a one-week participation period during which eligible activity may result in XP being awarded. XP received based on your activities during each epoch contributes to your Season 3 standing. ## Season 3 Epoch Schedule | Epoch | Start | End | XP distribution | | :---- | :--------------------------- | :--------------------- | :------------------ | | 1 | Thursday Aug 27th 16:00 UTC | Sept 3rd 15:59:59 UTC | Sept 3rd 19:00 UTC | | 2 | Thursday Sept 3rd 16:00 UTC | Sept 10th 15:59:59 UTC | Sept 10th 19:00 UTC | | 3 | Thursday Sept 10th 16:00 UTC | Sept 17th 15:59:59 UTC | Sept 17th 19:00 UTC | ## How the XP Program Works XP is designed to recognize active participation across Fairground. The exact XP formula is not shared publicly and may include a combination of factors, including: * **Trading activity** - placing orders that fill (opening and/or closing positions) during each epoch may contribute to XP * **PnL** - profitable trading and fees generated through eligible trading activity may contribute to your XP, but it is one of several factors considered. You do not need to be profitable every day to continue qualifying for XP. * **Rebates** - rebates earned from holding positions on the minority side of an imbalanced market. * **Contribution XP** - eligible feedback submissions, bug reports, and product suggestions may qualify for bonus XP. At the end of each weekly epoch:
\~ Trading activity is evaluated
\~ XP is distributed from a fixed pool
\~ The leaderboard is updated ## Qualifying for XP ### **What behaviors does XP reward?** XP rewards active and authentic trading on the platform. XP is distributed after each epoch based on overall trading activity relative to other participants during that period. ### **What activities count toward XP?** XP is designed to recognize active participation across Fairground. The exact XP formula is not shared publicly, but Season 3 XP may reflect a combination of factors, including trading activity, PnL, rebates, and eligible non-trading contributions. Placing orders that fill during each epoch, and higher trading activity may contribute more to your overall total. Profitable trading may also contribute to XP, but it is only one of several factors considered. You do not need to be profitable to continue qualifying for XP. Liquidity rebates from providing depth may also contribute to XP. Eligible feedback submissions, bug reports, and product suggestions may qualify for bonus Contribution XP. Traders who provide feedback, identify issues, suggest improvements, or help us refine the trading experience may be eligible for discretionary promotional XP or other promotional rewards subject to applicable eligibility criteria and separate program terms. ### **Do I need to be profitable to earn XP?** No, profitable trading may contribute to your XP, but it is one of several factors considered. You do not need to be profitable every day to continue qualifying for XP. ## XP Distribution ### **How are XP points distributed?** * Each weekly epoch distributes XP from a fixed pool. * XP is allocated proportionally based on activity within each epoch * XP accrued weekly contributes to your cumulative Season 3 XP and leaderboard ranking XP is allocated proportionally based on a participant’s trading activity relative to other traders during that period. The distribution resets every epoch, creating a new opportunity to earn XP each week. ### **Is the XP formula public?** No. The exact formula and weighting used to calculate XP are not publicly disclosed. ### **Is XP capped per wallet or per period?** XP is not capped per wallet. Instead, XP accrued within each activity category may be subject to per-epoch caps, meaning certain limits apply during each weekly epoch. These limits help support a more balanced distribution of XP across participants and may be adjusted during the program. ### **Is XP transferable?** XP has no monetary value and is not transferable or redeemable. Participation in XP and testnet activities does not confer any rights to tokens, digital assets, compensation or future rewards. ## Leaderboard The leaderboard ranks participants based on XP accumulated during the current season. Each season starts fresh with a new leaderboard. Participants can track: * Total XP earned in the current season * Relative ranking based on the current season XP * XP accrued during the most recent epoch * XP accrued during previous epochs in the XP Earning History tab * Eligible XP received in prior seasons carries forward on your account Leaderboard updates occur after each epoch once XP has been processed. ## XP Tracking ### **Can I see my XP in real time?** XP is not updated in real time. XP is calculated after each weekly epoch ends. The leaderboard and personal XP dashboard update once XP has been processed, with XP processing expected around 19:00 UTC. ### **Can I lose XP?** Yes. Certain actions or violations of platform rules may result in XP adjustments or account actions. The Fairground team reserves the right to review and correct XP allocations where necessary to maintain a fair experience for all participants.   *\* XP is a promotional participation metric that may be modified, adjusted, or discontinued at any time. XP has no monetary value, is not transferable or redeemable, and participation in XP or testnet activities does not create any entitlement or confer any rights to tokens, digital assets, compensation, or future rewards.* *Fairground may modify, suspend, reset, or discontinue XP, leaderboard rankings, participation metrics, or related promotional programs at any time.* ## Troubleshooting XP may not appear if: * The current epoch has not yet completed. * XP processing is still underway * No qualifying activity has occurred, such as placing an order during the epoch * Your wallet was recently approved and has not yet received its initial allocation If XP does not appear after multiple epochs of qualifying activity, please contact support via [Discord](https://discord.com/invite/uspz7RghvS). # Protocol Overview Source: https://docs.fairground.fi/index Fairground perpetuals exchange with fixed fees, no funding rates, and one oracle price. Fairground is a decentralized perpetuals exchange on Arbitrum. One oracle price, fixed fees, no funding rates—and rebates when you take the minority side. Connect a wallet, add USDC and ETH on Arbitrum, and start trading. Place, cancel, and manage orders. Add or remove margin on positions. One price per market—no mark/index split. Simpler and transparent. Fixed 4.5 bps per trade. Earn rebates when you provide the minority side. ## Advanced trading How reduce and increase orders are matched. When positions are liquidated and how it works. Protocol backstop for undercollateralized positions. Auto-deleveraging when the insurance fund is depleted. Definitions for protocol terms. ## Earn XP program and earn rewards. Market making and liquidity provisioning. ## Developer Docs API reference and integration guides for building on Fairground. # Official Links Source: https://docs.fairground.fi/official-links Trading app, socials, and other official resources. | Resource | Link | | :-------------------- | :---------------------------------------------------------------------------------------------------------------------- | | **Official Websites** | [https://fortefoundation.io/fairground](https://fortefoundation.io/fairground) / [https://forte.io/](https://forte.io/) | | **Trading App** | [https://fairground.fi](https://fairground.fi) | | **Discord** | [https://discord.gg/jzz5Z2HtQ3](https://discord.gg/jzz5Z2HtQ3) | | **GitHub** | [https://github.com/Forte-Service-Company-Ltd](https://github.com/Forte-Service-Company-Ltd) | | **Privacy Policy** | [https://fortefoundation.io/privacy-policy](https://fortefoundation.io/privacy-policy) | | **Terms of Use** | [https://fortefoundation.io/terms-of-service](https://fortefoundation.io/terms-of-service) | # Trading Hours Source: https://docs.fairground.fi/trading-hours Market hours for crypto, FX, stocks, and commodities Trading hours vary by asset class. Fairground follows the underlying market conventions for each product type. ## Crypto Crypto markets are open **24 hours a day, 7 days a week**. There is no daily close or weekend halt. ## FX (Foreign Exchange) The FX market is open **24 hours a day, 5 days a week**. * **Opens:** Sunday 5:00 PM ET * **Closes:** Friday 5:00 PM ET The global FX market runs continuously during this window as trading passes through Sydney, Tokyo, London, and New York. ## Stocks (NYSE, NASDAQ) * **Regular hours:** 9:30 AM – 4:00 PM ET, Monday – Friday * Exceptions around U.S. Holidays ## Commodities Commodities futures generally follow **CME Group** (CME, CBOT, NYMEX, COMEX) trading hours. Most products trade on **CME Globex**, which operates nearly 24 hours during the week. * **Opens:** Sunday 6:00 PM ET * **Closes:** Friday 5:00 PM ET All times are in **US Eastern Time (ET)**. # ADL (auto-deleveraging) Source: https://docs.fairground.fi/trading/advanced/adl What ADL is, when it triggers, and what happens to positions ADL (auto-deleveraging) is a **last‑resort solvency mechanism**. It only occurs in extreme conditions, when losses from liquidations would otherwise consume too much of the market’s insurance fund budget. ## When ADL is used Normally, if a liquidated position ends underwater, the [Insurance Fund](/trading/advanced/insurance-fund) covers the deficit so the system can settle and move on. ADL is used when the protocol determines that the insurance fund budget for a market is at (or beyond) its risk limit for a specific close‑out. ## Triggering The protocol periodically scans positions that are severely at risk. Those whose margin ratio has fallen well below the [liquidation](/trading/advanced/liquidation) level are candidates for ADL. The protocol then computes two values: 1. **Current deficit:** the insurance fund dollars needed to settle these positions at the current price. 2. **Shock deficit:** the insurance fund dollars needed if the price were to move an additional small percentage against these positions. These are compared against the market’s **insurance fund budget** (a fraction of the total insurance fund allocated to that market): * **Shock deficit ≤ budget:** No ADL action. The insurance fund can absorb even a short-term adverse price move, so normal liquidation handles it. * **Current deficit ≤ budget, but shock deficit > budget:** ADL triggers **at the current price**. The insurance fund can cover current losses, but a further price move could exceed the budget so ADL acts preemptively. * **Current deficit > budget:** ADL triggers at a computed **close‑out price** chosen so the market’s insurance fund allotment can exactly cover the settlement. * In this extreme case, the protocol may **halt trading** for the market. ## What happens when ADL triggers When ADL triggers, the protocol acts on **one side of the market at a time** (e.g. all at-risk longs, or all at-risk shorts): 1. **Closes underwater positions** on the losing side. 2. Applies a **pro‑rata reduction** to *all positions on the opposite side* to offset the imbalance. ### How ADL is applied to winning positions If you’re on the profitable side, your position is reduced by the **same percentage** as everyone else on that side. For example, if ADL needs to close an amount equal to **5% of the total open size**, then **every** position on the profitable side is reduced by **5%**. ## What you’ll see * **Your position size decreases** (only if you are on the opposite side of the at-risk positions included in the ADL close‑out). * The reduction happens at the **oracle price** (or the computed close‑out price in the extreme case). ## Relationship to liquidation * Liquidation closes positions that are below maintenance margin. See [Liquidation](/trading/advanced/liquidation). * The insurance fund covers deficits from **underwater** liquidations until the market reaches its risk limit. See [Insurance Fund](/trading/advanced/insurance-fund). * ADL is what happens **after** that limit is reached: it reduces positions on the opposite side to offset the loss and keep the protocol solvent for the market. # Glossary Source: https://docs.fairground.fi/trading/advanced/glossary Definition of terms used in the protocol Use this page to quickly look up protocol terms. | Term | Definition | | ---- | ---------- | # Insurance Fund Source: https://docs.fairground.fi/trading/advanced/insurance-fund When and how the insurance fund is used There is one insurance fund shared across the protocol. Each market has access to a **fixed-percentage budget** of the total insurance fund balance per close-out event. This means the amount available to a given market depends on the current fund balance and the market’s configured share. ## When it is used The insurance fund is part of the protocol’s liquidation backstop. It is used **when a liquidated position’s margin cannot safely cover the outcome** at the time the protocol’s close order fills: * **Seized at fill**: the position’s **remaining margin is forfeited** and sent to the insurance fund. * **Underwater at fill**: the position’s margin is negative, so the **insurance fund pays the deficit** to keep the system solvent. These cases correspond to the “Seized” and “Underwater” position health statuses described on the [Liquidation](/trading/advanced/liquidation) page. If the insurance fund budget for a market is exceeded during a close-out, [ADL (auto-deleveraging)](/trading/advanced/adl) triggers as a last resort. ## How it is funded The insurance fund receives capital from two sources: 1. **A share of trading fees:** After minority-side rebates, a portion of the remaining fees from each matching cycle is routed to the insurance fund (see [Fees and Rebates](/trading/fees-rebates)). 2. **Seized position margin:** When a liquidated position is seized at fill, its remaining positive margin is forfeited to the fund. # Liquidation Source: https://docs.fairground.fi/trading/advanced/liquidation How liquidation works, when it triggers, and what happens to your margin Liquidation is the process the protocol uses to **forcibly close positions that are at risk of not being able to cover losses**. Every open position has a (your collateral allocated to that position, plus or minus ). As the oracle price moves, your position margin changes in real time and so does your position's health status. The for a position equals ½ of the initial margin that would be required to open the same position at *max leverage* at the *current price*. In other words: > Maintenance Margin = Notional Position Value ÷ (2 × Max Leverage) For example, a 1 BTC long at \$50,000 with max leverage 20x: > Maintenance Margin = $50,000 ÷ (2 × 20) = $1,250 If your position margin falls below maintenance margin, your position can be liquidated. ## Position health statuses As price moves, your position can move through these statuses: | **Status** | **When it applies** | **What it means for you** | | :--------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------: | | **Healthy** | position margin > maintenance margin | No liquidation risk. | | **Liquidatable** | ⅔ maintenance margin ≤ position margin \< maintenance margin | Liquidation can be triggered. | | **Seized** | position margin \< ⅔ maintenance margin | Remaining margin is treated as forfeit to the Insurance Fund on close. | | **Underwater** | position margin \< 0 | Your losses exceed your margin; the [Insurance Fund](/trading/advanced/insurance-fund) backstops the deficit. | ## How liquidation is triggered Liquidation is triggered by a liquidation transaction, which anyone can submit for a specific position. When liquidation is triggered for a position that has moved from **Healthy → Liquidatable**: * The protocol **opens an order to close the position**. * That close order has **no execution price threshold** (it is intended to get filled, not “wait for a better price”). * The position owner **can no longer update the position** after liquidation is triggered. That close order is then processed by the normal matching flow the next time matching runs. If your position becomes **Liquidatable**, liquidation is triggered, and the protocol opens a close order. That close order stays open even if price later moves back and your position becomes technically healthy again before matching happens. In other words, once liquidation is triggered, the position is expected to be closed by the protocol during matching. ## What happens when the close order fills What you receive (or what happens to the remaining margin) depends on the position’s status **at the time the close order fills**: * **If the position is Liquidatable at fill**: you receive your remaining margin back, **minus the standard trading fee** (see [Fees](/trading/fees-rebates)). * **If the position is Seized at fill**: the remaining margin is sent to the **Insurance Fund**. * **If the position is Underwater at fill**: the **Insurance Fund pays the deficit** (the negative margin) so the system remains solvent. You can learn more about the backstop mechanism on the [Insurance Fund](/trading/advanced/insurance-fund) page. ## Liquidation price Your **liquidation price** is the price at which your position margin would fall to exactly the maintenance margin level. Beyond this price, your position becomes liquidatable. For a **long** position, the liquidation price is *below* your entry price. For a **short** position, it is *above* your entry price. Higher leverage means your liquidation price is closer to your entry price. # Order Matching Source: https://docs.fairground.fi/trading/advanced/order-matching How orders are matched and filled Matching is the process by which orders are filled and corresponding positions are created, closed, and updated. All matches execute at the **current oracle price**. The matching process is triggered by two separate scenarios: * A new order is placed (matching runs automatically for that market) * A matching transaction is sent to the protocol ## How matching works Each time matching is triggered for a market, the algorithm runs through three steps: Every unfilled order whose execution price threshold permits execution at the current oracle price is collected. Orders whose threshold is outside that range are skipped this round. The collected orders are split into two opposing queues by the direction they trade: * The **long queue** holds every order that buys. Orders opening a long position and orders closing a short position. * The **short queue** holds every order that sells. Orders opening a short position and orders closing a long position. Within each queue, orders are arranged by priority (see [Order priority](#order-priority) below). The two queues are filled against each other by total notional value. The smaller queue is filled completely; the larger queue is filled up to the same notional, working down from the top of the queue. For example, if the long queue totals 1,000 of notional and the short queue totals 500, the short queue is fully filled and the first 500 of notional in the long queue is filled. The remaining long orders stay unfilled this round. If an order is only partially filled in a cycle, the unfilled portion remains in its queue for the next matching cycle. ## Order priority Within each queue, orders are filled in a strict priority order. There is **no price priority.** An order's execution price threshold only determines whether it is executable, not its place in the queue. Orders are filled in the following order of priority: 1. **Liquidations:** Close orders generated by the liquidation engine are filled first. 2. **Reduce orders:** orders that close or reduce an existing position are filled next. 3. **Increase orders:** orders that open or add to a position are filled last. Within each level of priority, orders are filled in time priority (FIFO). The order placed earliest is filled first. # Advanced Trading Overview Source: https://docs.fairground.fi/trading/advanced/overview Deep dive into order matching, liquidations, the insurance fund, and ADL. Learn how Fairground handles order execution, risk management, and protocol backstops. How reduce and increase orders are matched. When positions are liquidated and how it works. Protocol backstop for undercollateralized positions. Auto-deleveraging when the insurance fund is depleted. Definitions for protocol terms. # Fees and Rebates Source: https://docs.fairground.fi/trading/fees-rebates Fee mechanics and rebate allocations Fairground does not use funding rates. Instead, a fixed fee is charged on every order or position change. The fee is split between minority-side rebates, the Insurance Fund, and protocol fees, based on market conditions. For **position-level fee and rebate detail** from the API, on-chain parameters, and integration-oriented notes aimed at liquidity providers and integrators, see [Market makers / LPs](/earn/market-makers-lps). ## Trade fee mechanics Every position change incurs a trading fee on the **notional changed**. The fee rate is a **per-market parameter** in the market's fee configuration. All markets currently charge **4.5 bps (0.045%)**. The fee applies whether you are opening, increasing, reducing, or closing a position. Examples on this page use the current 4.5 bps rate. | Action | Change in Notional | Fee | | ------------------------- | ------------------ | --------- | | Open `$100` position | `$100` | `$0.045` | | Increase `$100` -> `$250` | `$150` | `$0.0675` | | Reduce `$100` -> `$40` | `$60` | `$0.027` | | Close `$100` position | `$100` | `$0.045` | ### When fees are charged * **Open / increase:** Fee is deducted when the order is placed. * **Reduce / close:** Fee is charged when the order is matched and filled. If an open/increase order is canceled before fill, the pre-deducted fee is reimbursed. ### Open/increase sizing impact For open/increase orders, fee is taken from deposited margin before exposure is finalized, so the resulting notional is slightly below `margin * leverage`. For deposited margin `M`, fee rate `f` (`0.00045` at 4.5 bps), and target leverage `L`: ```text theme={null} fee = (f * L) / (1 + f * L) * M notional = L * (M - fee) ``` ## Where fees go Each matched side pays the trading fee on its matched notional. For routing purposes, total fees for a match are: ```text theme={null} matched notional * 4.5 bps * 2 ``` Those fees are allocated to: 1. **Minority-side rebates** 2. **[Insurance Fund](/trading/advanced/insurance-fund)** 3. **Protocol fees** The split is governed by market parameters: | Parameter | Meaning | | ------------------------------------- | ------------------------------------------------------------------ | | **Imbalance entitlement (E)** | Share of total fees allocated to minority-side rebates | | **Max entitlement (E\_max)** | Maximum rebate share once imbalance reaches its cap | | **Max imbalance (I\_max)** | Imbalance level where the max entitlement is reached | | **Insurance fund entitlement (E\_I)** | Share of the post-rebate remainder allocated to the Insurance Fund | The minority-side share `E` scales linearly with imbalance `I` up to a cap: ```text theme={null} E = E_max * min(I / I_max, 1) ``` For a match with total trade fees `T`: * Minority-side rebates: `E * T` * Insurance Fund: `E_I * (1 - E) * T` * Protocol fees: `(1 - E_I) * (1 - E) * T` When executable long and short notional are balanced, imbalance is zero, so `E = 0` and no minority rebate is generated for that matching cycle. ## What minority side means The protocol groups executable orders into two order sides: * **Long-side orders:** opening long positions and closing short positions. * **Short-side orders:** opening short positions and closing long positions. Executable notional is the notional from orders that can match at the current oracle price and their threshold configuration. The matching cycle compares: ```text theme={null} long-side executable notional = opening long + closing short short-side executable notional = opening short + closing long imbalance = absolute difference between those two sides ``` The side with lower executable notional is the **minority side** for that matching cycle. If the sides are equal, there is no minority-side rebate accrual for that cycle. When a user action triggers matching, the triggering order is excluded from the imbalance calculation. It still contributes to matched notional and fee accounting if it is filled. Liquidation reduce flow can change closing-side totals and therefore imbalance and fee routing. See [Liquidation](/trading/advanced/liquidation). ## How rebates are earned Rebates accrue to open positions on the position side that corresponds to the minority order side, tracked through two cumulative meters, one per position side. After a matching cycle with an imbalance, the meter for the matching position side increases by a per-unit amount: ```text theme={null} dollars per unit = (E * T) / post-match open interest on that position side ``` When the long order side is the minority, the long-position meter increases. When the short order side is the minority, the short-position meter increases. Open positions on the matching side accrue from any meter increase that occurs after their own snapshot, and realize that accrual on reduce or close. New positions do **not** inherit past meter values. When your position opens, the protocol records the current meter value as your snapshot, and you accrue only from later meter increases. ### Position lifecycle behavior | Event | Rebate treatment | | ------------- | -------------------------------------------------------------------- | | Open | Snapshot your side's current meter. No past fee accrual is inherited | | Increase | Preserve existing accrual and blend the snapshot for the added size | | Partial close | Realize accrued rebate on the closed portion only | | Full close | Realize accrued rebate on the full position | On reduce and close fills, meter payout uses the meter value **before** the current cycle's update. A close does not receive accrual from the same cycle that closes it. A new open that fills in the same cycle snapshots the pre-update meter, so it does pick up that cycle's increase. ### Quick reference | Matching cycle state | Rebate outcome | | --------------------------------------- | --------------------------------- | | Long-side and short-side notional match | No minority rebate is generated | | Long-order side notional lower | Long-position meter increases | | Short-order side notional lower | Short-position meter increases | | Imbalance larger than `I_max` | Rebate share is capped at `E_max` | ## What rebates are not * Rebates are not funding payments and do not create periodic holding costs. * Majority-side traders do not pay an extra "negative rebate" beyond the standard trading fee. * A placed order is not guaranteed to earn rebates. Rebate accrual depends on filled matches, imbalance, and the position-side meter. * Historical meter values are not a current rebate opportunity. Current rebate indicators should be based on recent meter changes, not raw cumulative meter levels. # Miscellaneous UI Source: https://docs.fairground.fi/trading/miscellaneous-ui UI-specific components and their descriptions ## Segment PnL and Lifetime PnL Fairground separates a position's recent performance from its performance over its entire lifecycle. **Segment PnL** focuses on the period since the position last changed, while **Lifetime PnL** carries across every change from original position open to full position close. Overall, Segment PnL is best used to understand position performance on a trade-by-trade basis, whereas Lifetime PnL is best used to understand overall position profitability. A position's *current value* is its margin plus unrealized PnL at the current price. This is the value that would be returned to the user if they closed the position at the current price. ```math theme={null} V_{\mathrm{now}} = M+\sigma\,(P_{\mathrm{now}}-P_{\mathrm{entry}})\,S ``` Where: * $M$ is the margin currently backing the position * $P_{\mathrm{entry}}$ is the entry price and $P_{\mathrm{now}}$ is the current mark price * $S$ is the position size * $\sigma=+1$ for a long and $\sigma=-1$ for a short $V_{\mathrm{last\ touch}}^+$ is what the current value of the position was at the time of the most recent margin or size change (the last "touch"). **Segment PnL:** ```math theme={null} \mathrm{SegmentPnL} = V_{\mathrm{now}}-V_{\mathrm{last\ touch}}^+ ``` **Lifetime PnL:** ```math theme={null} \mathrm{LifetimePnL} = V_{\mathrm{now}}+C_{\mathrm{out}}-C_{\mathrm{in}} ``` Where: * $V_{\mathrm{now}}$ is the marked value defined above, taken as zero once the position closes * $C_{\mathrm{out}}$ is all cash credited back to your wallet from the position * $C_{\mathrm{in}}$ is all cash debited from your wallet for the position (e.g. margin added) Because deposits and withdrawals enter as cash flows ($C_{\mathrm{in}}$ and $C_{\mathrm{out}}$), adding margin alone doesn't create a profit and removing margin alone doesn't create a loss. ### Segment PnL Segment PnL is the gain or loss on the current *segment* of your position. A segment is the stretch of time during which the position hasn't been interacted with by the trader. A new segment begins whenever you change the position's margin or size. The first segment begins when the position opens. Later actions can start a new segment: | Action | Segment treatment | | ---------------------------------------- | ----------------------------------------------------------------------- | | Add margin | Starts a new segment after a margin add | | Remove margin | Starts a new segment after a margin remove | | Increase the position | Starts a new segment after a position increase | | Partially close or decrease the position | Starts a new segment from the remaining position | | ADL size reduction | Starts a new segment by treating the reduction like a position decrease | | Fully close the position | Ends the final segment | ### Lifetime PnL Lifetime PnL is the total dollar gain or loss across the position's complete lifecycle. It does not reset when you add or remove margin, increase the position, or partially close it. ### Example Say you open a long with `$1,000` of margin at `10×` leverage, giving you `$10,000` of exposure at an entry price of `$100`. Your position value, the margin plus any unrealized profit or loss starts at `$1,000`, the same as your margin. Segment PnL and Lifetime PnL both start at `$0`. A 2% price move on 10× leverage is a 20% gain on margin. Unrealized PnL is `+$200`, lifting position value to `$1,200`
- Segment PnL: `+$200 (+20%)`
- Lifetime PnL: `+$200 (+20%)` Adding margin isn't a "gain", so it opens a fresh segment from the new `$1,500` baseline and segment PnL resets to `$0`. The `$300` is recorded as cash in, so Lifetime PnL stays at `+$200`. Your leverage also drops: the same `~$10,000` of exposure now sits on more margin, taking you from `10×` to about `6.8×`.
- Segment PnL: `+ $0 (+0%)`
- Lifetime PnL: `+$200 (+15.4%)` Another `+$300` of unrealized profit brings your position value to `$1,800`
- Segment PnL: `+$300 (+20%)` measured from the new `$1,500` position value
- Lifetime PnL: `+$500 (+38.5%)`. `$1,300` of margin was placed across the two deposits and `$1,800` total was withdrawn
- Segment PnL: `+$300 (+20%)`
- Lifetime PnL: `+$500 (+38.5%)` # Onboarding Source: https://docs.fairground.fi/trading/onboarding Get set up to trade on Fairground You need two things to trade: a wallet and collateral on Arbitrum. ## 1. Join via the Waitlist You can join the waitlist on the trading app here: [Join Waitlist](https://fairground.fi/421614/rewards). Connect a wallet or create social login as described in the next step and you'll see the waitlist pane appear. screenshot of waitlist ## 2. Connect a wallet **Option A: Use an existing wallet** Connect any EVM-compatible wallet (MetaMask, Rabby, WalletConnect, Coinbase Wallet, etc.). **Option B: Create one with social login** Sign up with your email, Google, X, Telegram, or Discord. A wallet is created for you automatically. You can find the public address of this wallet by expanding the wallet dropdown and clicking the `copy` icon within the Privy (Embedded) pane. ## 3. Receiving ETH and Test USDC on Arbitrum Sepolia Upon being granted access from the waitlist your wallet will receive enough testnet ETH to pay gas fees and test USDC to be used as collateral for opening positions on the app. Your wallet will be granted additional test USDC at the beginning of each epoch during the season. The address of the test USDC token used for this season is: [`0x4E1156749dd156D06dCE5baC0f8f5A43792C9EDb`](https://sepolia.arbiscan.io/token/0x4E1156749dd156D06dCE5baC0f8f5A43792C9EDb) *** ## Notes for users bringing their own wallet If you're using your own wallet, you'll probably need to add the Arbitrum Sepolia network to it. The easiest way to do this is to navigate to [https://sepolia.arbiscan.io/](https://sepolia.arbiscan.io/) and scroll down to the footer menu. You'll see a button to Add Arbitrum Sepolia Network. Click that and it should open the pane in your wallet to add the custom network. screenshot of add arbitrum sepolia button If you need to manually add the network, you can use the following information: | Info | Value | | :----------------- | :------------------------------------------------------------------------------- | | Network Name | Arbitrum Sepolia | | Default RPC URL | [https://sepolia-rollup.arbitrum.io/rpc](https://sepolia-rollup.arbitrum.io/rpc) | | Chain ID | 421614 | | Currency Symbol | ETH | | Block Explorer URL | [https://sepolia.arbiscan.io](https://sepolia.arbiscan.io) | # Orders Source: https://docs.fairground.fi/trading/orders How to place and modify positions ## Placing orders When you place an order, you specify: * **Market** - Which asset to trade * **Direction** - Long or short * **Size** - Position size in notional * **Margin** - how much margin to use * **Leverage** - multiplies your Margin to determine Size (between 1× and the market's maximum) * **Limit Price** (*Optional*) - The worst price at which you're willing to execute. For longs, your order is executable when the oracle price is at or below your threshold. For shorts, at or above. * **Stop Loss / Take Profit** (*Optional*) - Trigger prices for protective close orders attached to your position. You can only have **one open position per market**. Orders either **open** a new position, **increase** an existing one, or **reduce/close** an existing position. When you place an open or increase order, margin is locked and the trading fee is **pre-deducted from your deposited margin** (see [Fees and Rebates](/trading/fees-rebates)). Your order then enters the matching engine and will be filled when it matches with a counterparty. For reduce and close orders, fees are assessed at fill. ## Stop loss and take profit You can protect a position with a **stop loss (SL)** and a **take profit (TP)**: Close orders that trigger automatically when the oracle price reaches the trigger price you set. There are two ways to set them: * **With your order:** Include an SL and/or TP price when placing (or modifying) an open or increase order. The SL/TP orders are created alongside your position and become active once your order starts filling. * **On an existing position:** Add, update, or cancel SL/TP at any time while you have a pending order or an open position. ### Rules * **One SL and one TP per position**: To change a trigger price, update the existing SL/TP order; placing a duplicate is rejected. * **Full position size**: SL/TP orders cover your entire position. If your position size changes (increase, partial fill, partial close), the SL/TP update automatically. * **Trigger prices must be on the correct side of the current price**: | Order | Long position | Short position | | :-------------- | :---------------------- | :---------------------- | | **Stop loss** | Below the current price | Above the current price | | **Take profit** | Above the current price | Below the current price | ### How triggers execute For a long position, the stop loss triggers when the oracle price falls to or below your trigger price, and the take profit triggers when it rises to or above it. For a short position, the directions are mirrored. Once triggered, the order is converted to a **market-style close**: it stays executable even if the price moves back across your trigger, and fills at the oracle price through the normal [order matching](/trading/advanced/order-matching). ### Lifecycle * When your position fully closes, by manual close, stop loss, take profit, or liquidation, any associated SL/TP orders are cancelled automatically. Stop loss and take profit effectively act as one-cancels-the-other. * SL/TP are reduce orders, so trading fees are assessed at fill. Placing, updating, or cancelling them costs nothing beyond gas. * You can cancel or update an SL/TP at any time before it fills. Updated trigger prices are re-validated against the current price. ## Order states Your order moves through these states: | **State** | **Meaning** | | :------------------- | :------------------------------------------------------------------------------------------- | | **Pending** | Order is in the matching engine, waiting to be matched. | | **Partially Filled** | Part of the order has been matched; the rest remains in the matching engine. | | **Fully Filled** | The entire order has been matched. For open orders, this means you now have a full position. | | **Cancelled** | You cancelled the order (or the unfilled portion of a partially filled order). | ## Adding or removing margin You can adjust margin on open positions: **Remove margin:** When your position has excess margin (margin above the minimum required for your leverage), you can withdraw the extra amount. **Add margin:** When your position could use more margin (e.g., to reduce liquidation risk), you can add more. In both cases, your position size, leverage, entry price, and PnL stay the same. Only the margin balance on the position changes. ## Cancelling orders You can cancel any unfilled or partially filled order. When you cancel an open or increase order, your locked margin **and** the pre-deducted fee are returned to you. For partially filled orders, only the margin and fee for the unfilled portion are returned. # Pricing Source: https://docs.fairground.fi/trading/pricing The index price **_is_** the mark price Fairground uses a **single oracle price** for each market. Instead of maintaining a separate mark price for the perpetual and an index price that tracks the underlying asset, the protocol uses only the oracle price. ## Why it matters On most perps protocols, you juggle a mark price (used for liquidations, PnL) and an index price (spot reference, and funding). Fairground simplifies this: **the oracle price is the price**. It is used for everything, order execution, PnL calculation, margin calculations, liquidation, and fee assessment. ## How it updates The oracle price is pulled fresh at the start of each protocol action: matching, liquidation, and ADL. All orders processed within a single matching cycle execute at the same oracle price and as a result, two orders matched in the same block can execute at different prices if the oracle price changes between them.