Ledger / CryptoBilis: Three Token Deposits, Six ETH Departures, and an Unproved Zcash Link

On 9 October 2026, Ledger said it was investigating reported fund losses among Southeast Asian customers who had bought devices from CryptoBilis. Its notice asked the reseller to pause sales and shipments. It did not establish the cause, a total loss figure, or which public addresses belonged to affected buyers. Ledger Support notice, 9 October.

This review asks a narrower question: what can the transaction records establish about the addresses supplied as investigation leads? Three checked token transfers from two candidate addresses reach the same Ethereum recipient. Later, one candidate sends ETH to six recipients. One of those recipients makes two separately checked deposits into contracts labeled Tornado Cash. The six departures and the two later deposits are successive movements, not eight losses.

The token route is C1 / C2 → D; the selected later ETH branch is C1 → R2 → two labeled pools. R2 is simply the short name for the recipient of the second checked ETH departure. N → C1 is a separate incoming ETH record. Two earlier large ETH leads remain unjoined to these routes. These observations do not establish victim ownership, a total loss, a post-mixer recipient or a Zcash conversion.

Ledger later described a hardware implant that reads recovery words—the secret backup material used to restore wallet keys—from the display of a signing device and transmits them over a mobile connection. Ledger’s official statement. That is an attributed vendor finding, not our examination of a device. This article keeps that explanation separate from the transfers it can check. The later section on the official update sets out the scope and limits of that statement.

The roles before the numbers

ETH is Ethereum’s native asset and is used to pay transaction fees. USDT and USDC are separate tokens whose balances are maintained by their own contracts. A transaction can call one of those contracts without attaching ETH, while still instructing it to move a substantial token balance. That distinction matters when reading the three outgoing transactions.

C1 and C2 are short labels for the two candidate addresses selected in the existing investigation. “Candidate” is deliberate: the transaction pages establish activity at those addresses, not the identity of their operators or the ownership of the funds. D names their common token recipient, and N names the sender of one checked ETH receipt.

A service order is the instruction that asks a provider to exchange or deliver assets, potentially on another chain. The deposit and the payout can be separate blockchain transactions. To join them reliably, the investigator needs a record identifying the input, the requested destination and the actual fulfillment—not just a similar time or a familiar service label. This is the main missing connection tested below.

The full, linked Ethereum addresses are preserved in Appendix B. The short names above are used throughout so the narrative can be followed without memorizing address strings.

Service labels need the same restraint. Blockscout displays D as “HiFiSwap: Bridge 7” and N as “NEAR Intents.” Those labels help identify a possible service-record request. They do not prove that a particular customer used a bridge, that D’s operator controlled C1 or C2, or that the service participated in a theft. The analysis below relies on the address strings and transfers; the labels remain attributed context.

The morning records, in time order

06:24:23 UTC — C1 sends USDT to D

The first record in this selected sequence is E04 transaction. At Ethereum block 26,153,038, C1 submitted a successful transfer call to the USDT contract. The token-transfer entry names D as the recipient of 124,142.952049 USDT. This proves the token movement between those addresses. It does not identify the original owners of the tokens or the order, if any, that a service processed in return.

06:33:35 UTC — an ETH receipt reaches C1

Nine minutes and twelve seconds later, E03 transaction records 197.987401974409142087 ETH sent by N to C1, in block 26,153,084. The sender carries the explorer label “NEAR Intents.” The native ETH transfer is directly visible; its source-chain origin and associated customer order are not.

The order is important. The ETH receipt follows the USDT departure, which can make the pair look like a conversion. Timing alone does not show that E03 fulfilled E04. There is no verified order identifier, source execution, or destination-fulfillment record joining them in this review. They could belong to one service order, to different orders, or to unrelated activity. The figure therefore shows transfers that touch C1 without drawing a token-to-ETH conversion.

06:38:35–06:39:35 UTC — C2 sends two different tokens

At block 26,153,109, C2 sent 100,008.900873 USDC to D in E05 transaction. Exactly sixty seconds later, block 26,153,114 records 49,990.00111 USDT from C2 to the same D in E06 transaction. Both pages show successful transfer calls and zero attached ETH. The two entries concern different token contracts, not one stablecoin balance under two names.

