How to launch a crypto perpetuals exchange in 2026: a founder's playbook

Every month a founder emails us with the same question: how do I launch a crypto perpetuals exchange? The honest answer is that most people who ask should not. The ones who should are the ones who already know why — captive orderflow, a regulatory edge, a market segment nobody serves properly. If that describes you, this playbook is the map.

We are Basis Points. We build exchanges. Our team spent the last three decades writing trading algorithms, plumbing FIX connections into the major venues, standing up FX and crypto exchanges from scratch, running market-making and arbitrage books, and building the matching engines and low-latency infrastructure that makes any of it work. This is what we do. Everything below is what we have actually seen — the timelines, the costs, the traps, and what separates the operators who ship from the ones who quietly refund seed capital eighteen months in.

The build-vs-buy question, answered up front

The mistake most founders make is treating build-vs-buy as a philosophical debate. It is not. It is a maths problem.

Build a perpetuals exchange from scratch and you are looking at 24-36 months of engineering, £6m-£15m in fully-loaded cost, and a matching-engine team that does not exist in your current Rolodex. Buy a white-label from a spot-only vendor and you get a demo that impresses your board and a platform that cannot survive its first funding event without the risk desk melting down. The correct move — the one that actually gets you to a live orderbook with real users — is to work with an operator team that has already made every mistake worth making.

That is where we come in. Twelve to eighteen weeks to first fill. We will get back to timelines below.

Jurisdiction and legal: pick your regulator before you pick your stack

The four viable regimes for 2026

For a perpetuals venue, four jurisdictions are worth serious evaluation:

• BVI or Cayman — the default for offshore derivatives. Six-to-nine month path to a licence, £150k-£300k in setup fees, sensible-enough correspondent banking if you know where to look. Excludes US persons by construction.
• Seychelles or Vanuatu — cheaper and faster, but correspondent banking is worse and the reputational overhead with tier-one LPs is real. Not a serious answer for institutional volume.
• Dubai (VARA) — the credible middle ground since 2024. £500k-£1.2m all-in, twelve-month runway from application to approval, and a regulator that actually engages. If you want Middle East and Asian institutional flow, this is where you go.
• El Salvador — the fastest path to a live licence and the one everyone underestimates. Real regulation, real oversight, and roughly one-third the cost of Dubai.

Do not launch under a UK or EU regime and then try to bolt on perpetuals. MiCA does not accommodate perpetual futures. Anyone telling you otherwise is selling you a compliance opinion, not a licence.

The compliance stack that goes with it

Whichever regime you pick, budget for a Money Laundering Reporting Officer, a Chief Compliance Officer, a fit-and-proper board, an outsourced KYC/AML vendor (Sumsub, Jumio, or Onfido — pick one and integrate it once), and a Travel Rule solution (Notabene or Sumsub built-in). All-in operational compliance runs £40k-£80k per month once you are live. Anyone quoting you £10k a month is not modelling actual regulatory obligations, and you should read that as a red flag on everything else they have told you.

Banking and custody: the part that kills most exchanges

Banking is the reason most crypto exchange projects die between month nine and month fourteen. You raise the money, you build the platform, and then no fiat correspondent will onboard you.

What actually works

For fiat rails: Bank Frick, AMINA, Sygnum, and a small number of neobank correspondents will onboard properly-licensed derivatives venues. Expect three-to-six months of onboarding, a £250k-£1m operating balance requirement, and quarterly compliance reviews. Signature and Silvergate are gone — do not build your treasury model on what worked in 2022.

For custody, the answer is not "we will build it ourselves". Fireblocks or Copper for warm operational custody, BitGo or Ledger Enterprise for cold. MPC, not multisig, for anything that touches user funds. Insurance coverage terms matter more than the marketing sheet — read the exclusions. Custody costs run 5-15 basis points of assets under custody annually plus per-transaction fees; model this into your fee schedule from day one.

Technology: what you actually need to build (and what you must not)

Here is the stack, in the order it matters.

1. The matching engine

This is the heart. Get the matching engine architecture wrong and nothing else you do will save you. The non-negotiable requirements for a serious perpetuals venue in 2026:

