| Instrument | Tier | Last | Vol/B | Trd/B | Ord/B | Cad |
|---|
|
GREENVOLT
|
HIGH |
47.37
|
1799
|
251.10
|
427.36
|
0.20s
|
|
AURABANK
|
HIGH |
117.10
|
1840
|
258.13
|
428.36
|
0.20s
|
|
NORDSEA
|
MID |
37.26
|
1620
|
218.76
|
357.73
|
1.00s
|
|
HELVETIA
|
MID |
171.29
|
1603
|
216.76
|
358.66
|
1.00s
|
|
BERGKLINIK
|
MID |
87.96½
|
1613
|
218.36
|
358.76
|
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.