高频策略中的滑点控制：新人求教几个实战问题
大家好，我是刚入行半年的量化新人，目前在开发一个基于盘口动态的高频套利策略。回测阶段年化收益能达到120%，但实盘跑了两周发现滑点直接吃掉了35%的利润。具体遇到三个问题想请教各位前辈：
1. 在订单簿流动性突变时（比如大单突然撤单），除了改用TWAP算法，还有什么更好的应对方式？
2. 对于秒级交易频率，大家是用tick级回测还是自己构建更细粒度的仿真环境？
3. 我发现同一个策略在BTC和ETH上的滑点差异能达到15%，这是否意味着需要为不同标的单独优化参数？
目前试过在止损逻辑里加入买卖价差阈值过滤，但效果不太稳定。求各位分享实战经验，特别是处理加密货币这种波动大、流动性分布不均匀的市场。（注：所有数据都来自交易所公开API） 老哥你这滑点吃得比我食堂阿姨手抖还狠啊！我数学系在读的，最近也在搞回测，不过是在回测学校门口哪家麻辣烫最划算。说正经的，你那120%的年化看得我直流口水，但实盘这滑点...简直像极了我追女神的成功率，理论值很高，实际操作全垮掉。
我最近在淘宝搜“滑点修复大师”、“量化圣杯”，结果跳出来全是手机贴膜和算命服务。老哥你要是找到解决方法了，麻烦告诉我一声，我可以用我独创的“麻辣烫套利策略”跟你换！ 从历史经验看，金融市场的流动性危机往往源于结构性缺陷——比如1637年郁金香狂热时期订单簿的突然枯竭。建议参考1987年黑色星期一后的价差保护机制，在算法中加入动态流动性监测模块。
作为量化新人，我最近也在搭建tick级回测框架，发现用纳秒级事件驱动模型能更好模拟交易所撮合引擎的队列效应。不过ETH/BTC的滑点差异问题，或许可以借鉴外汇市场的交叉货币对参数优化方法？
（小声问）如果哪位前辈有处理过类似情况的代码框架，能否分享部分风控模块的实现逻辑？我可以提供自己整理的加密货币盘口异常模式数据集作为交换。
页:
[1]