做市商爆料：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%拒绝率完全不符（这里也有很多同行给出同类证据证明当时几乎是完全不可下单的状态）。我们质疑，对方却不给出可核验的统计口径、样本与审计报告，这种“说法冲在证据前面”的姿态，更加重了外界对其系统层级缺陷与事后追责标准的质疑。

为什么我们很纠结到底是10%的拒绝率还是100%的拒绝率，是关乎ReduceOnly 的本质：它是“拯救阀门”，设计目标就是在系统拥堵时也要被优先执行，把正在熊熊燃烧的风险从账户里抽走。 当系统宣称过载时（-1008/503），不应当把风控减仓订单一并“关在门外”；而事实是，在 05:12–07:02 的关键窗口，这些风控单被持续拒绝，优先级被反转，和平台对外的“ReduceOnly 优先”承诺发生了直接冲突（这个优先级在币安的文档里面明确有写），这一点在我们与币安的沟通与提供的证据中都有明确陈述。这不是“偶发网络抖动”，而是跨交易对、跨账户类别、跨分钟级的同型报错组合，集中指向系统层面的异常：在最该“保底”的一刻，系统选择了让风控单排队甚至直接拒绝。

大家都甩锅做市商抽走流动性，让价格自由落体，其实事实跟这个完全相反！市场并不是没有买盘——恰恰相反，极端波动时，做市商（MM）才是最愿意、也最有能力接住下坠之刃的那群人：他们带宽大、风控严格、反应快，钱多，靠不断双边报价来“铺路垫底”。如果整个系统真的没有任何问题，全市场可能没有一个用户愿意以0.1，0.01美元一个的价格去购买一个前50的代币ATOM呢？就是因为没法买，所以ATOM的价格才能跌到0.001，修改K线的尝试我们猜测也是企图掩盖这件事实。

在 10/11 这段时间里，当带宽最高、优先链路和订单排序最靠前的大型市商都被拒之门外，遭遇了上述系统层面阻塞与拒单，本该托底的买单进不去。更不用说零散的散户和普通策略了。于是，订单簿的买方像被抽走了支撑，卖单仍然不停砸下，内外流动性像被按下了暂停键。此时再想“等一等、挺一挺”，你等不到的是成交确认，你等来的是更大的滑点与更坏的定价（而发生此事进行时我正在睡觉）。

这一点在 Benson 发布的 “Binance Deviation Report” 里有清楚的侧写：他把极端压力期各大交易所的现货价格对齐比对，结论非常刺眼——作为全球流动性最好的交易所，币安的价格偏离却更深、更久。（参见：Benson 的贴文与偏差报告）Benson 的图表把这种“相对其他交易所更深的低点/更异常的轨迹”一张张摊开，给我们提供了横向对照的证据：这不是我们的账户孤例，而是全场层面的结构性失灵在价格上的投影。

常识是：流动性越深的池子，越不该在同一时刻跌得比小池子还狠，因为深池子买盘更多、接力更密；但这次，深池子反而成了“下探的那一个”。为什么？一旦“能下单”的机制被系统性阻塞，本该大量涌入承接的买单无法进入，订单簿失去厚度，报价质量塌陷，于是“全球最大的流动性场”在短时间内变成了“卖压最强、承接最弱”的地方，价格自然更深更快地穿透。

更糟的是，币安并不只是一家交易所，它还是“定价器”。市面上大量的指数价、标记价（mark price）、资金费率与强平阈值，都直接或间接把币安的价格作为关键输入。当最大的“价格源”在极端时刻跌得更深，那些把它当方向盘的衍生品平台、风险引擎、指数编制器就会跟着拐得更急，强平/减仓的触发阈值被提前、被放大，于是别的交易所也开始被动加速。这不是某家平台的“单点事故”，而是一种“病毒式传导”：币安侧因机制阻塞而诞生的异常价格，沿着指数与标记价的联动链条扩散到外部市场，触发更多平台的减仓、强平、再度下探；外部市场的再下探又回流到币安的指数与风控，形成互相踩踏的螺旋效应。在这条传导链里，交易者的“再努力”都敌不过“下不了单”的现实：当系统把唯一的逃生口封住，勇敢者与谨慎者的命运并无二致，唯一不同的是谁先被“没收了选择权”。

现在，补上一个往往被忽视但至关重要的机制细节：PM（Portfolio Margin）账户的一键平仓（Close All Positions）。这个功能允许用户选择在该 PM 账户中抵押的资产类型，比如 ETH、BTC、LTC、各种稳定币，或者质押代币如 WBETH 和 BNSOL。

