We speak with data and facts.
Because I previously engaged in arbitrage trading, I have many market maker friends in my social circle. Many of them know, directly or indirectly, that I suffered significant losses. Ironically, since we are all in this industry, there are quite a few friends who also lost money this time. We made many phone calls and actively provided each other with a lot of evidence, and the truth is becoming clearer.
I have a background in pure science, and I have a strong sense of seriousness. I also cannot tolerate those with ulterior motives taking this opportunity to engage in despicable acts. I just want everyone to know what really happened that day, whether Binance is responsible, and whether the compensation they offered corresponds to their responsibilities. Since we have come this far, there is no longer any privacy for me (I shared my UID with SISI several days ago, and they know I am the one posting these messages). However, I want to express my respect for Binance; as of now, no official from Binance has threatened or tried to stop me from speaking out. I am grateful to Binance for this, and I will continue to fight for the rights of us victims based on the facts. On October 11, during the Beijing incident, I had an account that was liquidated with a loss of around $3.9 to $4.1 million (due to price fluctuations, the account balance was in this range 24 hours before liquidation; specific details can be seen in the screenshots below). After the account was finally liquidated, only $0.22 remained. Since 2022, I have almost exclusively used Binance as my trading platform, so no other exchange or any competitor of Binance has given me a single cent to do these things. I will now recount what happened that night from the perspective of my friend C, a market maker in my circle. The following content has been repeatedly scrutinized based on the evidence we have, and I can vouch for its authenticity.
I am C, a market maker friend of 812.eth. At 05:12 (UTC+8) on October 11, the market began to accelerate its decline. For the first time in 1,137 days of operating my complete risk control system and algorithm, I encountered a physical limitation on Binance!
My strategy's first reaction was not to "increase my bets," but to execute pre-set withdrawals and risk control: reducing exposure and quickly cutting positions. To this end, the Bot issued multiple ReduceOnly/Close commands sequentially—these orders, which only "reduce and do not increase," should be the last line of defense in any sound matching system: the worse the market, the more they should be prioritized to allow for risk mitigation.
But this time, it was as if someone locked the fire escape from the inside.
The logs showed NEWORDERREJECTED (-2010), followed by a large number of "ReduceOnly Order Failed" (-4118, -2022) and "Server is busy, please try again later" (-1008), as well as HTTP 503 "Service Temporarily Unavailable" continuously appearing.
The BOT's attempts to reduce positions in DOGE and XRP kept retrying—DOGE attempted to sell 3,000,000 coins at once to quickly reduce the position of 3,413,001. At that time, the collateral was about $656,832, with an unrealized loss of about -$266,118; XRP also aimed to reduce from 7,326.10 to about one-fifth (down to 5,860.88 with ReduceOnly). However, during the same period, the same type of safe orders were almost always blocked by the same error codes.
In the following 106 minutes, the BOT made over 200 attempts to reduce positions around the same target, all in vain. The positions were forced to remain exposed in the market during the worst period, and the risk accumulated like a leak, ultimately leading to real losses: approximately $443,835 in losses for DOGE and about $148,000 for XRP, totaling $591,835 in losses. These numbers, timestamps, and error codes are clearly recorded and corroborated in our logs. From 05:12 to 05:16, we identified risks in SOL, BTC, DOGE, ETH, and XRP and took actions to reduce positions, encountering NEWORDERREJECTED (-2010) for the first time, followed by ReduceOnly being rejected (-2022/-4118);
From 05:15 to 05:16, HTTP 503 and -1008 began to appear, and the risk control reduction orders for DOGE and XRP continuously failed;
From 05:16 to 07:02, we continued to retry over 200 times without success, with an almost 100% rejection rate. The positions could not be reduced, and unrealized losses continued to expand, ultimately converting into clear and retrievable real loss figures.
These error codes may sound a bit difficult to understand. You can simply categorize Binance's failure signals into two layers: the transmission/infrastructure layer and the business/matching risk control layer. The former includes HTTP layer status codes, such as 503—plainly telling you "service unavailable/overloaded";
The latter includes business error codes in the API response body (the JSON code field), such as -1008 (Server is busy), -4118 (ReduceOnly failed), -2022 (ReduceOnly_Rejected), -2010 (new order rejected).
Our logs show that both types of signals appeared simultaneously in large numbers during critical periods: -1008 and 503 indicate that the infrastructure and queuing mechanism were "red-lighted," while -4118/-2022 indicate that the reduction/risk control orders that should have been prioritized were actively rejected by the business system. The combination of these two indicates a very clear conclusion—this is not a user-side network issue, but a systemic issue with the platform or its service providers. Moreover, this did not occur on just one account or one asset, but was a systemic manifestation across multiple assets and accounts within the same time window.
More critically, even according to their own public statements and commitments to users, ReduceOnly/Close risk control orders should be prioritized during congestion and should not be affected by overload throttling; however, the reality is quite the opposite. We have clear records and questions regarding this in our communications and evidence. At the same time, Binance's cloud architecture provider (passing the buck) mentioned a "10% rejection rate" in post-incident communications, which is completely inconsistent with the nearly 100% rejection rate we experienced (many peers have provided similar evidence proving that it was almost completely impossible to place orders at that time). We questioned them, but they did not provide verifiable statistical criteria, samples, or audit reports. This "statement rushing ahead of evidence" stance further intensified external doubts about their systemic flaws and post-incident accountability standards.
Why are we so conflicted about whether it is a 10% rejection rate or a 100% rejection rate? It concerns the essence of ReduceOnly: it is a "safety valve," designed to be prioritized for execution even during system congestion, to pull the burning risk out of the account. When the system claims to be overloaded (-1008/503), risk control reduction orders should not be "kept outside the door"; however, the fact is that during the critical window from 05:12 to 07:02, these risk control orders were continuously rejected, their priority reversed, directly conflicting with the platform's external commitment of "ReduceOnly priority" (this priority is clearly stated in Binance's documentation). This is not "occasional network jitter," but a combination of identical error messages across trading pairs, account categories, and minute levels, pointing to systemic anomalies: at the moment when it should have been "safeguarded," the system chose to queue the risk control orders or even directly reject them.
Everyone is blaming market makers for pulling liquidity and letting prices free-fall, but the truth is completely the opposite! The market does not lack buying power—in fact, during extreme volatility, market makers (MM) are the ones most willing and capable of catching the falling knife: they have large bandwidth, strict risk control, quick reactions, and ample funds, relying on continuous two-sided quotes to "pave the way." If the entire system truly had no issues, would there be a single user in the entire market willing to buy a top 50 token like ATOM at prices of $0.1 or $0.01? It is precisely because buying was impossible that ATOM's price could drop to $0.001. We suspect that attempts to modify the candlestick charts were also an attempt to cover up this fact.
During the period of 10/11, when the largest market makers with the highest bandwidth, priority links, and order sorting were all kept out and faced the aforementioned systemic blockages and order rejections, the buy orders that should have supported the market could not get in. Not to mention the scattered retail investors and ordinary strategies. As a result, the buy side of the order book seemed to lose its support, while sell orders kept pouring in, and both internal and external liquidity seemed to be paused. At this point, waiting for "a moment, holding on" would not yield a transaction confirmation; instead, you would face greater slippage and worse pricing (and during this incident, I was asleep).
This point is clearly illustrated in the "Binance Deviation Report" published by Benson: he aligned and compared the spot prices of major exchanges during periods of extreme pressure, and the conclusion is very striking—despite being the exchange with the best global liquidity, Binance's price deviated deeper and longer. (See: Benson's post and Deviation Report) Benson's charts laid out this "deeper low/abnormal trajectory compared to other exchanges," providing us with horizontal comparative evidence: this is not an isolated case of our account, but a projection of structural failure across the entire market in terms of price.
Common sense dictates that the deeper the liquidity pool, the less it should drop at the same time compared to smaller pools, because deeper pools have more buying power and tighter connections; yet this time, the deeper pool became the one that "dipped." Why? Once the mechanism for "placing orders" is systematically blocked, the buy orders that should have surged in to support cannot enter, the order book loses thickness, and the quality of quotes collapses. Thus, the "largest liquidity venue in the world" quickly turned into a place with the strongest selling pressure and the weakest support, causing prices to penetrate deeper and faster.
Worse still, Binance is not just an exchange; it is also a "price setter." A large number of index prices, mark prices, funding rates, and liquidation thresholds in the market directly or indirectly use Binance's prices as key inputs. When the largest "price source" drops deeper during extreme moments, those derivative platforms, risk engines, and index compilers that rely on it will also turn more sharply, triggering and amplifying the thresholds for liquidation/reduction. As a result, other exchanges also begin to accelerate passively. This is not a "single point incident" of a particular platform, but a "viral transmission": the abnormal prices arising from Binance due to mechanism blockage spread along the chain of indices and mark prices to external markets, triggering more platforms to reduce positions, liquidate, and further dip; the external market's further dip then flows back to Binance's indices and risk control, forming a spiral effect of mutual trampling. In this transmission chain, traders' "extra efforts" cannot overcome the reality of "unable to place orders": when the system seals off the only escape route, the fates of the brave and the cautious become indistinguishable; the only difference is who first loses their "right to choose."
Now, let's add a crucial mechanism detail that is often overlooked: the one-click close all positions feature for PM (Portfolio Margin) accounts. This function allows users to select the type of assets collateralized in the PM account, such as ETH, BTC, LTC, various stablecoins, or staked tokens like WBETH and BNSOL.
Through this feature, the system can directly close all your positions into the specified currency, making it very suitable for currency-based settlement. The problem is that this function can only be manually operated on the unified account (Portfolio Margin Account) interface; there is no SDK, and it cannot be implemented through the API, nor has the official released any relevant technical documentation.
From this detail, it can be inferred that when executing one-click close for institutional accounts, there may not have been a Margin Check or risk ratio review, or at least its logic is extremely flawed. This could be one of the significant defects in the risk control system. For example, the abnormal prices of WBETH dropping to $460 and BNSOL to $37 were likely triggered by this mechanism issue.
From an architectural perspective, the PM system is still very immature: its endpoints are almost a mirror of the "Classic Account," including the wallet structure, and on top of this mirror, a real-time monitoring system has been temporarily built to check margin, monitor risk collateral ratios, and execute liquidations. Once market maker withdrawal and buying liquidity vacuum are superimposed, it is very easy to trigger a chain reaction: first, the system will take over PM accounts with more than 2x leverage; next, it will affect 1.5x leverage accounts; and finally, it will impact accounts with around 1x leverage. The PM liquidation system performs poorly under high concurrency, forming what is known as a "Death Spiral."
As we understand, they are currently in urgent repair, but at least before the 10·11 incident, this system indeed had serious problems. (This section is a mechanism profile we have organized based on actual usage experience and public materials, corroborating the previous rejection/overload phenomena.)
Connecting these clues into a single axis: extreme volatility triggers risk control → we issue ReduceOnly/Close orders according to the rules → the platform rejects/blocks risk control orders at the most critical moment with a combination of -4118/-2022/-1008/503 → positions cannot be reduced according to the rules and are forced to remain exposed → at the same time, market makers are unable to submit buy orders due to the same system congestion, causing the "deep pool" to drop even deeper and faster, resulting in a price deviation that is more pronounced compared to other exchanges → Binance, as the "price source," spreads this anomaly to indices/mark prices/funding rates/liquidation thresholds → other on-site passive linkages accelerate reductions and liquidations, leading to a "viral" crash → a chain of liquidations. This chain has logs that can be audited, timestamps that can be verified, transaction book behaviors that can be corroborated, and horizontal price comparisons that can be validated: it is not an emotional guess, but a verifiable sequence of facts. The corresponding values, timestamps, error codes, profit and loss details, comparative observations align with our materials.
Therefore, our judgment is very clear: the "culprit" of this chain of liquidations is not the greed or panic of users, nor just a market disaster, but the systemic and mechanical failure of the Binance platform under extreme pressure.
When the "last insurance" like ReduceOnly/Close is systematically rejected by the platform in the name of overload, when the best depth in the market drops even deeper because "buy orders cannot get in," and when the platform, as the "price source," spreads abnormal pricing throughout the market triggering chain liquidations, the nature of this incident has escalated from "price fluctuation" to "infrastructure accident." As the operator of industry infrastructure, Binance has an obligation to explain this causal chain: why was the risk control channel locked for an extended period from 05:12 to 07:02?
Why was the priority commitment of ReduceOnly not fulfilled when it was most needed? Why did a deeper drop occur in a deep pool compared to a shallow pool? We do not need emotions to support this conclusion—just placing the logs, error codes, and price deviation charts together, aligning the common sense of matching priority with public commitments, and comparing our profit and loss is sufficient. Market risk can be borne by traders themselves, but systemic risk should not be borne by traders; when traders have taken all reasonable risk-reduction actions but are blocked by the platform's access control, then the resulting damage is not the responsibility of the traders. This is the fact we see and the conclusion we draw.
With the above questions in mind, we demand compensation and request Binance to provide the matching engine audit report, as well as the PM account margin checks and liquidation system logs. The responses we received were all evasive, dismissive, and even Binance-related personnel directly told me that if they compensated, they wouldn't know how much to pay (because retail contract traders like my friend 812.eth are the last layer of virus spread and also the group with the largest losses).
We are not an isolated case; we have learned about various PM accounts suffering different losses from the "1011" incident through different channels.
This inevitably reminds us of the CFTC/SEC lawsuit against FTX regarding the (matching engine) where priority links were exempt from automatic liquidation risk engines, and large market makers were excluded from the ADL protocol. Due to being found guilty of intentional design, the CFTC and SEC ordered the case to compensate investors $12.7 billion.
As well as more compensation for systemic design failures or expansions ordered by regulatory authorities, suspected criminal transfers.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
