EU Entity Suspected of Losing Over $106 Million From Exchange Accounts

Accounts at several exchanges, with the victim still unidentified

The description of the affected party is narrow: an entity in the European Union. Neither opened account names the organization or the exchanges that held its accounts. They describe a suspected theft from several centralized-exchange accounts and attach the November 1 date to that suspected incident.

That wording matters to readers trying to decide whether a service they use is affected. A loss involving an account held at an exchange leaves several questions unanswered, including how access was obtained and which party controlled the action that moved the assets. The original alert and the reports do not supply the information needed to answer those questions. Calling this an exchange infrastructure breach would add a conclusion that the published accounts do not establish.

The same limit applies to the victim's location. An EU entity is the description attributed to the alert; it does not identify a country, a regulated legal entity or a class of customers affected. Do not use the location to infer that every European account faces the same problem or that a particular national authority has opened a case.

If you maintain a record of this event, use a descriptive label for the unidentified entity. Leave the venue field blank until a named source supplies it. Inserting a familiar exchange name can attach the allegation to an organization that neither report actually names.

What the $106 million and 11 addresses mean

The loss figure is reported as more than $106 million. It is an attributed estimate, with a threshold rather than an exact total. Neither the original alert nor the short reports provide the asset-by-asset calculation behind that estimate, an account statement or a complete transaction list from which this article could reproduce it.

These details come from the Odaily account of the alert. The table separates the report's observations from the questions a later investigation would need to answer.

Eleven addresses cannot be read as eleven victims, eleven exchange accounts or eleven exchanges. The reports describe related addresses. The original post lists the addresses but does not explain each address's role. Counting addresses alone therefore cannot determine how many people or services were affected, nor how much remained recoverable.

There is also no basis here for dividing $106 million by 11 to produce a meaningful average loss per address. The loss and address count measure different things. Some addresses could appear at different stages of the movement, and the short reports do not provide the ledger needed to assign a balance to each. Keep the figure and the count in separate fields when taking notes.

The reported movement after the withdrawals

The outlets attribute a further account to ZachXBT: over the preceding 24 hours, the suspected attacker continued converting USDC into ETH and moving funds through instant-exchange services. The reports name WellWallet and Kyrrex and describe conversion into XMR through Wagyu, alongside transfers across multiple blockchain networks.

Those service names belong to the attributed description of the route. They do not establish that the named services participated in the suspected theft, approved the movement or knew the identity of the party moving funds. This article has not opened a response from those services or reconstructed the route from transaction records.

For a reader following stablecoin exposure, the sequence raises a useful accounting question: which asset was held at each point? The reports identify USDC and USDT at withdrawal, then mention conversion of USDC to ETH. They do not provide an exact amount for each conversion or establish that every withdrawn token followed the same path. Avoid turning a partial route into a claim about all the funds.

The reference to XMR also leaves the amount unspecified. It cannot support a calculation of how much entered XMR, how much was left in stablecoins or what share crossed a bridge. A later report giving a transaction amount should be compared with the specific leg it describes, rather than deducted automatically from the headline loss.

The preceding 24-hour window is relative to the alert as reported. The opened material does not identify the first and last transaction timestamps in that window. November 1 is the reported incident date; November 2 at 20:30 SGT is Odaily's publication time. Keep those dates separate when checking a future update.

The attribution assessment remains ZachXBT's

ZachXBT says the actor is unidentified. He also assesses with high confidence that the actor is not Lazarus Group, citing multiple laundering indicators. The original post does not lay out all those indicators, so that assessment remains attributed to him rather than an independently established identification.

An assessment excluding one group does not identify another. A service name or the use of a particular asset cannot fill the missing link between the reported activity and a named actor. A later attribution should be evaluated on the evidence it adds.

What this means for you

The following are account-review steps prompted by the allegation. They are recommendations for examining your own records, rather than a report that your account or any named venue has been affected.

1. Open the service through the route you normally use and examine its withdrawal history. If you see a withdrawal you cannot recognize, note the asset, amount, network, destination and displayed status before making further changes. Compare it with the instructions you actually submitted. A screenshot can preserve the visible record, while an export can help compare several entries if the service offers that option.

2. For a withdrawal you authorized, compare the destination with the receiving instructions you intended to use. Separate a pending withdrawal from one the account marks completed. If a transaction identifier is present, retain it with the account record. The alert's $106 million estimate does not explain the status of an unrelated transfer, so use the details of that transfer when seeking help.

If the record looks unfamiliar, contact the service through its existing support channel and give the specific entry you are questioning. Ask it to identify the withdrawal request and the account activity attached to it. Do not describe a private account issue as part of this EU incident unless a source establishes that connection.

For an account used by an organization, compare the withdrawal with the instructions and approvals your organization actually retains. Establish who requested it and which record supports that answer. This is a suggested review procedure, not evidence that any particular approval process failed in the reported case. The public accounts do not describe the affected entity's internal controls.

Avoid responding to unsolicited messages offering recovery of funds from this event. Use support routes you already know rather than a message's proposed destination, and do not send assets or reveal account-access material to prove ownership. This is a precaution for handling an incident alert; neither opened report establishes a particular recovery scam associated with this case.

Keep account security and market positioning separate

The reports describe suspected unauthorized withdrawals and subsequent movements. They provide no measured liquidation response, funding-rate change or price impact tied to this alert. A trader should not infer that the ETH conversions establish a broad market trend, or that the reported XMR route explains a particular price move.

If you also need to review a derivatives position, examine its own size and account margin separately from the withdrawal investigation. Use the funding-rates page for the funding question and the liquidations page for a separate review of observed liquidations. This article makes no numerical claim from those pages and attributes no market move to the suspected theft.

An account record can answer whether you recognize a withdrawal. A funding observation answers a different question about a contract at a particular time. Keeping these tasks separate helps avoid making a trade merely because the incident headline contains a large dollar amount.

What would make the next update useful

The most useful new information would identify the affected entity or provide transaction records sufficient to check the reported movements. A statement from the entity could address its own account activity. A named exchange's statement could address that service's role. Neither should be replaced with assumptions based on a wallet label.

An address list would help only if the role of each address can be checked. A later total should state which assets and valuation time it uses. A recovery figure should distinguish assets located, assets restricted and assets actually returned; the current reports provide no recovery amount in any of those categories.

When comparing a new report with this one, look for an added fact rather than another repetition of $106 million and 11 addresses. A different outlet quoting the same alert can confirm how it was reported, while still leaving the underlying allegation dependent on the same source.

Quick answers for account holders

Which exchange was breached?

Neither opened report names the exchanges or demonstrates a breach of exchange infrastructure. The allegation concerns accounts at multiple centralized exchanges. The venue and the access mechanism remain unidentified in the material used here.

Does the alert identify every USDC or USDT holder as affected?

It describes an unidentified entity's suspected loss and names the withdrawal assets. It does not identify a problem affecting all holders of either token. Check your own withdrawal entries instead of treating an asset name as proof that your account is involved.

Has the money been frozen or returned?

The two reports provide no verified frozen or returned amount. Keep those fields unanswered until a source supplies an amount, its scope and the action actually completed.