• Sub-millisecond order-to-fill latency, P99, under 10k orders per second sustained.
• Deterministic, replayable event log — every fill, every cancel, every funding tick, replayable byte-for-byte from cold start.
• Cross and isolated margin, in the same engine, with mark-price and index-price separation.
• Auto-deleveraging, Insurance Fund, and socialised-loss fallback — wired in from day one, not bolted on after your first cascade.
• Funding-rate calculation on a configurable cadence, per symbol, with basis-decay logic.

Most white-label vendors do not have this. They have a spot engine with a perpetuals wrapper on top of it. You will find out the difference the first time you have a liquidation cascade, and that is not the moment you want to find out.

2. Risk engine

Real-time position monitoring, mark-to-market on every price tick, pre-trade risk checks that add less than 50 microseconds to the order path. This is not a background job. This is the hot path.

3. Liquidation engine

Independent of the matching engine, watching every position on every tick. Bankruptcy price recomputed at liquidation time from live balance, not from stale ledger state. Zero-residual policy — traders zero out cleanly and the insurance fund absorbs anything left. Get this wrong and you either bleed the insurance fund or hand traders a subsidy.

4. Market data infrastructure

WebSocket fan-out that survives ten thousand concurrent connections. REST rate limiting per key and per IP. A ticker plant that does not fall over when Bitcoin moves 8% in an hour. Assume the day you launch will be the day the market moves.

5. Hedge routing

If you are running a hybrid book — some proprietary, some hedged externally — you need a router that can lift liquidity from external venues in the sub-millisecond bracket. That means co-location at a tier-one data centre, direct FIX connections to your hedge counterparties, and a reconciler that never cancels resting orders on the underlying venue. That last constraint has burned every operator we know at least once.

The stack you should not build

Do not build your own KYC pipeline. Do not build your own custody. Do not build your own Travel Rule solution. Do not build your own charting library — use TradingView. Do not build your own email or SMS provider. Every hour spent on these is an hour not spent on the matching engine, and the matching engine is where you win or lose.

Liquidity bootstrap: the chicken-and-egg problem, solved

An empty orderbook attracts no traders. No traders means no fills, which means no market makers. The default failure mode of a new exchange is a beautifully-engineered platform with a book that is 200 basis points wide and 0.1 BTC deep. The answer is three-layered.

Layer 1: house market making

You provide the initial liquidity yourself. This is not optional. Budget £500k-£2m in dedicated trading capital, run a cancel-and-repost strategy around a reliable mark price with inventory skew, and set a hedge ratio you can actually live with. We have built and run this exact system — the correct architecture is a sticky global kill switch, per-symbol size and spread configuration, and inventory-aware skew that widens spreads as your book gets unbalanced.

Layer 2: professional market maker deals

Once you have flow, you go to Wintermute, Amber, GSR, or one of the smaller specialists. The commercial deal is either a rebate arrangement, a subsidised loan of inventory, or a revenue share. Expect them to demand tight uptime SLAs, low-latency co-location, and a matching engine that behaves under stress. If they audit your engine and walk away, that tells you exactly what your engine is worth.

Layer 3: retail and prosumer flow

Marketing, referrals, incentive programmes. This is the last thing you do, not the first. An incentive programme run against a thin book is a subsidy paid to arbitrageurs, and it will not build the community you think it will.

Compliance operations: the boring part that keeps you alive

Ongoing obligations

Once you are live, the compliance workload is continuous. Transaction monitoring, sanctions screening on every deposit and withdrawal, SAR filing, quarterly regulatory returns, annual audits. This is a five-to-fifteen-person team depending on your jurisdiction and volume. If you are not staffing for it, you are not launching — you are opening yourself and your directors to personal liability.

Withdrawal operations

Every withdrawal is a decision. Automated below a threshold, human-reviewed above it, always with dual-key sign-off on hot-wallet transactions. Two-factor authentication is table stakes; step-up authentication for high-value operations is what separates a serious venue from a hobby project. Loud failures on withdrawal errors — no silent retries, no "we will get back to you". Operators must see every stuck transaction the moment it fails.

Launch: what actually gates the timeline

Tech deployment is fast; the rest of the launch is gated by things that are yours to move. Split the timeline honestly:

Tech deployment (1-3 weeks with an operator team)

• Days 1-3: environment provisioning, brand config applied, custody keys wired, KYC vendor integrated
• Week 1-2: hedge routing configured, house market maker seeded, load-test against sandbox counterparties, monitoring and alerting wired end-to-end
• Week 2-3: closed beta with invited traders on the actual production stack, final ops runbooks reviewed

