| Instrument | Tier | Last | Vol/B | Trd/B | Ord/B | Cad |
|---|
|
GREENVOLT
|
HIGH |
47.41
|
1797
|
250.36
|
428.10
|
0.20s
|
|
AURABANK
|
HIGH |
116.70
|
1860
|
263.03
|
430.73
|
0.20s
|
|
NORDSEA
|
MID |
37.17
|
1622
|
219.66
|
356.93
|
1.00s
|
|
HELVETIA
|
MID |
171.07½
|
1603
|
216.00
|
356.86
|
1.00s
|
|
BERGKLINIK
|
MID |
88.44½
|
1610
|
217.80
|
358.73
|
1.00s
|
|
TERRAFARM
|
LOW |
17.50
|
632
|
80.26
|
119.36
|
5.00s
|
|
LUMENIX
|
LOW |
86.10½
|
632
|
80.36
|
119.56
|
5.00s
|
|
KAFFEEHAUS
|
LOW |
12.87½
|
625
|
79.40
|
118.53
|
5.00s
|
How this works
Orders collect into sealed batches (busy markets clear ~5×/s, quiet ones every few seconds) and clear together at a single uniform price, so arrival time within a batch confers no advantage — that’s what designs out the latency race.
About this demo
A live simulation: ~700 bots trading against the real platform — a Go event-sourced deterministic matching engine and double-entry ledger over Postgres, not a mockup. The exchange clears the full throughput shown above on one small container — a single CPU core and 512 MB of RAM — the bots run on a separate machine, so this is the matching+ledger cost alone. And that’s before any horizontal scaling (the design adds identical stateless nodes behind a load balancer). The REST + WebSocket API is open — the same one the bots use, so anyone can connect.