| Instrument | Tier | Last | Vol/B | Trd/B | Ord/B | Cad |
|---|
|
GREENVOLT
|
HIGH |
33.70
|
1753
|
240.40
|
420.73
|
0.20s
|
|
AURABANK
|
HIGH |
108.53
|
1766
|
240.66
|
419.13
|
0.20s
|
|
NORDSEA
|
MID |
36.85
|
1765
|
244.46
|
395.86
|
1.00s
|
|
HELVETIA
|
MID |
97.70
|
1736
|
239.70
|
396.40
|
1.00s
|
|
BERGKLINIK
|
MID |
78.26
|
1730
|
234.93
|
392.46
|
1.00s
|
|
TERRAFARM
|
LOW |
16.46½
|
615
|
79.46
|
118.60
|
5.00s
|
|
LUMENIX
|
LOW |
66.28½
|
619
|
79.50
|
118.56
|
5.00s
|
|
KAFFEEHAUS
|
LOW |
7.54½
|
616
|
80.46
|
119.80
|
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.