2/ First of all in HFT there are "strict" problems that you must get right and "loose" problems that you just want to 80/20 at the beginning.
More problems than you think will fall into the second bucket.
Problems will migrate to the first bucket, but slower than you think.
3/ When getting started, only model, strategy, and latency should be part of the first problem class.
Some important sounding things that I would recommend the 80/20 principle on: 1) inventory management 2) sizing 3) hedging
I.e. almost all of the issues @pedma7 mentioned
4/ Starting with inventory management:
1. Query your positions periodically. 2. Listen to fill feed or order/cancel responses. 3. When your position changed, don't bother figuring out by how much. Instead, fade your top of book orders and don't take until you re-query.
5/ Sounds hacky, but a low volume HFT strategy running with this system will get almost all the good volume compared to running with drop-copy and real time position reconciliation.
The volume you miss with this setup will be the more marginal fills anyway.
6/ With market moves and hedging, just ignore it. Keep a small position limit, and bias towards flattening.
Again, if you truly have short term alpha, your expected pnl will not suffer from this adjustment.
Compute markouts to determine if you have edge.
7/ Once your strategy matures and you decide to productionize it, these issues slowly migrate towards things you must get "exactly right."
But when starting out the proper implementation will bog you down and not contribute to the sign of your pnl.
8/ Hope this is helpful for people starting out in HFT.
For a concrete example, here is an open source end-to-end liquidity provision strategy:
As you can see, it's very simple to get a template up and running to plug in your strategy logicgithub.com/hyperliquid-de…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1/ There's a lot of edge in building a production crypto HFT system the right way.
The abstractions should be rich enough to prevent careless mistakes but not too rigid to work with.
I converged on these after countless hours of building, debugging, and rewriting code 🧵
2/ Let's focus on a concrete example: How do you deal with continuous quantities?
Doing math in code with raw numeric types is error prone. Multiplying the price of one symbol by the size of another is sure way to blow up your strategy.
Just be careful? Nah, we can do better.
3/ A pervasive feature of our trading system is the concept of "units."
The first idea is to have separate types for Price, Size, Notional, etc.
1/ We've talked before about how latency is an important component of every crypto HFT strategy.
The optimization process is fun detective work because the exchange's tech is often a black box.
A thread on what to measure, graph, and analyze for your production HFT system 🧵
2/ The first important number to look at is the "exchange timestamp" field of websocket messages and REST responses.
If multiple time fields exist, use the one corresponding to matching engine time. The other fields are edge server times, which add more noise to your analysis
3/ Matching engine time is crucial because network delay and the exchange's internal machine topology add noise to the outgoing timestamps on your end.
Reconcile the matching engine and your outgoing timestamps and you can quantify and optimize the factors in between