CoinDCX: a 15,819,002 USDT transfer and the limits of the sweep explanation

A large USDT transfer drew attention to CoinDCX-linked deposit addresses in October 2026. CoinDCX later described a failure in the process used to collect deposits from retired addresses. The chain can help test the transfer sequence. It cannot show the exchange’s internal customer credits or diagnose its collection software.

This review follows one large-source address into a receiving address, then its six first-hop recipients and three selected onward transfers. Before following those departures, it reads a small deposit-and-collection sequence from the same day. Address names below describe observed roles, not proven people or organizations.

The verified route is large-source address → receiving address → six first-hop recipients, with only three onward transfers examined in detail. The operational question is separate: a sampled deposit address still made a collection transfer on 21 October. This does not identify when another address, or the wider system, stopped collecting deposits.

What the address names mean

USDT is a token intended to track the US dollar. This review follows the canonical TRON USDT contract, rather than trusting a token’s ticker alone. TRX is TRON’s native coin, used to pay transaction costs. A sweep is a transfer that collects deposits into another address. A transfer can fit that pattern without proving which software or person submitted it.

A Transfer event is a record emitted by the token contract when tokens move. A solidified receipt is the network record of an executed transaction after it has become final. Matching these records checks the asset movement; it does not identify the person behind an address.

CoinDCX’s 22 October follow-up names the TQKJQ wallet and says deprecated, previously compromised deposit addresses remained exposed to user deposits. It attributes operational losses to a sweep failure and says affected users were credited. These remain company statements, not findings from customer-account records.

Scope before the numbers

Before the incident: collection was observable, but a failure interval is not

4 May: a large-source deposit moved onward in 39 seconds

The large source received 300,000 USDT at 05:39:57 UTC on 4 May. At 05:40:36, it transferred the same amount to the collection-pattern destination. Both records have successful, solidified token-transfer logs. The 39-second interval shows a quick collection-like pair; it does not reveal the program that handled it. Deposit · Onward transfer.

The bounded history contains 183 canonical-USDT transfer entries for this address from 1 January through the cutoff. Its last indexed departure before 21 October is at 05:45:33 UTC on 4 May. No further entry appears before the October departure in that returned range. This is an observed gap in one token’s transfer history. It is not a dated outage log, proof of a software failure since May, or proof that every deposited unit had remained untouched.

21 October: a different address still made a collection transfer

At 12:13:45 UTC, the sampled deposit address received 9.67 USDT. Twelve seconds later it received 15 TRX from the fee-source address. At 12:14:06 it sent 9.67 USDT to the same collection-pattern destination used in the May pair. The token deposit and onward movement are 21 seconds apart; the TRX transfer precedes the onward movement by 9 seconds. The fee transfer supplies a separate asset and must not be added to the USDT amount. Deposit · 15TRX · Collection transfer.

Read Figure 1 from its first timestamp downward. Its arrows show chronological order, not tokens passing through every box. The blue-gray panels are observed records; the beige panel separates funding of the receiving address from the sampled collection pair.

Figure 1. A chronology of the sampled address and fee-source records. All times are UTC; spacing is schematic. The 168.63 USDT departure is not the earlier 9.67 USDT deposit being counted again.

The important observation is coexistence: a collection-like transfer occurred that day, before later departures to the receiving address. At 12:19:33, the fee-source address sent 100 TRX to that receiving address. At 15:15:21, the sampled deposit address sent 168.63 USDT there. The sequence does not prove that the same operator made all these transactions. The earlier funding of the 168.63 USDT is outside this day’s sample, so the two token amounts are not treated as a single deposit.

What remains missing is the operating record: which addresses the sweeper was configured to watch, when jobs failed, whether retries were attempted, and how deposits were credited. An absence of later USDT transfers at one address cannot supply those answers. The company’s statement does not give exact outage start and end timestamps.

21 October 15:35:54 UTC: the large transfer reaches the collector

At 15:35:54, the large source sent 15,819,002 USDT to the receiving address in block 87307956. The token’s Transfer event matches both full addresses and the raw amount 15819002000000. With 6 decimal places this is 15,819,002 USDT. The separate 6.7735 TRX transaction fee does not reduce the token-transfer quantity. Large-source transaction.

This establishes delivery of the tokens. It does not establish who controlled either key, whether the transfer was authorized, or what proportion of customers’ balances it represented. The receiving address also has other USDT inflows in the queried range. Its later departures must therefore be read as movements out of a shared token pool, not as uniquely identifiable units from this one deposit.

