DC

7年区块链老人，为什么还在crypto里玩耍? 我是在2018年才知道btc的， 那时候在刚来互联网公司上班，也才研究生毕业没两年， 组里有人组织了外部人员的区块链分享， 我当时完全不知道是个啥，什么账本，什么挖坑 但我隐隐感觉它是个有意思的东西， 尤其我我听到不可篡改的公共账本，还有数据主权，个人绝对所有权等，我立即就被击中了 当天就决定我要买入， 找到同事了解到了火币交易所，然后果然开户尝试买入第一笔100人民币的，然后开始学习研究，学习了两个月后，我知道btc的全部逻辑，也被它货币主权的叙事深深吸引，然后对于“至少拥有一个btc”的说法很认可， 那时候我简直找到了一个新的人生方向， 我天生反感集体主义，厌恶扼杀个性而强调集体的花束， 我也厌恶所谓有一个权威可以依赖，或者所谓让渡自己的权利去换取一些安全和保障，或者把自己的命运交给一个更大的掌舵着…等等诸如此类的，都是我嗤之以鼻，我认为每个人都应该为自己负责，甚至如果觉得每个人都自私一点，都只为自己考虑，放下那些助人之心， 放下所谓关爱，所谓“为你好”… 这个世界或许会更加让人舒适（不是美好，而是舒适） 在这样的一个自我个性下，我1000%的 buy in 区块链的叙事，且愿意投入自己的财富去压住， 所以我当时用蚂蚁借呗借款了30万以差不多9000美金的价格买入了3-4个btc， 我当时坚信这是一笔值得投入的资金，且就算30万亏逛逛，就当我一点上班白干了， 也无妨， 我还年轻。。 在这样的信念下，我一直对区块链充满期望，甚至在2021年从辞职创业，试图使用区块链技术打造一个去中心化数据库，以实现更便利的个人数据主权（当然很快就证明了这个伪命题） 跟大部分炒币人都经历过的一样，在这7-8年里，我的资产达到了财富自由的峰值然后又跌入破产， 在一个一个叙事中犀利，一开始充满信念，然后破碎，发现那只是一个故事，我们只是那些讲述故事的人的流动性， 回头来看，我几乎将我这上边8年来的全部资产和精力都投入到了区块链， hold， 合约，meme， 开发工具，投资，搞基金， 爆仓，赔钱，现货跌99%... 直到25年初，我意识到，我的财富在别人的故事和自己的无知中流失殆尽， 我本不是投资人， 对任何项目和他们的团队都一无所知，靠着道听途说的3手信息，去投资hold，（ 甚至一度自我洗脑，认为这是web3的伟大，普通人都能参与任何一个项目的最开始种子轮融资，陪着项目一起成长，而不用像传统上市公司，我们能交易股票都是经历了N轮之后的残羹剩饭， 是的，我的认知只有指甲盖那么大，却在主动为这个行业规划构建一个摩天大厦） 也就是这时候，随着我的资产在此归零，我也开始从零构建我的套利系统，直到这个时候，我才意识到，自己手中的这点usdt是多么的宝贵，它是你真正的生成资料，它是具备将1块钱变成1.1的能力的， 或者是说，我自己是有能力将它从1块钱变成1.1块的， 而不是扔到一个莫名其妙的项目里祈祷，祈祷背后某个力量能帮我打工，何其愚蠢至极。 当我的套利机器第一次开始盈利的时候，我意识到，只有自己才是那个人，只有自己才能依赖， 你需要的是非常专注，非常深入的投入，为自己投入的那1USDT注入力量，让它变成1.1, 1.2.., 唯有自己！！ 从那时候之后，我不在buyin 任何故事了， 包括btc的故事，ETH的故事， 对我来说，他们的故事是什么都不再重要， 我只关注自己是不是能将1USDT变成1.1USDT，如果不是依赖自己力量，而是依赖一个故事，祈祷某个资产涨，那都是痴人说梦，它今天能涨，明天也能跌，而且，我不认为在任何一个领域，你不做任何的智力或脑力的投入，简单所谓的hold就就能得到长期的财富，永远不可能。 说到这里，我为区块链感到一丝丝悲哀，像我这样的，一个过去如此“信仰” 区块链，btc的人，也开始质疑，这不得不说是区块链的一大损失， 损失了一个这样忠实的信徒，我想这样的人应该不仅仅只有我一个。 当然，这样的表述也许有误，失败的是那些宣传故事，宣传信仰的人，btc从一开始就没变过，它并没有宣传任何信仰，任何叙事，它只是一套规则，自顾自的运转在那里， 信与不信，它都在这里。 而我为什么现在还是在玩区块链，我开发量化系统，未来会基于它开发应用，开发产品等等。我的那个人主权的自我从来没有变过，比如，直到现在我依然不会把钱存在银行里， 也不会投资第三方托管的理财, 甚至都不会购买保险。 可以确定的是，未来10年时间里，我投入依然是围绕区块链，及时做ai产品（ 我现在在一个ai公司上班，每天都在做ai相关的工作，从底层训练调度，到模型微调，到agent，开发应用） ， 作为一个同时深入了解两个领域的程序员，及时目前我发现貌似ai带来的金钱收益远大于区块链给我带来的收益，我依然很热爱这个行业，应为它的开放性，它的黑暗森林，它的弱肉强食， 它的自我为主体性，让我觉得舒适。 过去很长时间，我是陷入迷茫的状态， 在各种叙事的起起伏伏，生生死死的找不到方向，而现在我内心非常安定， 现在不在关注故事，不在关注宏观趋势，不在关注经济指标，不在关注涨跌， 这些统统都跟我无关了， 我选在区块链里主动玩耍而不是被玩耍， 我只在乎一件事情，区块链是否还会继续存在… hope so .. （此文在半个多小时内一次写完，格式混乱请见谅）

