
The wallets were supposed to belong to CoinDCX’s past. After a July 2025 security breach, the Indian exchange had replaced the compromised infrastructure and told customers to use new deposit addresses. Some customers kept sending money to the old ones, however, and the company kept crediting their accounts while a separate service moved the coins out. In October, that second step failed.
Summary
- CoinDCX says 15.99 million USDT was lost after deposits accumulated in deprecated wallets when its automated sweeping service stopped working for an undisclosed period.
- The exchange says it credited customers when money arrived and absorbed the loss itself, leaving their displayed balances, active wallets and trading systems unaffected.
- Bitquery traced 40 affected TRON addresses, including one holding roughly 15.82 million USDT from 88 deposits that had not been moved onward.
- About 9.63 million USDT reached addresses associated with other exchanges and Tether froze roughly 2.21 million USDT, according to Bitquery’s dated tracing.
- CoinDCX has not publicly specified how long the sweep failed, how the assets were taken or whether any of the frozen funds have been recovered.
A cryptocurrency address does not expire when an exchange retires it. Someone can save it in a withdrawal form, copy it from an old message or automate transfers to it for months. The blockchain will accept the transaction even if the exchange’s current app displays a different destination. CoinDCX chose to recognise those deposits for its customers and sweep the actual coins into newer custody. The choice protected people from losing a mistaken deposit while leaving a path through the old infrastructure.
The company’s October 25 explanation says that path broke down. It does not establish every step of the unauthorised transfer, and an outside reader cannot see the exchange’s internal ledger. The visible result is an unusually instructive custody failure: customers could have a credited balance in the app while the corresponding deposited USDT remained in an address already considered unsafe. How that gap was detected, funded and closed matters beyond the headline loss.
The retired address still had a job
CoinDCX says customers continued to deposit to addresses retired after the July 2025 incident despite guidance to use new ones. When a transfer arrived, the exchange credited the customer’s portfolio immediately. A separate automated sweeper was meant to move the cryptocurrency from the old address to a secure wallet. The customer did not have to wait for that second transfer to use the credited balance.
The design contains a trade-off. If CoinDCX refused to acknowledge an old-address transfer, a customer who reused saved instructions might appear to lose money. Crediting first gives the person an account balance quickly, but the company takes responsibility for moving or replacing the actual coins. If the sweep fails, liabilities on the exchange’s books can rise even while the coins remain in vulnerable wallets.
An old address being “deprecated” can therefore mean two different things. It may no longer be displayed to new users or intended for routine operations. It can still receive blockchain deposits, be monitored by the exchange and be used in a recovery workflow. The initial October 22 dispute turned on that distinction. CoinDCX executives said the addresses were old, while investigators pointed to continuing movements between them and the exchange’s operational wallets. The company’s later explanation acknowledged that a process continued to handle deposits there.
It is tempting to call every movement through a retired address ordinary active use, or to treat “retired” as proof no money could arrive. Neither description captures the arrangement CoinDCX has now described. The addresses were not the destinations its app wanted users to choose. They were still monitored, customers were credited for deposits and the exchange maintained a service intended to move assets onward. Such a service must work consistently if the firm is taking on the customer’s loss risk.
The money built up while the sweep failed
CoinDCX says its automated sweeping service failed “for a particular period,” allowing deposits to accumulate. It has not said when the failure began, whether alerts fired, how many customers were involved or why a large unmoved balance did not trigger an intervention before October 21. Those missing details make it difficult to judge whether the weakness lasted hours, weeks or longer.
Bitquery’s TRON transaction study counted 40 drained wallets and put 15.82 million USDT of the 15.99 million total in a single deposit address. Its analysis said the big address held 88 deposits from one depositor, none of which had been moved on since March. If the attribution is correct, the interval between those deposits and the October removal was far longer than the short delay a customer might expect from an automated sweep. The blockchain can show transfers and balances; it cannot by itself show whether each deposit was credited to a customer or how an internal monitoring alert was handled.
Bitquery also examined the small TRX payments required to move USDT on TRON. It found fee top-ups to affected deposit addresses, followed by routine transfers, including activity on October 21. An exchange must fund an address with the network’s native token when it wants that address to send USDT. The repeated pattern helps explain why investigators challenged the claim that the wallets had simply been abandoned. It does not identify who obtained the means to drain them or prove the original source of each deposit.
CoinDCX says it noticed unusual activity in its systems on October 21 and saw irregular onchain movements the next day, with reports from its community prompting a deeper investigation. The company says immediate controls prevented an impact on active wallets and trading infrastructure. Its October 25 disclosure then confirmed the 15.99 million USDT loss. These are the company’s descriptions of detection and containment; the public chain supplies the transaction record, but not the company’s internal event logs.
A customer balance and a wallet balance are different
An exchange customer generally sees an account entry, not a particular coin sitting in a segregated blockchain address assigned exclusively to them. CoinDCX’s stated policy for old addresses credited the user’s account as soon as the deposit arrived. The exchange then owed the customer the amount shown, regardless of whether its separate sweep was delayed. When the assets disappeared from the old wallet, the loss could be borne by the company if it supplied replacement funds.
CoinDCX says it did exactly that.Its confirmed-loss account says the company absorbed the 15.99 million USDT and maintains that customer balances, active wallets and operations were unaffected. That is a material distinction from an exchange passing losses through to depositors or halting withdrawals. It is also a claim that merits follow-up with reconciliation, reserve and withdrawal data, because an outside observer cannot inspect all customer liabilities merely by viewing the addresses involved in the drain.
The exchange’s account does not make the missing funds imaginary. A customer may still have the full credited balance while the company has paid for a theft or an operational loss. Financially, the firm has to fill the gap out of its own assets or recover stolen coins. Its ability to do so should be assessed from dated financial and proof-of-reserves disclosures, along with whether withdrawals continue to settle, rather than from the phrase “funds are safe” alone.
CoinDCX had previously announced a customer protection fund with an initial allocation of about $6 million in 2024. The existence of that programme does not show it funded the October 2026 loss, which is larger than the original allocation. The company says it absorbed the shortfall. A transparent follow-up would identify whether the replacement came from ordinary treasury assets, a dedicated reserve, insurance or recoveries, without asking customers to infer a funding source from an old programme’s name.
Customers who saved an old address should update their payment instructions. On a public chain the sender can still broadcast to the old destination, and the network will not know what CoinDCX’s app currently recommends. The exchange says support for deprecated addresses is temporary. If that support ends, the handling of a later accidental deposit may change. An exchange’s current in-app address is the only one a customer should rely on for a new transfer, with the asset and network checked at the time of sending.
Tracing the USDT does not identify the thief
Bitquery traced roughly 9.63 million USDT through intermediate wallets to deposit addresses it associated with OKX, Binance and Gate within 18 hours of the main transfer. A payment arriving at an exchange-associated address may give investigators a place to seek records or cooperation. It is not proof that the named exchange carried out the theft, approved it or still holds all the money. Attribution of service addresses can also be revised.
The same study said Tether froze about 2.21 million USDT across nine wallets on October 22. A freeze may prevent those particular tokens from moving, but it is not the same as restitution to CoinDCX. Reimbursement could require legal process, coordination with the issuer and confirmation of ownership. The original company statement did not announce recovered assets. Reporting the frozen sum as money already returned would overstate what is known.
The public record reveals the size and path of transactions much more readily than the method of compromise. CoinDCX referred to unknown vulnerabilities in its deprecated infrastructure. It did not say whether the October loss came from keys exposed in 2025, a later access failure or some other route. Bitquery explicitly said its analysis could not show how the person moving the funds obtained the keys. The precise technical cause needs a post-incident account from the operator, ideally with independent review.
One address holding 15.82 million USDT makes the timing especially consequential. If the coins had been swept while they arrived, that balance would not have remained at that address at the moment of the drain. Such a counterfactual does not prove the theft would have been prevented altogether, because the destination wallet and access controls would also matter. It does explain why the sweeper’s failure is not a peripheral detail: it determined how much value sat in the compromised path.
The 2025 breach was a different incident
The July 2025 incident report described a roughly $44 million loss from an internal operational account used for liquidity provisioning on a partner exchange. CoinDCX said customer assets in segregated cold wallets were not affected and that it covered the exposure from its own treasury. The new 15.99 million USDT loss is a separate October 2026 event involving deposits arriving at infrastructure retired after that earlier breach.
The connection matters because CoinDCX itself says the old infrastructure had been compromised. Once an address or its surrounding system is regarded as exposed, continuing to rescue deposits through it requires especially careful monitoring and rapid movement of funds. The old incident cannot establish that the same attacker returned, and no public evidence reviewed identifies the person behind October’s transfers. The shared infrastructure history does raise a straightforward operational question: why did so much money remain there after the danger was known?
In 2025 the exchange also spoke about security redesign and the separation of customer wallets from operational accounts. Contemporaneous coverage of the server breach described the claimed isolation of the first loss. The second incident shows that segregating primary custody is only one part of the job. Deposits pass through addresses and automated services before reaching that custody. An old intake route can create a loss even if the main cold wallets remain untouched.
After the first incident, trading and rupee withdrawals resumed and the firm reiterated that it would bear the loss. The current assurance has the same customer-facing shape, though the mechanism differs. In July 2025 an internal liquidity account was breached. In October 2026, the stated failure was a service that should have swept deposits arriving in retired infrastructure. Comparing the two incidents requires keeping those mechanisms separate; the fact that both cost the company money is not evidence of a single attacker or a repeated exploit path.
That does not mean customers have suffered a direct debit. It means the company incurred a loss while honouring the credit it says it had already given them. Both propositions can be true at once. They are easily blurred by headlines that call the event either a harmless old-wallet movement or a proven customer balance shortfall. CoinDCX has acknowledged a real company loss and denied an impact on customer balances; public data do not settle every remaining accounting question.
Why the first denial matters
When investigators first circulated the transfers, CoinDCX said its current wallets were not breached and suggested the old addresses might be producing a false alarm. The statement addressed part of the concern, namely whether primary active infrastructure had been drained, but it did not explain why funds in the old addresses appeared to have been taken. By October 25 the firm had disclosed a real loss and a failed sweeping process.
CoinDCX acknowledged that it could have communicated more proactively. Investigating a blockchain movement takes time, especially when address labels and internal balances have to be checked. A company can still say what is known and unknown early on without treating an unverified attribution as a finished finding. Here the gap between the first response and the later account let customers and independent investigators argue over whether the old system was inactive in any meaningful sense.
The most useful follow-up would give a dated timeline of the sweep outage, when monitoring first saw the accumulating balance, how many affected deposits were credited, and the measures taken to stop additional deposits from collecting. It should also distinguish money frozen at an issuer from money recovered and returned. Such detail would let customers assess the process that failed rather than rely on either an early denial or a general reassurance.
The company says trading, deposits and withdrawals continued throughout. Continued access is relevant evidence about the immediate customer experience, but it is not an audit of every asset and liability. A statement of the firm’s loss absorption, backed by updated attestations and the ability to meet withdrawals, would make the conclusion more durable. Regulators may also have reporting expectations, though no confirmed action concerning the October transfers was identified in the reviewed public record.
Retiring a wallet takes more than changing the app
An exchange can stop displaying an old deposit address; it cannot remove that address from TRON or force a sender’s saved form to forget it. It must decide whether to monitor and rescue late deposits, block the customer from credit where possible, or warn that recovery may not be possible. Every choice has consequences. A rescue service creates an obligation to keep watching, even though most customers have moved to the new address.
CoinDCX’s approach split the task in two: credit first, then sweep. Its October disclosure shows what happens when the second step quietly stops. The event is therefore about more than a compromised key. It exposes a mismatch between the accounting moment a customer is told their money has arrived and the custody moment the exchange actually moves the asset out of a vulnerable location.
The final cost to CoinDCX may change if assets are recovered. The company has reported a 15.99 million USDT loss and has not announced such recovery in its statement. For customers, the decisive questions are whether credited balances can be withdrawn, whether future deposits go to current addresses, and whether the exchange has fixed the monitoring gap. For the wider market, the lesson lies in the old address that continued doing new work. Its retirement was incomplete as long as real funds still arrived and a separate automated process was responsible for saving them.
What to watch
- Outage timeline: Look for the dates the sweep stopped, when alerts fired and when staff first noticed the balance accumulating.
- Customer reconciliation: Check for a dated accounting of credited deposits, replacement assets and completed withdrawals.
- Asset recovery: Separate USDT frozen by Tether from any coins actually returned to CoinDCX.
- Technical cause: Wait for evidence on how the deprecated wallets were drained rather than assuming the July attacker returned.
- Old-address policy: Watch whether CoinDCX changes its temporary rescue service and how it warns customers whose saved deposit instructions still point to retired addresses.
FAQ
How much did CoinDCX lose in October 2026?
The company confirmed a loss of 15.99 million USDT associated with old wallet infrastructure. It says the loss was absorbed by the company.
Were customer account balances reduced?
CoinDCX says customers were credited when deposits reached the old addresses and that their balances and withdrawals remained unaffected. Independent onchain data cannot audit its complete internal customer ledger.
Why did users send money to retired addresses?
Some had saved the old destinations and continued to use them despite guidance to switch. A blockchain address remains capable of receiving funds even after an exchange stops displaying it.
What failed?
CoinDCX says the automated service that moved deposits from old addresses to secure wallets stopped working for an unspecified period. It has not published a full technical cause.
Did the July 2025 attacker steal the October funds?
The identity and method of the October actor have not been established publicly. The old infrastructure was retired after the July incident, but the incidents are separate.
Where did the missing USDT go?
Bitquery traced about 9.63 million USDT to addresses associated with other exchanges after intermediate transfers. That tracing does not establish who controlled the recipient accounts.
Has the frozen 2.21 million USDT been returned?
Bitquery said Tether froze that amount in nine wallets. CoinDCX’s public statement did not announce that the frozen tokens had been recovered and returned.
What should a customer check before depositing?
Use the current deposit address and network displayed in the exchange app for each transfer. Do not rely on a previously saved address for a new payment. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of October 26, 2026.


Leave feedback about this