Crypto Exchange Development: Where Exchange and Liquidity Break
The pain of entering a crypto exchange is almost always the same. The internal balances of the account panel diverge from the public ledger: the deposit went through, but the credit did not appear; the withdrawal left, but the reserve was debited twice.
During a sharp market move, orders hang in an intermediate state — the client repeats the trade and gets it twice.
The cause is not an individual failure, but the architecture.
Deposit taking, quoting, and execution live in different environments with their own sources of truth: as long as there is no single transaction journal and end-to-end reconciliation, any gap between them turns into manual investigation and a one-sided trade.
The cost is measurable. Industry reviews that we analyzed together with Chainalysis agree: a significant share of incidents at exchange services are not hacks, but balance desynchronization and stuck orders.
Every hour of exchange service downtime in a live market is lost turnover and clients who return to a competitor instead.
The bottlenecks of an exchange are exposed at the moment of load, when fixing them is most expensive.
That is why we start crypto exchange development not with the interface, but with accounting: regular reconciliation with the ledger, quarantine of disputed operations instead of manual edits, a separate environment for one-sided trades. We break down how this is addressed.
What Changes After Implementation: Speed, Margin, Resilience
A managed architecture changes three measurable values: the share of orders closed without an operator, the time from opening to settlement, and the amount of margin that remains after the work of external liquidity providers. Below is exactly what drives this.
Order Processing Time and the Operations Queue
Automation of exchange operations begins with the order storing state at each step: address verification, reserve for the pair, network confirmations, credit.
The steps are idempotent, so after a restart the handler continues from the last state rather than from scratch — the operations queue does not grow during a load spike.
The operator intervenes only where automated checks have raised a manual review flag; the share of such orders is the processing speed metric.
Eliminated Class of Failures and Margin Calculation
Fault tolerance here means controlled behavior when an external provider fails: while it responds longer than a set threshold, routing moves the flow to a backup source, and the spread is recalculated from the actual execution price. An entire class of failures disappears — orders closed at an outdated rate.
Exchange margin is calculated for each trade: fee, cost of liquidity acquisition, slippage. The discrepancy is visible in real time, so limits are adjusted based on actuals, not a monthly report. We align access separation and checks with the requirements of ISO/IEC 27001.
Hybrid Exchange Model vs. Direct Trades: What to Choose
The exchange's operating mode determines where the counterparty to a trade comes from: from the platform's own reserve, from external liquidity providers, or from other users. This affects the spread, execution speed, and service behavior during a sharp market move. Below are the real options chosen between at the design stage.
| Option | When It Fits | Limitations |
|---|---|---|
| Own reserve | Narrow list of pairs, predictable order flow | Capital is frozen; during a trend, one side of the reserve is depleted |
| Hybrid exchange model | Many pairs, need large orders without slippage | Position reconciliation is more complex, dependence on counterparties |
| Direct trades between users | Rare pairs, non-standard assets | Long wait for a counterparty, escrow and arbitration required |
| Order-book exchange with an order book | Liquid pairs with dense flow | Without market makers, the order book remains empty |
Hybrid: Own Reserve Plus External Liquidity
The core calculates the price from its own reserve and fills the missing volume from external providers via order routing. The reserve covers small trades without delay, while the external channel covers large and rare pairs.
Limits per counterparty and regular position reconciliation are needed: otherwise, a balance discrepancy will surface on client payouts.
Direct Trades Between Users and Order-Book Exchange
The platform here does not hold capital: it matches orders, locks the asset in escrow until payment confirmation, and resolves disputes through arbitration.
The model's limitations are the wait time for a counterparty and the risk of bad-faith behavior, so a rating, limits, and clear unlocking rules are needed. The order book provides instant execution on liquid pairs but requires constant support of the order book.
Implementation Procedure: From Audit to Handover to Operation
Crypto exchange development proceeds in waves, and order here matters more than speed: first we capture how funds move now, and only then do we change it.
Otherwise, the new settlement logic is layered on top of unaccounted manual operations, and discrepancies surface with live clients.
- Exchange infrastructure audit. We map the nodes, external rate and liquidity sources, key storage locations, and the list of those with access. Separately, we write down everything that is still done by hand.
- Fund flow diagram. We describe the route from receipt at the address to crediting to the user's balance: reserves, network confirmations, limits, fees, stuck operations, and the procedure for reviewing them.
- Environment setup. We separate development, test, and production environments, keep configurations identical, secrets outside the repository, and keys unique to each environment. Checks and experiments stop touching production funds.
- Settlement rules. We set the spread and margin, the procedure for applying the rate, rounding, limits per operation and per pair — with logging of every decision so the calculation can be explained and recalculated.
- Acceptance checks on historical data. We run the new rules on records of past trades and reconcile the result to the last digit. A discrepancy is a reason to return to the diagram, not to write it off as an error.
- Handover to operation. We hand over regulations, dashboards, deviation alerts, and the procedure for rolling back to the previous state, and train the on-duty shift.
Who Does What at Each Step
Our engineers conduct the audit and flow diagram together with your finance specialist and support service — they know the real exceptions.
We cover the environments, settlement module, and acceptance runs, while you make the launch decision after the reconciliation demonstration. After that, we stay in touch under the support regulations.
Handover Package: Configurations, Diagrams, Access Policies
The handover package is assembled in parallel with development, not at the end: each environment is described at the moment a change is made to it.
That is why system documentation does not diverge from the actual configuration, and acceptance turns into reconciliation rather than reconstructing history from correspondence.
Documentation and Diagrams
- Integration diagrams: order flows between the exchange core, liquidity environment, wallets, anti-fraud, and rate sources — with failure points and timeouts.
- Environment configurations: parameters of the test, pre-production, and production environments — limits, spreads, asset list, request retry settings.
- Data model description: trades, internal accounting entries, balances, and status history; the procedure for reconciliation with the blockchain.
- Operator instructions: handling a stuck order, manual payout, switching a pair to read-only mode.
Regulations and Responsibility Matrix
- Role matrix and access policies: who changes limits, initiates withdrawals, and rotates keys — separation of duties and two-factor authentication.
- Maintenance regulations: scheduled work, updating nodes and rate sources, backup, and recovery verification.
- Response regulations: actions during a rate spike, withdrawal surge, or provider failure — alert thresholds and responsible parties.
- Rollback procedure: configuration version, author of the change, and the method to return to the previous state without downtime.
Case Study: How We Reduced Manual Operations and Eliminated a Class of Failures
The exchange operated on a hybrid model: part of the volume was covered by the internal order book, and part went to external liquidity.
The bottleneck was not throughput, but manual operations — the operator confirmed every withdrawal, reconciled balances on hot and cold wallets, and investigated discrepancies using the journal.
The class of failures proved expensive: when a withdrawal request was resent due to a network timeout, the operation could go through twice, and the discrepancy surfaced only at the next reconciliation.
Response to such a failure took hours, and disputed trades were closed manually — using statements and correspondence.
What changed: idempotency by operation ID, automatic balance reconciliation with an alert on discrepancy, threshold margin rules, and a moderation queue that receives only anomalies above the limit. Manual confirmation remained where the amount or account behavior goes beyond the set boundaries.
Before and After
| Metric | Before | After |
|---|---|---|
| Share of operations with manual confirmation | most withdrawals | a few percent, only anomalies |
| Response to balance discrepancy | hours, upon detection | minutes, by alert |
| Disputed trades per quarter | dozens | isolated cases |
| Finding the cause of a failure | manually in the journal | by operation ID, minutes |
The class of failures with double withdrawal processing no longer reproduced: a repeated request is cut off by operation ID, and reconciliation finds a discrepancy before the client notices it.
According to industry data from Chainalysis, a notable share of incidents at exchanges is related not to a breached perimeter, but to operational processes and manual confirmations — this layer is what we removed.
What to Do If the Platform Is Already Deployed on an Off-the-Shelf Solution?
Migration of an exchange service is almost never done with a single switch.
An off-the-shelf solution versus a custom one is not an either-or choice: the old platform continues serving clients while a custom core is brought up alongside it with the same set of operations — order acceptance, rate calculation, debit and credit, withdrawal. Both environments live simultaneously, and this removes the main risk — exchange downtime.
Data migration of operations begins with history: orders, trades, balance movements, and fees are transferred in batches with checksums and repeatable writes, so a repeated run does not create duplicates.
During the transition, both systems write to a common ledger or synchronize via reciprocal exchange, and reconciliation for each client continues until balances fully match.
Gradual traffic migration — by directions and currency pairs. First, a small share of orders with an amount limit goes to the new core, then the limits are raised, and the old environment remains a backup route.
The rate and risk environment is shared: divergence of quotes between platforms is unacceptable, otherwise arbitrage appears within the service itself.
Separately, we address technical concerns: orders stuck in an intermediate status, double debit during a failure, and a one-way return to the off-the-shelf solution.
To do this, we maintain an operations journal, regularly reconcile totals, and keep a fast rollback mechanism that returns all traffic to the previous platform without losing history.
Technical Concerns: Fund Storage, Margin, Checks
The client's most frequent technical question is where client funds physically reside and who holds the keys. We build a custodial model with separation into hot, warm, and cold tiers: the hot tier holds only the operational reserve for withdrawals, the rest is in cold storage.
Private keys do not reach the application server: transaction signing goes through a separate service with a threshold scheme, where compromise of one site does not open access to the balance.
The second layer is margin calculation and operation verification. Accruals are calculated not by the exchange or the interface, but by a custom module with a double-entry journal: each trade, fee, and manual adjustment is a separate entry with an immutable identifier.
Regular automatic reconciliation compares internal balances with actual balances at addresses, and a discrepancy above the threshold stops withdrawals until review.
Who owns the private keys after project delivery?
You manage the keys. We describe the procedure for generating, backing up, and rotating access shares, but we do not retain the ability to withdraw funds. Access transfer follows a protocol with responsible parties recorded.
How is the correctness of accruals verified?
Each operation passes through a double-entry journal, so the balance always reconciles by entries, not by the current value in the database. A disputed trade can be retrieved in full: order, rate at the time of execution, fees, statuses.
What happens during a disputed operation?
Withdrawals from the account can be paused selectively, without stopping the entire platform. Trade history is immutable, so the review relies on actual records rather than reconstructed logs.
Let's Discuss the Task: What Is Needed for an Estimate and Work Plan
To come back with a task estimate and work plan, rather than general wording, we need a minimum of input data.
Below is about your current scheme, not our templates: the more precisely you describe the exchange and load, the fewer assumptions will remain in the estimate and schedule.
- Current exchange scheme: where quotes come from, where orders go, how balances are currently reconciled, and where margin is calculated.
- Roles and access: who changes rates, who confirms fund withdrawals, what rights are needed by the operator, risk manager, and support.
- Verification requirements: mandatory steps before crediting and withdrawal, thresholds for manual review, what to do in case of a balance discrepancy.
- Expected load: how many operations per day, peak hours, how many exchange directions and pairs you plan to support at launch.
- Environments and integrations: payment channels, asset storage solutions, internal systems with which the exchange must exchange data.
- Implementation timeline: the date by which the exchange must be operational, launch stages, whether ready infrastructure and platform requirements exist.
- Who on the client side accepts the result and by what criteria we agree to consider the work accepted.
Once we receive this, we name the team composition for your scope: how many engineers are needed, who is responsible for order matching, who for security and checks, and whom we bring in for integrations. Then we break the work down into stages with dates and acceptance points. Describe the task — we will come back with an estimate and work plan.