通过这个功能，系统可以将你的所有持仓直接平仓为你所指定的币种，非常适合进行币本位结算。问题在于，这个功能只能在统一账户（Portfolio Margin Account）界面上手动操作，既没有 SDK，也无法通过 API 实现，官方也没有公开相关的技术文档。

从这个细节可以推测：针对机构大户的统一账户在执行一键平仓时，可能没有进行 Margin Check（保证金检查）或风险比率审查，或者至少其逻辑极不完善。这可能是风险控制系统的重大缺陷之一。例如，当时 WBETH 跌至 460 美元、BNSOL 跌至 37 美元的异常价格，很可能就是由此机制问题引发的。

架构层面看，PM 系统仍然非常不成熟：它的端点几乎是“经典账户（Classic Account）”的镜像，包括钱包结构，而在这个镜像之上再临时搭建了一层实时监控系统，用来检查保证金、监控风险抵押率、执行清算。一旦叠加做市商撤单、买盘流动性真空，就极容易触发连锁反应：首先系统会接管杠杆 2 倍以上的 PM 账户；接着影响 1.5 倍杠杆账户；最后波及到 1 倍左右杠杆账户。PM 清算系统在高并发状态下的表现极差，形成所谓的“死亡螺旋（Death Spiral）。

据我们了解，他们目前正在紧急修复，但至少在 10·11 事件之前，这个系统确实存在严重问题。（这段为我们基于实际使用体验与公开材料梳理出的机制侧画像，与上文的拒单/过载现象相互印证。）

把这些线索串成同一根轴心：极端波动触发风控 → 我们按规则下达 ReduceOnly/Close → 平台在最关键时刻以 -4118/-2022/-1008/503 的组合拒绝/卡死风控单 → 仓位无法按规则减小，被迫裸露 → 同时做市商因相同的系统拥堵无法提交承接买单，导致“深池”反而更深更快地下穿，出现相对其他交易所异常加深的价差（Deviation）→ 币安作为“价格源”把这种异常向指数/标记价/资金费率/强平门槛外溢 → 其它场内被动联动、加速减仓与强平，链式传导成“病毒式”暴跌 → 连环爆仓。这条链路有日志可审、有时间可对、有成交簿行为可旁证、有横向价格对比可印证：它不是情绪化的猜测，而是可复核的事实序列。相应的数值、时间戳、错误码、损益明细、对比观察与我们在材料里一一对应。

因此，我们的判断非常明确：这次连环爆仓的“始作俑者”，不是用户的贪婪或恐慌，也不只是市场天灾，而是币安平台在极端压力下的系统与机制失灵。

当 ReduceOnly/Close 这样的“最后保险”被平台以过载之名系统性拒绝，当深度最好的场内因为“买单进不去”反而跌得更深，当作为“价格源”的平台把异常定价扩散到全市场触发连环强平，这场事故的性质就已经从“价格波动”升级为“基础设施事故”。作为行业基础设施的运营方，币安有义务对这条因果链作出解释：为什么在 05:12–07:02 的 106 分钟里，风控通道被长期锁死？

为什么 ReduceOnly 的优先承诺在最需要的时候没有兑现？为什么在深池子里却出现了比浅池子更深的下穿？我们不需要情绪来支撑这个结论——把日志、错误码与价格偏离的图表摆在一起，把撮合优先级的常识与公开承诺并排，对齐时间轴，再对照我们的损益就够了。市场风险可以由交易者自行承担，但系统风险不应该由交易者买单；当交易者已经采取了所有合理的降险动作，却被平台本身的门禁拦下，那么随之而来的损害，其责任就不在交易者一方。这就是我们看到的事实与我们得出的结论。

带着上述疑问？我们要求索赔，要求binance提供撮合引擎审计报告、和PM账户保证金检查、清算的系统日志。得到都是搪塞，漠视、甚至币安相关人士直接告诉我要是赔了我就不知道要赔多少钱（因为像我朋友812.eth这样的合约散户是病毒蔓延的最后一层，也是损失最大的一个群体。）

我们并非个例，我们已经从不同渠道获悉各种PM账户遭遇“1011”事件的不同损失。

这不由让我们想起CFTC/SEC起诉FTX中关于（matching engine）中优先链路免于自动清算风险引擎，大型市商被排除在ADL协议外。由于被判决故意设计，CFTC和SEC命令该案赔付投资者127亿美金。

以及更多系统设计故障赔付或被监管当局命令、涉嫌犯罪移交的拓展。

只讲述事实，只追求公平对待。