Nghiên cứu
Ghi chép từ phía hạ tầng
Những gì chúng tôi rút ra khi kết nối với các sàn và đo đạc chúng, được ghi lại để nhóm tiếp theo không phải tìm lại lần nữa. Không dự đoán giá, không tín hiệu.
Where the matching engines live, and why most of crypto now sits in Tokyo
A trading server's most important setting is its location. Venues do not advertise where their matching engines run, but enough is public to draw the map. As of autumn 2026 it has one centre of gravity.
Pay once, pay per order: where the time actually goes between you and a venue
A trading connector spends time in two very different ways. Some costs are paid once per connection; some are paid on every order. Mixing them is the most common reason latency work goes nowhere.
Order controls across seven venues: time in force, reduce-only, self-trade prevention and the dead man's switch
Beyond price and size, an order carries a handful of controls that decide what happens when things go wrong. Which ones exist on which venue decides how much of your safety has to live in your own code.
Maker-only orders: what "post-only" means on each venue and why a quoting engine cannot live without it
A limit order that would cross the book gets filled as a taker, pays the taker fee, and is not the trade you wanted. Post-only flags exist to prevent exactly that. They are spelled differently on every exchange and behave differently in the corners.
Clock skew and signed requests: why a venue rejects your perfectly valid order
Every signed request carries a timestamp, and every venue has an opinion about how far from its own clock that timestamp may be. The error messages rarely say "your clock is off". Here is what they say instead, and how to make the problem go away for good.
How we measure exchange latency, and what the two numbers mean
The Latency Monitor shows a connect time and a request time for every venue. Here is exactly how each is produced, why they are kept apart, and what you should not read into them.