@EleveResearch 开了多少杠杠？

操你妈的 Bybit 诈骗交易所 第一次见直接抢钱的 ARIA 的多单在 0.087 的时候直接按照 0.057 自动减仓 0.055 开的仓位也 ADL，才 9000 刀仓位 浮盈 5000 刀直接给自动减仓扣掉哈哈哈哈哈哈 真的你妈的畜生恶心人 干脆所有赚钱的仓位全部找个机会接近开仓价 ADL 算了 或者直接扣除余额吧 亏钱爆仓清算费和价格没少收 赚钱就直接自动减仓把差价吃掉 直接后台黑箱接管 60% 的差价和改余额不知道有什么区别 客服还不如 AI 找不到能真正处理问题的人 只会甩文档链接 诈骗交易所 Bybit 诈骗交易所 Bybit 诈骗交易所 Bybit @Bybit_Official @_Bybit_ZH

@cheuk_baby 就是

@0xDC_MA 规则改了都没提前说声儿

OKX 这波操作真离谱。 核心交易 API（下单）跑了几个月稳定，今天突然报错：instIdCode can not be empty。 问题是：没有明确公告、文档没更新、兼容策略也没给。 这是交易核心链路，不是小功能。 你们一句“规则变了”，用户这边就是实盘风险、策略中断、资金暴露。 做交易基础设施，最基本的是： 提前公告 文档同步 兼容过渡期 现在这三样都没做到。 请 OKX 给出正式说明和时间线。 请问交易失败亏的钱到底算谁的？多少基于api交易的做市场商这波又要吐血了 @okx @okxchinese

@Jiajia_OKX 再私信下 没看到，估计很多api交易的人遇到这个问题了吧

@0xDC_MA 需要多一点的信息，辛苦哥看下私信～

很喜欢这种从原始数据提出质疑的方式，很多时候，你都不知道自己看到的数据是哪个人在什么情况随手拍出来的，结果它流传开以至于人们开始盲信。我们逐渐陷入了不可知论的状态

@zeroonerobin cool 很喜欢这种质疑原始数据精神

美妙的上升曲线，持续印钞不能停

知道了，开始研究策略

@Jackyi_ld 这个逻辑有问题，如果是好项目，为什么大家都要抢着跑， 关键不在于退出先后，而在于是否真的有创业者投入创建优质项目

加密行业这几年最大的问题创新衰退了，这个问题根源来自两方面，一是美国上一届政府加密政策收紧，随着这次加密结构法案通过应该能解决。二是币安要求项目对加密VC的1➕3年锁仓机制，相信币安初心是好意，培养长期投资思维。现在这个机制后果是让项目方，做市商，交易所Liquidity先跑，而VC在漫长的解锁中归零。VC本来承担了一级市场最大的风险，却还要承担最晚退出风险，明显和传统投资市场向背，这样的后果是加密VC集体消亡，优质创业者很难融资，行业创新减少，@cz_binance 给CZ一个建议，给加密VC一个更好的退出机制，激活VC资本活跃起来，才能有利于行业创新，也更加有利于交易所上线优质资产。

一个币的价格方向向来不是散户的交易行为决定的