Start Figure 1 with N and C1 on the left, then read C2 on the right and the shared D below. The solid arrows show the four checked asset movements. Their widths do not measure value, and the layout is not a clock: E04 happened before E03 even though the ETH sender is drawn above C1.

Figure 1. Evidence E03–E06. Pastel boxes organize roles and evidence labels; solid arrows represent asset movements, not ownership. The ETH amount is rounded only in the artwork. Full amounts and transaction links are preserved in Appendix A.

The common endpoint is the strongest directly observed connection between the two candidates in this subset. It is a connection through a recipient, not proof of common control. The next task is to identify any order fulfilled for each deposit, rather than treating all of D’s activity as the continuation of these three transactions.

Why a zero-ETH call still moves tokens

An Ethereum transaction page can display both a transaction target and a token recipient. They answer different questions. The target is the address receiving the instruction. For a token transfer, that is normally the token’s contract. The token recipient is the address whose token balance increases when the instruction is processed.

E04 demonstrates the distinction. C1 is the transaction sender. The transaction targets the USDT contract, while the transfer entry names D as the token recipient. “Value: 0 ETH” means the transaction did not attach native ETH to that call. It does not mean zero USDT moved. C1 also paid a separately recorded fee of 0.000011148080355804 ETH. E04 transaction.

Read the upper row of Figure 2 as an instruction to token code, and the lower row as the token movement that the explorer reports. The dashed call arrow and solid asset arrow are two views of the same transaction. They must not be counted as two transfers or two losses.

Figure 2. Conceptual role diagram anchored to E04. Dashed blue-gray line = contract call; solid sage line = token movement. The rows distinguish address roles; they are not separate transactions or a complete internal-call trace.

The distinction prevents two errors: using the token contract as the final receiving wallet, and treating the native-value field as the token amount. It also shows the limit of a successful call. A successful transfer does not explain how signing authority was obtained, whether the owner consented, or whether a hardware device was altered. Those questions need evidence beyond this transfer record.

13:32 UTC — the public notice describes reports, not a cause

After the morning records and before the two afternoon ETH transfers, Ledger Support published the notice used for this article’s incident context. Its request to pause sales and shipments was precautionary. A signer is the device or software used to authorize a transaction; a seed is recovery material from which wallet keys can be derived. Ledger’s recommendation to consider a new signer with a new seed concerns replacing signing authority. It does not establish how any existing authority was compromised. Ledger Support notice, 9 October.

The notice is an off-chain statement placed here to distinguish its publication time from the blockchain events. It does not authenticate C1, C2, A or B as victim or attacker addresses. The next two records are therefore read as separate leads, not as a continuation endorsed by that announcement.

The separate afternoon ETH leads

Later on 9 October, two other successful transactions moved large amounts of ETH. At 15:04:35 UTC, E01 transferred 393.2698 ETH from A to A′. At 15:31:11 UTC, E02 transferred 438.5549 ETH from B to B′. Neither sender is C1 or C2, and neither recipient is D. E01 transaction; E02 transaction.

The block numbers, sender and recipient strings, amounts, success status, fees and gas-used fields were rechecked on the public explorer. Those observations support two direct ETH transfers. They do not establish a path from C1, C2 or D to A or B. The broader investigation contains additional route leads, but a graph’s inclusion of an address is not a substitute for a transaction-by-transaction, time-consistent link.

In Figure 3, read the upper token-route box separately from the two ETH pairs below. Whitespace is intentional: no arrow joins the evidence sets because no such link is established here. The two lower solid arrows mean only the individual ETH transfers.

Figure 3. Evidence E01 and E02. All solid arrows are directly checked transfers. The separated panels do not imply a hidden bridge or mixer connection. The two-transfer sum excludes fees and is not a loss estimate.

The gap changes the conclusion. It would be inaccurate to say these two candidates sent 831.8247 ETH onward, or that their tokens were demonstrably converted into those ETH transfers. It would also be inaccurate to conclude that no relationship can exist. The relationship is unresolved by the reviewed records. Any future connection needs its own source and destination anchors.

10–11 October — C1 sends its ETH onward

