An order book records what people say they will do. A blockchain records what actually moved. Market abuse lives in the gap between the two, which is why Seqlense Monitoring reads both flows and ties them to the same person.
A five minute read · No account needed · Written for whoever has to explain it internally
Two records of the same afternoon of trading: one kept inside your own systems, one kept by a public network that belongs to nobody. Most of the confusion in this field comes from treating them as one thing.
The trading system your clients' orders go through, whether you run the venue yourself or route to one. It holds every offer to buy or sell in the order it arrived, including the ones changed or pulled a second later, and most never become a trade. It is internal data: nobody outside sees the book unless you show it to them.
A public network that belongs to nobody, running outside your walls. It records value that actually left one wallet and arrived in another, written to a ledger nobody can rewrite afterwards. Anyone in the world can read it, you cannot switch it off or keep it private, and none of it carries a name.
The same person is on both sides of this. Read each record on its own and you get half a story that stays under every threshold. Step through the three views.
Half the story. A wall placed to be seen and pulled before it fills is a manipulation pattern in its own right, and an order book is the only record that holds it: the order never settled, so no ledger will ever show it. What this view cannot tell you is where any money went, or who was on the other side.
Half the story. Three transfers, deliberately sized to stay under the line that gets attention, ending in one place. The ledger proves the movement beyond argument. What it cannot tell you is that anybody placed an order at all, or why.
One subject, one case. The wall was pulled on one side while the funds were being split on the other, by the same person. Each half sits under its own threshold. Read together, against one identity, they are a file: the intent is in the book, the money is on the chain.
Illustrative, and deliberately small. A real run reads every book at once rather than one venue, because flow split across two venues disappears from any view keyed on a client id alone.
The row that matters most is the last one. Each record is blind in the exact place the other one sees.
| Question | On-chain | Order book |
|---|---|---|
| Whose system it is | Nobody's. A public network, outside your walls, that you cannot configure, pause or keep private. | Yours, or the venue's you route to. It is the internal trading system your own flow passes through. |
| What is recorded | Value that settled: a transfer that happened, timestamped by the network. | Intentions: every order placed, modified, cancelled or rejected, filled or not. |
| Where the data comes from | Public ledgers, read by our own indexer. Nobody's permission is needed. | Your venue, and only your venue. A CSV export or a server-to-server push. |
| Who else can see it | Anyone, anywhere, for as long as the chain exists. | You, and whoever you are obliged to show it to. |
| Who it identifies | An address. Not a person, until somebody says so. | A client id. Also not a person, and different on every venue. |
| What abuse looks like here | Wash trading between wallets one actor controls, transfers fragmented under thresholds, wallets moving in step ahead of an announcement. | Wash trading on a book, smurfing, layering and spoofing: quotes placed to be seen, pulled before they fill. |
| Which rules are in play | MiCA Title VI, and the order-data expectations of Commission Delegated Regulation (EU) 2025/885, which reaches activity on the ledger.MiCA | MAR and MiFID II: surveillance of order entry and cancellation, with the order record kept for five years.MAR · MiFID II |
| What it cannot tell you on its own | Intent. A transfer looks identical whether it settles an honest trade or moves the proceeds of a manipulated one. | Where the value went. A cancelled order leaves no money trail, because no money moved. |
Regulatory references are given for orientation. They are not advice, and the obligations that apply to you depend on your licence and your activity.
Abuse patterns are not on-chain or order-book by nature. They are one behaviour, wearing whichever costume the venue makes available.
On a book it is two client ids filling each other: volume that carries no risk, printed to make a market look alive. On a chain it is two wallets one actor controls, passing the same tokens back and forth. Identical intent, two completely different files to open.
Smurfing on a book is one client's interest chopped into many small orders. Fragmentation on a chain is one payment chopped into many small transfers. In both cases the size is chosen for the threshold, not for the trade, and the sum is the only honest number.
Layering and spoofing exist only in the book. The order is the whole act, and it is withdrawn before it settles, so no ledger will ever hold a trace of it. Any tool that reads settlement alone is blind to this by construction, not by oversight.
This one needs both halves to mean anything. The chain shows a wallet funding itself in the hours before an announcement. The book shows the order that used the money. Either half alone is a coincidence, and coincidences do not survive a supervisor's question.
Holding both records changes nothing while they sit in two systems. What makes them one case is the identity underneath: a wallet flagged on Monday and a trading client flagged on Thursday have to stop looking like two unrelated events.
A wallet scan and an order-flow run read different data and answer to different rules, then land their findings in the same list, against the same subjects. See how each engine works.
Matching is an analyst's judgement or an import from your own KYC base, never a heuristic guess, and it lives beside the order record rather than inside it. See identity resolution.
Paste a wallet into the free check, or bring one venue export and watch the first alerts land against named clients.
No, and they barely overlap. An explorer shows transfers that settled. A book shows intentions, including the ones withdrawn before they settled, which are frequently the evidence itself.
It proves that value moved, which is more than most records manage. What it does not carry is intent or identity, so an on-chain finding usually becomes a case when something off-chain, an order, a KYC file or an OSINT element, says who and why.
The book, in practice. Ledger data is public and we index it ourselves. Order data only exists inside your venue, which is why ingestion starts with mapping your own CSV columns once per venue.
It follows from what you run, not from preference. A firm that executes or arranges client orders carries order surveillance obligations, and the ledger side is where the funds actually are. Most firms watching only one side are watching the one they happened to have data for.
Not while that stays true. No order means no book to watch, and the wallet engine is the whole surface. The moment you start matching client buys and sells, the other half arrives with it.
It matters at the edges: deposits and withdrawals. The client whose orders you surveil funds the account from somewhere, and that somewhere is on a ledger you can read.
That is what it is for. It needs no account and it is the same explanation we give in a demo, so it travels well to whoever was not in the room.