因為之前做期現套利，我朋友圈有不少做市商朋友，他們中很多都直接或間接的知道我受到了很大的損失，說來好笑，因為都做這行，這次虧錢的朋友也不少。大家通了很多電話，也很積極的互相提供了很多證據，真相也越來越清晰。
我是學純理科出身，骨子裡有一股較真勁，也很看不慣有心之人借這此機會搞一些很下作的事情，我只想讓大家知道那天到底發生了什麼，幣安到底有沒有責任，他們給出的賠償到底跟應付的責任是否相符。既然都走到這一步了，對我個人來講也沒有什麼隱私可言了（我的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億美金。
以及更多系統設計故障賠付或被監管當局命令、涉嫌犯罪移交的拓展。
