Because I previously engaged in spot-futures arbitrage, I have many friends who are market makers. Many of them knew directly or indirectly about the significant losses I had incurred. It's funny to say, considering we're all in this business, many of us lost money this time. We had many phone calls and actively shared evidence with each other, and the truth became increasingly clear.
I'm a science major, and I have a serious nature. I can't stand those who exploit this opportunity to commit despicable acts. I just want everyone to know what exactly happened that day, whether Binance was responsible, and whether the compensation they offered commensurate with their liability. Now that it's come to this, I no longer have any privacy (I sent my UID to SISI several days ago, and they know I was the one who posted these messages. However, I want to say that I respect Binance deeply, and to date no one from Binance has threatened or tried to stop me from speaking out. I'm very grateful for this, and I will continue to fight for the rights of our victims based on the facts). In the Beijing incident, on October 11th, an account with approximately $3.9 to $4.1 million was liquidated (due to price fluctuations, the account balance was within this range 24 hours before the liquidation; see the screenshot below for details). After the final liquidation, the account had $0.22 left. I have almost exclusively used Binance since 2002, so no exchange or any competitor of Binance in any dimension has given me a penny to do these things. Next, I will use a first-person perspective, from the perspective of my friend C in the circle, to fully review what happened that night. The following content has been repeatedly scrutinized many times based on the evidence we have, and I can guarantee its authenticity.
I’m friend C, the market maker at 812.eth. At 05:12 (UTC+8) on the morning of October 11th, the market began to decline at an accelerated pace. For the first time on Binance, I encountered physical limitations on my complete risk control system and algorithmic system, which I had been operating normally for 1,137 days!
My strategy's first reaction isn't to "double down," but rather to implement pre-set drawdowns and risk management strategies: reducing exposure and rapidly reducing positions. To this end, the bot sequentially issues ReduceOnly/Close commands on multiple positions. These "reduce, not increase" orders should be the last line of defense in any robust matching system: the worse the market, the more they should be prioritized, providing a way out for risk.
But this time, it looked like someone had locked the fire escape from the inside.
The log read and write messages show NEW_ORDER_REJECTED (-2010), followed by a large number of "ReduceOnly Order Failed" (-4118, -2022), "Server is busy, please try again later" (-1008), and HTTP 503 "Service Temporarily Unavailable" errors.
BOT repeatedly attempted to reduce its DOGE and XRP positions. He attempted to sell 3,000,000 DOGE tokens at once to quickly reduce his 3,413,001 DOGE position, resulting in a collateral requirement of approximately $656,832 and an unrealized loss of approximately -$266,118. He also requested to reduce XRP from 7,326.10 to approximately one-fifth (by placing a ReduceOnly order of 5,860.88). However, the same safety orders, executed during the same period, were almost always rejected with the same error code.
Over the next 106 minutes, the bot made over 200 attempts to reduce its positions, all to no avail. This left its positions exposed to the market at the worst possible time, and the risk accumulated like a leak, ultimately collapsing into actual losses: approximately 443,835 USDT in DOGE and 148,000 USDT in XRP, for a total of 591,835 USDT. These numbers, timestamps, and error codes are clearly documented and corroborated in our logs. From 05:12–05:16, we identified risks in SOL, BTC, DOGE, ETH, and XRP, and took steps to reduce our positions. The first occurrence was a NEW_ORDER_REJECTED (-2010), followed by a ReduceOnly rejection (-2022/-4118).
05:15–05:16 HTTP 503 and -1008 errors began to appear, and risk control orders to reduce positions in DOGE and XRP continued to fail;
05:16–07:02 We tried over 200 times without success, with an almost 100% rejection rate. We were unable to reduce our positions, and our unrealized losses continued to expand, ultimately turning into clear and reproducible actual loss figures.
These error codes may sound a bit difficult to understand. You can simply divide Binance's fault signals into two layers: the transmission/infrastructure layer and the business/matching risk control layer. The former is the HTTP status code, such as 503, which directly tells you "service unavailable/overloaded";
The latter is the business error code in the API response body (the code field in JSON), such as -1008 (Server is busy), -4118 (ReduceOnly failed), -2022 (ReduceOnly_Rejected), and -2010 (New order rejected).
Our logs show a significant simultaneous occurrence of two types of signals during a critical period: -1008 and 503, indicating that the infrastructure and queuing mechanisms are failing, while -4118/-2022 indicate that orders for reducing positions or risk control that should have been prioritized were actively rejected by the business system. The combined presence of these two signals clearly indicates this isn't a user-side network issue, but rather a systemic issue with the platform or its service provider. Furthermore, this isn't limited to a single account or asset, but rather a systemic phenomenon across multiple assets and accounts within the same time window.
More importantly, even according to their public statements and promises to users, risk control orders like ReduceOnly/Close should be prioritized during periods of congestion and shouldn't be subject to overload throttling. The reality is the exact opposite, a point we've clearly documented and challenged in our communications and evidence. Furthermore, Binance's cloud infrastructure provider (who shifted the blame) cited a "10% rejection rate" in subsequent communications, completely inconsistent with the near-100% rejection rate we experienced (many peers have also provided similar evidence demonstrating a near-total impossibility of placing orders at the time). Despite our concerns, they refused to provide verifiable statistical data, samples, or audit reports. This "claims ahead of evidence" approach has only exacerbated external doubts about their system-level flaws and subsequent accountability standards.
The reason we're so concerned about whether the rejection rate is 10% or 100% is because ReduceOnly is essentially a "rescue valve," designed to prioritize execution even during system congestion, removing burgeoning risk from accounts. When the system declares an overload (-1008/503), risk reduction orders shouldn't be shut out. However, during the critical window of 05:12–07:02, these risk reduction orders were consistently rejected, their priority reversed. This directly conflicts with the platform's external commitment to "ReduceOnly priority" (this priority is clearly stated in Binance's documentation), a point clearly outlined in our communications with Binance and the evidence we provided. This isn't just "infrequent network jitter," but rather a consistent pattern of errors across trading pairs, account types, and minutes, pointing to a system-level anomaly: at the very moment when it should be "guaranteed," the system chose to queue or even reject risk reduction orders.
Everyone blames market makers for draining liquidity and causing prices to free fall, but the truth is completely the opposite! It's not that there's no buying in the market—quite the contrary. During periods of extreme volatility, market makers (MMs) are the ones most willing and able to catch the falling blade: they have vast bandwidth, strict risk controls, quick reactions, and ample funds, paving the way by constantly quoting two-way prices. If the entire system truly had no issues, wouldn't a single user in the market be willing to buy a top-50 token, ATOM, at $0.10 or $0.01? It's precisely because they can't buy it that the price of ATOM has plummeted to $0.001. We suspect the attempt to manipulate the K-line chart is an attempt to conceal this fact.
During the period between October and November, large market makers with the highest bandwidth, priority links, and top order queues were shut out, encountering the aforementioned system-level congestion and order rejections. Buy orders that should have supported the bottom of the market couldn't enter. This, not to mention individual retail investors and common strategies, meant that support was blocked. As a result, the buy side of the order book seemed to have been stripped of support, while sell orders continued to pour in, as if both internal and external liquidity had been paused. At this point, if you still want to "wait a little longer, hold on," you won't get a trade confirmation, but instead will face greater slippage and worse pricing (and I was sleeping while this happened).
This is clearly highlighted in Benson's "Binance Deviation Report." He compared spot prices across major exchanges during periods of extreme stress, and the conclusion is stark: Binance, the world's most liquid exchange, experienced deeper and longer-lasting price deviations. (See: Benson's Post and Deviation Report .) Benson's charts illustrate these "deeper lows and more unusual trajectories relative to other exchanges," providing comparative evidence: this isn't an isolated case in our account, but rather a reflection of market-wide structural failures on prices.
Common sense dictates that deeper liquidity pools shouldn't experience a sharper decline than smaller pools at the same time, as deeper pools have more buying and a more frequent backlog. However, this time, the deeper pools were the ones that "exploded." Why? Once the order-placing mechanism was systematically blocked, the flood of buy orders that would have otherwise flooded in were prevented from entering. The order book lost depth, and quote quality deteriorated. Consequently, the "world's largest liquidity market" quickly became the site of the "strongest selling pressure and weakest backlog," allowing prices to naturally penetrate deeper and faster.
To make matters worse, Binance isn't just an exchange; it's also a price-setter. Numerous market indices, mark prices, funding rates, and forced liquidation thresholds all directly or indirectly rely on Binance's price as key inputs. When the primary "price source" plummets further during extreme moments, the derivatives platforms, risk engines, and index compilers that rely on it for guidance will veer even more sharply, advancing and amplifying the thresholds for forced liquidation and position reduction, prompting other exchanges to also accelerate their movements. This isn't a single point of failure on a single platform, but rather a viral transmission: abnormal prices, caused by a clogged mechanism on Binance's side, spread through the chain of indices and mark prices to the external market, triggering position reductions, forced liquidations, and further declines on other platforms. Further declines in the external market then feed back into Binance's indexes and risk control systems, creating a mutually reinforcing spiral. In this transmission chain, no matter how hard traders try, they cannot defeat the reality of “not being able to place an order”: when the system blocks the only escape hatch, the fate of the brave and the cautious is no different. The only difference is who loses the option first.
Now, let's cover an often-overlooked but crucial detail: the one-click "Close All Positions" feature for Portfolio Margin (PM) accounts. This feature allows users to select the type of asset collateralized in their PM accounts, such as ETH, BTC, LTC, various stablecoins, or staked tokens like WBETH and BNSOL.
This feature allows the system to directly liquidate all your holdings into the currency you specify, making it ideal for currency-margin settlement. However, this feature can only be manually operated within the Portfolio Margin Account interface. There's no SDK or API implementation available, and no official technical documentation has been released.
This detail suggests that the unified account system for institutional investors may not have performed margin checks or risk ratio reviews when executing one-click liquidation, or at least the logic was extremely flawed. This could be a major flaw in the risk control system. For example, the abnormal price drops of WBETH to $460 and BNSOL to $37 at the time were likely caused by this mechanism.
From an architectural perspective, the PM system remains highly immature: its endpoints are essentially mirror images of "Classic Accounts," including the wallet structure. A temporary real-time monitoring system has been built atop this mirror to check margin, monitor the risk-to-collateral ratio, and execute liquidations. Once market makers withdraw orders and a liquidity vacuum occurs on the buy side, a chain reaction is easily triggered: first, the system takes over PM accounts with leverage exceeding 2x; then, accounts with leverage of 1.5x; and finally, accounts with leverage of around 1x. The PM liquidation system performs extremely poorly under high concurrency conditions, creating a so-called "death spiral."
We understand they're currently working on an urgent fix, but at least before the October 11th incident, this system did have serious issues. (This section describes the mechanism based on our actual user experience and publicly available materials, and corroborates the order rejection and overload issues mentioned above.)
These clues connect to a common thread: extreme volatility triggers risk control → We issue ReduceOnly/Close orders according to rules → The platform rejects/blocks the risk control orders at the most critical moment with a combination of -4118/-2022/-1008/503 → Positions cannot be reduced according to rules, forcing them to be exposed → Simultaneously, market makers are unable to submit buy orders due to the same system congestion, causing the "deep pool" to dive deeper and faster, resulting in an abnormally widened price deviation compared to other exchanges → Binance, as the "price source", transmits this anomaly to the index/mark price/funding rate/forced liquidation threshold → Other exchanges are passively linked, accelerating position reduction and forced liquidation, and the chain reaction is a "viral" plunge → a series of margin calls. This chain of events is supported by logs for review, timelines for verification, transaction book activity for collateral, and horizontal price comparisons for verification: it is not emotional speculation, but a verifiable sequence of facts. The corresponding values, timestamps, error codes, profit and loss details, and comparative observations correspond one-to-one with those in our materials.
Therefore, our judgment is very clear: the "culprit" behind this series of margin calls was not the greed or panic of users, nor was it just a natural market disaster, but the failure of the Binance platform's systems and mechanisms under extreme pressure.
When "safeguards" like ReduceOnly/Close are systematically rejected by the platform under the pretext of overload, when the deepest market plunges further due to a lack of buy orders, and when the platform, acting as the "price source," spreads abnormal pricing throughout the market, triggering a cascade of forced liquidations, the nature of this incident has escalated from "price volatility" to "infrastructure incident." As the operator of industry infrastructure, Binance has an obligation to explain this chain of causation: Why was the risk control channel locked for 106 minutes from 05:12 to 07:02?
Why didn't ReduceOnly's priority commitment materialize when it was most needed? Why did the deep pool experience a deeper dip than the shallow pool? We don't need emotion to support this conclusion—just juxtapose logs, error codes, and price deviation charts, align common sense about matching priorities with public commitments, align timelines, and compare our profits and losses. Traders can bear market risk, but they shouldn't be responsible for systemic risk. When a trader has taken all reasonable risk mitigation measures but is blocked by the platform's own access control, the trader is not responsible for the resulting losses. This is the facts we observe and the conclusion we draw.
With these questions in mind, we filed a claim, demanding Binance provide an audit report of the matching engine, as well as system logs for margin checks and liquidations. All we received were evasive responses and indifference. Binance representatives even told us directly that if I lost money, I didn't know how much I would have to pay (because retail traders like my friend 812.eth were the last group to be affected by the virus and suffered the most).
We are not an isolated case. We have learned from different channels that various PM accounts suffered different losses in the "1011" incident.
This reminds us of the CFTC/SEC lawsuit against FTX regarding its matching engine's priority link exemption from the automatic liquidation risk engine, which excluded large market makers from the ADL protocol. The CFTC and SEC ordered FTX to pay $12.7 billion in compensation to investors due to a ruling of deliberate design.