@huojichuanqi 是的，没错，低垂的果实已经不好采摘了，需要在策略上找优化点和差异，暂时还不打算放弃这个方向

@0xDC_MA 套利太卷了

看到群里很多做套利的朋友抱怨最近没有什么机会，确实如此，最近的bot交易量明显下滑，较两个月前，现在的成交量几乎减半了， 不过由于bot性能不错，还是能稳定赚到平均每天0.5%左右的收益，捕捉到的都是转瞬即逝的机会，希望行情能好起来。#套利

太多的人为规则反而成了llm的枷锁，是这个意思吗

@huojichuanqi 新老韭菜都学乖了

币圈是真不行了，龙虾这么火，没听说大家炒什么龙虾币？？？

持续半年都断断续续有机会的币可不多啊

@ziyang54593712 我没有群 水别人的群

@0xDC_MA 啥群拉拉

mark

@thalortw 目前只做了主流两个所

@0xDC_MA 好奇翻了一下過去的文章 只做主流所嗎？還是有 DEX？

经过一段时间的调整，套利策略进入稳定收益的模式了，在开仓限制和止损上都做了更严格的限制，策略更侧重于捕捉确定性机会， 目前看起来表现非常不错，已经联系13天正盈利，虽然收益率降低了不少，但是胜在稳定，波动变得更小了， 未来会是一个不错的理财产品，能肩负起每日猪脚饭的重任

@huojichuanqi @gch_enbsbxbs 过分了

@0xDC_MA @gch_enbsbxbs 听说老家伙们现在都是100ns，扣二进制码

