CoinDCX's $16 Million Loss Explained: What Happened to the 'Retired' Wallets

On October 25, 2026, Indian crypto exchange CoinDCX confirmed it lost 15.99 million USDT — about $16 million — after an automated tool that moves customer deposits into its main wallets failed on a set of older Tron addresses, letting funds build up at an address the exchange says it no longer actively used until someone drained it. The exchange is covering the loss itself and says customer balances weren’t touched, but the confirmation came three days after CEO Sumit Gupta publicly called the same reports a “false alarm,” and outside investigators dispute parts of CoinDCX’s explanation.

What actually happened, in order

Blockchain trackers first flagged the problem on October 21, 2026, when roughly 15.99 million USDT and 5,783.81 TRX moved out of CoinDCX-linked deposit wallets on the Tron network (CryptoTimes). Independent on-chain researcher Darcy, along with blockchain data firm Bitquery, reported that within about 18 hours the funds had been split up and routed to deposit addresses at major exchanges including Binance, OKX, and Gate — a pattern consistent with an attempt to launder the proceeds quickly before they could be frozen (crypto.news).

The next day, October 22, on-chain investigator ZachXBT escalated the situation publicly, posting on X that CoinDCX’s founders had privately and publicly denied anything was stolen, and telling users to withdraw their funds from the exchange while the dispute played out (CryptoTimes). Around the same time, Gupta told users on X that the breach reports sounded like “a false alarm.”

CoinDCX spent the following days investigating internally. On October 25, it reversed course: in a company blog update, it confirmed the loss, stating plainly that the sweeping failure “led to a loss of 15.99 million USDT which was absorbed by the company” (The Block).

CoinDCX’s explanation: a sweeping failure, not a hack

CoinDCX’s account centers on a piece of back-end infrastructure most users never think about: a deposit-sweeping service. When a customer sends crypto to an exchange, it usually lands at a unique deposit address first, and an automated process periodically “sweeps” those balances into the exchange’s main, more heavily secured wallets. CoinDCX says this sweeping service stopped working for a period on a set of Tron wallets it had stopped actively using after its prior 2025 security incident — so instead of being swept into secure storage, incoming deposits quietly accumulated at an address nobody was actively monitoring, until it was drained.

By this account, the incident isn’t a hack in the traditional sense of stolen private keys or a broken smart contract — it’s closer to an operational and monitoring failure: money sitting somewhere it shouldn’t have been able to sit, for long enough that whoever found it could take it. CoinDCX says current, active hot and cold wallets were not involved, and that all affected users’ deposits have since been credited back to their accounts normally.

The dispute: were these wallets really “retired”?

CoinDCX’s framing — that the affected wallets were legacy infrastructure retired after its 2025 breach — is the part outside investigators are pushing back on. ZachXBT said at least one of the flagged deposit addresses was still being used by a liquidity provider for roughly ten months after that 2025 incident, and was swept into CoinDCX’s current hot wallet as recently as April or May 2026, according to reporting that cites his findings (crypto.news). Bitquery’s on-chain analysis reportedly challenges CoinDCX’s claim that the addresses had sat untouched since mid-2025.

The distinction matters for anyone trying to judge how risky this is: “a wallet we fully decommissioned over a year ago just happened to still hold stray deposits” is a very different failure than “a wallet we were still actively routing money through until a few months ago lost its monitoring without us noticing.” CoinDCX hasn’t published a detailed technical post-mortem reconciling the two accounts, and as of this writing the gap between the company’s story and investigators’ on-chain findings remains unresolved.

Not CoinDCX’s first multi-million-dollar incident

This is CoinDCX’s second major loss in under a year and a half. In July 2025, the exchange disclosed that attackers drained roughly $44.2 million from an internal company account used for liquidity provisioning — not customer wallets — after what CEO Gupta described at the time as a “sophisticated server breach.” That incident also became public via ZachXBT, who flagged the outflow on X about 17 hours before CoinDCX itself confirmed it. CoinDCX absorbed that loss from its own reserves, suspended withdrawals for roughly two weeks as a precaution, and offered a bounty of up to 25% of any funds recovered. Some investigators suspected North Korea’s Lazarus Group was involved, though formal attribution was never confirmed (Decrypt).

