Case study

How we engineered a compliant, hybrid exchange for institutional trading.

This is a hybrid venue: orders match off-chain, settlement lands on-chain, and the compliance layer lives in the token itself rather than in a back-office process. We built it end to end.

Off-chain matching, on-chain settlement15,000 transactions per secondERC-3643 permissioned securities

Sector

Capital markets / institutional trading

Architecture

Hybrid — off-chain matching, on-chain settlement

Engagement

End-to-end product engineering

Disciplines

Blockchain, AI surveillance, product engineering

15,000

Transactions per second

Sustained institutional throughput on the settlement engine

~15

TPS on a public chain

The baseline a fully on-chain venue would be capped at

ERC-3643

Token standard

Permissioned transfers bound to verified identity

The challenge

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.

Constraints

What made it hard

The requirements that ruled out the obvious approaches.

01

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.

02

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.

03

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.

04

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.

Throughput

Why the chain was never the bottleneck

The throughput came from architecture, not from a faster chain. Once matching lives off-chain, 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. Matching never waits on consensus, and settlement is not being asked to also be the order book. Each side is sized for the job it actually has, and the ~15 TPS ceiling that constrains a fully on-chain design 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.

Compliance

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.

Outcomes

What shipped

The world's first blockchain-based stock exchange

This exchange was built end to end — matching, settlement and compliance — rather than assembled from a trading front-end over someone else's chain.

Institutional throughput without going fully on-chain

15,000 transactions per second sustained on the settlement engine — against the roughly 15 TPS a fully on-chain venue would have been capped at.

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.

FAQ

Questions we get about this build

The things teams ask when they're scoping something similar.

A Hybrid Blockchain Exchange

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 is hybrid: match orders off-chain, away from consensus, and use the chain for settlement. That split is what took this exchange to 15,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.

Related

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 architect

Boost your business with our top-notch technologies.

Tell us your project requirements — we'll respond with a plan, not a sales pitch.