The earlier snapshot was not the end of the story. The new review directly checked six later ETH departures from C1. At 09:42:59 UTC on 10 October, L01 transaction sent 468.9 ETH to a new recipient in this review. On 11 October, another five transfers followed. These records supersede any reading of the old snapshot as evidence that C1’s ETH remained unmoved. They do not change what the three earlier token records show.

At 09:43:11 UTC on 11 October, C1 sent 199.1 ETH to the address we call R2 in L02 transaction. R2 is a role label, not an identified person. Eight minutes later, M01 transaction records R2 calling deposit on the explorer-labeled 10 ETH Tornado Cash pool with 10 ETH. Thirty-six seconds after that, M02 transaction records a successful deposit of 1 ETH into the separately labeled 1 ETH pool. The sender address in both deposits is the recipient of L02.

A mixer is a service designed to make a deposit difficult to link to a later withdrawal. A checked deposit establishes entry into the contract, not the operator’s identity or a later payout. The two individually reread records here total 11 ETH. SentinelTX surfaced a larger pool-deposit set, but this article does not substitute that broader trace result for a fully checked transaction inventory.

The rest of C1’s departures continue the chronology after the selected pool deposits: 95 ETH at 15:43:35, then 199.1 ETH at 19:03:35, 85.08 ETH at 19:07:35 and 121.730854381543827 ETH at 19:08:23 UTC. The last amount retains its full precision. The six unique departure hashes total 1,168.910854381543827 ETH, excluding their transaction fees. This is a departure subtotal from C1, not independently established victim loss.

Read Figure 4 from C1 at the top. The left branch follows the selected 199.1 ETH recipient, R2, down to the two individually checked pool deposits. The right panel groups five different direct recipients; it is not a single wallet or an additional transfer. Solid arrows show asset movements, and neither arrow width nor spacing represents quantity or elapsed time.

Figure 4. Evidence L01–L06 and M01/M02. The two pool deposits are a selected 11 ETH subset, not a complete mixer total. Grouped recipients on the right are not a shared wallet. No post-mixer route is established.

This gives the investigation a concrete continuation from C1, rather than a merely similar-looking route elsewhere in the graph. It still does not join the earlier A/B ETH leads to C1. Nor does the presence of a public pool prove that all ETH R2 received belonged to this incident. Completing R2’s full history and the other five recipients’ routes remains a separate task. The next question is whether a deposit-specific service record establishes any Zcash conversion; none has been established in this review.

13–17 October — hardware findings and a different routing claim

In its 13 October statement, Ledger attributed a hardware-implant finding to Donjon and said one affected user’s device had been confirmed on 10 October. Ledger said a separate component observes recovery-word screen data and transmits it through LTE/eSIM without modifying the Secure Element, operating system, transactions or signatures. Recovery words are the secret backup material from which wallet keys can be restored. An unchanged signing chip therefore does not, by itself, establish that words displayed during setup remained confidential. This explains the company’s account; it is not our independent hardware reproduction.

Ledger did not confirm a total affected-user count or total loss in that statement. Its Germany follow-up, displayed 15 October KST also needs to be kept within its scope: Ledger said inspected retail and distributor samples showed no tampering, no implant-related fund loss had been reported in Europe, and the devices shown online had not yet been examined. Neither a reported implant nor a negative sample inspection establishes the condition of every device.

On 17 October, Specter claimed that CryptoBilis-linked funds had entered Zcash. The original post contains no Ledger or Triple-A transaction hashes; its attached image concerns Bitget and ZachXBT. That image is not supporting transaction evidence for this case. The deposit-to-payout checks in the renewed investigation did not supply a verified Zcash join and suffered provider-read failures. A failed or incomplete lookup is not evidence that a conversion never happened. It leaves the claim unproved here.

What the totals do—and do not—measure

Separate questions need separate arithmetic: how much of each token reached D, how much ETH moved in the independent afternoon pair, and what left C1 later. Transactions are deduplicated by their full hash. Token amounts are kept at the precision recorded in the fact ledger; fees are separate ETH costs, not deductions from token quantities.