The pattern across both incidents — a loss surfaces via independent blockchain investigators first, CoinDCX’s public response lags or initially downplays it, and the company ultimately absorbs the loss itself rather than passing it to customers — is now a repeat storyline for the exchange, even though the underlying technical causes (an alleged server compromise in 2025, a sweeping-tool failure in 2026) are different.

July 2025 vs. October 2026: how the two incidents compare

	July 2025 breach	October 2026 incident
Amount lost	~$44.2 million	$15.99 million ($16M)
What was hit	Internal liquidity-provisioning account	Legacy Tron deposit wallets
Stated cause	“Sophisticated server breach”	Automated deposit-sweeping service failure
Who flagged it first	ZachXBT, publicly, ~17 hours after	On-chain tracker “Darcy” / Bitquery
Company’s initial public response	Confirmed within ~10 minutes of ZachXBT’s post	CEO called early reports a “false alarm”
Time to full confirmation	Same day	~3-4 days
Customer funds affected?	No, per CoinDCX	No, per CoinDCX
Resolution	Absorbed loss, withdrawals paused ~2 weeks, bounty offered	Absorbed loss; no withdrawal suspension reported
Suspected attacker	Possibly Lazarus Group (unconfirmed)	Not publicly attributed as of this writing

Why “legacy wallets” are a recurring risk across the industry

CoinDCX isn’t the first exchange to run into trouble with old, deprioritized infrastructure. Whenever an exchange migrates to new wallet architecture — often because of a prior incident, as CoinDCX did after 2025 — it has to actually decommission the old addresses: redirecting any deposit flows still pointed at them, sweeping out residual balances, and removing them from active monitoring entirely. If any of those steps is incomplete, an old wallet can keep quietly receiving funds long after the team mentally considers it “retired,” with nobody watching closely because it’s no longer treated as live infrastructure. That gap between what a team believes is dead infrastructure and what’s actually still reachable on-chain is exactly the kind of blind spot outside forensics firms like Bitquery and independent researchers like ZachXBT have repeatedly caught across the industry, on CoinDCX and other exchanges alike.

What this means if you keep funds on an exchange

A few practical points worth taking from this, regardless of how the dispute over “retired” wallets is eventually resolved:

• An exchange’s first public statement about a suspected incident is not the final word. In both of CoinDCX’s incidents, independent on-chain researchers identified and publicized the problem before or faster than the exchange’s own communications caught up. Treat an early denial with some caution until the exchange publishes specifics.
• “Customer funds are safe” claims deserve scrutiny, not automatic trust. CoinDCX says active user wallets weren’t touched in either incident, and absorbing a loss from company funds rather than user balances is the right outcome when it happens — but that’s a claim to watch for confirmation on, not take as settled the moment it’s made.
• Operational failures are a real exchange risk category, separate from “getting hacked.” A sweeping tool silently failing, or an old wallet not being fully decommissioned, doesn’t require a sophisticated attacker finding a smart-contract bug or stealing a private key — it just requires a gap in internal process that goes unnoticed until outside researchers or an opportunistic actor finds it.
• Self-custody removes this specific risk category entirely. None of this — sweeping tools, deposit-address lifecycle management, internal monitoring gaps — applies to funds you hold yourself in a wallet you control. For a deeper look at a different kind of exchange-side failure, see our explainer on how $387 million disappeared from Bitget without a stolen private key.

The takeaway

CoinDCX’s confirmed $16 million loss wasn’t caused by a stolen private key or a classic external hack — by the exchange’s own account, it was an internal deposit-sweeping tool that silently stopped working on old wallets, letting customer deposits pile up somewhere unmonitored until they were drained. CoinDCX says it’s absorbing the full loss and that active customer funds were never at risk, but independent investigators dispute how “retired” those wallets actually were, and the exchange’s initial public denial — walked back only after days of pressure — echoes the same slow-disclosure pattern from its $44 million breach fifteen months earlier. Until CoinDCX publishes a fuller technical account, the responsible read is: the stated numbers and the “customers weren’t affected” claim appear consistent across reporting, but the root cause and whether it’s genuinely fixed remain open questions.

This is education, not financial advice. Exchange-side incidents — whether hacks or internal operational failures — are a real and recurring risk of keeping crypto on any platform. Do your own research, and consider self-custody for funds you don’t need for active trading.