Where does your exchange keep its order book?

It is the most useful question you can ask a trading venue, and almost nobody asks it.

"Decentralized exchange" suggests the whole system runs on a blockchain. In practice the term covers two different architectures.

In the common design, the order book and the matching engine run off-chain, on servers the operator controls. Orders are placed, queued, cancelled and matched in a private database, and only the settled result is written to the chain. There are honest engineering reasons for it. Order books are chatty, and most chains are too slow or too costly to carry that traffic.

In the other design, the book itself is chain state. That is how Metal X is built, and the point is that you can check it rather than take my word for it.

What is actually in the contract

The book. A table named orderbook holds every resting order: order id, market, price, quantity, side, and the account behind it. Not a summary or a snapshot pushed by an operator. It reads from a public node with no API key and no permission, which means anyone can inspect the live book without asking us for access.

Matching. The action that walks the book and fills orders sits in the public ABI alongside placeorder, cancelorder and withdraw. It is not restricted to the operator. Anyone can call it, and independent accounts routinely do. Matching is not a service being performed for you somewhere out of sight. It is a function on a contract.

Custody during the trade. Funds escrow into contract balances when an order is placed and settle back on fill, in the same on-chain sequence. That is why a filled order reconciles exactly rather than approximately.

Conditional orders. Even stop-loss and take-profit orders live in chain state, each carrying its trigger price, rather than on the operator's servers. On most venues, conditional orders are the most private thing in the system.

Fee tiers and market parameters. The fee schedule is on chain, per account, with a rolling thirty-day volume figure that determines the tier. Each market's configuration is a row in a table. So is the running count of every order and trade the contract has processed, which means activity is something you can verify rather than something we assert.

The trade-offs, stated plainly

An architecture argument with no costs in it is marketing, so here are the costs.

Putting every order into chain state only works if the chain is fast and cheap enough to carry it. XPR Network produces blocks about every half second and does not charge users gas. On a slower chain with a fee on every click, the design would be unusable.

The contract also has administrative actions. Pausing, fee account, user tiers. They are declared in the same public ABI as everything else, which is the point: the scope of operator authority can be established by reading rather than by asking.

Open mechanics, controlled participation

Participation is identity-gated, enforced at the contract layer. Crypto-native readers sometimes read that as a contradiction. It is two different questions.

Who is allowed into the market is a policy question, and anything touching regulated money has to answer it with verified participants only.

How the market behaves once they are in is an architecture question, and it should be answered visibly, on the record, checkable by anyone.

Permissionless protocols answer the second and ignore the first. Centralised venues answer the first and hide the second. Open mechanics with controlled participation is the combination a bank, a credit union or a licensed fintech actually needs, and it is rarer than it should be.

Why this becomes a due diligence question

As regulated institutions start offering digital asset access to their own customers, somebody inside those institutions has to explain how the venue underneath works. Not in a pitch. In an examination.

Four questions separate architecture from adjective. Where does the order book live, and can it be read without your permission? Is matching performed by the contract, or by your servers? Which actions are privileged, and where is that declared? If your API were unavailable, what could still be verified independently?

A venue built this way answers all four with a link. A venue built the other way answers with reassurance. Both may be honest. Only one can be checked by someone who does not work there.

"Their engineers explained it to us" is not a control. "Here is the contract, here is the table, anyone can read it" is.