做市商爆料：10·11 暴跌之夜究竟发生了什么？

因为之前做期现套利，我朋友圈有不少做市商朋友，他们中很多都直接或间接的知道我受到了很大的损失，说来好笑，因为都做这行，这次亏钱的朋友也不少。大家通了很多电话，也很积极的互相提供了很多证据，真相也越来越清晰。

我是学纯理科出身，骨子里有一股较真劲，也很看不惯有心之人借这此机会搞一些很下作的事情，我只想让大家知道那天到底发生了什么，币安到底有没有责任，他们给出的赔偿到底跟应付的责任是否相符。既然都走到这一步了，对我个人来讲也没有什么隐私可言了（我的UID好几天前就发给SISI了，他们也知道我是发这些帖子的人，但是我想说我很尊重币安的一点是，截止现在没有任何币安官方的人威胁或者阻止我发声，这点我很感谢币安，我会继续站在事实的基础上为我们受害者争取权益的。），我北京事件10月11日，爆仓了一个390~410万美元左右的账户（因为币价有波动，爆仓前24小时账户余额就在这个区间，具体可以看下面我的截图。）账户最后完成清算后还剩0.22美元。我的从22年开始几乎只使用币安一家交易所，所以并没有任何一家交易所或者币安任何维度上面的任何竞争对手给过我一分钱来做这些事，我接下来将用第一人称视角，从我圈内好友C的角度，完整的复盘那晚上发生了什么，并且以下内容我们根据我们掌握的证据反复推敲过多次，我可以为真实性担保。

我是812.eth的做市商好友C，10 月 11 日清晨 05:12（UTC+8）那一刻，市场的开始加速下跌，我正常运行1137天的完整_风控体系和算法系统，第一次在币安遇上了物理限制！

我的策略的第一反应并不是“加码去赌”，而是进行预先设定的回撤、风控执行：降低暴露、快速减仓。为此，Bot多笔持仓依次下达 ReduceOnly/Close 指令——这种只会“减而不增”的订单，在任何健全的撮合系统里都应当是最后一道保险：行情越差，它越该被优先放行，让风险有退路。

但这一次，像是有人把消防通道从里面反锁。

日志读写上 NEW_ORDER_REJECTED（-2010）， 随即大片的 “ReduceOnly Order Failed”（-4118、-2022）与 “Server is busy, please try again later”（-1008）以及 HTTP 503 “Service Temporarily Unavailable” 持续出现。

BOT在 DOGE 和 XRP 上的减仓尝试在不停重试——DOGE 一次就尝试卖出 3,000,000 枚来把 3,413,001 的仓位迅速压下去，当时抵押金约 656,832 美元、未实现亏损约 -266,118 美元；XRP 也要求把 7,326.10 减到约五分之一（下 5,860.88 的 ReduceOnly）。然而同一时段、同一类安全订单，几乎每次都被同样的错误码挡回。

在随后的 106 分钟里，BOT围绕同一目标做了 200 多次减仓尝试，全部无功而返，仓位被迫在最差的时段裸露在市场里，风险像漏水一样越积越深，最终溃堤成实损：DOGE 亏损约 443,835 USDT、XRP亏损约 148,000 USDT，总计亏损 591,835 USDT。这些数字、时间戳与错误码在我们的日志中都有明确记录与相互印证。05:12–05:16，我们先后识别到 SOL、BTC、DOGE、ETH、XRP 的风险并采取减仓动作，首次出现 NEW_ORDER_REJECTED（-2010），随后 ReduceOnly 被拒（-2022/-4118）；

05:15–05:16 开始出现 HTTP 503 与 -1008，DOGE、XRP 的风控减仓单连续失败；

05:16–07:02 我们持续超过 200 次的重试无果，几乎100%的拒绝率，仓位无法缩小，未实现亏损持续扩大，最终转化为清晰可复盘的实损数字。

这些错误码可能听起来有点难理解，你可以简单币安的故障信号分成两层：传输/基础设施层与业务/撮合风控层。前者是 HTTP 层 的状态码，例如 503——直白地告诉你“服务不可用/过载”；

后者是 API 返回体里的业务错误码（JSON 的 code 字段），例如 -1008（Server is busy）、-4118（ReduceOnly 失败）、-2022（ReduceOnly_Rejected）、-2010（新订单被拒）。

我们的日志显示，两类信号在关键时段同时大量出现：-1008 与 503 说明基础设施与排队机制已经“红灯”，而 -4118/-2022 则说明本该被优先放行的减仓/风控单被业务系统主动拒绝，这两者捆绑出现，结论就非常清楚——这不是用户侧的网络问题，而是平台或其服务商的系统性问题。且不是只发生在某一个账户、某一个标的上，而是在同一时间窗内多标的、跨账户结构的系统性表现。

更关键的是，即便按他们自己的公开表述与对用户的承诺，ReduceOnly/Close 这类风控单在拥堵时应当被优先处理，不应受过载限流影响；而现实恰恰相反，这一点我们在沟通与证据中已有明确记录与质疑。同时，币安的云架构商（甩锅）在事后沟通中提及“拒单率 10%”一类口径，跟我们实际经历的几乎100%拒绝率完全不符（这里也有很多同行给出同类证据证明当时几乎是完全不可下单的状态）。我们质疑，对方却不给出可核验的统计口径、样本与审计报告，这种“说法冲在证据前面”的姿态，更加重了外界对其系统层级缺陷与事后追责标准的质疑。