Ali H. Askar retweeted
做市實戰筆記 #4，這篇講參考價失真造成的錯向庫存，拆解牛津 Cartea 等人 2018 年的論文，當做市 bot 把幣安上一根短暫插針當成價格發現，結果把假訊號做成真倉位。
#1 到 #3 已經把 AS 跟 GLFT 只管庫存、不管方向這件事，從理論變成回測數字。
如果吃掉你的不是別人的單，是你自己的參考價，要怎麼從市場微結構理解它，事前又要怎麼處理才不會把誤判成本放大？
先講一個很多人搞反的地方，毛刺恢復了，你的庫存不一定會解套。
假設幣安從 100 瞬間被砸到 99.80，系統看到 Arcus 還在 99.98，判斷 Arcus 太貴，就在 Arcus 賣出做空。接著幣安彈回 100，Arcus 也跟著回到 100 附近，你得在大約 100.02 買回來，這一趟大概虧 4 bp 再加手續費。
你押的是 Arcus 往下跟上幣安，實際發生的是幣安往上回到 Arcus，價差確實消失了，只是消失的方向剛好打在你的單邊庫存上。這就是錯向庫存。
問題的根源在於，幣安只是估計公允價的依據，它本身並不是公允價。一筆真實成交有可能只是暫時性的價格衝擊，不代表價值真的變了。單看一根插針，你分不出來它是流動性真空，還是真的有資訊。
在微結構裡，這同時是暫時性價格衝擊，也是公允價估計的模型風險。
Cartea、Jaimungal 跟 Ricci 2018 年那篇講演算法交易跟互相激發過程的論文，處理的就是這種暫時性現象。他們用 Hawkes 過程描述市價單怎麼到達，一筆有影響力的大單會暫時把同方向甚至雙邊的下單強度一起拉高，單子因此成群出現，訂單簿的形狀也跟著暫時變形。他們放進中間價的那個短期 alpha 更為關鍵，它平均是零，大買單進來就往上跳，大賣單進來就往下跳，然後隨時間慢慢拉回原點。換成白話就是，大單會給價格一股短期推力，這股推力會慢慢消退，但它已經推動的價格不一定會退回去。
論文的結論是，在他們的模型設定下，高頻交易者如果沒把這個短期漂移的預測放進策略，一邊會被資訊更好的人逆選擇，一邊也賺不到方向的錢。庫存控制也綁在同一個問題裡，他們最大化終端財富時會對庫存加懲罰，最優報價會主動把庫存往零拉。所以訊號品質跟庫存管理其實是同一件事，你把暫時性衝擊當成持續的 alpha，庫存就會被推到錯的方向，等衝擊回歸時你已經站在不利的那邊。
這跟 #3 對上了。#3 跑完 20 天樣本外，結論是參數調得再漂亮也只是少被咬幾口，要賺錢得加方向訊號或逆選擇過濾。參考價失真是同一個問題的另一面，這次咬你的是你自己的估計模型，它把一根插針當成方向訊號，主動幫你在錯誤的收斂假設上建倉。
事前處理的重點，是讓參考價本身帶有可信度。全部交易一律多等 200 ms 這種做法太粗，正常行情還是要快速反應，只有在單一市場異常跳價、價差突然拉開、深度突然消失的時候，才降低那個來源的權重、縮小下單量，或暫停增加敞口。判斷時要一起看可成交的買賣價、深度、其他市場有沒有同向移動，還有行情新不新鮮、基差有沒有校正。只看最新成交價不行，把其他交易所還沒動直接當成假訊號也不行，因為真正領先的行情本來就會先動。當下沒辦法百分之百分辨毛刺跟趨勢，能做的是控制誤判的代價。
如果你問AI，他會讓你先給每個來源一個即時的可信度分數，看跳價幅度跟近期波動比起來有多大、跟其他主要市場的價差有沒有異常擴大。用連續的方式把分數作為權重調整。
可信度掉到門檻以下，新開倉的量就按比例縮，或乾脆不再加這個方向的倉。手上已經有的倉位不用馬上砍，但要設時間窗，比如 30 到 60 秒內價差沒照預期收斂，就開始用限價或小量市價把庫存推回零。設時間窗等於先承認這筆可能是錯向，主動控制持有時間，別賭毛刺會自己把你救回來。有了數據的累積，你甚至可以算出平均套牢時間。
公允價本身要用可成交中間價或多來源加權，單一最新成交價太容易被一筆單帶走。基差要即時校正，行情新鮮度要算進權重。深度突然消失的時候，就算價格沒跳也要降權，因為能成交的東西已經變少了。Pyth 給的最佳實踐也是同一個方向，信賴區間變寬時用移動平均降權或暫停依賴價格的動作、檢查報價有沒有過期、高波動時用對自己不利那側的價格、限制單筆大小，這些都是在承認參考價有模型風險。
誤判有兩種代價。把真的領先行情當成毛刺，你會錯過該跟的方向，這是機會成本；把毛刺當成真訊號，你會建出錯向庫存，這是實際虧損再加手續費。
做市商的庫存風險是不對稱的，所以我傾向先壓後者，但這只是假設，防錯向省下來的錢能不能蓋過漏掉正確訊號的成本。
要驗證得拿歷史插針事件回測，看單一市場跳價之後其他市場多久跟上、深度多久恢復，再比較兩種代價，決定降權跟縮單在哪裡觸發。不用追求完美
#3 講的過度擬合是參數層面的問題，這篇是訊號層面的問題，參數再漂亮，參考價如果把暫時性衝擊當成持續 alpha，庫存依然會被推到錯的那一邊。
來源：Cartea, Jaimungal, Ricci (2018), Algorithmic Trading, Stochastic Control, and Mutually-Exciting Processes, SIAM Review；Pyth Pro best practices。歡迎多交流。
xitter.gq/0xLUKE777crypt/status/…
做市實戰筆記 #3，這篇拿我在東京 AWS 上跑的 AS 模型做市 bot 做 backtest，看參數到底該怎麼設，順便回答前兩篇留下來的問題。
已知，被聰明的單吃掉才是做市商最大的成本。
求：回測看那一點點利潤被逆選擇咬掉之後還剩多少？
先確定模擬器靠得住。我拿公開成交重播 bot 第一次實跑的那段，模擬出來每小時 1,553 筆、每小時虧 48.63 USD，實際是每小時 1,547 筆、虧 47.56 USD。那段 6.6 小時跌了 3.81%，算蠻兇的盤，這樣都對得上，後面的回測才有意義。
再看預設參數。風險厭惡 0.12、成交率衰減 1.5、T 12，丟進 20 個乾淨樣本日（9/1 起每 3 天抽一天到 10/25，再加 10/29），平均每天虧 320.63 USD，沒有一天賺錢。
圖一是訓練期 10/26、10/27 的淨利熱力圖，越綠越賺、越紅越虧，黑線是損益兩平，白星是表面上的最佳組（風險厭惡 0.01、成交率衰減 0.25、T 6）
#2 花一大段講 T 在永續上很尷尬，實測它對損益影響有限。風險厭惡只要壓在 0.1 以下也都差不多。
這跟 #2 講的對得上。基本價差最受「掛遠一點成交機率掉多快」影響，這個參數設小，模型會覺得掛遠也有人吃，報價就拉寬，被知道方向的人咬到的次數也跟著變少。
圖二是最佳組在四段時間的累積淨利跟庫存，含 1 bps 手續費。左邊淨利看起來都不錯，10/26 收在 70 左右，10/28 收在 50 出頭。重點在右邊的庫存，藍線很常頂到 ±4000 上限然後躺好幾個小時。
10/27 晚上 9 點後一路空到上限、BTC 一直漲，淨利就在那段吐光。庫存卡在上限的時候 bot 已經不是在做市，比較像抱著一張方向單在賭。
所以我做了更嚴格的驗證。27 組參數先用 sha256 凍結，再丟進事先固定好的 20 天，避免自己偷看結果回頭改。
圖三上半部是三組參數每天的淨利，黃底是調參用過的 10/26 到 10/28，那三天幾乎都是正的，一離開黃底就正負亂跳，賺的時候幾十塊，9/28、10/29 一天就虧一百多。下半部是預設組，20 天全紅，10/29 一天虧超過 500。
圖四把 26 組疊在一起（預設組虧太多沒畫）。紅叉是樣本內日均，幾乎都在右邊賺 20 到 40；藍點是樣本外 20 天日均，全部在零的左邊。這個落差就是過度擬合長的樣子。
所以如果你把一切丟給 AI 去掃參數、挑最好看那格，大概就會挑到白星這種假的最佳化參數。
更痛的是這 27 組扣手續費前的毛 bps 全部是負的，手續費還沒算就在虧，問題不在費率等級，#1 講的逆選擇在這裡直接變成數字。
參數要怎麼設，我的看法是成交率衰減降到 0.2 左右，跟預設比虧損可以少大概 97%。風險厭惡要調的話，先把成交率衰減固定，用線上校準的到價成交強度做網格回測，再去樣本外驗證，別三個參數一起掃。
AS 跟 GLFT 都只管庫存，不管價格接下來往哪走。#1 寫的時候這還只是理論上的盲點，跑完這 20 天才知道它有多貴。
參數調得再漂亮也只是少被咬幾口，要賺錢得加方向訊號或逆選擇過濾。
熱力圖
成交率衰減最重要。
越綠代表訓練期越賺，綠色只擠在成交率衰減 0.15 到 0.25 那一窄條，往預設的 1.5 走就一路轉紅；在這條帶子裡，風險厭惡只要壓在 0.1 以下都差不多。這個參數設小，模型會把報價拉寬，被知道方向的人咬到的次數就變少。
累積淨利和庫存圖
表面上賺錢的日子，其實是運氣使然，賭對了方向。
左邊是含手續費的累積淨利，看起來都不錯；重點在右邊的庫存。藍線常常頂到 ±4000 上限，一躺就是好幾個小時，這時 bot 已經掛不出另一邊的單，等於抱著方向單在賭。10/27 晚上空單頂滿、BTC 一路漲，淨利就是在那段吐回去的。
每日長條圖
參數只在調它用的那幾天有效,換到別的日子就失靈。
黃底是調參數用過的 10/26 到 10/28，那三天幾乎都是正的；一離開黃底就正負亂跳，賺的時候幾十塊，9/28、10/29 一天就虧一百多。下面的預設組 20 天全紅，10/29 一天虧超過 500。
森林圖
樣本內的好成績到了樣本外整個消失,也就是過度擬合。
紅叉是樣本內日均，藍點是事先凍結好、樣本外 20 天的日均，橫線是 95% 信賴區間。紅叉全在右邊賺 20 到 40，藍點全在零的左邊，這個落差就是過度擬合。最佳組樣本外每天 −23.84 USD，整段信賴區間都在零下面。成交率衰減 0.3 的兩組墊底，庫存上限放到 8000 的也排在後面，抱越多虧越多。
Ali H. Askar retweeted
HFT is a lot about configuration once your trading system is solid
01/ validate at parse, not at runtime
- a fallback feed equal to its primary
- alias cycles in session schedules
- multipliers < 1
- out of range venue params
03/ everything gets a cap
you probably have a bunch of ema, spread and vol factors in your config.
all should be capped dynamically and validated before any change.
let your agents write and validate the change themselves.
04/ no defaults
if you have defaults, nobody knows what's live.
fail at startup when a required value is missing.
05/ every config param must be useful and documented
if you have 5 params that have no impact, they just shouldn't be there.
at big firms you literally have people whose job is to update these config files.
one param can make a huge difference in your pnl.
make it as easy as possible for you (or your agent) to know what actually matters.
06/ session config is a pricing parameter
- anchor sessions in the venue's timezone, not yours - model maintenance breaks
- holiday calendars per exchange family, not per exchange
- staleness grace per source, a leg that ticks seconds apart after the close shouldn't flap your spread
- test the weeks where uk and us dst don't match
after every config change should start a blast radius analysis for the next hours/days/weeks, what doesn't show up as an issue now can be in 2 days.
one thing every hft dev has to fight: transitions
01/ every transition is a way to lose or win big
your fair value changes at every transition, and volume moves: the nyse auctions, after-hours, blue ocean's overnight book
02/ it's not that easy
- make sure your slow signals are warmed up in time
- widen your quotes preemptively
- reduce size
- fc*kin timezones and holiday calendars
- every feed handler has a hard time at transitions, watch your p99 there
- filter outliers too: liquid -> illiquid is where bad prints show up
03/ where the money is
- snipe anyone who's mispricing instead of giving free options to arbers. don't be a chicken
- funding gets mispriced when the book goes thin: be the one collecting it
Ali H. Askar retweeted
Part 3: Measure once, cut twice: telemetry and Amdahl's law
Most people optimise their bot without ever measuring it. It's like trying to lose weight without a scale.
The bot from part 2 runs from my laptop in Singapore. It felt slow, and my first instinct was to dive into the Rust decision code and optimise the shit out of it. I was very wrong. It was nowhere near the bottleneck.
Then I remembered Kevin Bowers' @jump_firedancer talks at Breakpoint, and measured first.
One trip, step by step
The bot now timestamps every step from a Binance price update to our new order resting on Bullet, and exports it all to Grafana. Averaged over 5 minutes:
1. Inside Binance: 0.4ms
2. Binance to us: 41.6ms
3. Waiting in our queue: 0.010ms
4. Our code deciding (tick-to-trade): 0.0057ms
5. Order to live on Bullet: 190ms
End-to-end: 232ms
Amdahl's law
Speeding up one part only helps as much as that part's share of the total. Our trading logic is 0.002% of the trip. Make it 99% faster and the whole trip gets about 0.002% faster. Days of work, basically nothing to show for it.
That's the whole point of measuring: know where to look before you spend your time, or Amdahl's Street Justice (as Kevin Bowers likes to call it) gets you.
And the numbers already tell us what to fix:
• Binance to us (41.6ms) is distance. Part 4 moves the bot next to the exchange. Hint hint, colocation.
• Order to live (190ms) is our naive executor. It cancels the old order, waits for Bullet to confirm, then places the new one, and waits on every request. Part 6 fixes that.
Two traps when measuring
• Use Rust --release builds. Debug builds skip the compiler's optimisations, and made our code look 3-5x slower than it really is. More on squeezing Rust in part 9.
• Sync your clocks. Binance to us compares Binance's clock with your laptop's, so if yours is off, the number is off. Mine drifted 433ms behind, so messages arrived before they were sent. That's why end-to-end only uses the exchanges' clocks. Details in the github
Now everything is timed and we have a target. Measure first, then fix the biggest number.
Tomorrow we move the bot to Tokyo, next to the exchange.
Part 2: Running a simple Rust market maker from your laptop in 5 minutes
Today: 2-sided quoting on SOL-PERP
Market making 101
The order book has bids (people wanting to buy) and asks (people wanting to sell). The gap between the best bid and best ask is the spread. Depth is how much size sits at each price. See attached image.
A market maker rests a bid below fair value and an ask above it, and earns the spread when both get filled. Fill too much on one side and you're holding inventory, so you skew both quotes to lean back toward flat. Get filled right before price moves through you and that's adverse selection, the thing that kills makers.
Fair value comes from Binance, where most price discovery happens: the Binance mid plus the average gap between Binance and Bullet. No trustworthy price, no quotes.
The design
The bot uses the actor model. Every input (a Binance tick, a Bullet book update, a fill, a timer) becomes an event on one queue. The market maker reads one event at a time and answers with intents: place this, cancel that. An executor carries them out and reports back as more events.
Why that fits a trading bot:
• One writer, no locks. Only the market maker touches its state, so there are no races between a fill and a requote.
• Quote on the newest info. If more events are waiting, read them first. Quoting on a price you know is stale is a gift.
• Testable. The market maker never touches the network, so its 48 tests run in milliseconds with made-up events.
• Dry run is real. Paper trading is just a different executor, so dry run runs the same code as live.
• Room to grow. Later parts move feeds and the executor onto their own threads without touching the strategy.
It's the same idea LMAX built a famously fast exchange on: a single thread owning the business logic, fed by a queue.
Why Rust
It's fast, close to C++. The compiler is strict, catching memory bugs (no manual memory mgmt with malloc) and data races before they ever reach production. The cargo crate ecosystem is extensive. And there's no garbage collector. A GC pauses your bot at random (see the orange spikes), and the worst time to pause is mid-move, with stale quotes resting. See the test below, same loop in Go vs Rust on my box: Go's worst tick was ~1ms, Rust's ~0.05ms (chart). That tail is where you get picked off.
To be clear, this strat rn has no edge. The defaults are deliberately wide and tiny, and it's slow: every order is synchronously waited on before the next event is read. It also measures no latency numbers yet.
Tomorrow we timestamp every hop, spoiler alert, our Rust trading logic won't be the bottleneck.
Ali H. Askar retweeted
How I made $6K PnL in 30 days on $10K principal market making perps ($158m+ volume).
The strat was entirely built by me and my quant, Claude (he won a national math competition in China).
Last night I asked if you'd want a guide. Hundreds of you said yes, so here it is: HFT for Dummies.
The honest timeline when I did it:
- Days for basic harness and venue integrations.
- Weeks to get it semi-competitive.
- Months to really tune and get it properly profitable.
This series can hopefully shortcut the learning curve for you.
I've been writing trading bots since 2017. It's how I got into crypto (free market data!), and how I met my co-founder.
Back then the barrier was high. You had to know how to code, to study data to find alpha, and to grind devops to have systems not blow up in production. Thankfully I taught myself Python and later Rust, but not everyone has a CS degree.
Nowadays with LLMs, anyone can have a skilled quant in their pocket. I use it for data analysis, strategy tuning, research and alpha generation and infra optimisation. It's a ridiculous time saver.
I'm extremely bullish on one-person quant shops. I think this will be a huge trend this next decade as finance comes on chain and market data and connectivity are accessible to anyone. I've already met many hobbyists who've made a living trading on e.g. Hyperliquid, enough so to quit their day jobs.
What we'll be building
A delta-neutral, reference-price market maker.
Binance is where most price discovery happens. We stream its market data, use it as a reference price, and quote a bid and an ask around it on another venue. I'm using @Bulletxyz because it's the one I know best.
Market making is the business of picking up pennies. Mine are under half a basis point per dollar. Enough pennies add up at the scale of millions of volume.
The catch is speed. If the market moves and you're slow to update, someone lifts your stale quote and you're the exit liquidity. It's a fun game of algorithmic cat and mouse.
On Bullet, takers get a 100ms speed bump. Why? It gives soon-to-be market makers like you a safety buffer so you don't get steamrolled by billion dollar firms with microwave towers.
The goal
The goal: tick to order sent in under 10ms. Stretch goal: under 1ms, which is very achievable if you're determined. We'll also focus on minimising jitter (randomness) because your slowest orders are the ones that will lose you the most pnl.
Agenda:
I'll aim to post one topic a day, going from easy wins, and getting progressively more deep in the weeds. If you work at any HFT firm this will all be elementary stuff, but hopefully it's helpful for newcomers.
Saving seconds
1. Basic intro to algo-trading (this post)
2. Running a simple market maker from your laptop
3. Measure once, cut twice: telemetry and Amdahl's law
4. AWS: Infra and colocation
Saving millis
5. Stop polling: websockets are your friend
6. Optimising order execution
7. How to not get rekt by API rate limits
8. Linux tuning: CPU pinning, IRQs and other nerd stuff
Saving micros (diminishing returns, but fun)
9. Optimising the hot path with CPU profiling in Rust
10. AWS: the last mile
11. Bonus: nonces (and other DeFi quirks)
I'll try share some open source code along with it. Don't expect to be beating Jump in the orderbooks just yet. It should be a good baseline that you can extend and take it as far as you want (you can take it pretty far!).
Tomorrow: setting up a basic MM in Rust, the architecture of which will roughly follow the diagram attached below.
Ali H. Askar retweeted
最近在做 perp 跨所套利 (Hyperliquid, Lighter, Binance, Entropy).
下面这些冷知识都是我自己实测出来的
1. VPS 放 AWS 东京, AZ 选az4. LightSail的话选默认的A地区就行了. 因为这里离币安服务器最近.
az4 到 Binance 0.3ms, 另外两个区 1.5-1.9ms.
HL 和 Lighter 都走 CloudFront. 换 Lightsail AZ C会比A快1ms..
2. Hyperliquid 行情开 3-4 条连接, 用最先到的消息. (比单条链接快). 具体为啥我也不清楚. 币安数据就没这个问题.
3. HL 撤报价别用 cancel, 用 modify 把单子挪远, 会快一倍..
4. Lighter 免费账户就够了
5. 美股闭市期间. Binance 上的币股变动都是最先的. 领先 Lighter main 50-200ms, Lighter RH 250-350ms, trade.xyz 450-550ms, Entropy ~800ms
6. 美股盘中 Binance 只落后 Nasdaq 50-60ms. 而正常情况在东京收 Nasdaq 行情最快也要 75ms+.
很明显是一些大的做市商有专线, 连接纽约和东京. 比公网链路快很多. 这个咱们散户没办法..
![Trade[XYZ]](https://pbs.twimg.com/card_img/2115366249777545216/g5OBP5LF?format=jpg&name=800x419)
Ali H. Askar retweeted
Ex-Tower Research HFT trader Annanay Kapila (@annanay) on why hedge funds trade mid-frequency instead of HFT:
"Proprietary trading firms who don't have a lot of capital need to achieve a very high return on capital. They tend to do high-frequency trading because they never end up in big positions."
"By contrast, hedge funds tend to end up more in mid-frequency trading, because they're not interested in small gains or losses that you can realize on each trade from high-frequency trading."
"If I have the ability to put a lot of capital behind my trades and take large positions, then I have the privilege of being able to predict much longer in the horizon."
"In that region, where we're trying to predict hours, days, maybe even weeks out into the future, I need to take on bigger positions overall to make it worth my while. I need more capital, and I'll probably achieve lower return on investment."
"I'll be able to make more dollars, even if I don't make as much percentage return."
"Greed makes markets."
Annanay Kapila (@annanay) spent years as an HFT quant at Flow Traders and Tower Research before founding QFEX (@QFEX), a perpetual futures exchange for equities, commodities & FX. Cambridge Maths.
At his last job, the desk traded $10B+ of volume a day, run almost entirely by algorithms.
In this lecture, he builds market making from first principles:
- The map of systematic trading: prop money vs. other people's money, HFT vs. mid-frequency, and why every strategy lives in one quadrant
- Why prop firms can return 50-100% a year while hedge funds can't: HFT never leaves you holding a big position
- The order book from scratch: bids, offers, limit orders, and why the first order on a price level gets the trade
- No free lunch: how arbitrageurs force every order book to reveal a fair price without anyone trying to
- The entire strategy in one line: bid below fair value, offer above it, collect the difference forever
- Market making is "time-spreading risk," warehousing positions between a seller who shows up now and a buyer who shows up later
- Adverse selection: you're most likely to get filled precisely when your price is most wrong
- Why market makers are completely self-serving, and why that's exactly what makes markets work
- The competitive race that compresses spreads: greed among market makers means lower costs for everyone else
- Thick books vs. thin books, and the vicious loop that keeps illiquid markets illiquid
Highlights:
(00:45) The systematic trading map: capital vs speed
(01:45) Prop firms vs hedge funds: return-on-capital economics
(06:29) A message from Onyx
(07:55) Where market making sits: high-Sharpe prop HFT
(08:55) Fungibility and why exchanges exist
(11:00) How a central limit order book actually works
(17:40) No free lunch: arbitrage-free pricing in the book
(19:55) Theo: reading fair value from the mid
(22:45) Who really posts the book (not retail)
(24:35) Market making as warehousing risk across time
(27:20) Edge: quoting around your fair value
(29:45) Queue priority and the adverse selection problem
(33:05) How competition compresses the bid-offer spread
(37:40) Thick vs thin books: liquidity begets liquidity
(43:55) Scaling to $10B a day on algorithms
Ali H. Askar retweeted
ETH Zürich's "Mathematical Foundations for Finance"
PDF: metaphor.ethz.ch/x/2021/hs/4…
Ali H. Askar retweeted
如何更快取得 @HyperliquidX 的盤口數據？
在 Hyperliquid 進行跨所套利時，發現部分成交滑點偏高，p90 達 2–8 bp
經查，主因為下單當下所持盤口數據已過時，價格已先行變動，所見仍為數百毫秒前的狀態。伺服器部署於東京，物理距離已盡量縮短，惟官方公共 WebSocket 推送之盤口仍偏慢。以全天生產數據統計：
中位數 236 ms
p90 346 ms
約 2% 之幀超過 1 秒才抵達
後續採用 @Quicknode 的 gRPC 盤口推送
p50：236 ms → 176 ms
p90：346 ms → 211 ms
超過 1 秒之幀：2.05% → 0.02%
費用方面，Build 方案每月 49 美元，包含 8,000 萬 credits。僅訂閱最佳買賣報價、約 20 個幣種，已完全足夠
若追求更快，可自行成為 Hyperliquid validator，直接自鏈上取得數據，惟每月伺服器成本約 1,000 美元
真正的機會來自結構差異——跨所、跨 DEX、資金費率與定價規則之間的不一致。先找出結構，機會方才存在；速度僅是使既有機會執行得更為乾淨
以每月 49 美元換取約 60 ms 的改善，性價比可接受；更高成本則待結構機會更為明確後再行考慮。因此，QuickNode 對我而言是實用工具，而非 alpha 本身。先尋找結構，再談論速度
(但是我仍然尋找當中....)
Ali H. Askar retweeted
Ex-Tower Research HFT trader Annanay Kapila (@annanay) on why prop firms can make 100% a year and hedge funds can't:
"Proprietary trading firms tend to have only their own partners' money. So they tend to be less well capitalized. So they need to achieve a good return on capital."
"They tend to run strategies that you can't necessarily put a lot of money behind, but you can make a lot of return from them. So returns on proprietary trading firms can be upwards of 50%, even 100% a year."
"You'd struggle to find a hedge fund achieving those kinds of returns. But the point with a hedge fund is they take in a lot of capital. Even if they achieve a modest return on that capital, they still make a lot of money."
"Hedge funds ultimately are dealing with clients' money. They have to act within risk constraints that their clients put on them. There needs to be a sales process to get the capital in, and a process for how to return the capital."
"With proprietary trading firms, none of those considerations really apply, because ultimately you're trading with your own money."
"Greed makes markets."
Annanay Kapila (@annanay) spent years as an HFT quant at Flow Traders and Tower Research before founding QFEX (@QFEX), a perpetual futures exchange for equities, commodities & FX. Cambridge Maths.
At his last job, the desk traded $10B+ of volume a day, run almost entirely by algorithms.
In this lecture, he builds market making from first principles:
- The map of systematic trading: prop money vs. other people's money, HFT vs. mid-frequency, and why every strategy lives in one quadrant
- Why prop firms can return 50-100% a year while hedge funds can't: HFT never leaves you holding a big position
- The order book from scratch: bids, offers, limit orders, and why the first order on a price level gets the trade
- No free lunch: how arbitrageurs force every order book to reveal a fair price without anyone trying to
- The entire strategy in one line: bid below fair value, offer above it, collect the difference forever
- Market making is "time-spreading risk," warehousing positions between a seller who shows up now and a buyer who shows up later
- Adverse selection: you're most likely to get filled precisely when your price is most wrong
- Why market makers are completely self-serving, and why that's exactly what makes markets work
- The competitive race that compresses spreads: greed among market makers means lower costs for everyone else
- Thick books vs. thin books, and the vicious loop that keeps illiquid markets illiquid
Highlights:
(00:45) The systematic trading map: capital vs speed
(01:45) Prop firms vs hedge funds: return-on-capital economics
(06:29) A message from Onyx
(07:55) Where market making sits: high-Sharpe prop HFT
(08:55) Fungibility and why exchanges exist
(11:00) How a central limit order book actually works
(17:40) No free lunch: arbitrage-free pricing in the book
(19:55) Theo: reading fair value from the mid
(22:45) Who really posts the book (not retail)
(24:35) Market making as warehousing risk across time
(27:20) Edge: quoting around your fair value
(29:45) Queue priority and the adverse selection problem
(33:05) How competition compresses the bid-offer spread
(37:40) Thick vs thin books: liquidity begets liquidity
(43:55) Scaling to $10B a day on algorithms
Ali H. Askar retweeted
good stuff. i used a similar tactic in 01 to be the first one on the books whenever they got out of (usually unplanned) maintainance.
hammer the API to be the first one in the books, and pick off anyone who forgot or couldnt to cancel their orders.
gud monies
exchanges deploy too, downtime exist.
use that as an edge.
01/ for example
recently lighter added a shutdown notice before closing:
{"close_in_ms":12943,"type":"shutdown"}
then closes with code 1012 "server shutting down". they say within 30s
02/ ok then what ?
all sockets got the notice within 13ms of each other. close_in_ms ranged from ~5.3s to ~13.8s, different per socket.
every close landed between 10ms before and 4ms after the deadline. data kept flowing until the close
think about it. everyone has the same constraints, if you're the first to reconnect, you're basically alone for a few seconds.
won't matter in most cases, sure, but during high volatility times this can be a money printer.
03/ works for market data too
you can open the new socket while the old one is still draining, so there's no blind window at all.
basically you always have to treat venue maintenance as a normal state of your system, not an exception.
04/ edge lies in the p99
when designing hft systems, always think about the worst case, the last quantile, that's where shit ton of money can be printed (or lost)
every api/dependency you have can go down, be ready for this
Ali H. Askar retweeted
After almost 10 years of work corporateownershipdata.com now makes available all publicly available ownership records of 7,156 publicly traded firms, not just the S&P 500, including dual-class shares.
Ali H. Askar retweeted
one thing every hft developer should have:
a repeatable blueprint of scenarii that you can run on any exchange API to understand its behavior.
01/ list all possible operations
think about all the possible edge cases there can be, try sending each operation 3x then 10x, then invert the order of operations.
try everything so you can draw as much conclusions as possible on how their ordering/matching engine works.
02/ pipeline it
make this easily repeatable, so you can easily run it through any new exchange API you find.
every time you find an edge case on any exchange, add it to your blueprint and test it everywhere.
many details are hidden out there waiting for you to be found.
03/ run it after every update
exchanges update their logic pretty often, don't assume things will always be the way they are.
use this as an edge, the faster you catch an internal logic change, the longer you can take advantage of it.
a few more good HFT tricks for you to try out
again. not rocket science. just there to nudge you in the right direction.
01/ multiple feeds
subscribe to multiple feeds, from different places, with different IPs, multiple times.
and deduplicate the output.
you never know why one feed or the other can be faster in different conditions.
benchmarking when the market is calm has nothing to do with high vol times.
even the worst median can be the best p99.
yes ultimately you want a private fiber w/ @Avelacom_Corp but until then just compound the feeds you have and make the best usage of em. can already get you pretty far.
02/ always a/b test
keep a low risk engine running on the side that serves as a reference for your optimizations.
first, well you can still catch some liquidations but more importantly bugs early on and actually see your improvements.
more volume, more activity = more messages going through your system, you need to be able to spot where is the bottleneck at all times.
03/ stale data is worse than no data
you have to know your data feeds, their edge cases, especially when pricing fair value using multiple sources and layers.
each layer should have its own thresholds and protections, an oracle feed you're using for a basis or a weekend mid price should not be treated equally.
Ali H. Askar retweeted
勇闯Perp价差套利第一周，供大家参考：
延迟：（我的服务器在 AWS 东京）
@arcus_xyz：挂单 43ms，改价 28ms，撤单 52ms，挂单成交到收到推送 10ms 左右
@Lighter_xyz ：357ms，其中 300ms 是 Standard 档固定的吃单延迟，网络往返只有 33ms
@entropyIO：540ms 撮合，780ms 收到回执
540ms 里网络只占很小一部分，东京到交易所的往返通常只有几十毫秒。剩下的大部分应该是 Hyperliquid 链上出块、撮合的等待时间
每组 2个号，本金 = 两边账户合计
A 组｜Entropy × Lighter RH
运行 4.8 天｜本金 $205｜交易量 $12,035｜平均 OI $404
盈利 +$6.01
B 组｜Arcus × Lighter RH（保守）
运行 7 天｜本金 $282｜交易量 $20,269｜平均 OI $699
盈利 +$2.69｜积分 1.26
C 组｜Arcus × Lighter RH（均衡）
运行 4.8 天｜本金 $411｜交易量 $47,463｜平均 OI $1,361
盈利 +$4.27｜积分 1.94
D 组｜Arcus × Lighter RH（激进）
运行 2 天｜本金 $200｜交易量 $31,593｜平均 OI $819
盈利 +$1.94｜积分 0.87
Arcus × Lighter（B + C + D）合计：本金 $893，交易量 $99,325，盈利 +$8.90，Arcus积分 4.07，Lighter给的积分总共不到0.3😂😂
Arcus积分跟什么有关：
OI x 持仓时间、交易量
大约每 1 万刀交易量 0.17 分，每 1000 刀 OI 持仓一天 0.18 分，三组的误差都在 4% 以内。
也就是说，持仓 1000 刀 OI 一整天，差不多相当于刷 1 万刀交易量。
各品种表现：（我只选择了流动性还不错的RWA品种，Crypto只做了ZEC）
CRCL 赚得最多，SPCX 滑点最大、SPY滑点最小，只有ZEC是亏得。
Ali H. Askar retweeted
高频基建大致可以分成这几层，从底层硬件一直到上层运维
1. 硬件与网络
机房选址和托管：服务器放在离交易所撮合引擎最近的地方（比如 AWS 东京）
服务器配置：CPU 绑核、关超线程、大页内存、网卡选型
网络：内核旁路（kernel bypass）、多网卡分离行情和下单、专线
2. 时钟与延迟测量
时钟同步（NTP、PTP）
全链路打点：从收到行情到发出订单，每一段花了多少时间
延迟分布统计：看的是 p50、p99，而不是平均值
3. 行情层
连接管理：WS 订阅、断线重连、心跳
解析与归一化：不同交易所格式统一成内部格式
本地订单簿重建：快照加增量、序号断档检测和补数据
数据质量：乱序、重复、丢包、延迟异常的识别
4. 交易接口层（连接层）
交易所适配：每家 API 的差异抽象成统一接口
限频管理：按 API Key 或按 IP 的令牌桶
下单通道：WS 下单、批量下单、撤改单
5. 订单管理（OMS）
订单状态机
成交回报处理与持仓计算
状态对账：本地和交易所的订单、持仓核对
6. 策略引擎
事件驱动框架：行情、成交、定时器事件的调度
低延迟设计：无锁队列、预分配内存、避免 GC
策略和基础设施的接口解耦
7. 风控
事前风控：下单前的仓位、金额、价格偏离检查
实时风控：回撤、库存、敞口监控
熔断与 kill switch：行情异常、延迟超标、交易所故障时停止报价并撤单
8. 数据与研究
行情和成交的全量落盘存储
回放系统：用历史 tick 数据重放
回测与仿真：撮合、队列位置、延迟模型
9. 监控与运维
监控面板：延迟、成交率、PnL、系统资源
告警：分级告警，谁接、多久响应
日志、部署、灰度发布、故障恢复
10. 资金与账户
多交易所、多账户资金调度
费率档位和做市协议管理
Ali H. Askar retweeted
🐘 Introducing Postgres Internals in 3D.
🌟 pgrun.dev/pi
Stop reading boring diagrams. Start exploring PostgreSQL.
An interactive 3D map to understand how Postgres actually works.
100% free. Built for developers.
xitter.gq/alxshp/status/21100494…
Introducing PGSync 🐘
Real-time PostgreSQL replication. FREE. OSS
Built in Rust. 🦀
Postgres 16 / 17 / 18.
No extensions. No triggers. No complex setup.
→ snapshot
→ replicate
→ stream changes
→ track WAL
→ recover from crashes
→ resume automatically
→ keep databases in sync
~15 MB RAM during streaming.
Built for developers. Built for AI agents.
Open source.
xitter.gq/alxshp/status/21078790…
Ali H. Askar retweeted
Before you ship a vibe-coded site, make Opus 5.5 audit it like a performance team.
Send 4 subagents across these 20 checks:
*Images + fonts*
• Convert images to WebP/AVIF and size them correctly
• Use next/image for large assets
• Lazy-load below-the-fold media
• Prioritize the main above-the-fold image
• Use framework-native font loading
• Keep fonts limited
• Remove unused third-party scripts
• Delay analytics/chat widgets until after load
*Frontend*
• Run a bundle analyzer
• Replace full-library imports with only what you use
• Dynamically import heavy charts, editors and maps
• Fetch homepage data on the server
• Stream AI responses
• Use skeletons while loading
*Database + APIs*
• Add indexes for filtered/sorted columns and RLS fields
• Use (select auth.uid()) in RLS policies
• Kill N+1 queries
• Paginate long lists
• Cache shared API responses, never user-specific ones
• Move emails, image processing and reports to background jobs
*Servers + network*
• Keep functions near the database region
• Use static pages or ISR where possible
• Parallelize independent API calls
• Test on low-end Android + slow 4G
Then paste this:
“Send one subagent per group to check it without editing anything, and note which file each issue is in and which page it affects. Run the database subagent at high effort. Before changing anything, run a production build or preview, then run Lighthouse three times in mobile mode on the homepage and the two or three slowest pages and note the median. Then fix everything yourself from their lists, measure again the same way, and give me the before-and-after numbers. Don’t remove features to gain speed. Ask me before removing dependencies, changing the deploy region, or changing the database.”
Ali H. Askar retweeted
time to talk about pricing in HFT
01/ micro price or mid price?
well none, you need a proper filter.
mid price and micro price can easily be manipulated, especially during weekends or illiquid markets.
what you want, is to filter out the noise from the signal.
1. don't overreact to price movements, wait for confirmations.
2. anchor on the deepest side of the book.
3. the tighter, the closer to the actual mid
02/ kalman filter
there is a very good description of it in the book "Algorithmic Trading: Winning Strategies and Their Rationale"
not for lead-lag arb or tight quoting.
good if you have one fast but noisy source and one slower more reliable source.
be careful to align on origin timestamps.
rewind, correct, replay.
03/ future contracts rolling
xitter.gq/AriPingle/status/20422…
outdated alfa, but if you look around closely it's still a good example on how you can print with better pricing models.
look at the oracles used by each market, there are lots of innefficiencies or MMs mispricing out there.
Yesterday, Hyperliquid oil perp was paying -300% annualized funding. Onchain infrastructure is telling us something about how commodity markets will work going forward
@tradexyz perps use CME front month as the oracle. Front month ~$95, back month ~$87. Oracle rolls over 5 business days, stepping down ~$1.70 per shift
The "obvious" trade is to short the perp, hedge on CME, collect the roll. We open-sourced a model to price it w/ a link at end of the 🧵
Ali H. Askar retweeted
Introducing Anatomy
Describe a machine in one line. Claude brings it to life.
- Interactive isometric wireframes you can rotate, inspect and explore
- WebGL shaders for fire, water, plasma and more
- Real 3D motion, with individual parts that rotate and move
Install it as an agent skill. Fully open source.