Have you ever saved an old bank account number and kept sending money to it long after the bank closed that account? Something similar happened in crypto, only the stakes climbed into the tens of millions. An Indian exchange discovered that addresses it had already retired after a security incident the previous year continued to receive deposits. Customers got credited. The coins themselves sat waiting. Then the automated system meant to move them out simply stopped working. Nearly sixteen million dollars in USDT disappeared.
I still find the whole sequence unsettling. Not because customers lost their balances. They didn’t. The company says it covered every cent. What bothers me is how quietly a known weak point could fill up again. One address alone held more than fifteen million from eighty-eight separate deposits. That kind of accumulation does not happen overnight.
How Retired Addresses Became Active Again
After a serious breach in July 2025, the exchange replaced compromised systems and told users to switch to fresh deposit addresses. Most people did. Some did not. Old addresses live forever on the blockchain. Anyone who copied one into a withdrawal form, an automated script, or a note on their phone could keep sending funds for months. The network accepts the transfer without checking whether the exchange still wants that address.
The company chose a customer-friendly path. Whenever money arrived at a retired address, it credited the user’s account right away. A separate automated sweeper was supposed to pull the actual coins into safer custody. In theory this protected people from accidental losses. In practice it created a new dependency. The sweeper had to keep working every single day.
I’ve found that many exchanges face the same quiet dilemma. Do you reject the deposit and risk angry customers who simply reused an old QR code? Or do you accept the credit risk and hope your internal process never fails? CoinDCX took the second route. For a while it worked.
The Moment the Sweeper Went Silent
Sometime before mid-October 2026 the automated service stopped moving funds. The company has not said exactly when the failure began or how long it lasted. What we do know is that deposits kept arriving. One heavily used address collected roughly 15.82 million USDT across eighty-eight transfers. None of those coins left until the drain happened.
On-chain analysis later counted forty affected TRON addresses in total. The big one dominated the numbers. Investigators also noticed repeated small TRX top-ups. Those payments are required to pay network fees when an address needs to send USDT. The pattern suggested someone still controlled the keys and was preparing the wallets for movement rather than leaving them completely abandoned.
Perhaps the most interesting aspect is the gap between what the app showed customers and what the blockchain showed the world. Users saw their balances rise. The exchange carried a growing liability. The actual tokens sat in places already labeled unsafe after the earlier breach.
Detection and the Company’s Response
Unusual activity appeared in internal systems on October 21. The next day irregular on-chain movements became visible. Community reports pushed the investigation deeper. By October 25 the exchange confirmed a loss of 15.99 million USDT and stated it would absorb the entire amount itself.
Trading, deposits, and withdrawals continued without interruption. Active wallets and core infrastructure were not touched. That distinction matters. Many past exchange incidents forced customers to wait or absorb partial losses. Here the company stepped in immediately.
Customer balances, active wallets and operations remained unaffected. The loss sits entirely on the company’s books.
Still, absorbing a sixteen-million-dollar hit is not free. The firm previously set aside a customer protection fund of about six million dollars. The October loss exceeded that original allocation. Whether the shortfall came from general treasury, insurance, or other reserves has not been detailed publicly. Those numbers will matter for anyone watching the company’s long-term financial health.
Where the Money Went After the Drain
Tracing tools followed roughly 9.63 million USDT through intermediate wallets. Within eighteen hours a large portion reached addresses linked to several major exchanges. That does not mean those platforms took part in any theft. It simply gives investigators potential places to request records.
Separately, about 2.21 million USDT across nine wallets was frozen by the stablecoin issuer. Freezing stops further movement of those specific tokens. It is not the same as returning the funds. Recovery still requires legal steps, ownership confirmation, and cooperation. The exchange has not announced any recovered amount yet.
The public chain shows the size and the path. It does not reveal the method of compromise. The company spoke of unknown vulnerabilities in the deprecated infrastructure. Whether the keys came from the 2025 breach, a later failure, or something else remains unclear. Outside analysis explicitly noted it could not determine how the actor obtained control.
Two Separate Incidents, One Shared Weak Spot
The July 2025 event involved an internal operational account used for liquidity on a partner platform. Roughly forty-four million dollars disappeared. Customer cold wallets stayed untouched and the company covered the loss from its own funds. The October 2026 event is different. It involved deposits that arrived at infrastructure already retired after the first incident.
The connection is operational rather than criminal. Once an address or its surrounding systems are considered exposed, any rescue service that continues to use them needs tight monitoring and fast movement. Leaving large balances sitting there after the danger was known created exactly the exposure that later materialized.
In my view the second incident underlines a broader lesson. Isolating primary cold storage is necessary but not sufficient. Deposits travel through intake addresses and automated services before they reach that storage. An old intake route can still generate losses even when the main vaults remain secure.
Why the Early Communication Matters
When the transfers first circulated, the exchange stated that current wallets had not been breached and suggested the old addresses might be generating a false alarm. That answer addressed one concern while leaving another open. Why had funds in the retired wallets been removed? The later disclosure filled that gap by confirming both a real loss and a failed sweeping process.
The company later acknowledged it could have communicated more proactively. Investigating blockchain movements takes time, especially when internal ledgers must be matched against public transactions. Even so, stating what is known and what remains unclear early can reduce speculation. The gap between the first response and the final account left room for debate about whether the old system was truly inactive.
A clear timeline of the sweep outage, the first monitoring alerts, the number of affected deposits, and the steps taken to prevent further accumulation would help everyone assess the process that failed. Separating frozen tokens from actual recovered funds would also avoid overstatement.
What Customers Should Do Going Forward
Anyone who previously saved a deposit address needs to update it. The blockchain will still accept transfers to the old destination. The network does not know which address the exchange currently displays in its app. Support for deprecated addresses is described as temporary. Once that support ends, handling of accidental deposits may change.
The safest habit is simple. Open the exchange app, select the asset and network, and copy the address shown at that moment. Never rely on a previously stored string for a new transfer. Double-check the network as well. Sending USDT on the wrong chain is another common way funds become hard to recover.
- Always copy the current deposit address from the live app
- Verify both the asset ticker and the network before confirming
- Avoid saving addresses in external notes or automated scripts long term
- Treat any address older than a few months as potentially retired
- Contact support immediately if you believe you sent funds to an outdated address
These steps will not eliminate every risk, but they remove the most common human error that keeps old infrastructure in play.
The Larger Custody Lesson
An exchange can stop displaying an old address. It cannot delete that address from the blockchain or force every user to forget it. The firm must decide whether to monitor and rescue late deposits, refuse credit, or warn that recovery may become impossible. Each choice carries consequences. A rescue service creates an ongoing obligation to watch, fund, and move assets even when most customers have already switched.
CoinDCX split the process into two steps: credit the customer first, then sweep the coins. The October disclosure shows what happens when the second step quietly fails. The event is therefore about more than a compromised key. It reveals a mismatch between the accounting moment a customer is told their money has arrived and the custody moment the exchange actually secures the asset.
That mismatch is not unique to one platform. Many centralized services face similar trade-offs. The more an exchange tries to protect users from their own outdated habits, the more operational complexity it inherits. Complexity invites failure modes that are hard to monitor continuously.
What Remains Unanswered
Several practical questions still lack public answers. How long exactly did the sweeper stay offline? When did the first alert fire? How many distinct customers had deposits credited during the outage window? What technical control ultimately allowed the drain? Will any of the frozen tokens return to the company?
These details matter less for the immediate safety of current balances and more for evaluating the robustness of the monitoring systems. A one-time absorption of nearly sixteen million dollars is manageable for a sizable exchange. Repeated gaps of the same type would not be.
Independent on-chain data can show the size and destination of the transfers. It cannot audit the full internal customer ledger or the exact funding source used to replace the lost assets. Continued ability to process withdrawals provides practical evidence that customer claims remain whole. Updated attestations and reserve disclosures would make that evidence stronger.
Practical Takeaways for Everyday Users
Most retail users will never interact with deprecated infrastructure. Still, a few habits reduce exposure across the board.
- Treat every deposit as a fresh action rather than a repeated routine.
- Confirm the address and network inside the app immediately before sending.
- Keep only small working balances on any centralized platform when possible.
- Watch for official announcements about address changes after any security event.
- Remember that “funds are safe” usually refers to credited balances, not necessarily the physical location of every token at every moment.
None of these steps is complicated. Together they close the most common doors through which old infrastructure remains relevant.
The final cost to the company may still change if assets are recovered. Until that happens the confirmed figure stands at 15.99 million USDT absorbed by the exchange. For customers the decisive questions are simpler: Can credited balances still be withdrawn? Do future deposits go to current addresses? Has the monitoring gap been closed?
For the wider market the lasting image is the retired address that continued to do new work. Its retirement stayed incomplete as long as real funds arrived and a separate automated process remained responsible for saving them. That is the part of the story that stays with me. Technology can mark an address as deprecated. Operational reality is slower to catch up.
Looking ahead, clearer timelines, more detailed post-incident accounts, and explicit statements about recovery progress would strengthen confidence. Until then the episode serves as a concrete reminder that custody risk does not end the moment an address stops appearing in the user interface. The chain keeps accepting deposits. The internal systems must keep watching.
I’ve watched enough of these incidents to know that the next one will look slightly different. The pattern of old infrastructure quietly collecting value, however, is likely to reappear somewhere else. Paying attention to how platforms handle that specific risk may be one of the more useful habits any regular user can develop.
