# GetMarketConfigs Source: https://docs.fairground.fi/api-reference/markets/getmarketconfigs /developers/api-reference/markets.yaml post /market_service.v1.MarketService/GetMarketConfigs Returns the full configuration for one market, resolved by numeric `market_id` or by `market_symbol`. # GetMarketIdByName Source: https://docs.fairground.fi/api-reference/markets/getmarketidbyname /developers/api-reference/markets.yaml post /market_service.v1.MarketService/GetMarketIdByName Returns the numeric `market_id` for a market, looked up by `asset_symbol` and optional `quote_symbol` (for example `BTC`). Use it to turn a market name into the id that other endpoints accept. # GetMarkets Source: https://docs.fairground.fi/api-reference/markets/getmarkets /developers/api-reference/markets.yaml post /market_service.v2.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/markets.yaml post /market_service.v2.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/orderbook.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/orders.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/orders.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. # DeleteApiKey Source: https://docs.fairground.fi/api-reference/permissions/deleteapikey /developers/api-reference/permissions.yaml post /permissions.v1.PermissionService/DeleteApiKey Deletes the API key with the given `id` for `user_address`. Use `ListApiKeys` to find the id. # GenerateApiKey Source: https://docs.fairground.fi/api-reference/permissions/generateapikey /developers/api-reference/permissions.yaml post /permissions.v1.PermissionService/GenerateApiKey Creates a new API key for `user_address`, with an optional `label`. The key value is returned only in this response, so store it securely: `ListApiKeys` returns key ids and labels, not key values. # ListApiKeys Source: https://docs.fairground.fi/api-reference/permissions/listapikeys /developers/api-reference/permissions.yaml post /permissions.v1.PermissionService/ListApiKeys Lists the API keys for `user_address`: each key's `id`, `label`, and creation time. Key values are not returned. # GetPortfolio Source: https://docs.fairground.fi/api-reference/portfolio/getportfolio /developers/api-reference/portfolio.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/positions.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/prices.yaml post /price_service.v2.PriceService/GetHistoricalPrices Returns oracle-price OHLC candles for one market from `start_time` (inclusive) to `end_time` (exclusive). `interval` sets the candle width and defaults to 1 hour. Supports `limit`/`offset` pagination. Only the `market_id` form of the market selector is supported. # GetPrice Source: https://docs.fairground.fi/api-reference/prices/getprice /developers/api-reference/prices.yaml post /price_service.v2.PriceService/GetPrice Returns the current oracle price for one market, with its `market_id`, canonical name (for example "BTC-USD"), and the time the price was printed. Resolved by `market_id` or `market_symbol`. # GetUserFills Source: https://docs.fairground.fi/api-reference/trades/getuserfills /developers/api-reference/trades.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. # 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 eight 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 | | **Permissions** | Generate, list, and delete API keys | | **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 Every request needs an API key, sent as a bearer token in the `Authorization` header. Requests without one return `401 unauthenticated`. To create an API key: **1. Open the Fairground app** Go to [app.fairground.fi](https://app.fairground.fi) and connect your wallet. **2. Open API Keys** Open the **More** tab in the navigation, then select **API Keys**. **3. Generate a key** Create a key and store it somewhere safe. Treat it like a password. ### Example ```bash cURL theme={null} curl -X POST https://api.fairground.fi/market_service.v1.MarketService/GetMarketConfigs \ -H "Authorization: Bearer $FAIRGROUND_API_KEY" \ -H "Content-Type: application/json" \ -d '{"market": {"marketSymbol": {"assetSymbol": "BTC", "quoteSymbol": "PERP"}}}' ``` ```json Response theme={null} { "marketConfig": { "marketId": "1", "marketName": "BTC-USD", "minLeverage": 1, "maxLeverage": 20, "tickDecimals": 1, "sizeDecimals": 8 } } ``` > [!WARNING] > > 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: > **Selecting a market: market\_id vs. market\_symbol** > > 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 addresses** > > Wallet address fields are matched case-insensitively and trimmed of surrounding whitespace > server-side. > **Pagination** > > 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 | | - | - | | `unauthenticated` | Missing or invalid API key in the `Authorization` header | | `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 it if it persists. | # 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 the current oracle 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 the current oracle 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 Fairground 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. > **[API Reference](/developers/api-reference/introduction)** > > 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 returned hex code. > **[Error Selector Reference](/developers/error-selector-reference)** > > Decode on-chain revert reasons from their 4-byte hex. # Use with AI Source: https://docs.fairground.fi/developers/use-with-ai Connect AI assistants and coding tools to the Fairground docs Every page on this site is available to AI tools in plain text, and the docs run an MCP server your assistant can search directly. ## Connect the MCP server The Fairground docs MCP server exposes a `search_fairground` tool that searches every page, including the API reference. | Setting | Value | | - | - | | URL | `https://docs.fairground.fi/mcp` | | Transport | Streamable HTTP | You can also use the page menu at the top of any page to connect Cursor or VS Code, or to copy the MCP server URL. ## Plain-text versions of the docs | Resource | URL | | - | - | | Page index | [`/llms.txt`](https://docs.fairground.fi/llms.txt) | | Full docs, one file | [`/llms-full.txt`](https://docs.fairground.fi/llms-full.txt) | | Any single page | Add `.md` to its URL, for example `/trading/pricing.md` | | OpenAPI spec | [`/developers/api-reference/openapi.yaml`](https://docs.fairground.fi/developers/api-reference/openapi.yaml) | ## Instructions for coding agents Paste this into your agent's instructions file (for example `AGENTS.md` or `CLAUDE.md`) when it works with the Fairground API: ```markdown theme={null} ## Fairground API - Docs: https://docs.fairground.fi (search with the MCP server at https://docs.fairground.fi/mcp) - Every endpoint is a POST with a JSON body (ConnectRPC). Send `Authorization: Bearer `. - Never hard-code or log the API key. Read it from an environment variable. - Fairground is in testnet on Arbitrum Sepolia (chain ID 421614). Testnet funds have no value. - All fills happen at the oracle price. There is no order book matching and no funding rate. - Ask a human before taking any action that moves real funds. ``` # 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 the trader-facing fee and rebate walkthrough, see [Fees and Rebates](/trading/fees-rebates). For deeper protocol behavior, check the links under [Related protocol topics](#related-protocol-topics) at the end. Fairground gives market makers a way to provide liquidity without a time-based fee for traders. Makers provide two-sided depth with **no-rush orders**, receive the **impact fee** from the standard orders they fill against, and collect rebates on the open interest those orders create. The impact fee is designed to offset the adverse selection that comes with filling at a single oracle price. ## No-rush orders Market makers provide liquidity by designating orders as **no-rush orders**. That designation changes matching and fee treatment; it does not change the fill price. All fills still execute at the current oracle price (The latest market price of the underlying asset on spot markets provided by the oracle.). No-rush orders: * Have **no execution price threshold (The worst acceptable fill price. No-rush orders are unrestricted and do not use a threshold.)** (unrestricted, always eligible at the current oracle price) * **Do not trigger matching** when placed, so posting them does not start a matching cycle * Fill only after other orders in the cycle (the residual stage) * **Never fill against other no-rush orders** Size that fills from no-rush orders is tagged as **eligible open interest**. That tagged size is what rebates accrue to. > [!NOTE] > > No-rush orders are an advanced order type. With no price threshold, they fill at whatever the > oracle price is when matching runs, and the maker doesn't control when that happens. Size and > hedge positions accordingly. ## Impact fee The impact fee is the Fairground equivalent of spread on a CLOB. It is paid by **standard orders (Any order that is not a no-rush order. Standard orders trigger matching, fill in the first matching stage, and pay the impact fee.)** (market and limit orders alike) and received by **no-rush orders**: * Standard–no-rush match: the standard order pays, the no-rush order receives * Standard–standard match: both orders pay the impact fee The impact fee rate is determined dynamically from **external** order-book depth: the cost of buying or selling on major venues at the same timestamp as the oracle price. It is quoted for the total standard size filled on each side in a matching cycle. Because fills still happen at a single oracle price, the impact fee is what stops a standard order from capturing that price for free when external markets are offering a worse bid or ask. A well calibrated impact fee addresses the adverse-selection problem of filling at one oracle price. Impact is assessed at fill and scales with size. Splitting an order does not reset depth. Later same-side size pays as if it walked further into the external book. ## Trade fee and no-rush volume discounts Every position change pays a trade fee on notional changed. The rate is set per market and recalculated every 24 hours: it starts at the market's maximum and falls toward its minimum as eligible OI grows. Trade fees on no-rush fills are further discounted based on the wallet's no-rush volume in that market during the previous epoch. See [Fees and Rebates](/trading/fees-rebates#trade-fee) for the details and example rates. Each matched side pays the trade fee. After a match, collected fees are allocated to: * **Rebates** on eligible open interest * The **[insurance fund](/trading/advanced/insurance-fund)** * A **protocol** remainder Impact fees are separate from this split. They transfer from taker orders to no-rush orders when those orders match. ## Rebates Order side still matters for **matching**. It does not drive rebate accounting. Rebates accrue only to eligible size. The protocol keeps a single cumulative rebate index. After each matching cycle, the index increases by that cycle's fee pool divided across all open interest on both sides. Positions earn that increase on their eligible size and realize it on reduce or close. Because the pool is divided across all open interest, eligible positions receive only their share. The portion attributable to non-eligible open interest goes to the insurance fund and protocol. Size that did not come from a no-rush fill does not accrue rebates. > [!NOTE] > > A close does not receive accrual from the same cycle that closes it. New no-rush size that fills > in that cycle snapshots the pre-update index and does pick up the increase. ## How makers typically quote A typical maker strategy on Fairground: * Post large long and short no-rush orders and hold the resulting two-sided open interest to collect rebates * Rely on the impact fee when standard orders fill against that liquidity * Close when volatility is high or when the resulting exposure cannot be hedged Standard orders, market and limit alike, pay the impact fee, much as a taker pays spread and slippage on a CLOB. Market orders still fill promptly most of the time. ## Matching implications Matching still builds a long queue and a short queue by order side (opens and closes that buy vs sell). Within each queue, liquidations, then reduce orders, then increase orders fill first. Remaining opposing standard flow can then fill against no-rush orders, with no-rush reduce orders filling before no-rush increase orders. Leftover no-rush size on both sides stays unfilled. Placing a no-rush order does not start a matching cycle. No-rush orders become eligible the next time matching runs for that market. Matching runs when a standard order is placed, or when a matching transaction is sent. See [Order matching](/trading/advanced/order-matching). ## Related protocol topics * [Fees and Rebates](/trading/fees-rebates) * [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 to 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 4 standing. ## Season 4 Epoch Schedule | Epoch | Start | End | XP distribution | | - | - | - | - | | 1 | Monday, Oct 26, 16:00 UTC | Nov 2, 15:59:59 UTC | Nov 2, around 19:00 UTC | | 2 | Monday, Nov 2, 16:00 UTC | Nov 9, 15:59:59 UTC | Nov 9, around 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 on eligible open interest (size that filled from no-rush orders). * **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 4 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. Rebates from providing no-rush liquidity 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 4 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 by XP earned in the current season, and it resets at the start of each season. Your XP itself is not reset: XP from previous seasons carries forward on your account. The rewards page shows both totals separately: * **All-time XP:** everything you've earned across all seasons * **Current season XP:** what you've earned this season, which sets your leaderboard rank You can also see XP from the most recent epoch, and XP from earlier epochs in the XP Earning History tab. 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 that fills 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://fairground.fi/discord). # 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. Fairground 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, any season, 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, future season 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? Trading fees apply when positions are opened, increased, reduced, or closed. Fairground's fee structure includes two components: * **Trade Fees:** Apply to all orders, with rates that vary based on market conditions and order type. * **Impact Fees:** Apply to Standard Orders and are designed to serve a similar function to spreads on a Central Limit Order Book (CLOB) exchange. Fees vary based on factors such as order size, trade direction, and market activity. Applicable Trade Fees and Impact Fees are displayed separately at Fairground, allowing traders to review estimated costs before placing an order. Eligible positions may also qualify for rebates. For details on fee calculations and how they apply to different order types, see [Fees and Rebates.](/trading/fees-rebates) ### Are there hidden fees or costs without funding rates? No. Fairground's fee structure is designed to provide transparency into trading costs, allowing traders to review estimated Trade Fees and applicable Impact Fees before placing an order. With no periodic funding payments, Fairground simplifies the economics of maintaining a position by reducing the number of cost variables traders need to consider. For more details, see How do trading fees work on Fairground?. ### How do rebates work? Fairground offers rebate opportunities on eligible open interest (OI) generated through No-Rush Orders. Rebates accrue while eligible open interest remains open and are paid when positions are reduced or closed. Rebates only ever add to your balance: they can never be negative. Amounts vary based on market activity, eligible position size, and holding duration, and are not guaranteed. See [No-rush orders](/trading/orders#no-rush-orders) and [Fees and Rebates](/trading/fees-rebates#rebates)for details. ### What is a no-rush order? A no-rush order is an order designated to provide liquidity. It has no execution price threshold (The worst acceptable fill price. No-rush orders are unrestricted and do not use a threshold.), does not trigger matching when placed, fills only after other orders, and never fills against another no-rush order. Size that fills from a no-rush order is eligible for rebates. See [Orders](/trading/orders) and [Fees and Rebates](/trading/fees-rebates). ## Pricing ### Where does the oracle price come from? Fairground uses a proprietary oracle built in-house to determine the market price. The protocol operates on a single oracle price, so there is no separate mark price or index price. ### How often is the oracle price updated? The protocol retrieves the latest oracle price at the start of each protocol action, including matching, liquidation, and ADL. There is no fixed update interval. See [Pricing](/trading/pricing). ### Are fees different for No-rush and Standard Orders? All orders pay a Trade Fee based on the notional value traded, at the market's current rate. However, the fee structure differs by order type: * **Standard Orders:** Pay an Impact Fee in addition to the Trade Fee. When two Standard Orders match against each other, both pay the Impact Fee. * **No-rush Orders:** May qualify for discounted Trade Fees based on the wallet's No-rush trading volume. When matched with a Standard Order, the No-rush Order receives the Impact Fee paid by the Standard Order. Eligible open interest (OI) generated through No-rush Orders can also qualify for rebates. For more details, see [Fees and Rebates](/trading/fees-rebates). ## 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 (The minimum margin that must be maintained to keep a position open; falling below this level triggers liquidation. Equals ½ of the initial margin required at max leverage at the current oracle price (Notional ÷ (2 × Max Leverage)).) 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 reaches your position's liquidation threshold when a keeper submits a liquidation transaction, your position may be liquidated immediately. ### 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 (Buffer fund absorbing losses from liquidations before ADL triggers.). ### Can profitable positions be auto-deleveraged (ADL)? Yes. Auto-deleveraging (ADL) is a last-resort risk management mechanism used when liquidation losses exceed, or are at risk of exceeding, a market's insurance fund budget. In these circumstances, positions on the opposite side of the market may be reduced, including those that are profitable. ## Orders ### How are orders matched? All fills execute at the current oracle price. There is no price priority. Within each side, liquidations fill first, then reduce orders, then increase orders, then no-rush orders (no-rush reduces before no-rush increases). At each level, earlier orders fill first (FIFO). No-rush orders never fill against other no-rush orders. See [Order matching](/trading/advanced/order-matching). ### How is my entry price calculated if my order fills in several parts? 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 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? Yes. Adding margin lowers your leverage and moves your liquidation price further from the current price. Removing margin moves your liquidation price closer to the current price. However, the protocol prevents margin from being removed if doing so would push the position's leverage above the market's maximum leverage at the current oracle price. ### 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? A mobile app is planned for a future release. Updates on availability will be announced through official Fairground channels. # Overview Source: https://docs.fairground.fi/faqs/overview ### What is Fairground? Fairground is a decentralized perpetuals exchange that simplifies the economics of holding a position by removing periodic funding payments. Traders can take leveraged long or short positions across crypto, commodities, and FX markets, with trades executed at a single oracle price. ### What trading strategies does Fairground support? Fairground supports a range of trading strategies where periodic funding payments would otherwise influence the economics of maintaining a position. Examples include: * **Directional Trading:** Take leveraged long or short positions across crypto and real-world markets without reoccurring funding payments. Whether holding a position for a short period or longer, there are no additional funding costs for maintaining it over time. * **Funding Arbitrage:** Use Fairground as one leg of a strategy involving funding rate differences across perpetuals exchanges. Because Fairground does not charge periodic funding payments, traders can maintain exposure without an additional funding payment on the Fairground side. * **Hedging:** Manage or offset market exposure through leveraged long or short positions. With no periodic funding payments, traders can maintain a hedge without recurring funding costs, particularly over longer holding periods. * **Liquidity Provision:** Provide liquidity through [No-rush orders](/trading/orders#no-rush-orders), and order type designed for market makers and experienced traders. Positions filled through No-Rush Orders are eligible to earn rebates based on market activity, position size, and holding duration. # Fairground Referrals Source: https://docs.fairground.fi/faqs/referrals ## Access & Mechanics ### Are referrals open to everyone? No. Referrals are available only to eligible active participants from previous Fairground seasons. Each eligible participant can invite up to two new traders to join Season 4. Newly referred traders cannot extend additional invitations. ### How do I find/access my referral link? Eligible participants can access their personal referral link on the [**Referrals page**](https://app.fairground.fi/421614/referrals) after connecting their registered wallet. Referral details and links are also provided in the Season 4 access email sent to their registered email address. ### Where can I see how many referrals I have remaining? Your [Referrals page](https://app.fairground.fi/421614/referrals) shows how many of your 2 referrals you’ve used and how many remain. Once both 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 4 or until all 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 4. ### 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 4. 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 4 XP total and leaderboard position? Yes. Referral XP is included in your total Season 4 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 4 Source: https://docs.fairground.fi/faqs/season-4 ## Overview ### When does Season 4 run? Season 4 runs from **Monday, October 26, 2026, at 16:00 UTC** through **Monday, November 9, 2026, at 15:59:59 UTC**. It is made up of two one-week epochs: | Epoch | Start | End | | - | - | - | | 1 | Oct 26, 16:00 UTC | Nov 2, 15:59:59 UTC | | 2 | Nov 2, 16:00 UTC | Nov 9, 15:59:59 UTC | The schedule may be adjusted based on testing needs, platform performance, and participant feedback. See the [XP Program](/earn/xp-program#season-4-epoch-schedule) for when XP is distributed. ### 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 every day at 16:00 UTC for trading. Eligible participants are allocated 2,000 Testnet USDC each day at 16:00 UTC. ## Participation + Access Season 4 is open to active traders from previous Fairground seasons, along with new traders who receive a referral invitation. To qualify as an active trader, you must have held or filled at least one order during a previous season. Eligible returning participants can invite up to two new traders to join Fairground. Referral invitations are limited to existing active participants; newly referred traders cannot extend additional invitations. New traders must register through a valid referral link. If selected, they will receive an email from [**access@fairground.fi**](mailto:access@fairground.fi) with access instructions. If you believe you were eligible but did not receive your testnet USDC allocation, please open a support ticket in [Discord](https://fairground.fi/discord) and provide your registered Fairground wallet address. Our team will review your eligibility and look into your daily testnet allocation. ### How do I join Season 4? Participants from previous Fairground seasons can access Season 4 by connecting their previously registered Fairground wallet. New traders can join through a valid referral link shared by an existing participant. Once registered, participants can access Fairground and receive daily testnet USDC to begin trading. ### Is my private data collected? Participation in the testnet requires providing an email address and wallet address, with the option to include social media handles. 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 4 Trading ### What markets are available in Season 4? During Season 4, 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. ### What order types are supported in Season 4? Season 4 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 4 uses Testnet USDC for all trading activity. * For Season 4, 2,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 4 ends? Season 4 marks Fairground's final testnet phase as the exchange prepares for its next chapter. Trading activity, platform performance, and participant feedback will help inform what comes next. Details on Fairground's next phase and future participation opportunities will be announced soon. # Troubleshooting Source: https://docs.fairground.fi/faqs/troubleshooting Common problems and what causes them ### Why was my position liquidated? Your position margin fell below the maintenance margin, so anyone could trigger liquidation. Once liquidation is triggered, the protocol's close order stays open even if the price moves back before it fills. What you get back depends on your position's status when the close fills. See [Liquidation](/trading/advanced/liquidation). ### Why hasn't my order filled? The most common reasons: * **Your price threshold isn't met.** An order can fill only when the current oracle price is within its execution price threshold. Longs need the oracle price at or below your limit; shorts need it at or above. * **The market is closed.** Orders don't fill while their market is closed. See [Trading Hours](/trading-hours). * **There isn't enough opposing flow.** Matching fills one side up to the size of the other. Any unfilled size stays open for the next matching cycle. * **Matching hasn't run yet.** Matching runs when a standard order is placed or a matching transaction is sent. See [Order Matching](/trading/advanced/order-matching). ### Why did my order fill at a different price than I saw when I placed it? Every order fills at the oracle price at the moment its matching cycle runs, which can differ from the price when you placed it. A limit price sets the worst price you will accept. See [Pricing](/trading/pricing). ### Why can't I remove margin? Removing margin can't push the position's leverage above the market's maximum leverage at the current oracle price. Try a smaller amount. ### Why can't I update my position? If liquidation has been triggered for the position, you can no longer update it. The protocol will close it at the next matching cycle. ### What does a hex error code mean? Transactions that revert return a 4-byte error selector, such as `0x6223f681`. Look it up in the [Error Selector Reference](/developers/error-selector-reference). ### Why don't I see my XP yet? XP is calculated after each weekly epoch ends, not in real time. See [XP Program troubleshooting](/earn/xp-program#troubleshooting). # Protocol Overview Source: https://docs.fairground.fi/index Fairground is a perpetuals exchange with no periodic funding payments, built around a single oracle price. Fairground is a decentralized perpetuals exchange on Arbitrum, currently in testnet on Arbitrum Sepolia. It has one oracle price, and fees are charged only when a position changes. There are no funding rates. Experienced liquidity providers can earn rebates with no-rush orders. > **[Get started](/trading/onboarding)** > > Connect a wallet, get testnet USDC and ETH on Arbitrum Sepolia, and start trading. > **[Orders](/trading/orders)** > > Place, cancel, and manage orders. Add or remove margin on positions. > **[Pricing](/trading/pricing)** > > One price per market for execution, PnL, margin, and liquidation, with no mark/index split. > **[Fees & rebates](/trading/fees-rebates)** > > A per-market trade fee that updates daily, plus a dynamic impact fee on market and limit > orders. Liquidity providers can earn rebates with no-rush orders. ## Advanced trading > **[Order matching](/trading/advanced/order-matching)** > > How orders are matched, including no-rush residual fills. > **[Liquidation](/trading/advanced/liquidation)** > > When positions are liquidated and how it works. > **[Insurance fund](/trading/advanced/insurance-fund)** > > Protocol backstop for undercollateralized positions. > **[ADL](/trading/advanced/adl)** > > Auto-deleveraging when liquidation losses threaten a market's insurance fund budget. > **[Glossary](/trading/advanced/glossary)** > > Definitions for protocol terms. ## Earn > **[XP Program](/earn/xp-program)** > > XP program and earn rewards. > **[Market Makers / LPs](/earn/market-makers-lps)** > > Market making and liquidity provisioning. ## Developer Docs > **[Developer Docs](/developers/overview)** > > 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://fairground.fi](https://fairground.fi) / [https://fortefoundation.io/](https://fortefoundation.io/) / [https://forte.io/](https://forte.io/) | | **Trading App** | [https://app.fairground.fi](https://app.fairground.fi) | | **Discord** | [https://fairground.fi/discord](https://fairground.fi/discord) | | **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, commodities, and stocks, and what happens when a market is closed 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) > [!NOTE] > > Stock markets are not currently listed on Fairground. The hours below apply once they are. * **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 > [!NOTE] > > XAU (gold) and XAG (silver) have a 60-minute break each day beginning at 5:00 PM ET. All times are in **US Eastern Time (ET)**. ## When a market is closed Orders do not fill while their market is closed. This applies to orders placed during the closure and to orders already resting when the market closes, including limit, stop loss, and take profit orders. They become eligible to fill again once the market reopens. > [!WARNING] > > Prices can move while a market is closed, so the price at reopen may differ from the last price > before the close. Keep this in mind when setting stop loss and take profit levels on FX and > commodities positions held over a close. # 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 (Buffer fund absorbing losses from liquidations before ADL triggers.) 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 at-risk positions** on the losing side. This includes every position whose margin ratio is below the ADL threshold, even if it still has some margin left. Remaining margin on these positions is not returned. 2. Applies a **pro‑rata reduction** to *all positions on the opposite side* to offset the imbalance, whether or not each position is individually profitable. ### How ADL is applied to opposite-side positions If you’re on the opposite side, your position is reduced by the **same percentage** as everyone else on that side. > [!TIP] > > For example, if the positions being closed total **5% of the open size on the > opposite side**, then **every** position on that side is reduced by about **5%**. > Each reduction is rounded to a valid order size, so an individual position may > be reduced slightly more or less. ## 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 (The latest market price of the underlying asset on spot markets provided by the oracle.)** (or the computed close‑out price in the extreme case). ## Relationship to liquidation * Liquidation closes positions that are below maintenance margin (The minimum margin that must be maintained to keep a position open; falling below this level triggers liquidation. Equals ½ of the initial margin required at max leverage at the current oracle price (Notional ÷ (2 × Max Leverage)).). 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 when that limit is reached, or when a small further price move would push losses past it: 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 | | - | - | | Add Margin | Add capital to a position’s margin. | | Auto-deleveraging (ADL) | A last-resort mechanism that reduces positions on the opposite side of the market to offset losses from liquidations. | | Cancel an Order | Withdraw an unfilled order before execution. | | Close a Position | Offset an existing position entirely, reducing exposure to zero and realizing PnL. | | Closed Position | A position that has been fully offset and realized; no longer open. | | Eligible open interest | Open interest that came from no-rush order fills. Only eligible open interest earns rebates, and each market's average eligible open interest sets its daily base trade fee. Size added to a position with a standard order is not eligible. | | Entry Price | The average execution price at which a position was opened. | | Executable long / short depth | Maximum notional that can be bought (long) or sold (short) immediately: the sum of notionals of all currently executable orders. | | Execution price | The actual price at which an order is filled. | | Execution price threshold | The worst acceptable fill price. No-rush orders are unrestricted and do not use a threshold. | | Exit Price | The average execution price at which a position was closed. | | Fill an Order | Match an order against liquidity, resulting in a fill at the execution price. | | Funding rate | Not applicable on Fairground: we don’t have funding rates because we don’t use a separate price from the oracle price. We may have other types of fees, but they are not called a funding rate. | | Healthy Position | A position where margin > maintenance margin. | | Impact fee | A fee on standard orders, designed to feel like spread on a CLOB. Its rate is quoted from external order-book depth for the total standard size filled on that side in a matching cycle. When a standard order fills against a no-rush order, the standard order pays and the no-rush order receives it. When two standard orders match, both pay. | | Increase (Position) Size | Increase a position’s size (typically via an increase order). | | Initial Margin | Collateral locked when the position is opened. Initial Margin = Value / Leverage. | | Insurance Fund | Buffer fund absorbing losses from liquidations before ADL triggers. | | Isolated margin / cross-position margin | Not applicable on Fairground: we only offer isolated margin, so we don’t distinguish. | | Leverage | A multiplier that allows controlling a larger position than deposited collateral. Leverage is the ratio of initial exposure to initial margin (e.g., 10x, 50x). | | Liquidatable Position | A position that can be liquidated: (2/3) × maintenance margin ≤ position margin \< maintenance margin. | | Liquidation | Forced closure of a position when margin is at risk of not covering losses. | | Liquidation Price | The estimated price at which liquidation will occur: the price below which (or above which for shorts) the position becomes liquidatable. | | Long / short | Going long means buying to profit if price rises. Going short means selling to profit if price falls. | | Long / short Open Interest | Total value (notional) of all open long positions (long OI) or all open short positions (short OI). | | Maintenance Margin | The minimum margin that must be maintained to keep a position open; falling below this level triggers liquidation. Equals ½ of the initial margin required at max leverage at the current oracle price (Notional ÷ (2 × Max Leverage)). | | Maker | A trader who provides liquidity with no-rush orders. Open interest that fills from no-rush orders is eligible for rebates. | | Market | A specific perp contract for a given underlying asset (e.g. BTC-USD). | | Mark Price vs. Index Price | Not applicable on Fairground: we only have the oracle price (no separate mark/index prices). | | Net Contributions | How much a trader has put into a position. Initialized to Initial Margin; decreases when margin is removed and increases when margin is added. | | No-rush order | An order designated to provide liquidity. No-rush orders have no execution price threshold, do not trigger matching, fill only after other orders, and never fill against other no-rush orders. | | Open a Position | Enter into a new exposure: from 0 exposure to x exposure (x can be positive or negative). | | Open Interest | Long open interest + short open interest. | | Open Position | A live position that has not been fully closed. | | Oracle price | The latest market price of the underlying asset on spot markets provided by the oracle. | | Order | Instruction to buy or sell a perp contract under specific conditions. An order may optionally be designated as a no-rush order. | | Order Book | Fairground does not match orders through an order book: every fill happens at the oracle price. Unfilled orders rest until they become executable, and the GetOrderBook API endpoint returns simulated depth of those resting orders. | | (Order) Original Size | The original size of an order when the user first created it. It may differ from current size if the order was partially filled. | | Order Size | The size specified by an order. In the app you can enter it in USDC (notional) or in units of the underlying asset (e.g. 50 JPY) using the toggle in the size field. | | Perp | A perpetual futures contract with no expiry, tracking an underlying asset’s price over time. | | Place an Order | Submit a new order to the system; it becomes an unfilled order. | | PnL | Profit and Loss from a trade. For longs: PnL = (Exit Price − Entry Price) × Position Size. For shorts: PnL = (Entry Price − Exit Price) × Position Size. For unrealized PnL, use current spot/oracle price instead of Exit Price. | | Position | Exposure held after orders are filled. | | Position Margin | Collateral locked to support a position. Position Margin = Net Contributions + System PnL. | | Position Size | The quantity of the underlying asset the position represents (e.g. 50 JPY). | | Position Value (USD) | The notional a position controls: value = price × size. | | Realized / Unrealized PnL | PnL is realized when a position closes or is modified to reduce exposure. PnL is unrealized when a position is open. | | Reduce-only Order | An order that can only reduce an existing position, decreasing exposure. | | Reduce (Position) Size | Reduce a position’s size (typically via a reduce-only order). | | Remove Margin | Remove funds from a position’s margin. | | ROE | Return on Equity (percentage): PnL / margin × 100%. | | Seized Position | A position where position margin \< (2/3) × maintenance margin; remaining margin is treated as forfeit to the Insurance Fund on close. | | Side | The direction of a trade: long or short. | | Slippage | Difference between expected and actual execution price. | | Standard order | Any order that is not a no-rush order. Standard orders trigger matching, fill in the first matching stage, and pay the impact fee. | | Toxic Position | Any position that is not healthy. Toxic = liquidatable + seized + underwater. | | Trader Vault | Holds traders’ margin for all open positions for a market. | | Trigger price | The price at which a take profit or stop loss order becomes executable. Once triggered, it fills at the oracle price. | | Underlying Asset | The base asset the perp tracks (e.g. BTC for BTC-USD). | | Underwater Position | A position where position margin \< 0 (losses exceed margin); the Insurance Fund backstops the deficit. | | Unfilled Order | An order (or part of it) that has not yet been executed. | | Unfilled order depth | Sum of all notionals of unfilled orders (whether executable or not). | | USD | U.S. Dollar, used as the quote currency. | | Volume | Total traded notional over a period of time. | # 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 (Forced closure of a position when margin is at risk of not covering losses.) 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 (A position where position margin \< (2/3) × maintenance margin; remaining margin is treated as forfeit to the Insurance Fund on close.) at fill**: the position’s **remaining margin is forfeited** and sent to the insurance fund. * **Underwater (A position where position margin \< 0 (losses exceed margin); the Insurance Fund backstops the deficit.) 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 a close-out would exceed the market's insurance fund budget, or a small further price move could push it over, [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 collected fees:** After rebates, the remaining fees from each matching cycle are split between the insurance fund and the protocol. Currently all of the remainder goes to the insurance fund (see [Fees and Rebates](/trading/fees-rebates#where-trade-fees-go)). 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 **Position Margin (Collateral locked to support a position. Position Margin = Net Contributions + System PnL.)** (your collateral allocated to that position, plus or minus PnL (Profit and Loss from a trade. For longs: PnL = (Exit Price − Entry Price) × Position Size. For shorts: PnL = (Entry Price − Exit Price) × Position Size. For unrealized PnL, use current spot/oracle price instead of Exit Price.)). As the oracle price moves, your position margin changes in real time and so does your position's health status. The **Maintenance Margin (The minimum margin that must be maintained to keep a position open; falling below this level triggers liquidation. Equals ½ of the initial margin required at max leverage at the current oracle price (Notional ÷ (2 × Max Leverage)).)** 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. | ```mermaid theme={null} flowchart TD H["Healthy
margin above MM"] -->|price moves against you| L["Liquidatable
margin between ⅔ MM and MM"] L -->|keeps moving| S["Seized
margin below ⅔ MM"] S -->|keeps moving| U["Underwater
margin below zero"] L -.->|close fills| R1["You get remaining margin
minus fees"] S -.->|close fills| R2["Remaining margin
goes to Insurance Fund"] U -.->|close fills| R3["Insurance Fund
covers 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 (The worst acceptable fill price. No-rush orders are unrestricted and do not use a 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. > [!NOTE] > > 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 trade fee and impact fee (A fee on standard orders, designed to feel like spread on a CLOB. Its rate is quoted from external order-book depth for the total standard size filled on that side in a matching cycle. When a standard order fills against a no-rush order, the standard order pays and the no-rush order receives it. When two standard orders match, both pay.)** on the liquidation fill (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. ### Calculating your liquidation price For a position opened at entry price `E` with leverage `L`, in a market with maximum leverage `Lmax`, the liquidation price is approximately: ```text theme={null} Long: liquidation price = E × (1 − 1/L) ÷ (1 − 1/(2 × Lmax)) Short: liquidation price = E × (1 + 1/L) ÷ (1 + 1/(2 × Lmax)) ``` This follows from the maintenance margin formula above. It ignores fees and any margin you add or remove after opening, so treat it as an estimate. The app shows the exact value for your position. For example, a 10x BTC long at $50,000 in a market with 20x max leverage has a liquidation price of about $50,000 × 0.9 ÷ 0.975 ≈ **\$46,154**, a 7.7% drop. ### How far price can move before liquidation In a market with 20x max leverage: | Leverage | Long: price drop to liquidation | Short: price rise to liquidation | | - | - | - | | 2x | 48.7% | 46.3% | | 5x | 17.9% | 17.1% | | 10x | 7.7% | 7.3% | | 20x | 2.6% | 2.4% | > **[Insurance Fund](/trading/advanced/insurance-fund)** > > How the protocol covers underwater positions. > **[Auto-deleveraging](/trading/advanced/adl)** > > What happens when the Insurance Fund isn't enough. # 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 latest market price of the underlying asset on spot markets provided by the oracle.)**. The matching process on a market is triggered automatically by two separate scenarios: * A standard order (Any order that is not a no-rush order. Standard orders trigger matching, fill in the first matching stage, and pay the impact fee.) is placed (excludes no-rush orders (An order designated to provide liquidity. No-rush orders have no execution price threshold, do not trigger matching, fill only after other orders, and never fill against other no-rush orders.)) * A matching transaction is sent to the protocol ## How matching works Each time matching is triggered for a market, the algorithm runs through these steps: **1. Collect executable orders** Every unfilled standard order whose execution price threshold (The worst acceptable fill price. No-rush orders are unrestricted and do not use a threshold.) permits execution at the current oracle price is collected. Orders whose threshold is outside that range are skipped this round. **2. Build two queues** 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). **3. Match standard orders** The two queues are filled against each other by total notional value, working down from the top of each queue. This first stage fills liquidations, reduce orders, and increase orders. The smaller side of that flow is filled completely; the larger side is filled up to the same notional. For example, if first-stage long flow totals 1,000 of notional and first-stage short flow totals 500, the short side is fully filled and the first 500 of notional on the long side is filled. **4. Fill remaining flow against no-rush orders** Any leftover size from the first stage can fill against no-rush orders on the opposite side. No-rush orders never fill against other no-rush orders. If both sides still have leftover no-rush size, that size stays 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. ```mermaid theme={null} flowchart TD T["Matching triggered
(standard order placed or matching transaction)"] --> P["Read current oracle price"] P --> C["Collect executable standard orders"] C --> Q["Build long and short queues
liquidations → reduces → increases, FIFO"] Q --> M["Stage 1: fill queues against each other
at the oracle price"] M --> N["Stage 2: fill leftover flow
against no-rush orders"] N --> R["Unfilled size waits for the next 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. No-rush orders are unrestricted and skip that threshold check. 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 next. 4. **No-rush orders:** remaining opposing flow can then fill against no-rush orders. Within this stage, no-rush reduce orders fill before no-rush increase orders. Within each level of priority, orders are filled in time priority (FIFO). The order placed earliest is filled first. No-rush orders never fill against other no-rush orders, even if they sit on opposite sides of the book. > **[Liquidation](/trading/advanced/liquidation)** > > When positions are closed by the protocol. > **[Troubleshooting](/faqs/troubleshooting)** > > Why an order might not fill. # 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. > **[Order matching](/trading/advanced/order-matching)** > > How orders are matched, including no-rush residual fills. > **[Liquidation](/trading/advanced/liquidation)** > > When positions are liquidated and how it works. > **[Insurance fund](/trading/advanced/insurance-fund)** > > Protocol backstop for undercollateralized positions. > **[ADL](/trading/advanced/adl)** > > Auto-deleveraging when liquidation losses threaten a market's insurance fund budget. > **[Glossary](/trading/advanced/glossary)** > > Definitions for protocol terms. # Fees and Rebates Source: https://docs.fairground.fi/trading/fees-rebates Trade fees, impact fees, and rebates Fairground does not use funding rates, and there are no fees for holding a position over time. The only fees positions experience on Fairground are charged when a position changes (open, increase, reduce, close). > [!NOTE] > > These are the Season 4 testnet fee parameters. They may change before mainnet. Every position change pays a **trade fee**. Standard orders (Any order that is not a no-rush order. Standard orders trigger matching, fill in the first matching stage, and pay the impact fee.) (market and limit orders) also pay an **impact fee**. [No-rush orders](/trading/orders#no-rush-orders) pay the trade fee but receive the impact fee instead of paying it. | Fee | Applies to | Range per fill | What sets it | | - | - | - | - | | Trade fee | All orders | From 1 bps up to 5 bps (0.01% - 0.05%) of notional changed | The market's daily base rate | | Impact fee | Standard orders (market, limit) | From 0 bps to 5 bps (0.00% - 0.05%) of notional changed | External market slippage for your fill, set at fill time | For a standard order, your cost on a fill is the trade fee and impact fee added together. No-rush orders never pay an impact fee. The impact fee is how Fairground prices execution. Instead of building spread and slippage into your fill price, every order fills at the oracle price and the impact fee is shown as its own line item, based on what the same trade would cost on major external venues. It applies to limit orders as well as market orders, and the full 5 bps applies only to unusually large fills or very one-sided markets. 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 Every position change incurs a trade fee on the **notional changed**, whether you are opening, increasing, reducing, or closing a position. Standard orders pay the market's base rate. No-rush orders pay the base rate multiplied by a [wallet discount](/trading/fees-rebates#no-rush-wallet-discount). ### Market base rate Each market's base trade fee is between **1 bps (0.01%)** and **5 bps (0.05%)**. It is recalculated every 24 hours from the average eligible open interest (Open interest that came from no-rush order fills. Only eligible open interest earns rebates, and each market's average eligible open interest sets its daily base trade fee. Size added to a position with a standard order is not eligible.) over the previous completed 24-hour period, then held fixed for the next 24 hours: ```text theme={null} if average eligible OI = 0: base rate = 5 bps otherwise: base rate = 1 bps × (OI target / average eligible OI), but never less than 1 bps or more than 5 bps ``` * **Average eligible OI** is the average of no-rush originated long and short open interest, measured in the market's base asset (for example, BTC on the BTC market). * **OI target** is set per market. It is the average eligible OI at which the base rate reaches its minimum. * Until a market has a full 24-hour period of data, it uses the maximum rate. With Season 4's 1 bps minimum and 5 bps maximum, the base rate depends on how close eligible OI is to the market's target: | Average eligible OI, as a share of the market's OI target | Base trade fee (bps) | Base trade fee (%) | | - | - | - | | 0% to 20% | `5` | `0.05%` | | 25% | `4` | `0.04%` | | 50% | `2` | `0.02%` | | 100% or more | `1` | `0.01%` | ### No-rush wallet discount A no-rush order's trade fee is the base rate multiplied by your wallet's discount multiplier. The multiplier is set from your filled no-rush volume in that market during the previous completed discount period (rolling 14 day window, in seconds), and it stays fixed for the current period: the more no-rush volume, the lower the multiplier. It ranges from **1.0** (no discount) down to **0.5** (half the base rate). Standard orders don't get this discount. So a standard order's trade fee is between 1 and 5 bps, and a no-rush order's trade fee can be as low as `1 bps × 0.5 = 0.5 bps` (0.005%). ## Impact fee > [!NOTE] > > The impact fee is separate from the trade fee. Every position change still pays the trade fee. The impact fee reflects the execution cost of trading your size in one direction, similar to the slippage a taker pays on an order book. Every standard order pays it, market and limit alike, when it opens, increases, reduces, or closes a position. It ranges from **0 to 5 bps (0.05%)** of the notional filled. The impact fee is charged separately on the fill. It is **not** built into your execution price. The rate depends on: * **External market slippage:** what it would cost to trade the same size on major external venues at that moment * **Trade direction and fill size:** buys and sells are priced separately, and larger fills pay a higher rate * **Recent same-side volume:** recent standard-order fills on the same side (buys or sells), including your own, raise the rate. Flow on the opposite side doesn't offset it, and the effect fades over time On Fairground, limit orders are standard orders, not maker orders, so they pay the impact fee too. [No-rush orders](/trading/orders#no-rush-orders) are the order type that provides liquidity and receives it. ### Example: how the impact fee is calculated For each market, Fairground gets slippage quotes from major external venues: what it costs, on average, to buy or sell 10,000 USD and 100,000 USD of the asset compared with the oracle price. The two quotes are blended into a rate per dollar traded. Your impact rate is that blended rate applied to your **counted volume**: recent standard-order volume on the same side, plus half of your own fill. Counting half your fill gives the average rate across the fill under this model. Say ETH is at \$2,000 and external venues quote: | Amount bought | Average price | Slippage | | - | - | - | | `$10,000` | `$2,000.40` | `2 bps` | | `$100,000` | `$2,001.60` | `8 bps` | Each quote becomes a rate per 1,000 USD traded: 2 bps spread over 10,000 USD is 0.2 bps per 1,000, and 8 bps over 100,000 USD is 0.08 bps per 1,000. Weighting them equally gives (0.2 + 0.08) ÷ 2 = **0.14 bps for every \$1,000 of counted volume**. Here is what different buy orders would pay: | Your buy order | Recent buy volume | Counted volume | Impact rate | Impact fee | | - | - | - | - | - | | `$10,000` | `$0` | `$5,000` | `0.7 bps` | `$0.70` | | `$10,000` | `$20,000` | `$25,000` | `3.5 bps` | `$3.50` | | `$40,000` | `$0` | `$20,000` | `2.8 bps` | `$11.20` | | `$100,000` | `$0` | `$50,000` | `7 bps`, capped at `5 bps` | `$50.00` | **Recent buy volume** is the market-wide volume of standard-order buys, including fills earlier in the same block. It decays over time, so older fills count for less and the rate falls back as same-side flow slows. Sell orders work the same way, using sell-side quotes and recent sell volume. The quotes above are an example; real quotes move with market conditions. Because recent same-side volume isn't shown in the app, use the impact fee estimate in the [order panel](#fees-in-the-app) to see what your order will pay before you place it. Impact fee is assessed at fill: * When a **standard order** fills against a **no-rush order**, the standard order pays the impact fee and the no-rush order receives it. * When two standard orders fill against each other, both pay the impact fee, and it goes into the fee pool described in [Where trade fees go](#where-trade-fees-go). ## Fees in the app The order panel shows two fee line items before you place an order: * **Trade fee:** an estimate for every order type * **Impact fee:** an estimate of what a market or limit order will pay Both are estimates. The actual fees are set when the order fills. ### When fees are charged * **Open / increase:** The trade fee is estimated and taken along with the margin when the order is placed. At fill time, the execution price (The actual price at which an order is filled.) and fee may have changed from the estimates, and excess value is used for additional collateral for the position. * **Reduce / close:** The trade fee is charged when the order is matched and filled. > [!NOTE] > > If an open/increase order is canceled before fill, the pre-deducted fees (and margin) are > returned. ## Where trade fees go Collected fees include trade fees, and impact fees from matching cycles with standard orders on both sides. Collected trade fees are allocated to: 1. **Rebates** (see the [Rebates](#rebates) section below for how this share is determined) 2. **[Insurance Fund](/trading/advanced/insurance-fund)** 3. **Protocol fees** After the rebates allocation, the remaining collected fees are split between the IF and the protocol according to a single parameter. In this initial phase, this parameter is set to send all remaining collected fees to the IF. ## Rebates Rebates offer an additional benefit to traders who provide liquidity through No-rush Orders. Eligible open interest (OI) generated from[no-rush order](/trading/orders#no-rush-orders)fills can accrue rebates while positions remain open. No-rush Orders are an advanced order type designed for market makers and experienced liquidity providers: they trade price control and fill timing for receiving the impact fee and earning rebates. Rebates are funded by a pool of value collected each matching cycle, made up of trade fees, plus any impact fees from two standard orders matching each other. That pool is divided across all open interest in the market, but only eligible open interest (the portion that came from no-rush order fills) actually receives a share. The rest funds the Insurance Fund and protocol fees. Two factors drive how much you earn: * How much trading activity the market sees: more volume means a bigger pool of rebates that cycle. * How much eligible OI you hold, and for how long: your rebate accrues continuously on your eligible size and is paid out when you reduce or close. Note: only the portion of a position that came from a no-rush order fill is eligible. If you increase an existing position with a standard order, the added size is not eligible. If you partially close a mixed position, the eligible and non-eligible portions shrink proportionally. ## What rebates are not * Rebates are not funding payments and do not create periodic holding costs. * You never pay an additional "negative rebate" beyond the trade fee and, when applicable, the impact fee. * A placed order is not guaranteed to earn rebates. Rebate accrual depends on filled no-rush size remaining as open interest and later matching cycles. # Onboarding Source: https://docs.fairground.fi/trading/onboarding Get set up to trade on Fairground All you need to trade is a wallet. Fairground runs on Arbitrum Sepolia (testnet), and eligible wallets receive testnet USDC and ETH automatically, so you don't need to bring your own funds. ## 1. Get access Season 4 is open to: * **Active traders from previous seasons.** Connect the wallet you registered with in an earlier season. * **New traders with a referral link.** Ask an active trader from a previous season for a referral link and register through it. See the [Season 4 FAQ](/faqs/season-4#participation-+-access) for who qualifies as an active trader and how referrals work. ## 2. Connect your 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 Once you have access, your wallet receives enough testnet ETH to pay gas fees and test USDC to use as collateral for opening positions in the app. Your wallet will be granted additional test USDC every day at 16:00 UTC 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](https://mintcdn.com/fortedex/bEEyrvt9OPGAwDnA/images/add-arbitrum-sepolia-network.jpg?fit=max\&auto=format\&n=bEEyrvt9OPGAwDnA\&q=85\&s=592413fc5e44f6a296c181723e32a23c) 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, entered in USDC (notional) or in units of the underlying asset. Use the toggle in the size field to switch. * **Margin** - how much margin to use * **Leverage** - multiplies your Margin to determine Size (between 1× and the market's maximum) * **Order type** - [Market, limit, or no-rush](#order-types) * **Limit Price** (*Limit orders only*) - 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 limit. 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 and [fees](/trading/fees-rebates) are then held until the order is filled. If the order is cancelled before it is filled, margin and fees are returned to the trader. For reduce or close orders, fees are assessed and deducted from the position value released by each fill. The amount remaining is returned to the trader. ## Order types Fairground has three order types. Market and limit orders are both standard orders (Any order that is not a no-rush order. Standard orders trigger matching, fill in the first matching stage, and pay the impact fee.); no-rush orders are an advanced order type for providing liquidity. Every fill, whatever the order type, executes at the current oracle price (The latest market price of the underlying asset on spot markets provided by the oracle.). | | Market order | Limit order | No-rush order | | - | - | - | - | | **Fills when** | The next matching cycle | The oracle price is at or better than your limit price | Opposing standard flow is left after standard orders fill | | **Fill price** | Oracle price | Oracle price | Oracle price | | **Triggers matching** | Yes | Yes | No | | **Trade fee** | Yes | Yes | Yes | | **Impact fee** | Pays | Pays | Receives, from standard orders it fills against | | **Earns rebates** | No | No | Yes, on the open interest it creates | See [Fees and Rebates](/trading/fees-rebates) for fee ranges and how each fee is set. ### Market orders A market order has no limit price. It triggers matching when placed and fills at the oracle price in that matching cycle, as far as opposing flow allows. Any unfilled size stays open for later cycles. ### Limit orders A limit order sets the worst price you'll accept, its execution price threshold (The worst acceptable fill price. No-rush orders are unrestricted and do not use a threshold.). It fills only while the oracle price is at or below your limit (longs) or at or above it (shorts), and it fills **at the oracle price**, not at your limit price. If the price isn't within your limit, the order waits for a later matching cycle. ### No-rush orders A no-rush order is an advanced order type for market makers and experienced liquidity providers. It provides liquidity to standard orders. In the app, no-rush is a separate order type. * No-rush orders have **no execution price threshold**, so they can fill at whatever the oracle price is when matching runs. * Placing a no-rush order does **not** trigger matching. It fills the next time a standard order or a matching transaction triggers a cycle. * During a matching cycle, no-rush orders fill only after standard orders have filled against each other, and they **never fill against other no-rush orders**. * No-rush orders pay the trade fee but don't pay an impact fee (A fee on standard orders, designed to feel like spread on a CLOB. Its rate is quoted from external order-book depth for the total standard size filled on that side in a matching cycle. When a standard order fills against a no-rush order, the standard order pays and the no-rush order receives it. When two standard orders match, both pay.). Instead, they receive the impact fee from the standard orders they fill against. * Open interest created by a no-rush fill is eligible for [rebates](/trading/fees-rebates#rebates). > [!WARNING] > > No-rush orders trade price control for fee and rebate benefits. With no limit price, a no-rush > order fills at whatever the oracle price is when matching runs, and you don't control when, or > whether, it fills. Rebates then depend on later market activity. Use no-rush orders if you can > actively manage and hedge the resulting position. The order panel shows the no-rush liquidity waiting on each side of the market, and the positions table shows how much of each position is eligible for rebates. See [Order matching](/trading/advanced/order-matching) and [Market makers / LPs](/earn/market-makers-lps). ## 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 (The price at which a take profit or stop loss order becomes executable. Once triggered, it fills at the oracle 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. Other pending orders in that market are not cancelled, and any position they open later has no SL/TP until you set one. * SL/TP are reduce orders, so trade 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:** You can withdraw margin as long as the position's leverage afterward, at the current oracle price, stays at or below the market's maximum leverage. **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. # PnL Source: https://docs.fairground.fi/trading/pnl How Segment PnL and Lifetime PnL are calculated ## 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. > **Segment & Lifetime PnL math** > > A position's *current value* is its margin plus unrealized PnL (PnL is realized when a position closes or is modified to reduce exposure. PnL is unrealized when a position is open.) 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 (The average execution price at which a position was opened.) and $P_{\mathrm{now}}$ is the current oracle 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`. **1. Price rises 2% to $102 → position value $1,200** 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%)` **2. Add $300 margin → position value $1,500** 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%)` **3. Price rises to $105 → position value $1,800** 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%)`. **4. Position is closed at \$1,800** `$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%)` # Pricing Source: https://docs.fairground.fi/trading/pricing How orders use the oracle price, and how bad prices are handled Fairground uses a **single oracle price** for each market. Instead of maintaining a separate mark price (Not applicable on Fairground: we only have the oracle price (no separate mark/index prices).) 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 (Not applicable on Fairground: we don’t have funding rates because we don’t use a separate price from the oracle price. We may have other types of fees, but they are not called a funding rate.)). Fairground simplifies this: **the oracle price is the price**. It is used for everything: order execution, PnL calculation, margin calculations, liquidation, and fee assessment. Because every position is valued at this one price, its accuracy matters more than anything else on the exchange. A single bad price could liquidate positions at a level the real market never reached. The rest of this page explains how your orders use the price and how Fairground guards against bad prices. > [!NOTE] > > We'll share more about how Fairground sources and verifies its prices as we approach mainnet. ## How your order uses the price Every order fills at the oracle price at the moment its [matching cycle](/trading/advanced/order-matching) runs: * **One price per cycle.** The protocol reads a fresh oracle price at the start of each protocol action: matching, liquidation, and ADL (A last-resort mechanism that reduces positions on the opposite side of the market to offset losses from liquidations.). All orders filled in the same matching cycle execute at that same price. * **The price you see can differ from your fill price.** The app shows the latest oracle price, but your order fills at the price read when matching runs. If the price moves in between, your fill reflects the new price. * **Your limit price sets the worst price you'll accept.** An order fills only while the oracle price is within its execution price threshold. Longs need the oracle price at or below the threshold; shorts need it at or above. * **Matching runs on activity.** Matching runs when a standard order is placed or a matching transaction is sent, so a resting order fills at the next cycle where its threshold is met. * **Orders don't fill while a market is closed.** FX and commodities follow their underlying [trading hours](/trading-hours), and the price can gap between the close and the reopen. Because every order fills at the oracle price, execution cost is shown separately: market and limit orders pay an [impact fee](/trading/fees-rebates#impact-fee) based on what the same trade would cost on major external venues. ## Price safeguards Every market data feed occasionally produces bad prices: sudden spikes that reverse within milliseconds, feeds that fall behind the market, and feeds that stop updating. When a price can't be trusted, Fairground stops trading that market rather than letting anyone trade, or be liquidated, at that price. | Safeguard | What it does | Status | | - | - | - | | **Stale price halt** | If a market's price hasn't updated within its staleness limit, the market becomes untradeable until a fresh price arrives. | Live | | **Spike halt** | A price that moves more than a set distance in a single update is not published, and trading on that market halts. Limits are set per market and can vary by time of day. If the price returns to its pre-spike level, trading resumes automatically; otherwise the market reopens after a manual review, which can include checking the price against other sources. | Rolling out before mainnet | | **Reference cross-check** | Each market's primary price is compared against an independent reference feed to catch prices that drift away from the market. | Rolling out before mainnet | | **Tiered signing keys** | Normal price updates are signed with standard keys. Unusually large moves must be signed with a separate key held in a hardware-backed key service, where the private key can't be exported. A stolen standard key can't be used to push an extreme fake price. | Rolling out before mainnet | > [!NOTE] > > Halting a market is a deliberate trade-off: a short pause is better for traders than fills, > margin calls, or liquidations at a price that never existed in the real market. > **[Order Matching](/trading/advanced/order-matching)** > > How orders fill at the oracle price. > **[Fees and Rebates](/trading/fees-rebates)** > > What you pay when a position changes.