X100 Attacker Address Reportedly Moves 821.2 ETH to Tornado Cash

What the October 26 reports actually say

Odaily published its flash at 22:56 SGT on October 26. It attributed the observation to PeckShield and described an address marked as the X100 attacker sending 821.2 ETH to Tornado Cash, with an approximate value of $1.89 million. ChainCatcher published matching figures at 22:59:49 SGT. PANews also reported the same amount and destination, naming PeckShieldAlert as the source. Odaily ChainCatcher PANews

All three identify the underlying project as X100 and its token as X. They describe an earlier flash-loan governance attack on October 24. The October 26 transfer report is therefore a development in an existing incident, rather than a report that the same attack has just happened again. The articles do not describe a fresh exploit accompanying this transfer. Odaily ChainCatcher

The reporting chain matters here. Three publications carry the observation, but each attributes it to the same monitoring source. Their agreement supports an accurate account of what was reported. It does not supply three separate investigations of the wallet or an independent reconstruction of the transactions. The wallet attribution remains PeckShield’s.

Keep the ETH amount and dollar estimate separate

The reported on-chain amount is 821.2 ETH. The dollar figure is approximate: about $1.89 million. Preserve both units when recording the report. Writing only “$1.89 million moved” hides the denomination and makes later comparisons less clear. Writing “821.2 ETH recovered” would change the reported action entirely. The sources describe a deposit into Tornado Cash. PANews

There is no execution price in the opened reports. Dividing the approximate dollar estimate by the ETH amount would produce an implied conversion figure, but it would not identify an actual sale, a fill price or a verified market quote at the transfer time. The estimate supplies no verified ETH execution price.

The transfer amount also cannot serve as the incident's final loss figure. A movement between addresses and a complete loss assessment answer different questions. To connect them, a later account would need to explain the relevant wallets, earlier movements and the scope of the assets being counted. Until that accounting is available, keep the reported transfer as its own line in an incident record.

What this means for you

1. Preserve your wallet record. If you used a wallet, preserve the transaction identifiers and the wallet address you used. Record the network shown in your own transaction history, the asset and the amount. Keep the original record rather than replacing it with a typed summary. These are suggested evidence-preservation steps, not a claim that the reported attacker transfer includes your assets.

2. Preserve your exchange order history. If your exposure was through an exchange account, export or save the relevant order and account-history entries available to you. Keep an order fill separate from a deposit or withdrawal. A record showing that you bought X answers a different question from a record showing that you sent an asset to a project contract. Do not combine the two when describing what happened to support staff or an incident-response contact.

Use the exact project name and the asset identifiers recorded in your own account. The news reports identify X100 and the token X; they do not verify the identity of every product using a similar ticker. Before sending an incident query, compare the product you used with the project named in the report. If the connection is unclear, describe that uncertainty in the query instead of asserting that your account was affected.

A useful support request states what you observed, the relevant transaction or order identifiers, and the answer you need. For example, ask whether your own recorded deposit is affected by a stated service restriction, if one appears in your account. Ask about the particular entry you saved, using the account support channel you already use.

Preserve the time shown by your own records together with its timezone. When comparing it with this report, Odaily's publication time is 22:56 SGT on October 26. A publication timestamp tells you when the report appeared; it is not a substitute for the transfer's block timestamp. The latter is not supplied in the opened article bodies.

What remains unresolved

The reports supply no transaction hash or full sending address, and establish neither recovery nor an exchange service restriction. A detailed update should add the transfer identifiers and explain how the address was linked to X100. For affected users, the unresolved questions include any amount returned, its receiving party and a distribution process. Keep the October 24 attack and October 26 transfer as separate entries in an incident record, with a source attached to each.

When preparing that record, retain the original source URL and the time you saved it. If a later notice corrects the amount or the address attribution, add a dated correction beside the earlier entry. Preserve both versions so a support contact can see which information you relied on at the time.

A wallet record and an exchange order can sit in the same incident folder, with their roles stated clearly. Label your own activity as your activity. Label the reported attacker transfer as an attributed public report. That avoids presenting an unrelated purchase as a transfer to the reported address when you ask someone else to investigate.