> 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, markouts and intra-spread volume are measured from tick-level trades and order books, 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. We record these ourselves. Our collector subscribes to an exchange's public WebSocket feeds and records every trade and every order book change, 24/7, and the metrics are built from that recording. Nothing needs to be exported or hosted on your side: what we need is a feed we can record, and the details below that make it record correctly. If your exchange page shows these metrics as unavailable, your feeds are not in the collector yet, or a market has less than 72 hours of recording. Recording cannot be backfilled, so a market's history starts on the day we start recording it. **What to send:** links to your WebSocket and REST API documentation. That is enough to start. [For your developers](#for-your-developers) below is the technical detail: the more of it your docs or your team answer up front, the faster the integration is built. ### How a feed is checked before it goes live Every feed is validated live before its metrics are published. The book we maintain has to match your REST book, recover from every gap with a fresh snapshot, and stay uncrossed; the reported trade side has to behave like the taker's; and a full day of recorded trade notional has to land on the volume your own candles report for that day. Anything that does not match comes back to you as a question rather than going live. {% hint style="info" %} A market becomes rankable on its third full day of recording, because execution metrics need 72 hours of coverage. The sooner the feed is in the collector, the sooner your exchange is measured. {% endhint %} ### For your developers #### What the feeds need to carry | Feed | What we read | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Order book | Price levels with absolute sizes, a full snapshot to start from, then incremental updates. Either a snapshot on subscribe, or a REST snapshot the update stream can be applied on top of | | Trades | Every fill: price, size, timestamp in milliseconds or finer, a trade id, and the **taker's** side | | Ticker, perpetuals | Mark and index price, funding rate and next funding time, open interest. A REST endpoint is fine where the WebSocket does not carry them | | Top of book, REST | One light call returning best bid and ask, which we use to cross-check the book we maintain | #### What to tell us Venue documentation is wrong or silent on at least one of these more often than not, and each one has broken a real integration. One line per question saves a week: | Question | Why it matters | | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | | **Sequencing**: which field chains one book update to the next, and exactly what makes two updates consecutive? Is the counter per market or per connection? | It is the only proof that no update was lost. Without it a book can drift silently | | **Checksum**: is there one, and does it actually compute rather than sit at a constant? | A constant checksum checks nothing | | **Re-snapshot**: how do we get a fresh book for one market without dropping the connection? | Recovery after a gap, without disturbing every other market on that connection | | **Snapshot depth**: how many levels does a snapshot carry, and does any channel resend the whole book on every push? | A channel that resends the full book every update can be too heavy to record | | **Trade side**: is the side reported the taker's or the maker's? | A maker-side feed signs every trade backwards, which inverts slippage and markouts | | **Trade replay**: does subscribing replay recent trades, how many, and how are they marked? | Replayed trades are how fills missed during a reconnect are recovered, and must not be counted twice | | **Timestamps**: exchange time in milliseconds, or coarser? | Fills are priced against the book standing at that millisecond | | **Units**: are book and trade sizes in coins or contracts, and what is the contract size? | The same thousand-fold problem as in section 1 | | **Funding and open interest**: is funding a fraction or a percentage? Is open interest in base, quote or contracts, and one-sided or long plus short? | Both are published as they arrive, so the unit has to be known | | **Per-connection caps**: subscriptions per connection, streams per subscribe message, frame size | A cap past which extra subscriptions are silently ignored leaves markets without a book | | **Client message rate**: frames per second a client may send, and do pings count? | Subscribe bursts and recovery passes get a connection dropped | | **Keepalive**: who pings, how often, the exact ping and pong format, and how fast an idle connection is closed | A wrong interval looks like a flaky venue | | **Connection rate**: handshakes per second, and any penalty for reconnecting quickly | Reconnect bursts can earn refused handshakes or a penalty window | | **REST limits and errors**: per-IP limits, per endpoint if weighted, and does an error come back as an HTTP status or as a 200 with an error in the body? | A 200 carrying an error looks like success | | **Access**: does the handshake need any headers, an API key, or an allowlisted IP? | Some feeds refuse connections without a User-Agent | Answers can sit in your docs, in a short note alongside the links, or come straight from your developers. Example payloads for a book snapshot, a book update and a trade, copied from the live feed, answer most of these at once. *** ## Get in touch Send your API documentation, including your WebSocket docs if you want execution metrics, 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.