再给大家分享一波：高频量化套利架构与低延迟开发指南.md （我的脚本就是按照这个指南写的，这也是我跟ai沟通了很久采取的方案） # 高频量化套利架构与低延迟开发指南（行业通用版） > 目标读者：要做“高频、低延迟、延迟敏感”的量化套利系统的开发团队。 > 文档定位：不写具体代码，只讲设计方案、架构原则、性能策略和落地注意事项。 > 说明：本文是通用行业方法，不依赖你当前仓库实现。 --- ## 1. 先说结论（最重要的 8 条） 1. 高频套利系统的核心不是“策略公式有多复杂”，而是**能否稳定地更快下单**。 2. 架构必须拆成两层：**交易主链路（热路径）** + **旁路系统（监控/报表/分析）**。 3. 热路径必须“极简”：不做磁盘写入、不做慢网络调用、不做重日志。 4. 优先做**延迟预算**（每一段允许花多少微秒/毫秒），再做编码。 5. 风控必须在线且轻量，不能关；但风控逻辑也要做成常数级开销。 6. 先保证“稳定低延迟”，再追求“极限低延迟”。抖动（延迟忽高忽低）比平均值更危险。 7. 生产系统必须支持降级：旁路坏了不影响交易，单个交易所异常要可隔离。 8. 不要上来全量重写；先性能画像（profiling，白话：先测哪里慢）再动大手术。 --- ## 2. 业务目标如何转成工程指标 高频系统必须把“赚钱目标”翻译成“机器指标”。 ### 2.1 必要指标（建议） - **行情到决策延迟**（Market-to-Decision）：行情到策略出信号的时间。 - **决策到下单延迟**（Decision-to-Order）：信号到请求发出的时间。 - **端到端延迟**（E2E）：行情到交易所确认的总时间。 - **P99 延迟**：99% 请求都不超过这个时间（比平均值更重要）。 - **丢信号率**：有效机会被系统漏掉的比例。 - **撤单失败率 / 拒单率**：执行可靠性关键指标。 - **风控拦截命中率**：风险是否真的被挡住。 ### 2.2 延迟预算（示例） > 下面是“设计预算”的例子，不是固定标准。 - 行情解码：0.2ms - 盘口更新：0.2ms - 信号计算：0.3ms - 风控检查：0.2ms - 下单组包与签名：0.4ms - 网关发送：0.2ms - **主链路总预算：1.5ms（不含外部网络 RTT）** 白话：先给每段“定额”，谁超额就优化谁，不要靠感觉调优。 --- ## 3. 推荐总架构：双平面 + 模块隔离 ## 3.1 双平面架构 1. **交易平面（热路径）** 只包含：行情接入 -> 状态更新 -> 信号计算 -> 风控 -> 执行网关。 2. **旁路平面（冷路径）** 只包含：监控、日志聚合、报表、回放、策略研究、UI、告警。 白话：交易平面只做“抢机会”，旁路平面做“看和管”。 ## 3.2 逻辑数据流（推荐） `行情源 -> 归一化层 -> 内存订单簿 -> 策略引擎 -> 风控引擎 -> 执行引擎 -> 交易所` 旁路订阅： `交易平面事件 -> 消息队列/共享内存 -> 监控与分析系统` --- ## 4. 热路径设计原则（必须严格执行） ### 4.1 单一职责 - 每个模块只干一件事。 - 例如“风控模块不做日志落盘”，“执行模块不做统计报表”。 ### 4.2 无阻塞优先 - 禁止在热路径做： - 同步磁盘 I/O（白话：边交易边写文件） - 慢 HTTP 请求 - 数据库查询 - 外部 RPC 重试循环 ### 4.3 数据结构优先级高于算法花活 - 低延迟系统更看重数据搬运成本。 - 优先选择：连续内存、少拷贝、固定结构。 - 避免：频繁动态分配、大对象序列化、深拷贝。 ### 4.4 线程模型要可控 - 典型模式：`1~N 行情线程 + 1 策略线程 + 1 执行线程`。 - 尽量减少跨线程共享写，降低锁竞争。 - 能用单写多读（白话：一个线程写，多个线程读）就不要多写抢锁。 ### 4.5 日志策略 - 热路径只记关键事件（错误、风控、成交摘要）。 - 明细日志异步输出到旁路。 - 日志要节流，避免高频字符串拼接吃 CPU。 --- ## 5. 行情系统设计（延迟和正确性的根） ## 5.1 多源输入与优先级 - 主行情：WebSocket（白话：实时推送）。 - 兜底行情：REST 轮询。 - 要定义清楚“谁是主、谁是备、切换条件是什么”。 ## 5.2 归一化层 - 把不同交易所字段转成统一内部模型。 - 单位统一：价格、数量、时间戳、币种精度。 - 明确“交易所原始时间”和“本地接收时间”。 ## 5.3 新鲜度控制 - 每条行情都要判定 staleness（白话：是否过期）。 - 过期行情禁止触发下单。 - 断流时快速告警并降级。 ## 5.4 订单簿维护 - 只维护策略真正需要的层级，不要全量重建。 - 增量更新优先，快照定时校准。 - 检测序列号跳变，必要时重拉快照。 --- ## 6. 策略引擎设计（快、稳、可解释） ### 6.1 信号计算要常数级 - 高频策略尽量 O(1) 或接近 O(1)。 - 单次决策只读当前必要状态。 - 不做全局扫描，不跑重统计。 ### 6.2 机会去重与节流 - 同类机会去重，避免重复触发。 - 设置最小触发间隔，防止抖动过度下单。 - 拥塞时允许丢“过时机会”，优先最新机会。 ### 6.3 可解释输出 - 每次触发都能回答三件事： 1) 为什么触发 2) 价格依据是什么 3) 风险边界是什么 --- ## 7. 风控引擎设计（必须在线，不可旁路） ## 7.1 热路径风控（必须同步） - 单笔最大数量 - 单市场最大暴露 - 单交易所可用余额阈值 - 当日亏损阈值 - 下单频率上限 白话：这些必须在下单前立刻检查，不能“事后再看”。 ## 7.2 风控要轻量 - 风控规则尽量表驱动（配置化），不要写复杂脚本解释器。 - 结果二值化：通过 / 拦截，减少分支复杂度。 - 风控日志只输出关键字段。 ## 7.3 失败策略 - 风控模块异常时默认“保守”而不是“放行”。 - 可以按策略设置 fail-close（白话：出错就停）或 fail-open（白话：出错仍放行），但生产建议关键风控 fail-close。 --- ## 8. 执行网关设计（决定实盘成败） ## 8.1 统一下单抽象 - 内部用统一订单模型，再映射到各交易所。 - 明确区分：限价单、市价单、FOK/IOC/GTC（白话：不同成交约束）。 ## 8.2 并发执行与回报确认 - 双腿套利通常并发发单，但必须设计单腿失败回补流程。 - 回报优先走私有 WS，REST 仅兜底。 - 设定确认超时，防止执行线程卡死。 ## 8.3 幂等与去重 - 每个订单必须有唯一客户端 ID。 - 网络重试不能造成重复下单。 - 所有重试动作都要可追踪。 ## 8.4 失败恢复 - 交易所超时：分级重试（快速一次 + 慢速一次）。 - 单腿成交：立即进入应急对冲流程。 - 交易所异常：快速熔断（circuit breaker，白话：临时停用这个通道）。 --- ## 9. 状态与存储设计（热冷分层） ## 9.1 热状态（内存） - 最新盘口、最新持仓、可用余额、风险计数器。 - 强一致要求高，更新必须快。 ## 9.2 冷存储（异步） - 订单明细、成交回报、回放日志、审计记录。 - 通过异步队列批量落盘，不阻塞交易线程。 ## 9.3 事件回放能力 - 关键事件要可回放，用于复盘和问题定位。 - 回放系统与实盘系统物理隔离，防误操作。 --- ## 10. 监控与告警（没有监控就没有生产） ## 10.1 必看监控面板 - 延迟：P50/P95/P99、抖动、峰值。 - 执行：下单成功率、拒单率、撤单成功率、超时率。 - 策略：触发次数、命中率、盈亏曲线。 - 风控：拦截次数、原因分布、阈值触发。 - 系统：CPU、内存、GC（垃圾回收，白话：自动回收内存行为）、网络丢包。 ## 10.2 告警分级（建议） - P0：无法下单、订单状态不一致、风控失效。 - P1：延迟突增、拒单率突增、行情断流。 - P2：旁路服务异常、报表延迟。 --- ## 11. 语言与技术栈（实用建议） ## 11.1 常见组合 - **C++/Rust**：热路径、执行网关、订单簿维护。 - **Python**：策略研究、编排、离线分析、旁路服务。 - **Go/Java**：中间服务与后台系统（视团队能力）。 白话：不是“只用一种语言”，而是“让合适语言做合适环节”。 ## 11.2 Rust 的典型使用场景 - 低延迟行情处理 - 高并发执行网关 - 风控核心模块 不建议一开始全量重写，建议先迁最热 20% 链路。 --- ## 12. 部署与网络策略（延迟敏感系统的硬条件） ## 12.1 机房策略 - 尽量靠近交易所服务器（同城/同机房）。 - 固定低抖动网络路径。 - 主备线路独立，避免单点网络故障。 ## 12.2 系统调优（方向） - CPU 固定核绑定（pinning，白话：把关键线程固定在指定核心）。 - 减少上下文切换（白话：线程来回切换）。 - 控制后台任务抢占。 - 时间同步（NTP/PTP，白话：系统时钟尽量准确一致）。 ## 12.3 容灾 - 多实例主备，故障自动切换。 - 交易所级别熔断与隔离。 - 限定“最大事故半径”（白话：一次故障最多影响多大范围）。 --- ## 13. 测试与上线流程（没有这部分，实盘风险很高） ## 13.1 测试层次 1. 单元测试：规则与边界条件。 2. 集成测试：交易所适配与回报流。 3. 回放测试：用历史行情重放，验证稳定性。 4. 压测：峰值行情下延迟与丢包表现。 5. 故障注入：模拟断网、超时、拒单、延迟抖动。 ## 13.2 上线节奏 - 先 shadow（影子模式，白话：只算不下单） - 再小资金灰度 - 最后逐步扩容 每一步都要有“自动回退开关”。 --- ## 14. 常见反模式（务必避免） 1. 在热路径同步写数据库。 2. 在回调里做慢 HTTP。 3. 大量 debug 日志直接打在交易线程。 4. 没有唯一订单 ID，重试后重复下单。 5. 风控放在旁路，导致“先下单后告警”。 6. 把所有功能塞进一个进程，故障不可隔离。 7. 只看平均延迟，不看 P99 和抖动。 8. 没有演练过“单腿成交失败回补”。 --- ## 15. 研发协作建议（保证长期可维护） - 每个新功能都要回答： 1) 是热路径还是旁路？ 2) 会增加多少延迟预算？ 3) 故障时怎么降级？ - PR（代码变更）必须附带： - 延迟影响说明 - 风险点 - 回滚方案 白话：高频系统不是“能跑就行”，而是“快、稳、可回退”。 --- ## 16. 一页式落地清单（可直接执行） 1. 先画出交易主链路，删掉所有非必要逻辑。 2. 给每段定义延迟预算和 P99 目标。 3. 建立在线风控最小集（余额、暴露、频率、亏损）。 4. 做旁路监控与告警，确保旁路故障不影响交易。 5. 建立单腿风险回补和熔断机制。 6. 上线前做回放 + 压测 + 故障注入。 7. 先影子模式，再灰度，再扩容。 --- ## 17. 最后一句话 高频套利系统的工程本质是：**把“时间”当成最稀缺资源管理**。 你每减少一次不必要拷贝、一次阻塞调用、一次线程争锁，都是在直接提升真实交易竞争力。