---
title: "Centralised Exchanges"
book: "Markets III: Commodities, Energy and Crypto"
subject: quant
language: en
chapter: 15
exercises: 8
source: https://one-course.com/books/quant/3/en/chapter/15-centralised-exchanges
---

# Chapter 15 — Centralised Exchanges

In the week that began on 6 November 2022 the customers of one of the largest crypto exchanges withdrew seven billion dollars from it. On 8 November it paused all customer withdrawals; on 11 November it filed for bankruptcy. Its customers had thought of it as a venue: a place where their orders met other orders. They learned that it had also been their broker, holding their accounts; their custodian, holding their coins; their clearing house, guaranteeing their trades and liquidating their leveraged positions; and, through an affiliated trading firm that could borrow from the exchange without limit, the counterparty that had spent their money. Crypto trading happens mostly on such venues. This chapter describes what a [centralised exchange](#def-m3-centralised-exchanges-cex) is, how a trading firm connects to one and pays for it, and what the firm is exposed to while its assets sit there: the risk that the venue is not what it says, what proofs of reserves can and cannot establish, and the settlement arrangements built to keep a firm’s collateral out of the venue’s hands.

## 15.1 The exchange that is also broker, custodian and clearing house

In the equity and futures markets of One Quant Book 1, a trade passes through separate institutions, each regulated for its role: a broker holds the client’s account and routes its orders (chapter 4), the exchange matches them, a central counterparty guarantees the trade and collects margin, and a custodian or settlement system holds the securities and the cash (chapter 5). Each has its own capital, its own supervisor and its own rules on what it may do with client assets.

**Definition 15.1 (Centralised exchange).**

A *centralised exchange* is a crypto trading venue run by a company that holds its customers’ assets in wallets and bank accounts it controls, keeps their balances in its own internal ledger, matches their orders on its own order book, and settles trades by changing that ledger rather than on a [blockchain](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-chain).

Only deposits and withdrawals touch a chain. A customer who sends bitcoin to the exchange gives up the coins in exchange for a line in the venue’s database; every trade after that moves numbers between lines, and only a withdrawal turns a line back into coins. The same company performs the four roles of the traditional chain, and usually more: it lends to customers who trade with leverage, runs the liquidation engine that closes their positions ([Chapter 18](https://one-course.com/books/quant/3/en/chapter/18-margin-liquidation-and-loss-allocation#ch-m3-margin-liquidation-and-loss-allocation)), issues its own [token](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key), and may operate a trading arm or be affiliated with one.

![In regulated securities and futures markets separate institutions hold the account, match the order, guarantee the trade and hold the assets; a centralised crypto exchange does all of it inside one company, whose internal ledger is the only record of who owns what. Schematic.](https://one-course.com/images/onecourse/chapters/quant-3/m3-centralised-exchanges/fig-999c6cfc6c65.svg)

***Figure 15.1.** In regulated securities and futures markets separate institutions hold the account, match the order, guarantee the trade and hold the assets; a centralised crypto exchange does all of it inside one company, whose internal ledger is the only record of who owns what. Schematic.*

**Definition 15.2 (Customer asset segregation).**

*Customer asset segregation* is the separation of assets held for customers from the holder’s own assets, in distinct accounts or wallets and under legal terms that keep them out of the holder’s estate if it fails, so that they cannot be used for its own purposes and return to the customers in an insolvency.

Segregation is what makes a broker’s or a futures commission merchant’s failure survivable for its clients. On a [centralised exchange](#def-m3-centralised-exchanges-cex) it depends on the venue’s terms of service, on the law of the country where it is incorporated, and on its honesty. Where the terms or the law are silent, a customer’s balance is an unsecured claim on the company, and the coins the venue holds belong to its creditors as a whole.

For a trading firm, the practical consequence is that a balance on an exchange is a credit exposure to that exchange, of the full amount, for as long as it sits there. The firm sets limits per venue, as a bank sets limits per counterparty, and measures what it would lose, and how fast it could withdraw, if the venue stopped paying.

## 15.2 Accounts, matching and interfaces

A firm opens a master account with the exchange after an onboarding review ([Chapter 25](https://one-course.com/books/quant/3/en/chapter/25-getting-access-crypto-venues#ch-m3-getting-access-crypto-venues)) and divides it for its strategies and desks.

**Definition 15.3 (Sub-account, API key).**

A *sub-account* is a separately margined account under a master account, with its own balances, positions and limits, between which the master can move assets. An *API key* is a credential, a key identifier and a secret, with which a program signs its requests to an exchange; each key carries permissions (read balances, trade, withdraw) and may be restricted to a list of IP addresses.

[Sub-accounts](#def-m3-centralised-exchanges-subaccount) separate strategies so that a loss or a liquidation in one cannot consume the collateral of another, and they make each strategy’s fees, positions and P&L visible to the firm without its own bookkeeping. [API keys](#def-m3-centralised-exchanges-subaccount) are the firm’s most sensitive operational secret after the [private keys](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) of its wallets: a key with withdrawal rights is a key to the money. Trading keys are issued without withdrawal rights, restricted to the firm’s servers’ addresses, rotated, and held in a secrets store rather than in code; withdrawals go through a separate process with its own approvals and address allow-lists.

Matching follows the price-time priority of One Quant Book 1, chapter 19, with differences a trader notices at once. The market never closes, so there are no opening and closing auctions and no overnight gap; the order types are fewer, with market, limit and stop orders, their time-in-force flags, and the [post-only order](#def-m3-centralised-exchanges-postonly) of the next section; and self-trade prevention, which stops a firm’s own buy and sell orders from matching each other, is a flag on each order with several modes (cancel the resting order, the incoming one, or both).

A program talks to an exchange over two kinds of interface. Requests (place, amend and cancel an order, query balances and open orders) go over a request-response interface, usually HTTPS; market data and the account’s own events (fills, balance changes) arrive on streaming WebSocket connections. The streams’ behaviour, their sequence numbers, snapshots and gaps, is the subject of [Chapter 26](https://one-course.com/books/quant/3/en/chapter/26-crypto-data-and-infrastructure#ch-m3-crypto-data-and-infrastructure). The request side is where the venue protects itself.

**Definition 15.4 (Rate limit, request weight).**

A *rate limit* is the maximum number of requests, or of units of load, that a venue accepts from a client in a time interval, beyond which it rejects requests and may ban the client for a period. A *request weight* is the number of units a request consumes against such a limit, set by the venue per endpoint to reflect its cost: a full order-book snapshot weighs more than a single order.

**As of September 2026 — Rate limits at a large venue.**

Binance’s spot API documentation assigns each endpoint a weight and returns the weight used so far in each interval in a response header; limits apply per IP address, not per [API key](#def-m3-centralised-exchanges-subaccount), and order-count limits per account, also reported in a header. A request that breaks a limit receives HTTP status 429 with a `Retry-After` header; an IP that keeps sending after 429 responses is automatically banned, with status 418, for periods that scale for repeat offenders from 2 minutes to 3 days. On 24 September 2026 its exchange-information endpoint returned limits of 6 000 units of [request weight](#def-m3-centralised-exchanges-ratelimit) per minute, 100 orders per 10 seconds, 200 000 orders per day and 300 000 raw requests per 5 minutes; they change, and a client reads them rather than hard-coding them.

Two properties of such limits shape a client’s design. The first is that the windows are fixed.

**Proposition 15.5 (The burst at a window boundary).**

Under a limit of $L$ units per fixed window of length $T$ aligned on the clock, a client can send $2L$ units within an interval of length shorter than $T$ that straddles a window boundary, but never more than $2L$ in any interval of length $T$. A sliding window, which counts the units of the last $T$ seconds, caps every interval of length $T$ at $L$.

**Proof.** Send $L$ units just before the boundary and $L$ just after: each window holds $L$. Any interval of length $T$ meets at most two windows, each holding at most $L$. A sliding window counts, at each instant, exactly the units sent in the preceding interval of length $T$ and refuses any unit that would take it above $L$. ∎

A client that relies on the boundary burst gets an advantage for a moment and is sometimes caught by a venue that counts differently from what it documents. The robust design counts conservatively on its own side, never sends a request it expects to be refused, and treats a 429 as a bug to be fixed, since the ban that follows repeated ones takes the firm off the venue.

The second property matters more for a market maker. Every quote change is an order, or a cancel and an order, and order counts are limited per account. When the market moves fast the strategy wants to change its quotes most often, which is exactly when the limit binds. A client that queues the updates it may not yet send sends them later, in order: quotes computed for a market that has moved. [Figure 15.2](#fig-m3-centralised-exchanges-burst) shows the effect.

![A quoting strategy on five instruments under a limit of 100 orders per 10 seconds: 5 quote updates a second, 25 a second in a volatile minute (seconds 60 to 119). Queued and sent in order, the backlog reaches 900 updates and the oldest waits 89 seconds; coalesced (only the latest quote per instrument kept), nothing waits. Illustrative rates; the limits are those of . Data: the chapter’s tutorial.](https://one-course.com/images/onecourse/chapters/quant-3/m3-centralised-exchanges/fig-50ebc892a728.svg)

***Figure 15.2.** A quoting strategy on five instruments under a limit of 100 orders per 10 seconds: 5 quote updates a second, 25 a second in a volatile minute (seconds 60 to 119). Queued and sent in order, the backlog reaches 900 updates and the oldest waits 89 seconds; coalesced (only the latest quote per instrument kept), nothing waits. Illustrative rates; the limits are those of [Box 15.1](#dat-m3-centralised-exchanges-limits). Data: the chapter’s tutorial.*

The cure is to coalesce: keep, per instrument and side, only the latest desired quote, and send the difference between it and what is resting when the limit allows. The backlog is then at most one update per instrument and side, and what is sent is current. The build of this chapter is the governor that decides, before each request, whether the venue will accept it.

## 15.3 Fees, rebates and market-maker programmes

Crypto venues charge by maker-taker pricing with volume tiers (One Quant Book 1, chapter 4): a taker, whose order executes on arrival, pays more than a maker, whose resting order provides the liquidity, and both pay less as their thirty-day volume grows. A strategy that intends to provide liquidity must be sure its orders never take it by accident.

**Definition 15.6 (Post-only order).**

A *post-only order* is a limit order that the venue accepts only if it would rest on the book; if it would execute at once against a resting order, the venue rejects it (or, on some venues, reprices it one tick away) instead of filling it as a taker.

A [post-only order](#def-m3-centralised-exchanges-postonly) guarantees the maker fee and the absence of a crossing trade, at the price of a rejection when the market has moved through the order’s price while it travelled. For a market maker whose quotes are computed from a price a few milliseconds old, that rejection is the right outcome.

**As of September 2026 — Spot fee schedules at two venues.**

Binance’s spot fee schedule charges a regular user 0.100% as maker and as taker (0.075% when paid in its own [token](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key), BNB), and its highest tier, VIP 9 (thirty-day volume of at least USD 4 billion or a BNB holding), 0.011% as maker and 0.023% as taker. Kraken Pro charges its lowest spot tier 0.40% as maker and 0.80% as taker, and its highest tier 0.00% and 0.05%. Schedules change often, and large market makers negotiate terms outside them.

| Venue and tier | maker (bp) | taker (bp) | both legs taker (bp) | both legs maker (bp) |
| --- | --- | --- | --- | --- |
| Binance, regular | 10.0 | 10.0 | 20.0 | 20.0 |
| Binance, VIP 9 | 1.1 | 2.3 | 4.6 | 2.2 |
| Kraken Pro, lowest | 40.0 | 80.0 | 160.0 | 80.0 |
| Kraken Pro, highest | 0.0 | 5.0 | 10.0 | 0.0 |

***Table 15.1.** The cost of a round trip (a buy and a sale) in basis points of notional, from the schedules of [Box 15.2](#dat-m3-centralised-exchanges-fees). A strategy whose expected edge per round trip is a few basis points exists only at the top tiers.*

[Table 15.1](#tab-m3-centralised-exchanges-fees) makes the point of the tiers. A strategy that captures five basis points per round trip loses money at the lowest tier of either venue and makes it at the highest; the difference is not skill but volume. The venues’ market-maker programmes go further, paying rebates (negative maker fees) and sometimes a fixed fee in return for quoting obligations: a maximum spread, a minimum size, a share of the time. These are incentive programmes in the sense of One Quant Book 1, and [Chapter 25](https://one-course.com/books/quant/3/en/chapter/25-getting-access-crypto-venues#ch-m3-getting-access-crypto-venues) works through one. Two cautions apply. A discount paid in the venue’s own [token](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) is a position in that [token](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key), whose value depends on the venue’s health. And a volume-based schedule rewards volume, including volume that trades with itself, which is one reason why reported volumes on some venues overstate real activity ([Chapter 16](https://one-course.com/books/quant/3/en/chapter/16-spot-markets#ch-m3-spot-markets)).

## 15.4 The exchange as counterparty: the failure of FTX

The customers of FTX discovered the difference between a venue and a counterparty in a week. The account below comes from the charges brought by the US Securities and Exchange Commission and from the filings of the debtors, the administrators who took over the companies in bankruptcy.

FTX ran a large international exchange, FTX.com, and a smaller US one, FTX.US. Alameda Research, a trading firm owned by the same founder, came to dominate borrowing on FTX.com. In December 2022 the SEC charged the founder, Samuel Bankman-Fried, with defrauding the equity investors from whom FTX had raised more than USD 1.8 billion, by concealing that FTX customers’ funds were being diverted to Alameda, and that the commingled customer money was used for venture investments, real estate and political donations. The debtors’ reports describe how. The exchange’s code gave Alameda a borrowing limit of USD 65 billion and settings that let it withdraw assets and hold a negative balance without being liquidated, privileges no other customer had. Customer deposits of dollars were partly received into accounts controlled by Alameda. Almost all crypto assets were held in internet-connected wallets, without the multi-signature controls common in the industry.

![FTX.com, 1 to 11 November 2022: customers withdrew, net, USD 7.0 billion, 3.3 billion of it on 7 November; Alameda and other related parties deposited, net, USD 3.2 billion, mostly on 6 to 8 November. USD millions at petition-time prices, as published; cumulative sums differ from the filing’s totals by rounding. Data: FTX Debtors, presentation of 2 March 2023, In re FTX Trading Ltd., Bankr. D. Del. No. 22-11068.](https://one-course.com/images/onecourse/chapters/quant-3/m3-centralised-exchanges/fig-f24044900e50.svg)

***Figure 15.3.** FTX.com, 1 to 11 November 2022: customers withdrew, net, USD 7.0 billion, 3.3 billion of it on 7 November; Alameda and other related parties deposited, net, USD 3.2 billion, mostly on 6 to 8 November. USD millions at petition-time prices, as published; cumulative sums differ from the filing’s totals by rounding. Data: FTX Debtors, presentation of 2 March 2023, In re FTX Trading Ltd., Bankr. D. Del. No. 22-11068.*

When doubts about Alameda’s balance sheet became public in early November 2022, customers ran. [Figure 15.3](#fig-m3-centralised-exchanges-flows) shows the run in the debtors’ figures: net customer withdrawals from FTX.com of about USD 1.8 billion on 6 November and 3.3 billion on 7 November, before withdrawals effectively stopped. The companies filed for Chapter 11 bankruptcy on 11 November (and some affiliates on 14 November). On the day of the filing, unauthorised transfers drained a further few hundred million dollars from the exchanges’ wallets.

| FTX.com, USD million | customer claims | assets located | coverage |
| --- | --- | --- | --- |
| Cash and [stablecoins](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-stable) | 6 991 | 270 | 3.9% |
| Bitcoin | 1 591 | 1 | 0.1% |
| Ether | 922 | 9 | 1.0% |
| All liquid [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) (Category A) | 10 544 | 694 | 6.6% |
| All [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key), with receivables | 11 233 | 2 540 | 22.6% |

***Table 15.2.** Customer claims on FTX.com and the assets the debtors located in its wallets at the petition time, USD millions at petition-time prices. Category A: [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) with a market capitalisation of at least USD 15 million and a daily volume of at least USD 1 million; most Category B assets were [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) linked to FTX and Alameda. Receivables are what customers owed the exchange. Preliminary figures, from the debtors’ presentation of 2 March 2023.*

[Table 15.2](#tab-m3-centralised-exchanges-shortfall) is the balance sheet customers were in fact exposed to. Of USD 10.5 billion of claims in liquid assets, the exchange held 694 million. It held one million dollars of bitcoin against 1.6 billion owed. The only assets worth more than the claims on them were illiquid [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) related to the group itself, valued at prices no one could sell at. The debtors’ later complaint against the founders records that by August 2022 they privately estimated the exchange owed customers more than USD 8 billion in dollars it could not repay.

**As of September 2026 — FTX afterwards.**

Samuel Bankman-Fried was convicted of fraud by a jury in New York in November 2023 and sentenced on 28 March 2024 to 25 years in prison, with a forfeiture of more than USD 11 billion. On 8 August 2024 a federal court, in a case brought by the Commodity Futures Trading Commission, ordered FTX and Alameda to pay USD 8.7 billion in restitution and 4 billion in disgorgement, finding that FTX had claimed to segregate customer assets while commingling and misappropriating them. Under the US Bankruptcy Code a claim is determined in dollars as of the date of the petition, so a customer owed a bitcoin was owed its November 2022 dollar value: the plan confirmed on 7 October 2024 promised 98% of creditors by number about 119% of their allowed claims, in dollars, whatever the coins had since become worth.

FTX was not the first such failure. Mt. Gox, an early bitcoin exchange, filed for bankruptcy in Tokyo on 28 February 2014, saying it might have lost about 750 000 of its customers’ bitcoins and 100 000 of its own; the court converted them into a civil rehabilitation in June 2018, and the trustee began repaying creditors in bitcoin and bitcoin cash in 2024, ten years after the failure. The lessons for a trading firm are practical. A balance on a venue is an unsecured loan to it unless the firm knows otherwise; the loan should be sized as one, spread across venues, and swept back to the firm’s own custody when it is not needed for trading. A run starts before the news is certain, and the first to withdraw are paid. And a venue’s own statements about its reserves are a claim, which the next section examines.

## 15.5 Proof of reserves and its limits

After November 2022 several exchanges began to publish evidence that they held their customers’ assets.

**Definition 15.7 (Proof of reserves, proof of liabilities).**

A *proof of reserves* is evidence that an exchange controls on-chain assets at least equal to its customers’ balances at a moment: signatures from its addresses, whose balances anyone can read on the chains, compared with a total of customer balances. A *proof of liabilities* is the evidence that this total is complete and correct: a commitment to every customer balance, usually the root of a Merkle tree (a binary tree in which each node is the hash of its children), against which each customer can check that her own balance was counted.

In a Merkle sum tree each leaf commits to one account, by hashing the account’s identifier, a secret nonce known to its owner, and its balance, and carries the balance; each parent hashes its two children together with the sum of their balances and carries that sum. The root’s hash commits to every leaf and its sum is the published total of liabilities. A customer receives her leaf’s nonce and the siblings on the path from her leaf to the root, one per level, and recomputes the root: $\log_2 n$ hashes for $n$ accounts, eleven for two thousand.

![A Merkle sum tree of four accounts. Each node carries the hash of its children and the sum of their balances; the root commits to all balances and their total. A customer’s inclusion proof is the siblings on her path (grey for account 4). Schematic.](https://one-course.com/images/onecourse/chapters/quant-3/m3-centralised-exchanges/fig-918bf52cf597.svg)

***Figure 15.4.** A Merkle sum tree of four accounts. Each node carries the hash of its children and the sum of their balances; the root commits to all balances and their total. A customer’s inclusion proof is the siblings on her path (grey for account 4). Schematic.*

**Proposition 15.8 (What an inclusion proof establishes).**

Let the hash function be collision-resistant. (i) If a customer’s leaf and path recompute the published root, her balance is a leaf of the committed tree and is counted in its total. (ii) If moreover every leaf balance is non-negative, the published total is at least the sum of the balances of all customers whose proofs verify. Without (ii), a tree containing a negative leaf verifies for every customer while its total understates the liabilities by the size of that leaf.

**Proof.** (i) A different leaf or path reaching the same root would give two different inputs with the same hash at some level. (ii) The root’s sum is the sum of all leaves; removing the non-negative leaves of the customers who did not check can only lower it. For the last claim, a negative leaf changes no other leaf’s hash, so every honest path still recomputes the root, whose sum is lowered by the negative amount. ∎

The negative leaf is not a curiosity: it is the cheapest way for an insolvent exchange to shrink its published liabilities to match its reserves. It is caught when customers’ verifiers check that every sum on their path is non-negative, since the negative leaf makes its ancestors’ sums negative until a subtree holds more real balances than it hides. The tutorial builds a tree of 1 023 customers and one fake account that hides 60% of the liabilities: all 1 023 proofs pass a hash-only check, and all 1 023 fail a check of the sums. Schemes that do not want to reveal sibling sums use zero-knowledge range proofs to show that every leaf is non-negative. Omitting accounts is harder to catch: it is found only when an omitted customer checks, so an exchange that omits the dormant accounts least likely to check is caught with small probability.

**As of September 2026 — A published proof of reserves.**

Kraken describes its [proof of reserves](#def-m3-centralised-exchanges-por) as an independent accountant’s review: an anonymised snapshot of client balances aggregated in a Merkle tree, each leaf the first 16 characters of a SHA-256 hash of a record identifier and the balances, and a comparison of those balances with on-chain holdings whose control the accountant verifies by signatures. Clients can verify their inclusion in the tree themselves. Kraken lists what the review does not prove: exclusive possession of the [private keys](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key), the absence of hidden liabilities or of funds borrowed to pass the review, off-chain assets, and anything after the snapshot; the assets in scope were BTC, ETH, SOL, USDC, USDT and XRP.

A [proof of reserves](#def-m3-centralised-exchanges-por) is thus a snapshot of one side of a balance sheet with a partial check of the other. It cannot show liabilities the exchange owes to lenders rather than to customers, assets lent out the day after, or keys held by someone else too. It is useful evidence against the crudest fraud, and it would not have revealed the FTX borrowing privilege, which lived in the matching engine’s settings, not in the balances.

## 15.6 Off-exchange settlement

If the risk is that the venue holds the collateral, the remedy is for it not to.

**Definition 15.9 (Off-exchange settlement).**

*Off-exchange settlement* is an arrangement in which a trading firm’s collateral stays with an independent custodian, the exchange credits the firm with a trading balance mirroring it, and the gains and losses of the firm’s trading are settled between the custodian and the exchange at set intervals or on demand, so that only the unsettled amount is at risk to the exchange.

The arrangement moves the firm’s exposure from the exchange’s balance sheet to the custodian’s, which is chosen for its segregation, controls and supervision, and limits what an exchange failure can take to one settlement period’s net gains. It also lets a firm trade on several venues against one pool of collateral, netting across them. It is not free of risk: the custodian is now the concentration, the exchange extends credit to the firm between settlements and prices that credit into its limits, and the firm needs its positions, its mirrored balances and the settlements to reconcile every cycle.

**As of September 2026 — An off-exchange settlement network.**

Copper, a custodian, describes its ClearLoop network as “[off-exchange settlement](#def-m3-centralised-exchanges-oes)” with “single net settlement” across connected venues, which it lists as including OKX, Coinbase, Bybit, Gate.io, Deribit, Bitget, Bitfinex and Kraken; assets are held in Copper’s custody. Other custodians and some exchanges offer similar arrangements; terms, settlement frequency and connected venues are the providers’ and change.

![Off-exchange settlement: the firm’s collateral stays with a custodian, the exchanges credit a mirrored trading balance, and net gains and losses are settled between custodian and exchanges at set times. An exchange’s failure can take only the unsettled amount. Schematic.](https://one-course.com/images/onecourse/chapters/quant-3/m3-centralised-exchanges/fig-987678e24053.svg)

***Figure 15.5.** [Off-exchange settlement](#def-m3-centralised-exchanges-oes): the firm’s collateral stays with a custodian, the exchanges credit a mirrored trading balance, and net gains and losses are settled between custodian and exchanges at set times. An exchange’s failure can take only the unsettled amount. Schematic.*

## 15.7 Tutorial: checking a proof of reserves

**Goal.** Build a Merkle sum tree of customer balances, produce and verify inclusion proofs, and construct the counter-example of [Proposition 15.8](#prop-m3-centralised-exchanges-inclusion). **End state:** the numbers of the section on [proof of reserves](#def-m3-centralised-exchanges-por).

1. **The tree.** Leaves commit to account, nonce and balance; parents to their children and the sum. `def h (*parts: str ) -> str : return hashlib.sha256(" | " .join(parts).encode()).hexdigest() def leaf (account: str , nonce: str , balance: int ) -> tuple [str , int ]: """A leaf commits to the account, a secret nonce and the balance (in the smallest unit).""" return h(account, nonce, str (balance)), balance def build (leaves: list [tuple [str , int ]]) -> list [list [tuple [str , int ]]]: """Merkle sum tree: each node hashes its children and the sum of their balances.""" levels = [leaves] while len (levels[-1 ]) > 1 : lv = levels[-1 ] + ([(" 0 " * 64 , 0 )] if len (levels[-1 ]) % 2 else []) levels.append([(h(lv[i][0 ], lv[i + 1 ][0 ], str (lv[i][1 ] + lv[i + 1 ][1 ])), lv[i][1 ] + lv[i + 1 ][1 ]) for i in range (0 , len (lv), 2 )]) return levels def proof (levels, i: int ) -> list [tuple [str , int , bool ]]: """Siblings on the path from leaf i to the root: (hash, sum, sibling is on the left).""" path = [] for lv in levels[:-1 ]: lv = lv + ([(" 0 " * 64 , 0 )] if len (lv) % 2 else []) j = i ^ 1 path.append((lv[j][0 ], lv[j][1 ], j < i)) i //= 2 return path def verify (node: tuple [str , int ], path, root: tuple [str , int ], check_sums: bool = True ) -> bool : """Recompute the root from a leaf and its path; optionally refuse any negative sum on the way.""" hh, s = node for sh, ss, left in path: if check_sums and ss < 0 : return False hh = h(sh, hh, str (ss + s)) if left else h(hh, sh, str (s + ss)) s += ss return (hh, s) == root` **Listing 15.1.** A Merkle sum tree, inclusion proofs and their verification. code/markets-3/15-centralised-exchanges/python/m3_cex.py
2. **The counter-example.** Insert one account with a negative balance equal to 60% of the liabilities and count the customers whose proofs pass with and without the check of sums: `fake_negative(customers())` .
3. **The shortfall.** `ftx_coverage()` reads the debtors’ table and returns the shares of [Table 15.2](#tab-m3-centralised-exchanges-shortfall) ; `fig_cex.py` writes the chapter’s chart data.

**What to change next.** Hide only 2% of the liabilities and count the customers who still detect it; put the fake leaf next to the largest account; replace the sibling sums by commitments and ask what a customer can still check.

## 15.8 Build: the rate-limit governor

**Purpose.** Every request the miniature firm sends to a venue passes a governor that knows the venue’s limits and refuses, before sending, any request the venue would reject; after a 429 or a 418 it stops for the time the venue says. A trading system that learns about limits from the venue’s rejections gets banned.

**Interface.** `Rule(kind, interval_ms, limit)` for weight or order-count rules; `Governor(rules)`; `try_send(now, weight, is_order)` returns whether to send and, if not, how long to wait; `on_status(now, status, retry_after_ms)`. The C++20 header `firm_ratelimit.hpp` and the Rust crate `firm_ratelimit` implement the same interface; the Python module is the reference.

**Rules.** Fixed windows aligned on the epoch, as the venue counts; a request is sent only if every rule has room, and then consumes all of them; a blocked governor refuses everything until the block ends; integer milliseconds, no floating point.

**Acceptance tests.** `code/firm/ratelimit/tests/`, `cpp/firm_ratelimit_test.cpp` and the Rust crate’s tests: a refused request’s waiting time to the next window; order and weight rules counted separately; backoff after 429 and 418.

**Stretch.** Sliding windows; per-endpoint weights read from the venue’s exchange-information response; reconciliation with the venue’s usage headers; a coalescing quote sender on top of the governor.

```cpp
    // (allowed, milliseconds to wait if not)
    std::pair<bool, std::int64_t> try_send(std::int64_t now, std::int64_t weight, bool is_order) {
        if (now < blocked_until_) return {false, blocked_until_ - now};
        for (const auto& r : rules_) {
            const std::int64_t need = r.kind == Kind::weight ? weight : (is_order ? 1 : 0);
            if (need > 0 && r.room(now) < need) return {false, r.wait_ms(now)};
        }
        for (auto& r : rules_) {
            const std::int64_t need = r.kind == Kind::weight ? weight : (is_order ? 1 : 0);
            if (need > 0) r.consume(now, need);
        }
        return {true, 0};
    }

    void on_status(std::int64_t now, int status, std::int64_t retry_after_ms) {
        if (status == 429 || status == 418) {
            if (now + retry_after_ms > blocked_until_) blocked_until_ = now + retry_after_ms;
            log_.push_back(std::to_string(status) + "@" + std::to_string(now));
        }
    }
```

***Listing 15.2.** The C++20 governor’s decision and its reaction to the venue’s status codes. code/firm/ratelimit/cpp/firm_ratelimit.hpp*

Sources and further reading

- US Securities and Exchange Commission, “SEC Charges Samuel Bankman-Fried with Defrauding Investors in Crypto Asset Trading Platform FTX”, press release 2022-219, 13 December 2022.
- FTX Debtors, “Preliminary Analysis of Shortfalls”, presentation to the Official Committee of Unsecured Creditors, In re FTX Trading Ltd., No. 22-11068 (JTD), Bankr. D. Del., Doc 792-1, 2 March 2023.
- J. J. Ray III, *First Interim Report to the Independent Directors on Control Failures at the FTX Exchanges* , Doc 1242-1, 9 April 2023; FTX Debtors, complaint against the founders, Doc 1886, 20 July 2023.
- Securities and Exchange Commission v. Bankman-Fried, complaint, S.D.N.Y., 13 December 2022; FTX Debtors, press release on the confirmation of the plan, 7 October 2024; NPR, report of Mt. Gox’s filing, 28 February 2014.
- Commodity Futures Trading Commission, press release 8938-24, 8 August 2024; UPI, report of the sentencing, 28 March 2024.
- Binance, Spot API documentation (limits, enums) and fee schedule; Kraken, fee schedule and proof of reserves pages; Copper, ClearLoop product page; MtGox rehabilitation trustee’s website. All accessed September 2026.

## 15.9 Exercises

**Exercise 15.1 ★.**

Name the four roles that separate institutions play in a regulated futures trade and that a [centralised exchange](#def-m3-centralised-exchanges-cex) plays alone.

**Solution of Exercise 15.1.**

The broker (the account), the exchange (matching), the central counterparty (guarantee and margin) and the custodian or settlement system (holding the assets).

**Exercise 15.2 ★.**

A limit is 1 200 units of weight per minute in fixed windows. What is the most a client can send in any two seconds? In any minute?

**Solution of Exercise 15.2.**

2 400 in both cases: 1 200 just before a window boundary and 1 200 just after ([Proposition 15.5](#prop-m3-centralised-exchanges-burst)); no interval of a minute can meet more than two windows.

**Exercise 15.3 ★.**

Why should an [API key](#def-m3-centralised-exchanges-subaccount) used by a trading strategy not carry withdrawal rights?

**Solution of Exercise 15.3.**

A strategy’s key lives on servers and in configuration that many people and programs touch; if it leaks, a trading-only key lets an attacker trade badly, a withdrawal key lets him take the assets. Withdrawals go through a separate process with approvals and allow-listed addresses.

**Exercise 15.4 ★★.**

A strategy trades USD 50 million a day, half as maker and half as taker, at Binance’s regular tier and then at VIP 9 ([Box 15.2](#dat-m3-centralised-exchanges-fees)). What does it pay in fees a day in each case?

**Solution of Exercise 15.4.**

Regular: $25\text{ million} \times 0.10\% \times 2 = \$50\,000$ a day. VIP 9: $25\text{ million} \times
(0.011\% + 0.023\%) = \$8\,500$ a day.

**Exercise 15.5 ★★.**

An exchange has 2 000 000 accounts. How many hashes does a customer compute to verify her inclusion? If the exchange omits 100 accounts and each customer checks with probability 1%, what is the probability that at least one omission is found?

**Solution of Exercise 15.5.**

The tree has 21 levels above the leaves ($2^{21} = 2\,097\,152$), so 21 hashes after her own leaf’s. $1 - 0.99^{100} = 63.4\%$.

**Exercise 15.6 ★★.**

From [Table 15.2](#tab-m3-centralised-exchanges-shortfall), what share of cash and [stablecoin](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-stable) claims could the exchange have paid from the cash, [stablecoins](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-stable) and receivables of that line (USD 270 and 310 million)?

**Solution of Exercise 15.6.**

$(270 + 310)/6\,991 = 8.3\%$.

**Exercise 15.7 ★★★.**

*Coding.* With `fake_negative`, hide 2% of the liabilities instead of 60%. How many of the 1 023 customers detect it when they check sums? Explain why fewer do.

**Solution of Exercise 15.7.**

15 customers detect it (1 008 pass). A fake leaf hiding 2% makes negative only its ancestors up to the subtree of 16 leaves, whose real balances exceed it; only the customers whose paths have one of those negative nodes as a sibling ($1 + 2 + 4 + 8 = 15$) see a negative sum. Hiding less is harder to detect.

**Exercise 15.8 ★★★.**

*Find the flaw.* “The exchange published a [proof of reserves](#def-m3-centralised-exchanges-por) last month showing assets above customer balances, so our USD 40 million there is safe.”

**Solution of Exercise 15.8.**

A [proof of reserves](#def-m3-centralised-exchanges-por) is a snapshot: it does not show liabilities to lenders, assets borrowed for the snapshot or lent out after it, keys that others also hold, or anything since. And even a solvent exchange is an unsecured counterparty: USD 40 million there is a credit exposure to be limited and swept, not “safe”.

## 15.10 Problem: The Hole in the Balance Sheet

**Problem 15.1.**

Weekend problem — what a customer of FTX.com was owed and what was there

Use [Table 15.2](#tab-m3-centralised-exchanges-shortfall), [Figure 15.3](#fig-m3-centralised-exchanges-flows) and the debtors’ figures quoted in the text. All amounts in USD millions at petition-time prices.

**Part I — The run.**

1. How much did customers withdraw, net, from FTX.com from 1 to 11 November 2022?
2. On which day was the largest net withdrawal, and how large was it?
3. What did related parties do over the same days, and why might that matter to customers?
4. Why did withdrawals almost stop from 9 November?
5. Who was paid in full in this run, and why?

**Part II — The shortfall.**

6. What share of claims in liquid [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) was covered by the liquid [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) located?
7. What share with the receivables of those [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) (USD 383 million)?
8. What share of bitcoin claims was covered?
9. What share of all claims was covered by all assets and receivables, and what was the deficit?
10. Why is the last share misleading?

**Part III — What would have shown it.**

11. Would a Merkle-tree [proof of liabilities](#def-m3-centralised-exchanges-por) have revealed the shortfall?
12. Would a [proof of reserves](#def-m3-centralised-exchanges-por) , with on-chain holdings compared against the total, have revealed it?
13. Would either have revealed Alameda’s borrowing privilege?
14. How would [off-exchange settlement](#def-m3-centralised-exchanges-oes) have changed a firm’s loss?
15. What should a firm’s venue limit have been, measured how?

**Part IV — Judgement.**

16. Why were claims fixed in dollars at petition-time prices, and who gained or lost by it?
17. How is a customer balance on a [centralised exchange](#def-m3-centralised-exchanges-cex) different from an account at a broker with segregated client assets?
18. What signs, before 6 November, might a risk manager have acted on?
19. State the *named result* : the share of FTX.com customer claims in liquid [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) covered by liquid [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) located at the petition time, without and with receivables.
20. In one sentence: what is a balance on a [centralised exchange](#def-m3-centralised-exchanges-cex) ?

**Solution of Problem 15.1.**

**1.** USD 7 014 million (the filing’s total; 7 013 from the rounded daily rows). **2.** 7 November: 3 306 million. **3.** They deposited, net, 3 241 million, mostly from 6 to 8 November; the filing notes that the sharp rise in deposits was in large part from Alameda. Deposits by the affiliate swelled balances on the exchange’s ledger while customers took real assets out. **4.** The exchange had run out of assets it could pay with and effectively stopped processing withdrawals. **5.** The customers who withdrew first, while assets remained: a run pays in order of arrival. **6.** $694/10\,544
= 6.6\%$. **7.** $1\,078/10\,544 = 10.2\%$. **8.** $1/1\,591 = 0.06\%$ located, 0.4% with receivables. **9.** $2\,540/11\,233 = 22.6\%$; a deficit of 8 693 million. **10.** It counts illiquid [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) linked to the group at quoted prices (MAPS: 1 004 million located against 96 owed) that could not be sold anywhere near them. **11.** Only partly: it would have shown each checking customer that her balance was counted, not that assets matched the total. **12.** Yes, if the comparison was honest and complete: one million dollars of bitcoin against 1 591 million owed cannot be hidden, unless assets were borrowed for the snapshot. **13.** No: the privilege lived in the matching engine’s settings, not in balances. **14.** Collateral held by an independent custodian would have been outside the estate; the loss would have been the unsettled gains at the exchange. **15.** A credit limit sized to the firm’s capital and to the venue’s quality, on the marked value of balances plus pending withdrawals and unrealised gains, with excess swept daily. **16.** The Bankruptcy Code determines claims in dollars at the petition date; customers owed assets that later rose lost that rise, and the estate kept it. **17.** Segregated client assets stay outside a failed broker’s estate; an exchange balance, absent such terms and law, is an unsecured claim. **18.** Public doubts about the affiliate’s balance sheet, concentration in the group’s own [token](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) and a fall in its price, slower withdrawals: signs to reduce balances before the facts were certain. **19.** *Named result:* 6.6% of [liquid-token](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) claims covered by liquid [tokens](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key) located, 10.2% with receivables. **20.** An unsecured loan to the exchange, unless its terms and the law make it more.

## 15.11 Interview questions

**Interview question 15.1 ★ trader.**

What is a [post-only order](#def-m3-centralised-exchanges-postonly) and when would you use one?

**Solution of Interview question 15.1.**

A limit order that is rejected (or repriced) if it would execute at once, so that it only rests: it guarantees the maker fee and that a quote computed from a stale price does not cross the spread. Market makers and passive execution use it.

*What the interviewer is looking for: maker fee, no accidental take, and the rejection as the right outcome.*

**Interview question 15.2 ★ risk.**

How would you limit a trading firm’s exposure to the failure of a crypto exchange?

**Solution of Interview question 15.2.**

Treat balances as unsecured credit: per-venue limits sized to capital and venue quality, balances kept to what trading needs and swept to own or third-party custody, [off-exchange settlement](#def-m3-centralised-exchanges-oes) where offered, [sub-accounts](#def-m3-centralised-exchanges-subaccount) to separate strategies, monitoring of signs of stress (withdrawal delays, the venue’s [token](https://one-course.com/books/quant/3/en/chapter/14-blockchains-for-traders#def-m3-blockchains-for-traders-key), news) with a plan to withdraw quickly.

*What the interviewer is looking for: credit limits, sweeping, and custody outside the venue.*

**Interview question 15.3 ★★ developer.**

Your system receives HTTP 429 from an exchange several times an hour. What do you do?

**Solution of Interview question 15.3.**

Treat it as a bug: stop and honour `Retry-After`, since further requests lead to an IP ban; then find why the client’s own accounting of weights and orders diverged from the venue’s (usage headers, weights changed, several processes sharing an IP), fix the governor, and coalesce updates so that bursts do not exceed the limits.

*What the interviewer is looking for: backoff, own-side accounting, and the ban.*

**Interview question 15.4 ★★ developer, researcher.**

Explain how a customer checks her inclusion in an exchange’s [proof of liabilities](#def-m3-centralised-exchanges-por), and how an exchange could cheat it.

**Solution of Interview question 15.4.**

She receives her leaf’s nonce and the sibling hashes and sums on her path, recomputes the root and compares it with the published one, checking that every sum is non-negative. The exchange could omit accounts unlikely to check, or add negative balances to shrink the total if verifiers do not check sums.

*What the interviewer is looking for: the path, the sums, and the two cheats.*

**Interview question 15.5 ★★ trader, risk.**

What does a [proof of reserves](#def-m3-centralised-exchanges-por) not prove?

**Solution of Interview question 15.5.**

Liabilities other than customer balances, assets borrowed for the snapshot or lent afterwards, exclusive control of the keys, off-chain assets and liabilities, and anything after the snapshot.

*What the interviewer is looking for: a snapshot of one side of the balance sheet.*

**Interview question 15.6 ★★★ developer.**

Design the component that sends quote updates for 200 instruments to a venue that allows 100 orders per 10 seconds per account.

**Solution of Interview question 15.6.**

400 quotes (two sides) cannot all be updated at 10 orders a second; hold for each instrument and side the desired quote and the resting one, rank pending changes by value (distance from the fair price, instruments in motion), and let a governor release the most valuable changes as the limit allows, coalescing so that only the latest desired quote is sent; widen or pull quotes that cannot be kept current, and use amend or cancel-replace as the venue counts them.

*What the interviewer is looking for: coalescing, prioritisation and the governor.*