USDT and USDC are both commonly described as dollar-pegged tokens, but that does not make their quantities a verified dollar-loss figure. This review neither applies an incident-time price nor adds ETH to stablecoins. It also does not add E03 to the token departures as new damage: if a conversion were later demonstrated, summing both legs as separate losses would count the same economic value twice.

The six later C1 departures total 1,168.910854381543827 ETH. The two selected R2 pool deposits total 11 ETH, but that is later movement from a recipient already present in the departure subtotal: it is not another 11 ETH to add as damage. No balance is inferred from these selected transfers. Establishing what remains requires a balance at a named block and a complete ledger of relevant activity. A service endpoint may process unrelated customers’ funds, so its wider traffic is not assigned to this case. A chart is not included because a loss-sized bar would imply an economic scope that the evidence does not establish.

What could connect the evidence

Ledger’s notice confirms that the company was investigating reports and had requested a precautionary pause. It also advised recent purchasers who had not configured their devices not to begin setup, and asked those who had configured them to consider a new signer with a new seed. These were the company’s recommendations in that notice, not findings that this review independently established about the cause. Ledger Support notice, 9 October.

The same boundary applies to the addresses. To connect a transfer to a reported loss, an investigator needs a reliable record linking the affected account, the withdrawal, and the relevant purchase or setup history. A reseller purchase does not, by itself, prove device tampering. A transfer from a candidate address does not, by itself, establish a stolen private key or an unauthorized approval.

There are plausible alternative readings. Shared service use could reflect different customers. The ETH receipt and USDT departure could be related or unrelated orders. The afternoon ETH leads could be part of the incident, or simply leads selected for testing. The original six selected records do not discriminate among those possibilities, and the later C1 departures do not close those earlier joins. Naming the missing record is more useful than choosing the most dramatic explanation.

The concrete response point is therefore evidence preservation. Retain the three deposit hashes and their exact token contracts, and seek deposit-specific order records through appropriate authorized channels. Preserve buyer purchase and setup records separately from chain observations. No contact, freeze request, recovery action or live monitoring deployment is claimed in this review.

Conclusion

Three token deposits reach D, where the checked token route remains unresolved. Six later ETH departures extend the record from C1, and two selected deposits establish that R2 sent 11 ETH into explorer-labeled Tornado Cash contracts. The earlier A/B ETH leads remain unjoined, and no Zcash conversion is established. Victim ownership, common control, the full mixer total and an incident-wide loss figure remain outside the independently checked scope. The next investigation must complete recipient histories and seek deposit-specific service fulfillment, rather than drawing a missing connection from a familiar label or a similar amount.

Evidence appendix

All times below are UTC, with each date printed explicitly. E01–E06 were previously reread on public Blockscout detail pages; L01–L06 and M01/M02 were directly read in the 18 October follow-up. Local +09:00 explorer timestamps were converted to UTC. Direct checking means checking displayed transaction details, not replaying Ethereum execution, auditing device hardware or identifying the people behind addresses.

Appendix A — Transaction anchors

E04 · USDT record

E03 · ETH record

E05 · USDC record

E06 · USDT record

E01 · ETH record

E02 · ETH record

L01 · ETH record

L02 · ETH record

M01 · ETH record

M02 · ETH record

L03 · ETH record

L04 · ETH record

L05 · ETH record

L06 · ETH record

Appendix B — Address-role register

Role names describe the reviewed records. They do not establish natural-person identity, common ownership, consent, culpability, or authority to freeze the assets. All address links target Ethereum address-detail pages, not transaction pages.

Sources and verification boundary

The primary incident context is the Ledger Support notice, 9 October, supplemented by the later Ledger and Specter statements linked alongside their discussion. E01–E06 and the eight newly checked L/M records in Appendix A supply the direct movement evidence. The existing SentinelTX investigation supplied candidate identifiers and additional leads; broader balances, service-wide aggregates and unrechecked mixer totals are not adopted as independently established findings in this article.

This is a bounded evidence review, not a complete incident census or a current-balance assessment. No full victim-origin ledger, successful deposit-to-payout cross-chain order matching, complete downstream review or hardware reproduction has been completed. Provider failures limit the renewed bridge lookup. The date of reading historical records does not extend the transfer window to the present. No Zcash or post-mixer route is asserted.