| Instrument | Tier | Last | Vol/B | Trd/B | Ord/B | Cad |
|---|
|
GREENVOLT
|
HIGH |
47.34
|
1797
|
249.43
|
426.03
|
0.20s
|
|
AURABANK
|
HIGH |
116.99
|
1839
|
258.13
|
427.66
|
0.20s
|
|
NORDSEA
|
MID |
37.21
|
1620
|
218.90
|
355.56
|
1.00s
|
|
HELVETIA
|
MID |
171.22½
|
1607
|
216.86
|
358.40
|
1.00s
|
|
BERGKLINIK
|
MID |
88.56½
|
1615
|
218.70
|
359.06
|
1.00s
|
|
TERRAFARM
|
LOW |
17.53
|
639
|
80.86
|
119.96
|
5.00s
|
|
LUMENIX
|
LOW |
86.46½
|
635
|
80.53
|
119.96
|
5.00s
|
|
KAFFEEHAUS
|
LOW |
12.88½
|
623
|
78.86
|
118.16
|
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.