> For the complete documentation index, see [llms.txt](https://docs.llama.fi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.llama.fi/exchanges/list-your-exchange.md). # How to list an exchange Exchanges on the [Exchanges dashboard](https://defillama.com/exchanges) are integrated by the DefiLlama team from each exchange's public API. There is no adapter to write and nothing to push to us. Send your API documentation and we do the integration. Listing is free and applies to both centralized and decentralized exchanges. *** ## 1. Market data (required) Tell us which segments you run: **spot**, **USD-margined perpetuals**, **coin-margined perpetuals**. Each is tracked separately, because settlement, fees, leverage and order books differ between them. | Endpoint | Spot | Perpetuals | What we read | | ------------- | :--: | :--------: | --------------------------------------------------------------------------------------------------------------------------------- | | Markets list | Yes | Yes | Symbol, base and quote asset, status, contract size, tick and step size, and where available max leverage and your own fee fields | | Candles | Yes | Yes | Open, high, low, close and volume, daily and hourly, with as much history as you keep | | Order book | Yes | Yes | Full ladder, or at least around 100 levels per side | | Open interest | n/a | Yes | Current value, plus history if you keep it | | Funding | n/a | Yes | Current rate, next funding time, funding interval, mark and index price, plus history | Only the markets list and candles are required. Everything else is optional: we integrate what you publish and skip what you do not, and a missing endpoint is never held against you. It also helps to know how far back your candles go, whether daily candles follow UTC days, your rate limits, and whether anything needs an API key. A typical set of responses, for shape. Field names do not matter, the content does: ``` GET /markets { "symbol": "BTC-USD", "base": "BTC", "quote": "USD", "status": "active", "contract_size": 1, "tick_size": 0.1, "step_size": 0.00001, "max_leverage": 20, "funding_interval": "1h", "maker_fee": 0.000125, "taker_fee": 0.0004 } GET /klines?symbol=BTC-USD&interval=1d&start=…&end=… [ 1789430400000, "75649", "76060", "75300", "75811", "23.57662", 1787 ] open time (ms), open, high, low, close, volume, trade count GET /open-interest?symbol=BTC-USD { "open_interest": "128.93871", "open_interest_usd": "9772000" } GET /funding?symbol=BTC-USD { "funding_rate": "0.0000125", "next_funding_time": 1789552800000, "mark_price": "75782", "index_price": "75802" } GET /orderbook?symbol=BTC-USD&depth=100 { "bids": [["75808","0.04205"], ["75800","0.18986"]], "asks": [["75809","0.09306"], ["75810","0.02828"]] } ``` ### Units This is the one part that reliably causes problems, and it cannot be detected from the data alone, because a price and a size that are scaled the same way still multiply out to a total that looks correct. Please state: * **Volume**: is it in the base asset, the quote asset, contract count, or USD? * **Price**: is it per unit of the base asset, or per contract? If per contract, what is the contract size? * **Open interest**: same question, and is it one-sided or long plus short combined? * **Volume convention**: one-sided, or both sides of each trade summed? * **Order book sizes**: base asset or contracts? * **Timestamps**: UTC, and is a candle stamped at its open or its close? Why it matters, using the candle above. If that volume of `23.57662` is in BTC, the day is worth `23.57662 × 75,811 = $1.79M`. If it is a count of contracts worth 0.001 BTC each, the same day is worth `$1,787`. Both are plausible figures for a real exchange, and nothing in the response distinguishes them, so one sentence from you removes a thousand-fold error. *** ## 2. Exchange information (optional) Market data alone is enough to be listed. This section fills in your profile page, and can be sent at any time, including long after your market data is live. It is also how you correct anything already published about your exchange. Availability, fees and products differ by country, so most of it is recorded **per region** rather than as one global answer. A region means any market you run under its own rulebook: a separate licence, entity, fee schedule, or product carve-out. If your terms are identical across a whole area, one entry covers it. | Group | What we record | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identity | Legal entities you operate through and the country of each, founding year, headquarters, and a native or fee-discount token if you have one | | Links | Website, mobile apps, official social accounts, and a supported-countries page we can link to | | Availability (per region) | Available, restricted or unavailable, the countries a region covers, and any excluded countries inside it | | Regulation (per region) | Operating entity and country, licences held with regulator, licence type, licence ID and date granted, whether a licence is passported, which services it authorises, and a register link | | Products (per region) | Which of spot, margin, perpetuals, dated futures, options, convert, earn, staking or card are offered, and which are explicitly not offered | | Trading fees | Base maker and taker fees, or your spread if you are a broker, plus VIP tiers and what qualifies for each, and any discount for holding or staking a token | | KYC and limits (per region) | Verification levels and what each unlocks, deposit and withdrawal limits per level, and the thresholds that trigger source-of-funds checks | | Fiat on-ramp | Currencies supported, and the deposit fee for each method and currency, including bank transfer, card and mobile wallets. Please flag fees charged by a third-party processor, and name it | | Fiat off-ramp | Withdrawal fee per method and currency, whether it is a percentage or a flat fee, and any minimum or cap | | Crypto rails | Networks supported per asset, whether withdrawal fees are passed at cost or marked up, and a typical value for a major asset | | Security | 2FA methods, withdrawal address whitelist, anti-phishing code, cold storage arrangements, insurance or reserve fund and its size, and any proof-of-reserves or third-party audit with a link | | Markets and products | How many assets and trading pairs users can trade | | Promotions | Any current sign-up or deposit offer, with a terms link and start and end dates | Everything here is published with a public source link and dated to the month it was verified, so a link to your fees page, help centre or licence register alongside each answer is ideal. We can send a short form covering all of the above if that is easier than writing it out. Three regions, filled in. Note that a region is only worth its own entry when something about it actually differs: ``` Region: EEA, excluding the Netherlands Status: available Entity: Example Europe UAB (Lithuania) Licence: MiCA CASP, licence 12345, granted 2025-03, passported to all EEA Products: spot, perpetuals. Not offered here: margin, options KYC: L1 ID and selfie unlocks trading and withdrawals L2 proof of address raises the daily withdrawal limit to EUR 100k Fees: standard schedule, quoted in EUR Note: the Netherlands is excluded pending local registration Source: https://example.com/fees, https://example.com/licences (2026-09) Region: United Kingdom Status: restricted Entity: Example UK Ltd, FCA registered cryptoasset firm, FRN 987654 Products: spot only. Perpetuals are not offered to UK retail customers KYC: same levels as EEA, plus an appropriateness assessment at signup Fiat in: Faster Payments free, card not available Source: https://example.com/uk (2026-09) Region: United States Status: unavailable Note: not served. US persons are blocked at signup and by IP address Source: https://example.com/terms (2026-09) ``` ### Fiat ramps The detail that matters is per currency and per method, in both directions, and who actually charges the fee. Free rails are worth stating explicitly rather than leaving blank: | Currency | Method | Deposit | Withdrawal | Notes | | -------- | --------------- | ----------- | ------------- | --------------------------------- | | EUR | SEPA | Free | EUR 1.00 flat | Minimum EUR 10 | | EUR | SEPA Instant | Free | EUR 1.50 flat | | | EUR | Card, Apple Pay | 1.80% | Not available | Charged by Processor X, not by us | | GBP | Faster Payments | Free | GBP 0.50 flat | UK entity only | | USD | Wire | USD 10 flat | USD 25 flat | Correspondent bank fees may apply | ### Crypto ramps Per asset and per network, with withdrawal fees as the number a user is actually charged, and whether that number is the network cost or includes a markup: | Asset | Network | Deposit | Withdrawal | Priced | | ----- | -------- | ------- | ----------- | --------------------- | | BTC | Bitcoin | Free | 0.00004 BTC | At cost, floating | | ETH | Ethereum | Free | 0.0012 ETH | At cost, floating | | ETH | Arbitrum | Free | 0.0001 ETH | Flat | | USDT | Ethereum | Free | 3.50 USDT | Flat, includes markup | | USDT | Tron | Free | 1.00 USDT | Flat | If a network is deposit-only, withdrawal-only, or temporarily suspended, say so on the row. The same applies to any asset where deposits carry a minimum or a confirmation count that is unusually high. {% hint style="info" %} Reserves shown on the [rankings page](https://defillama.com/exchanges/rank) are read from public evidence rather than submitted. For a centralized exchange that means live on-chain wallets, audited financials or a published attestation. For a decentralized exchange it is read on-chain. Sending us the wallet addresses or contracts holding customer assets, and flagging any part held in your own token, is the most useful thing you can do to make that figure accurate. {% endhint %} *** ## What happens next 1. We build the integration against your public API. 2. We reconcile our computed volume and open interest against your own published figures, and come back to you with anything that does not match. 3. Your exchange information is authored from whatever you send, with sources and dates. 4. The exchange goes live on the dashboard and updates automatically from then on. History is backfilled as far as your API allows, so most exchanges arrive with their full trading history rather than starting from the listing date. {% hint style="info" %} We do not accept submitted volume, open interest or depth figures. Everything published is computed from data we collect ourselves, which is what makes exchanges comparable on the dashboard. {% endhint %} *** ## 3. Execution quality data (optional, but needed for execution metrics) Cost to trade, spread, slippage and markouts are measured from tick-level trades and order book snapshots, never taken from an exchange's own figures. Exchanges are listed and ranked without them, and they can be added at any time after listing. If your exchange page shows these metrics as unavailable, this is why: we do not have a tick-level source for you yet. We track around 30,000 markets, so we do not run our own live collectors against every venue's WebSocket. Instead we read the data from files the exchange publishes, the same way we read candles. The requirements are short: * **Daily files**, one per market per UTC day, at a public URL with a predictable path. Gzipped CSV or JSON lines, whatever your pipeline already writes. * **At least the last 7 days** available at any time. More history is welcome and is backfilled. * **Up to one day of delay is fine.** Yesterday's file appearing today is enough. * A REST endpoint that serves the same daily files works just as well as a static bucket. A live WebSocket alone is not enough on its own, because history cannot be recovered from a live feed and we do not record feeds ourselves. If a WebSocket is all you have today, recording it into daily files on your side is a small job and is exactly what a few exchanges already do for us. Two datasets are needed, per market, per UTC day. **Trades.** One row per fill: timestamp in milliseconds or finer, price, quantity, and the taker's side. The side is the field that matters most, because without it a fill cannot be signed as a buy or a sell. Binance publishes this archive in exactly the right shape: [data.binance.vision/?prefix=data/futures/um/daily/trades/](https://data.binance.vision/?prefix=data/futures/um/daily/trades/) ```csv timestamp,trade_id,price,quantity,side 1789554918924,8463277428070451,75908.0,0.00076,sell 1789554918894,8463277428070452,75909.0,0.00076,buy 1789554860625,8463277428070453,75911.0,0.01318,buy ``` **Order book snapshots.** Top 25 levels per side, emitted on every book change or on a fixed interval of 500ms or faster. A steady 100ms snapshot is as usable as an event-driven feed. One snapshot, best price first on each side, sizes per level and not cumulative. Levels 4 to 24 are omitted here only for brevity: ```csv timestamp,side,level,price,quantity 1789555030600,bid,0,75808,0.04205 1789555030600,bid,1,75800,0.18986 1789555030600,bid,2,75797,0.15706 1789555030600,bid,3,75794,0.99140 1789555030600,ask,0,75809,0.09306 1789555030600,ask,1,75810,0.02828 1789555030600,ask,2,75815,0.23544 1789555030600,ask,3,75816,0.33463 ``` Every row of one snapshot carries the same timestamp, and the next snapshot repeats the full ladder rather than sending only what changed. A JSON-per-line form with `bids` and `asks` arrays works equally well, as does an incremental feed with periodic full snapshots. Whatever your pipeline already emits is almost certainly fine, we adapt to the format. {% hint style="warning" %} Binance also publishes a file named `bookDepth`, which is **not** per-tick book data and cannot be used for these metrics. It records cumulative depth at fixed percentages of mid price, sampled roughly every 30 seconds. Realized slippage needs the mid price standing at the millisecond of the fill, predicted slippage needs individual price levels to walk, and a one-second markout cannot be resolved at 30-second sampling. That kind of file is useful for depth charts, so send it if you have it, but it does not replace the snapshots above. {% endhint %} Delivery is the daily-file arrangement described at the top of this section: a predictable public path per market and day, the last 7 days always present, up to one day late. The sooner the files start, the more history your exchange has, because days before the first file cannot be recovered. The same unit questions from section 1 apply here, and if full depth is hard to export, best bid and ask at tick resolution alongside trades is a useful halfway point that still yields effective spread, realized slippage and markouts. *** ## Get in touch Send your API documentation and the segments you want tracked to the DefiLlama team through any of the contact channels listed on [defillama.com](https://defillama.com). API documentation alone is enough to start.