How we engineered a compliant, 50,000-TPS on-chain exchange for institutional trading.
BEX GLOBAL is the world's first blockchain-based stock exchange. We built it end to end — order book, matching engine, on-chain settlement, and a compliance layer that lives in the token itself rather than in a back-office process.
Sector
Capital markets / institutional trading
Engagement
End-to-end product engineering
Scope
Matching engine, settlement, compliance
Disciplines
Blockchain, AI surveillance, product engineering
50,000+
Transactions per second
Sustained institutional throughput on the settlement engine
~15 TPS
What legacy chains offer
The baseline we had to engineer past
ERC-3643
Token standard
Permissioned transfers bound to verified identity
An exchange is two systems with incompatible speeds.
A trading venue does two very different jobs. It matches orders — a latency-sensitive, in-memory problem measured in microseconds — and it settles them, moving legal ownership of an asset from one party to another. In conventional market structure these are separated by days: trades match instantly, then sit in a clearing window while counterparty risk accumulates behind them.
Putting settlement on-chain collapses that window. Ownership moves atomically with the trade, the ledger is the record rather than a reconciliation of six private records, and the counterparty risk in the gap simply stops existing. That is the entire argument for a blockchain-based exchange.
The reason it had not been done is arithmetic. A public chain settling at roughly fifteen transactions per second sits three orders of magnitude below what an institutional order book generates during an open or a volatility event. Bolting an exchange onto a chain at that throughput does not produce a fast exchange — it produces a queue. Closing that gap, without giving up deterministic finality or regulatory defensibility, was the engineering problem.
What made it hard
The requirements that ruled out the obvious approaches.
Throughput floor, not average
Order flow is bursty. Sizing for average volume guarantees failure at the open, at the close, and on exactly the days that matter most. The engine had to hold its rate under burst, not on a benchmark.
Deterministic finality
Probabilistic finality is acceptable for a payment and unacceptable for a securities trade. An institution needs to know a settlement is final now — not final with high likelihood after n confirmations.
Compliance before transfer, not after
In a regulated venue an ineligible transfer must be impossible, not detectable. That pushes eligibility checks down into the transfer path itself, where they can reject rather than report.
Reconstructable audit trail
A regulator asking what happened to a specific order on a specific day needs a complete, tamper-evident answer — order, match, settlement, and the identity state of both parties at that moment.
Split the hot path from the settlement path.
The design decision the whole system rests on: stop asking the chain to do the thing chains are bad at. Match in memory at microsecond latency, settle on-chain with deterministic finality, and let each layer run at the speed it is actually good at.
Order gateway
Ingress, validation, rate control
Normalises and validates incoming order flow, enforces per-participant limits, and rejects malformed or ineligible orders before they ever reach the book.
Matching engine
In-memory order book
Price-time priority matching held entirely in memory. No database round-trip on the hot path — the book is the state.
Settlement engine
On-chain finality at 50,000+ TPS
Matched trades are committed on-chain with deterministic finality. Batching and commitment strategy are what carry the throughput from the low tens to five figures per second without weakening the finality guarantee.
Token layer
ERC-3643 permissioned securities
Assets are issued as permissioned tokens bound to an on-chain identity registry, so eligibility is a property of the instrument rather than a rule applied by a downstream system.
Compliance-as-code
KYC/AML in the transfer path
Transfer rules — investor eligibility, jurisdiction, lock-ups, holder limits — are evaluated on-chain at transfer time and aligned to frameworks including MiCA. An ineligible transfer reverts; it does not settle and get flagged later.
AI market surveillance
Real-time abuse detection
Models watching the live order and trade stream for manipulative patterns and fraudulent activity, surfacing them as they form rather than in a next-day report.
Getting from 15 TPS to 50,000+
The throughput came from architecture, not from a faster chain. Once matching lives off-chain in memory, the chain is no longer in the latency path of a trade — it is in the finality path. Those are different problems with different budgets.
That reframing is what makes the numbers work. The matching engine can run at memory speed because it never waits on consensus. The settlement engine can commit in batches because it is not being asked to also be the order book. Each layer is sized for the job it actually has, and the 15-TPS ceiling that constrains naive designs never applies.
The remaining work is making sure the split cannot drift: the on-chain record has to be the authoritative one, and the two layers must never be able to disagree about what settled.
Why compliance had to live in the token
The instinct is to put eligibility checks in the application layer — the venue asks a compliance service whether a transfer is allowed, and proceeds if it says yes. That works right up until an asset moves through a path the application layer does not control, at which point the rule was never really enforced.
ERC-3643 moves the check into the instrument. The token holds a reference to an identity registry, and the transfer function itself evaluates whether both sides are eligible under the applicable rules. An ineligible transfer reverts at the protocol level. There is no path around it, because there is no path that is not the transfer function.
The practical consequence is that KYC/AML stops being a process that runs alongside trading and becomes a property of the asset. Compliance-as-code, and MiCA-aligned smart contracts, are what let a venue answer a regulator with the ledger rather than with a report about the ledger.
What shipped
The world's first blockchain-based stock exchange
BEX GLOBAL was built end to end — order gateway, matching engine, settlement and compliance — rather than assembled from a trading front-end over someone else's chain.
Institutional throughput on-chain
50,000+ transactions per second sustained on the settlement engine, against a legacy-chain baseline around 15 TPS.
Atomic settlement
Ownership transfers with the trade, removing the counterparty risk that accumulates inside a conventional multi-day clearing window.
Compliance enforced at protocol level
Investor eligibility, jurisdiction and holding rules evaluated inside the transfer path via ERC-3643 permissioned tokens, aligned to MiCA-style requirements.
Surveillance built in, not bolted on
AI models watch live order flow for manipulative and fraudulent patterns as part of the venue rather than as an external reporting layer.
Questions we get about this build
The things teams ask when they're scoping something similar.
BEX GLOBAL
Can a blockchain actually handle exchange-level throughput?
Not if you ask it to be the order book. Public chains settle in the region of fifteen transactions per second, which is three orders of magnitude below institutional order flow. The workable design separates the two jobs: match orders in memory off-chain at microsecond latency, and use the chain for deterministic settlement finality. That split is what took BEX GLOBAL to 50,000+ TPS — it came from architecture, not from waiting for a faster chain.
What is ERC-3643 and why use it for tokenised securities?
ERC-3643 is a permissioned token standard for regulated assets. Unlike ERC-20, where any holder can transfer to any address, an ERC-3643 token is bound to an on-chain identity registry and its transfer function evaluates whether both parties are eligible before the transfer succeeds. Eligibility becomes a property of the instrument rather than a rule enforced by whichever application happens to be handling the asset — which means an ineligible transfer reverts rather than settling and being flagged afterwards.
How does KYC/AML compliance work on-chain?
Verified identity claims are held in an identity registry that the token contract references. When a transfer is attempted, the contract checks both sides against the applicable rules — investor eligibility, jurisdiction, lock-up periods, holder limits — and reverts if any fail. This is what compliance-as-code means in practice: the rule is executable and enforced at the protocol level, aligned to frameworks such as MiCA, instead of living in a back-office process that runs after settlement.
Why does on-chain settlement matter for institutional trading?
Conventional market structure matches trades instantly but settles them days later, and counterparty risk accumulates in that gap. On-chain settlement makes ownership transfer atomic with the trade, so the gap closes. It also replaces reconciliation between several private ledgers with a single authoritative record, which materially simplifies audit and dispute resolution.
How long does it take to build a system like this?
It depends entirely on regulatory scope, asset classes and custody model — those drive far more of the timeline than the trading technology does. We scope it in our Blueprint phase: architecture, compliance model and a fixed-scope plan with milestones, delivered before any build commitment is made. If you're evaluating a venue build, that phase is the right place to start.
Do you build exchanges only, or the infrastructure underneath?
Both, and usually the infrastructure is the harder half. The same ledger, compliance and throughput layer that underpins a trading venue also underpins tokenised real-world assets, fractional ownership platforms and settlement networks. We design that layer around the throughput and regulatory profile the roadmap actually needs.
The capabilities behind this build
Scoping something in this territory — an exchange, a settlement layer, or tokenised assets that have to survive a compliance review? Tell us the constraints and we'll come back with an architecture.
Talk to an architectBoost your business with our top-notch technologies.
Tell us your project requirements — we'll respond with a plan, not a sales pitch.