Operations, running in parallel from day one — the actual critical path

• Legal + jurisdiction lock-in: 4-15 months depending on regime
• Banking correspondents: 3-6 months from first conversation to opened accounts
• Custody partnership + insurance: 4-8 weeks
• Liquidity partners + market-maker contracts: 4-12 weeks
• Compliance operation staffed and drilled (MLRO, CCO, transaction monitoring): 3-6 months to get to genuinely running

The tech side is where operator teams like ours compress the timeline. The operational side is where the actual months-to-launch are — banking, licensing, and a compliance operation you can put your name on. Anyone promising to compress those isn't reading the same regulator letters you are.

This is a working timeline, not a marketing timeline. It assumes engaged founders, decisions made in days not weeks, and no attempt to relitigate architecture halfway through the build.

Where the 30 years matters

The reason we can quote tech deployment in weeks rather than quarters is because we are not learning any of this on your dollar.

The Basis Points team has spent three decades on the operator side of financial markets. We wrote trading algorithms in the era when FIX 4.2 was the new hotness and getting a direct connection to a tier-one venue took a hand-negotiated ISV agreement and a fibre install. We built and ran FX brokerages, connected them to prime-of-primes and LPs, and dealt with every regulator that matters. We built crypto exchanges when the entire industry was running modified spot engines and everyone was pretending they understood perpetual funding. We ran market-making and arbitrage books across venues, learned every latency-arbitrage failure mode from the inside, and built the matching engines and co-located infrastructure that let us compete with firms an order of magnitude larger.

This is what we do.

Every technical decision above — the deterministic event log, the zero-residual liquidation policy, the reconciler that never cancels resting orders, the inventory-skewed cancel-and-repost market maker — is not theory. It is what we built, ran, broke, fixed, and are still running today.

The alternative is one of two things. You build it yourself, in which case you spend 24-36 months and £6m-£15m to discover the same set of production failures we have already priced in. Or you buy from a white-label vendor whose entire company has done a fraction of what our senior engineers have done individually — and you inherit their limitations, their assumptions, and their bug backlog on your platform, on your licence, with your users' money.

Spot-only white-labels are fine if you never want to run perpetuals; if you do, they are a dead end. The generalist FX-first trading-tech vendors treat crypto as an afterthought — none will co-locate your matching engine at a tier-1 colo, none will hand you a system that has been production-battle-tested through real liquidation cascades on real user balances. That is not what they do. It is what we do.

Common mistakes

Six pitfalls we see repeatedly, in rough order of how much they cost you.

1. Underestimating the matching engine

Founders treat the engine as commodity and the frontend as differentiation. It is the opposite. The frontend is a solved problem. The engine is where every exchange either wins or dies. Budget accordingly.

2. Launching before banking is confirmed

We have seen three seed-stage exchanges spend eighteen months building product before securing a fiat correspondent — only to discover no bank will take them. Get the banking indicative letter before you write your first line of code.

3. Running an incentive programme on a thin book

You will pay millions in rebates to arbitrageurs and get no organic retention. Deepen the book first. Market second.

4. Building custody in-house

You will be hacked. Not maybe — will. Fireblocks, Copper, BitGo. Pick one. Move on.

5. Trusting a vendor demo

Every vendor demo runs on a clean, low-volume environment against a scripted flow. Ask to see a production replay of a cascade liquidation event on real user positions. If they cannot show one, they have not run one, and that means the first one they run will be on your platform.

6. Confusing legal opinion with regulatory approval

A KC-signed opinion that says you "could operate" is not a licence. Regulators do not care what your lawyer thinks. Get the actual licence.

The path forward

The build path takes 24-36 months and £6m-£15m. It ends in either a functional exchange with a two-year gap on the competition, or a wound-down cap table.

The vendor path takes six months and £500k-£2m. It ends in a platform you cannot extend, cannot co-locate, and cannot trust with a real liquidation event.

The Basis Points path takes 1-3 weeks to deploy the platform end-to-end; operational tasks (licensing, banking, compliance) run in parallel and set the true launch date. Real matching engine, real risk system, real liquidity, real operators behind it. Talk to us.

Frequently Asked Questions

Evaluating the platform?

Related articles