From 17:05 UTC: the collector distributes USDT to six addresses

The first verified outgoing transfer in this window was 10 USDT at 17:05:27 to the address used here as Branch A. A 2,000,000 USDT transfer followed to that same address at 17:07:18. This ordering can be consistent with testing before a larger transfer, but intent is not recorded. Other branches followed later that evening and overnight.

All 18 outgoing USDT entries returned for the collector in this window were checked against solidified Transfer logs. They total 15,991,414.313412 USDT across six distinct recipients. That is the collector’s observed outgoing volume, not an independently established incident-loss total. Its 64-entry indexed history also contains 46 incoming entries. Their relationship to the incident has not been individually established. Small receipts remain in the context data rather than being automatically assigned to the incident. Full addresses, not shared prefixes or suffixes, define each counterparty.

Start Figure 2 at the receiving address and follow each solid arrow into a recipient panel. Each panel aggregates only collector-to-recipient transfers, without adding any later forwarding as new loss. Colors separate panels rather than claiming different levels of guilt or ownership.

Figure 2. Observed first-hop USDT transfers through 23 October 06:30 UTC. Solid arrows show verified token direction; line width and spacing are schematic. No exchange identity, cash-out, or common control is asserted.

The diagram shows distribution, not a final destination. Three selected onward records extend the review by one more step. Branch A sent 100,000 USDT to a further address at 17:16:39 on 21 October (record); Branch C sent 1,000,000 USDT at 19:46:15 (record); Branch B sent 1,000,000 USDT at 05:52:27 on 22 October (record). These are selected continuations, not the complete onward history. Their recipients are preserved in the appendix without service labels because independent evidence for such labels was not established here.

Once value is pooled with other inflows, a matching amount or a later transfer alone does not earmark particular units from the large-source deposit. A service label, if later confirmed, would identify an investigative contact point—not a person, a completed sale, or recoverable funds.

23–24 October: a reported freeze and a narrower state check

AMLBot reported on 23 October that Tether had frozen about $2.2 million linked to this incident. That is AMLBot’s attributed estimate, not a frozen-value total reproduced by this review. A blacklist restricts a token’s use at an address; it is not evidence that funds have been returned to customers.

A separate read-only query of the canonical USDT contract shortly after 23:33 UTC on 23 October checked two addresses already in this report. The function isBlackListed(address) returns whether an address is currently on that token’s blacklist. It returned true for the collector’s 20,000-USDT first-hop recipient and false for the selected Branch C onward recipient. These are latest-state responses, not measurements pinned to a historical block or a verification of the blacklist transaction, its timing, or a frozen balance.

The two responses do not reproduce AMLBot’s wider address set or estimated total. A false response also does not mean an address is safe or that every asset is unrestricted. Figure 2 remains a historical transfer map through its stated cutoff, not a map of current restrictions. The sweep failure’s exact interval and cause, ownership, customer credits, and the complete net loss remain unresolved.

What the records support, and what they leave open

The narrow result is stronger than a transaction alert but smaller than a full incident reconstruction: a large source-to-collector transfer is verified, the collector’s six first-hop recipients are reconciled, and three further transfers are anchored. A separate deposit sample shows a collection-like transfer on the incident day. None of these records diagnoses the sweep failure described by CoinDCX.

Where a response can be specific

For the operator, the relevant review is address lifecycle management: compare the retired-address list with the actual watch list, fee-funding rules and collection-job failures. The 12:13–12:14 sample is a useful timestamped control point for that comparison, not proof that every address was functioning. For affected deposit reconciliation, each customer’s original transaction must be matched with the exchange’s internal credit record.

For investigators, preserve the 18 collector departure hashes and request account-level evidence only where a recipient’s service attribution can be independently established. An unlabelled downstream address should remain unlabelled. The next technical step is selective service-endpoint verification, not expanding every address into a supposed attacker cluster.

Evidence appendix

All addresses below are on TRON. Address links retain the full string and point to address pages; transaction links retain the complete hash. Block times are UTC. USDT quantities exclude separate TRX fees. This appendix contains the selected 27 receipt-verified USDT transfers and 2 native TRX records, not every indexed context entry.

USDT execution records 1–7

USDT execution records 8–14

USDT execution records 15–21

USDT execution records 22–27

Native TRX records

Source and method register

The research uses public TRON records and direct event decoding. No complete exchange-custody audit, key-forensics review or downstream recovery finding is implied.