Crypto exchange software is a set of connected systems that run a centralized trading venue. A matching engine pairs orders, a ledger tracks every balance to the smallest unit, a custody stack moves coins on real blockchains, and compliance and risk systems keep the venue legal and solvent.
This page covers the software: what each component does, how the components connect, where they fail, and what a build costs. The white-label exchange guide compares ready-made platforms, and the exchange development guide covers the business side of launching a venue.
Core components of cryptocurrency exchange software
| Component | What it does | What goes wrong |
|---|---|---|
| Matching engine | Keeps order books, matches orders by price-time priority and emits trades | Different results on replay, latency spikes, wrong state after a restart |
| Ledger and accounting | Records every balance change as a double-entry journal entry | Balances drift from on-chain holdings, and race conditions appear on withdrawals |
| Wallet and custody | Creates deposit addresses, watches chains, holds hot, warm and cold funds, sends withdrawals | Key theft, deposits missed during chain reorganizations, token contracts with unusual behavior |
| Risk engine | Runs pre-trade checks, position limits, and margin and liquidation if offered | Chains of liquidations that leave bad debt, manipulated price indexes |
| Compliance | KYC and KYB onboarding, sanctions screening, transaction monitoring, Travel Rule messages | Sanctioned users get accounts, and regulators act |
| API gateway | REST and WebSocket APIs for apps and algorithmic traders, with rate limits and API keys | Abuse, stale market data, leaked keys |
| Front ends | Web and mobile trading apps, account pages and the admin back office | Session hijacking, phishing copies of the site, unsafe admin tools |
| Market data | Tickers, candles, order book snapshots and trade history | The app and the API show different data |
The matching engine
The engine keeps one central limit order book for each trading pair and checks each new order against the opposite side of the book. A buy order at or above the best ask price trades, and any unfilled part stays on the book. Most venues use price-time priority: the best price fills first, then the earliest order at that price. Order types usually include limit, market, stop and post-only, and time-in-force options include immediate-or-cancel (IOC) and fill-or-kill (FOK).
Two design properties matter more than throughput claims:
- Determinism. The same sequence of inputs must always produce the same outputs. Production engines usually run one thread per order book, reading a sequenced input log and writing an output event log. After a crash, the engine rebuilds its state by replaying the log and does not trust memory.
- Separation from money movement. The engine trades only funds that the ledger has already reserved. A pre-trade check locks the balance before an order reaches the book, so a matched trade cannot create a negative balance.
Teams write engines in Rust, C++, Java or Go, and a well-built single-threaded engine can process tens of thousands to hundreds of thousands of orders per second for each book. Most new venues never reach that volume, so correctness and auditability come before speed.
The ledger: where exchanges fail
Each change to a user's balance should be a double-entry journal record: one account is debited, another is credited, and no code edits a balance directly. Trades, fees, deposits, withdrawals and internal transfers all post journal entries. The journal lets you rebuild any balance at any past moment and compare total user balances with the assets the exchange holds on-chain.
That reconciliation should run all the time. If users are owed more of an asset than the exchange controls in its wallets, the cause is a bug, a theft or an accounting error. FTX collapsed in 2022 with a large gap between customer balances and real assets, and since then users expect proof of reserves. A proof of reserves combines a Merkle tree of user balances, which each user can check, with signed proof that the exchange controls its wallets.
Wallet and custody infrastructure
Custody is the highest-risk part of the system, and most of the largest exchange losses came from stolen keys or broken wallet processes, not from trading bugs. The Bybit theft of about $1.5 billion in February 2025 is the largest example.
Deposits
Each user gets a deposit address on each chain, generated from HD wallets (BIP-32 and BIP-44) or supplied by the custody provider. Indexers watch each chain, wait for a set number of confirmations per chain, and then credit the ledger. Some chains, such as XRP Ledger, Stellar and some Cosmos chains, use a memo or tag to identify the user. A deposit without its memo becomes a support ticket.
Withdrawals
Each withdrawal passes withdrawal limits, address-book rules, sanctions checks and risk scoring before signing, and some also get a manual review. The hot wallet holds only the funds needed for a day of withdrawals, while warm and cold wallets hold the rest behind slower approval by several people.
Key management options
- Hardware security modules (HSMs) keep keys inside tamper-resistant hardware, but each chain needs signing support in the HSM.
- Multi-party computation (MPC) splits a key into shares on separate servers, so no single machine ever holds the whole key. Most institutional custody vendors offer MPC wallets.
- On-chain multisig, such as Safe on EVM chains, shows the approval policy on the chain, though each chain needs its own multisig setup.
Each new chain adds a node or RPC provider, an indexer, a signing integration and new edge cases, so ten chains mean about ten small integration projects.
Compliance and risk
A custodial exchange is a regulated financial business in nearly every country, and the software must support these functions:
- Identity checks, usually through a KYC vendor.
- Sanctions and politically exposed person (PEP) screening.
- Blockchain analytics that flag deposits from mixers or stolen funds.
- Transaction monitoring with case management.
- Travel Rule data exchange for transfers to other virtual asset service providers, as set by FATF Recommendation 16.
- Audit logs for every admin action.
In the EU, MiCA's rules for crypto-asset service providers (CASPs) have applied since December 2024. Transition periods for existing firms ended by 1 July 2026 at the latest, so EU venues now need a MiCA license. In the US, an exchange registers with FinCEN as a money services business and usually needs state money transmitter licenses. The split of federal oversight between the SEC and the CFTC changed during 2025 and 2026.
Reference architecture
A practical layout for a new venue has these services:
- An API gateway that ends TLS, authenticates sessions and API keys, and applies rate limits.
- An order service that validates orders and asks the ledger to reserve funds.
- A sequencer, often Kafka or a custom log, that feeds one matching engine process per market.
- A settlement service that posts journal entries for fills and fees.
- A market data service that builds order books, candles and tickers from engine output and sends them over WebSocket.
- A wallet service for each chain behind a signing layer (MPC or HSM), in its own network segment.
- Compliance services and a back office with role-based access, where sensitive actions need approval from a second person.
Keep the money path (ledger, wallets and signing) in a smaller, more locked-down codebase than the user apps, because attackers often break into a less protected system first and move from there to the signer.
Build steps
- Scope the venue. Decide on spot trading only or margin and derivatives as well, and choose the countries, fiat payment rails and assets. Derivatives make the risk engine and licensing much harder.
- Choose to build, license or combine. Many teams license a matching engine or a custody stack and build the rest.
- Design the ledger and money flows first. List every journal entry type before anyone codes the interface.
- Build the engine with a replayable event log and a test harness that sends random order sequences and compares the results with a reference model.
- Add custody one chain at a time. Start with one or two assets and run reconciliation from the first day.
- Integrate KYC, screening and monitoring vendors and build the case management workflow.
- Run a security review. Commission external penetration tests, document key ceremonies, write incident runbooks and start a bug bounty.
- Soft launch with withdrawal limits and a short asset list, then expand.
Crypto exchange software cost: an estimate with assumptions
These figures are estimates based on stated assumptions, not quotes. The scope is a custom spot exchange with a production-grade engine and ledger, two to five chains, and web and mobile apps. That scope usually needs about 8 to 15 people across backend, blockchain, front end, mobile, DevOps, QA and security for about 9 to 18 months. At blended rates of $60 to $150 per hour, the total falls between about $0.7 million and $6.5 million. Licensing, legal fees, liquidity and vendor fees come on top.
A white-label platform can cut time to market to a few months, but you still pay for integration, compliance and security work, and you depend on the vendor's code quality. Recurring costs often matter more than the first build:
- Custody provider fees.
- KYC fees per check and blockchain analytics subscriptions.
- Node or RPC infrastructure and market data.
- Security audits and penetration tests.
How to evaluate a crypto exchange software vendor
- Ask how the engine recovers after a crash; the answer should be that it replays the input log.
- Ask to see the ledger model and the reconciliation process against on-chain balances.
- Ask which custody approach the vendor uses and who held the keys in past deployments.
- Request recent third-party penetration test reports for the trading codebase, not only for a website.
- For a license, check the terms for source code escrow or full code ownership.
- Treat any offer of a "ready exchange" that skips licensing, liquidity or compliance as a warning sign.
Liquidity needs its own plan, because users leave an exchange with empty order books, and most plans use market maker agreements, and regulators review the conflicts of interest in those deals. Some teams offer algorithmic trading APIs early to attract professional traders. If users should keep their own keys, look at decentralized exchange software or a hybrid exchange design.
Frequently asked questions
Should I build a matching engine from scratch?
Build one only if trading speed or an unusual market structure is what makes your venue different. A correct engine is achievable, while the ledger, custody and compliance layers hold most of the effort and risk. Many teams license an engine and build the money path themselves.
What is the difference between a hot and a cold wallet on an exchange?
A hot wallet is online and signs withdrawals automatically, so it holds only the funds needed for a day of withdrawals. Cold storage keeps most funds offline or behind slow approval by several people. A warm wallet sits between the two and refills the hot wallet.
Do I need a license to run a crypto exchange?
In most major countries, yes, if you hold customer funds or exchange crypto for fiat money. Requirements differ by country and change often, so get legal advice before you build.
How do exchanges prove they hold customer funds?
Proof of reserves combines a Merkle tree of user balances with cryptographic proof of wallet control. The proof shows assets at one moment but cannot show hidden debts, so independent audits still matter.
Which programming languages does crypto exchange software use?
Matching engines often use Rust, C++, Java or Go. Other services use Go, Java, Kotlin or TypeScript, and front ends use React or a similar framework. Determinism, testing and operating discipline matter more than the language.
How many cryptocurrencies should I list at launch?
Start with a few liquid assets, because each chain adds wallet infrastructure and new ways to fail. Add more assets after reconciliation and custody processes work reliably.