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.

勇闯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是亏得。

高频基建大致可以分成这几层，从底层硬件一直到上层运维 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. 资金与账户 多交易所、多账户资金调度 费率档位和做市协议管理

🐘 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. nitter.siddz.com/alxshp/status/21100494…

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.”

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 nitter.siddz.com/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.

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.

I need help from my street quants. When I create features, I plot quantiles of the feature value vs forward returns, I often get this kind of results: linear positive relation in the middle, and reversion at the tails of the feature. I added an example, of feature= 10 days returns / 10 days std. the three lines are just the same feature but on 3 terciles of the universe by ADV. In the end, I want to use a linear model so it won’t pickup this behavior. 1. I could use a non-linear model (will probably overfit) 2. I could apply a transform to the feature such that larger values of the features gets lower. 3. I could ignore this issue Still not figured out what the best solution is, any advice ?

最初通过加密交易所而非传统交易所接触程序化交易的交易员无疑是幸运的。 在IB，你需要为几乎所有实时数据支付费用，股票、大宗、债券等等，各种不同交易所的标的都要收一遍，L1和L2还要拆开来收。少则两三美元一个月，多则一两百刀一个月。如果不交，只能看到延时15分钟的数据。即使交了数据订阅费，你也只能同时订阅3个标的的L2，每3个L2标的实时数据需要一个月30刀。周六数据服务器维护时段你是调不了历史数据的。你的手机端和服务器端都需要维护各自的账号才能不产生登录冲突。所有交易标的的交易权限都要手动开通，有的还要答各种题目。出入金存在相当程度的时延而且基本只能从同名账户出入。 我要是AI Agent我一定会从加密交易所开始我的交易之旅，毕竟我连传统交易所的KYC都过不去。而据我所知AI会在接下来10年内接管一切。

This is a must read for all aspiring traders/PMs Contrary to clever punditry, risk is both quantitative and qualitative in nature. The physics of money works under a stable regime but the seismic monetary resets, where the big money is, occur by the whims of the human condition

This is all you need for your next System Design interview. Bookmark these 👇 github.com/liquidslr/system-… pagefy.io/system-design/syst…

