How to list an exchange
Exchanges on the Exchanges dashboard 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.
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.
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:
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:
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:
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.
What happens next
We build the integration against your public API.
We reconcile our computed volume and open interest against your own published figures, and come back to you with anything that does not match.
Your exchange information is authored from whatever you send, with sources and dates.
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.
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 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.
For your developers
What the feeds need to carry
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:
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. API documentation alone is enough to start.
Last updated
Was this helpful?