| Instrument | Tier | Last | Vol/B | Trd/B | Ord/B | Cad |
|---|
|
GREENVOLT
|
HIGH |
47.43
|
1800
|
250.00
|
428.13
|
0.20s
|
|
AURABANK
|
HIGH |
116.67
|
1866
|
264.03
|
430.76
|
0.20s
|
|
NORDSEA
|
MID |
37.17
|
1618
|
219.00
|
357.90
|
1.00s
|
|
HELVETIA
|
MID |
170.66½
|
1600
|
215.50
|
357.43
|
1.00s
|
|
BERGKLINIK
|
MID |
88.34½
|
1607
|
217.06
|
359.56
|
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.