Don’t underestimate how much value you can get from a free blog. I came across a blog by Sergi (the #1 trader on Darwinex) explaining how he evaluates whether a filter actually improves a trading strategy. I used his framework to build a model that systematically evaluates the effectiveness of filters applied to any trading strategy. I’m pretty confident this will become one of the core pillars of my development process going forward. I combined his framework with another concept I learned from Timothy Masters (Monte Carlo Permutation Tests) to develop the full model. There are so many gems like this on Sergi’s website. You just have to dig. Here’s the blog post: sersansistemas.com/filtros-t…

Daha önce parasını yaklaşık 10 bin katına çıkaran Qullamaggie ile ilgili bir paylaşımım olmuştu. Manuelci arkadaşlardan inek öğrenci modunda detaylı araştırmak isteyen olursa pozisyon büyüklüğü risk ve poz kapatma tarzı ile ilgili oldukça detaylı bir makale var alıntıda. Kabaca özetlersek: her bir tradede çok az miktarı riske atıyor ve poz kapatırken kuralcı davranışlardan daha çok sezgisel hareket ediyor. Detaylar makalede.

在量化交易的微结构分析中，委托簿的形状反映了市场的供需弹性，深厚平坦的委托簿价格不易被推动，浅薄陡峭的委托簿则价格敏感。本文想谈谈如何计算订单簿的斜率与深度指标，从委托簿的分布结构中提取短线价格压力的讯号 什么是订单簿斜率 订单簿斜率衡量的是：当价格偏离最佳报价时，累积委托量增加的速度。斜率愈大，代表委托量集中在最佳报价附近，价格稍微偏离就会遇到大量流动性；斜率愈小，代表委托量分散在各个价位，价格偏离时需要吃掉的委托量相对较少 以买方为例，假设 Best Bid 的价格为 P_0，对应的累积委托量为 Q_0，通常就是该价位的委托量。在价格 P_0 - ΔP 处，累积委托量为 Q(ΔP)，即从 P_0 到 P_0 - ΔP 之间所有买单的总和。则买方委托簿在深度 ΔP 处的斜率定义为： Slope_bid(ΔP) = Q(ΔP) / ΔP 类似地，卖方委托簿在深度 ΔP 处的斜率为： Slope_ask(ΔP) = Q(ΔP) / ΔP 其中 Q(ΔP) 是从 Best Ask 到 Best Ask + ΔP 之间所有卖单的总和 在实务中，价格是离散的，例如以 tick 为单位，因此斜率通常以每 tick 的累积委托量来衡量。例如，若从 Best Bid 往下数五个 tick，累积委托量为 500 张，则斜率为 100 张/tick。 什么是订单簿深度 订单簿深度衡量的是：在距离最佳报价某个特定价格范围内，总共有多少委托量。深度指标比斜率更直观，它直接告诉你在当前价格的上下 X% 范围内，有多少流动性可用 深度指标的定义为： Depth(ΔP) = Q(ΔP) 其中 Q(ΔP) 是在价格范围 [P_best - ΔP, P_best] 内的累积买方委托量，或在 [P_best, P_best + ΔP] 内的累积卖方委托量。ΔP 的选择通常以百分比表示，例如 0.1%、0.5% 或 1% 深度指标与斜率指标之间的关系是：深度 = 斜率 × ΔP。两者从不同角度描述同一件事，斜率描述的是增加一单位价格偏离所带来的委托量增加，深度描述的是在特定价格偏离范围内的总委托量 订单簿失衡指标 除了斜率与深度之外，另一个重要的微结构指标是订单簿失衡。它衡量的是买方与卖方委托量的相对强弱 最简单的失衡指标是买卖深度比： Imbalance = (Depth_bid - Depth_ask) / (Depth_bid + Depth_ask) 这个指标介于 -1 与 1 之间。正值代表买方深度大于卖方深度，市场有较强的买方支撑；负值代表卖方深度大于买方深度，市场有较强的卖方压力 更精细的失衡指标会考虑不同价位的权重。例如，靠近最佳报价的委托量给予较高的权重，远离最佳报价的委托量给予较低的权重。这是因为靠近最佳报价的委托更有可能在短期内被执行，对价格的影响更直接 如何从斜率与深度提取交易讯号 第一种是流动性压力讯号。当买方深度显著大于卖方深度时，Imbalance > 0，代表市场有较强的买方支撑，短期价格可能偏向上涨。反之，若卖方深度显著大于买方深度，短期价格可能偏向下跌。这种讯号的时间尺度通常很短，从数秒到数分钟 第二种是流动性枯竭讯号。当委托簿的深度急剧下降时，代表流动性提供者正在撤出市场。这种情况通常发生在重大资讯即将公布之前，或市场波动率突然上升之时。流动性枯竭本身不预测价格方向，但它预示着价格波动即将放大。交易者可以据此调整部位规模或扩大停损范围 第三种是斜率变化讯号。当委托簿的斜率突然变陡时，代表流动性正在向最佳报价集中。这可能意味着市场参与者对当前价格有较强的共识，价格短期内不易被推动。当斜率突然变平时，代表流动性正在从最佳报价向外扩散，市场的供需弹性增加，价格可能更容易被推动 第四种是委托簿形状不对称讯号。除了单纯的深度失衡之外，委托簿的形状本身也蕴含资讯。例如，若买方委托簿在最佳报价附近很厚、但往外迅速变薄，而卖方委托簿在最佳报价附近很薄、但往外迅速变厚，这种不对称的形状可能预示着价格即将向上突破，因为买方在近端有强力支撑，而卖方在近端的阻力较弱

很多人问我如何做回测 我是用Walk-forward滚动的方法，把时间切成多段，用前面一段优化或确认规则，再用紧接着的下一段做样本外检验，然后窗口往前滚

你如果是data scientist或者统计学background，做量化自动交易strategy是你现在这个时代投资回报率最高的事情 我踩过的坑： 1. 不要做高频，你没有和Jane street一样硬件你做不了高频。swing trade 你也可以自动交易 2. 不要让AI从头开始写回测框架：无论是哪个model，他们都很擅长自己偷看未来函数和忽略滑点，你做回测要上专业级别的quantconnect或者nautilus trader中去测 3. 让不同的模型进行讨论和博弈 我还记得我当年在投行上班的时候，写一个rolling window backtest，debug，查stackoverflow需要花一周甚至几周，大量的精力都发在debug上，现在你完全就可以做一个策略艺术家，在上面指挥

一直在跑量化，发推密度肉眼可见减少 四种策略类别：alpha based, arbitrage, volatility, market making 。L1 L2 L3数据，coinglass tardis kaiko, 东京的服务器，交易所的优先订单权，都试遍了 结论是，越发感受到手工古法主观交易的不可替代性 再有人告诉我ai 会取代所有交易员的，我会直接challenge 你的专业性。有万分之一概率开出极品大佬，那我直接跪下来拜师 还是会继续搞，学习的痛苦是暂时的，未学到的痛苦是终生的

防止未来函数和忽略滑点 数据层强制记录 event time 和 available time，先做 PIT（Point-in-Time，时点一致性）检查，禁止策略读取当时尚未出现的数据；训练层加入 Walk-Forward（滚动向前验证）、Purged CV（清除式交叉验证）和 Embargo（隔离期），避免训练集和测试集互相泄漏； 执行层再用 NautilusTrader / QuantConnect LEAN 做事件驱动复核，并强制计入手续费、Spread（买卖价差）、Slippage（滑点）、Funding（资金费率）和成交延迟。 以后一个策略先证明“没有偷看未来、没有理想化成交”，再去看 Sharpe、收益率和回撤。最终目标不是让 Alpha Foundry 产出更多漂亮回测，而是让它能判断：这个回测到底值不值得信。 所以多模型之间交叉验证很重要，也可以用单模型去进行多次对抗式审查

盘口为什么会在某一刻突然变薄。 主流交易所的盘口上，一笔成交背后对应着几十次撤挂。也就是说，盘口显示的深度，九成以上是随时可以撤回的意向。变薄不是异常，是常态。真正要分辨的是谁在撤，以及撤完之后还会不会回来。 定价者的撤退是同步的。锚一动，所有存量报价立刻过期，不撤就是给市场送免费期权。这种变薄的特征是全价位成片消失，而且先于成交价的变动。你在盘口上看到的"变薄"，往往是几十毫秒前公允价格已经变了的结果，变薄领先于跳动，说明公允价格在别处先动了。 知情者的撤退是局部的。大单进来之前，知道消息的人会先撤走自己同向的挂单。这种变薄无法从盘口本身分辨，如果你的被动成交之后价格立刻单边走，你就是被清场的那一个。 还有一种是假厚。深度是真的，意愿是假的。同一价位挂了撤、撤了挂，是机器在对价。成交持续发生但盘口深度纹丝不动，是冰山单在偷偷喂量。这种盘口看着厚，一碰就穿。分辨方法很朴素，别看深度，看 replenish，盘口被扫掉之后，回补需要多少毫秒。回补快，说明做市商还在。超过没有回补，流动性真空就出现了，这个时候挂过去的每一单都是在接飞刀。

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.