Defend Against Cybercrime with the Power of Community

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 numbersETH 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.RoleWhat this label meansC1 · candidate addressSends USDT in E04; receives ETH in E03. Incident attribution is not independently established.C2 · candidate addressSends USDC and USDT in E05/E06. The role does not establish common control with C1.D · token recipientReceives E04–E06; explorer label “HiFiSwap: Bridge 7” is provider attribution.N · ETH senderSends E03; explorer label “NEAR Intents” does not identify a source-chain customer.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.Review measureScope / resultSelected evidenceE01–E06, six later ETH departures L01–L06, and two selected pool deposits M01/M02. Not a complete downstream history.On-chain record window9–11 October 2026 UTC; selected records only, not attack duration.Preparation and scope18 October follow-up; the exact later departures and two deposits directly reread. No complete chain-wide audit or current-balance claim.Token transfers to DThree transfers; two sender addresses; USDT and USDC kept separate.Incident-linked loss totalNot established. No USD valuation or victim count is adopted.The morning records, in time order06:24:23 UTC — C1 sends USDT to DThe 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 C1Nine 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 tokensAt 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.Evidence / UTCMovementQuantityE04 · 06:24:23C1 → D124,142.952049 USDTE03 · 06:33:35N → C1197.987401974409142087 ETHE05 · 06:38:35C2 → D100,008.900873 USDCE06 · 06:39:35C2 → D49,990.00111 USDTStart 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 tokensAn 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 causeAfter 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 leadsLater 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 onwardThe 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.UTC / recordMovementETH2026-10-10 09:42:59 · L01 transactionC1 → recipient 1468.92026-10-11 09:43:11 · L02 transactionC1 → R2199.12026-10-11 15:43:35 · L03 transactionC1 → recipient 3952026-10-11 19:03:35 · L04 transactionC1 → recipient 4199.12026-10-11 19:07:35 · L05 transactionC1 → recipient 585.082026-10-11 19:08:23 · L06 transactionC1 → recipient 6121.730854381543827The 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 claimIn 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—measureSeparate 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.CalculationQuantityMeaningE04 + E06174,132.953159 USDTTwo USDT transfers received by D; not verified victim loss.E05100,008.900873 USDCOne distinct USDC transfer received by D.E01 + E02831.8247 ETHTwo independent ETH transfers; excludes fees; no proved link to C1/C2.E03197.987401974409142087 ETHOne receipt at C1; not a verified conversion of E04.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 evidenceLedger’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.QuestionMissing recordWhat a match could establishDid E03 fulfill E04?Service order, source execution and fulfillment identifierA specific deposit-to-payout relationship, not merely time proximity.Where did E04–E06 go after D?Deposit-specific destination chain, recipient and payout transactionAn onward route for each deposit, without importing unrelated service flows.Are E01/E02 connected?A directed, time-consistent sequence or verified service-order joinWhether the separate ETH leads belong to the same fund path.Which transfers are losses?Victim-confirmed account/withdrawal records and authorization historyA bounded loss ledger; distinct from gross transfer volume.What caused the reported losses?Device/setup evidence and applicable signing or authorization recordsA technical explanation that transaction timing alone cannot supply.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.ConclusionThree 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 appendixAll 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 anchorsE04 · USDT recordFieldChecked valueFull hash0x0fb0cc83c4647ce0e384840f5e4d3aa9e03c5d9870ad15a3c5e266910e4a5184UTC / block2026-10-09 06:24:23 UTC / 26153038Sender0x83aeaC166f6832aE3500000a24510a95a052A599Recipient0x1481e58411608B2d628Ef305b92B01cF4f83DB70Asset / exact quantityUSDT / 124142.952049Status / feeSuccess / 0.000011148080355804 ETHToken contract0xdAC17F958D2ee523a2206206994597C13D831ec7Call / native valuetransfer / 0 ETHE03 · ETH recordFieldChecked valueFull hash0xb1b7fc7b4911994739652507586eb8d0e4fd06434efe19b17ba041474ee6f55cUTC / block2026-10-09 06:33:35 UTC / 26153084Sender0x2CfF890f0378a11913B6129B2E97417a2c302680Recipient0x83aeaC166f6832aE3500000a24510a95a052A599Asset / exact quantityETH / 197.987401974409142087Status / feeSuccess / 0.000013016071173 ETHE05 · USDC recordFieldChecked valueFull hash0x64f6ad0dccc64ee6657324f809acff6140db12477998ffeacb173d3e2da0e7b5UTC / block2026-10-09 06:38:35 UTC / 26153109Sender0x033636e45d519BeBB7b5c2520Ca6CE56FBDB4F7aRecipient0x1481e58411608B2d628Ef305b92B01cF4f83DB70Asset / exact quantityUSDC / 100008.900873Status / feeSuccess / 0.00001065616800284 ETHToken contract0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48Call / native valuetransfer / 0 ETHE06 · USDT recordFieldChecked valueFull hash0xcfb9cb65511a67b89f044c3df34f16fa8c906375211de58f53d7a09e580c261bUTC / block2026-10-09 06:39:35 UTC / 26153114Sender0x033636e45d519BeBB7b5c2520Ca6CE56FBDB4F7aRecipient0x1481e58411608B2d628Ef305b92B01cF4f83DB70Asset / exact quantityUSDT / 49990.00111Status / feeSuccess / 0.000011126499141282 ETHToken contract0xdAC17F958D2ee523a2206206994597C13D831ec7Call / native valuetransfer / 0 ETHE01 · ETH recordFieldChecked valueFull hash0x266f2dbb1e5f2e5f29242f9f7b8352bd5ca8ebef6edcfb66a69bfa058825000fUTC / block2026-10-09 15:04:35 UTC / 26155632Sender0x131c9Cafa8959A5E7cD7293Df8D5D4B0887dFA6aRecipient0xA27FF374C9aD192728e6EB1e177b5fa11F9d650FAsset / exact quantityETH / 393.2698Status / feeSuccess / 0.000011926562676 ETHE02 · ETH recordFieldChecked valueFull hash0x595c655e9bc3ee94d75b71ac1259eac3e23adaff9a62ef063c2c3e7f72ccedb6UTC / block2026-10-09 15:31:11 UTC / 26155765Sender0xfa4EaBB840A33C156E600311433AE261CBfCb0e2Recipient0x75F88067D274BA59B3C467ab26e6229881480AACAsset / exact quantityETH / 438.5549Status / feeSuccess / 0.000014498392671 ETHL01 · ETH recordFieldChecked valueFull hash0x0edec454766797e722e3b4f73eaf93b97735f98eef2f72b4480295b49b62c302UTC / block2026-10-10 09:42:59 UTC / 26161210Sender0x83aeaC166f6832aE3500000a24510a95a052A599Recipient0xDC651DF8f6368a85297F86f79038986b002CE203Asset / exact quantityETH / 468.9Status / feeSuccess / 0.000004538316468 ETHL02 · ETH recordFieldChecked valueFull hash0x303c3aa4b08d8faea9484edf230479ff05f761792a502cda25aca984ce0ff297UTC / block2026-10-11 09:43:11 UTC / 26168385Sender0x83aeaC166f6832aE3500000a24510a95a052A599Recipient0xAc567666EA5253Adf8E03e84557f29A79D14d9D5Asset / exact quantityETH / 199.1Status / feeSuccess / 0.000004463891565 ETHM01 · ETH recordFieldChecked valueFull hash0x9c947f79a1ce0b8e756f17d9d9353aa9cfd47fd7418dbd701c323dfbfcba7337UTC / block2026-10-11 09:51:11 UTC / 26168425Sender0xAc567666EA5253Adf8E03e84557f29A79D14d9D5Recipient0x910Cbd523D972eb0a6f4cAe4618aD62622b39DbFAsset / exact quantityETH / 10Status / feeSuccess / 0.000119711477203248 ETHM02 · ETH recordFieldChecked valueFull hash0xa5d67098585e895402d0afb444a81032f7653bec3cb2f682ebcf90846cb26bd1UTC / block2026-10-11 09:51:47 UTC / 26168428Sender0xAc567666EA5253Adf8E03e84557f29A79D14d9D5Recipient0x47CE0C6eD5B0Ce3d3A51fdb1C52DC66a7c3c2936Asset / exact quantityETH / 1Status / feeSuccess / 0.00010945216451463 ETHL03 · ETH recordFieldChecked valueFull hash0xc11bc87c99eeb2e850beffb9e22e0c5833145078c101e8d20c0c9ed054258539UTC / block2026-10-11 15:43:35 UTC / 26170183Sender0x83aeaC166f6832aE3500000a24510a95a052A599Recipient0xb62aa10E987f5C65A63c0E26F410C75e8C2838C3Asset / exact quantityETH / 95Status / feeSuccess / 0.000006734734587 ETHL04 · ETH recordFieldChecked valueFull hash0x2ae1ba618ad5d71a59a10bb94e2dc755e2faadd7cf0032af230aeea94fc7b39aUTC / block2026-10-11 19:03:35 UTC / 26171180Sender0x83aeaC166f6832aE3500000a24510a95a052A599Recipient0xa82a701887d89ADe05F5682Cf670901f0ccCA9D3Asset / exact quantityETH / 199.1Status / feeSuccess / 0.000005870449809 ETHL05 · ETH recordFieldChecked valueFull hash0x04ae3e77f209a65db3f40b4b3d784ab98f5443cb7c4bbb549b9177fc7023b022UTC / block2026-10-11 19:07:35 UTC / 26171200Sender0x83aeaC166f6832aE3500000a24510a95a052A599Recipient0xd26aB39EBBc7EB38E5bECC94eEB59575ec0b554BAsset / exact quantityETH / 85.08Status / feeSuccess / 0.000005233847073 ETHL06 · ETH recordFieldChecked valueFull hash0x30f4ea623780cc9a99761599e63d8a6111a0a02b143961bd69dabd6bf24723a3UTC / block2026-10-11 19:08:23 UTC / 26171204Sender0x83aeaC166f6832aE3500000a24510a95a052A599Recipient0x422078B0B25F63627dc5D51c264a565d0a7bD255Asset / exact quantityETH / 121.730854381543827Status / feeSuccess / 0.000005227081797 ETHAppendix B — Address-role registerRoleFull Ethereum addressC1 · candidate address0x83aeaC166f6832aE3500000a24510a95a052A599C2 · candidate address0x033636e45d519BeBB7b5c2520Ca6CE56FBDB4F7aD · token recipient0x1481e58411608B2d628Ef305b92B01cF4f83DB70N · ETH sender0x2CfF890f0378a11913B6129B2E97417a2c302680USDT contract0xdAC17F958D2ee523a2206206994597C13D831ec7USDC contract0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48A · E01 sender0x131c9Cafa8959A5E7cD7293Df8D5D4B0887dFA6aA′ · E01 recipient0xA27FF374C9aD192728e6EB1e177b5fa11F9d650FB · E02 sender0xfa4EaBB840A33C156E600311433AE261CBfCb0e2B′ · E02 recipient0x75F88067D274BA59B3C467ab26e6229881480AACL01 · ETH recipient; further route not reviewed0xDC651DF8f6368a85297F86f79038986b002CE203R2 · L02 recipient and M01/M02 sender0xAc567666EA5253Adf8E03e84557f29A79D14d9D5L03 · ETH recipient; further route not reviewed0xb62aa10E987f5C65A63c0E26F410C75e8C2838C3L04 · ETH recipient; further route not reviewed0xa82a701887d89ADe05F5682Cf670901f0ccCA9D3L05 · ETH recipient; further route not reviewed0xd26aB39EBBc7EB38E5bECC94eEB59575ec0b554BL06 · ETH recipient; further route not reviewed0x422078B0B25F63627dc5D51c264a565d0a7bD255M01 · deposit contract; Tornado.Cash: 10 ETH (explorer label)0x910Cbd523D972eb0a6f4cAe4618aD62622b39DbFM02 · deposit contract; Tornado.Cash: 1 ETH (explorer label)0x47CE0C6eD5B0Ce3d3A51fdb1C52DC66a7c3c2936Role 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 boundaryThe 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.

18 October 2026The 16–17 October disclosures revisit the NEAR Intents / HOT Bridge incident reported for 29 September–1 October 2026. They add postmortem and recovery context to an earlier exploit. The central questions are how bridge backing and internal credit became separated, what the BNB Chain record supports, and what evidence establishes the reported return.SentinelTX’s 25-page report, CASE-ASYNCE30, distinguishes three transfer-anchored payouts totaling 3,500,000 BSC-USD from two further calls in its narrative. Its routing appendix gives those two calls a different classification. That qualification matters as much as the headline number. This article summarizes the native report; its claims have not been independently re-verified here.What changed in the October follow-upThe report’s chronology attributes the 16–17 October coverage to a deposit-notification bug, “ghost balances,” a reported full recovery, and changes including feature removal and an automatic pause. The feature-removal statement comes from a Defiprime search snippet; the report says that page was not an admissible fetch source. These remain attributed reports, rather than a fresh implementation review.Earlier coverage cited in the PDF places the reported return around 3 October. The later postmortem therefore updates the explanation and safeguards. It does not supply a hash-anchored recovery transaction within this report. [PDF pp. 3, 8, 14–15]Three payouts, two further calls, and a classification gapThe executive summary and conclusion classify these treasury-to-recipient transfers as confirmed:800,000 BSC-USD: 30 September 2026, 23:54:30 UTC; block 125,000,023. Transaction1,200,000 BSC-USD: 1 October 2026, 00:24:02 UTC in the routing appendix; block 125,003,957. Transaction1,500,000 BSC-USD: 1 October 2026, 00:50:42 UTC in the routing appendix; block 125,007,511. TransactionNarrative-confirmed total: 3,500,000 BSC-USD.Two additional recipient-signed treasury calls contain calldata words equal to 330,000 × 10^18 and 35,000 × 10^18. The narrative classifies them as partial: transaction objects were examined, but the cited transfer legs were missing. It attributes the corresponding 330,000 USDT and 35,000 USDT payouts, and the 3,865,000 USDT total, to CertiK.Source qualification: page 16 also lists those same two hashes as “verified” treasury-to-recipient BSC-USD movements, with transfer amounts of 330,000 and 35,000. Page 19 says the routing table lists movements of value. This differs materially from the partial classification on pages 3 and 14. The report does not reconcile the classifications. We retain the narrative’s three-payout total while making the appendix’s additional evidence explicit.Figure 1. The narrative’s three confirmed payouts total 3,500,000 BSC-USD. Its two partial calls correspond to a further 365,000 in CertiK’s reported USDT total; page 16 separately labels both as verified BSC-USD movements. These classifications remain unreconciled. Sources: PDF pp. 3, 14–16, 19.Address keyTreasury role, attributed to CertiK: 0x233c5370CCfb3cD7409d9A3fb98ab94dE94Cb4CdRecipient: 0x09fd1f5d9f185067a92493e43aa259ea4ab3ad37BSC-USD token contract in the report: 0x55d398326f99059ff775485246999027b3197955The treasury and recipient returned no attribution-database label in this investigation. Their incident roles derive from CertiK’s public account. BSC-USD quantities are preserved as recorded; public-source USDT and dollar figures are not silently substituted for them. [PDF pp. 3–4, 7]How the reported accounting failure workedThe PDF attributes the NEAR-side explanation to CertiK. A refund calculation was bounded by the receiver’s existing balance but not by the current deposit. An oversized burn event then exceeded the log limit, the resolver failed, HOT returned the deposited backing, and the earlier Intents credit survived. This describes the separation between returned backing and surviving internal credit that underlies the reported “ghost balance” mechanism.The report names intents.near and v2_1.omni.hot.tg, and attributes the first exploit transaction to 29 September 2026 at 16:14:19.280 UTC. Native NEAR tracing was unsupported and refused before querying that chain. These details remain public-source context, not native NEAR findings.One numerical conflict must stay visible: page 3 gives a 16,495-byte event and a 16,384-byte limit, a difference of 111 bytes. Page 11 instead describes an 11-byte overflow. This article does not select a corrected figure.Figure 2. Reported mechanism: resolver failure leaves Intents credit in place while HOT returns backing. This NEAR-side sequence is attributed to CertiK, not natively traced by SentinelTX. The report’s 111-versus-11-byte discrepancy remains unresolved. Sources: PDF pp. 3, 11, 22.On BNB Chain, the examined payout transaction objects show the recipient submitting calls to the treasury. That transaction-sender direction differs from the token-transfer direction: the calls travel toward the treasury, while the payouts travel toward the recipient. The report did not decode the withdrawal selector or establish the signer of the trailing authorization-like blob. [PDF pp. 3, 10]What the movement record showsAt 23:57:38 UTC on 30 September, a recorded swap sends 100,000 BSC-USD through the MetaMask Swap Router and returns 128.865999 BNB. Fourteen seconds later, the narrative records another 128.75691 BNB inflow. Although that narrative citation omits the input leg, page 16 supplies a further 100,000 BSC-USD input for the second transaction. This is additional appendix detail, not evidence that the narrative’s narrower citation was a complete flow account.At 01:25:39 UTC on 1 October, the report records 350 BNB entering CoW Protocol EthFlow. A subsequent WBNB-contract hop is described, but its own transaction hash is not cited. A token-contract destination does not identify a custodial exchange deposit; the eventual order settlement remains unresolved.The narrative also identifies direct relationships with three downstream wallets. Pages 17–18 add direction and amounts for selected movements beyond the narrative’s narrower citations. Those rows do not, by themselves, complete every route or establish a return.Similarly, the KuCoin-labelled leg is partial in the narrative. Page 18 identifies a depositor, 0xcd87c2e1f53b7df97f1db56aec6c63cbd60bb262, and a 99.999959 BNB recorded amount. Its relationship to exploit proceeds still lacks the complete amount-anchored path described as missing in the narrative. The earlier Binance-labelled treasury transfers occurred on 29 August and are excluded from incident attribution. No cross-chain route was established. [PDF pp. 7–11, 16–19]Why reported recovery remains a separate claimSeveral outlets cited by SentinelTX report a full return of approximately $3.8 million. The report does not identify a hash-anchored return from the recipient or downstream wallets to the treasury or a designated HOT/NEAR recovery address.An 18 October token-balance query returned no token holdings for the recipient. That cannot establish where the assets went or prove repayment. Nor should it be read as a comprehensive finding of zero assets across chains.Collection limits matter too. Two executed query windows span 29 August–18 October, but the 3,397 retained movements run only from 29 August to 2 October. The appendix records page caps, unwalked rows and a provider page that did not answer. It also states that enforcement of a requested historical window or block cutoff was not established. A query end date is not proof of complete coverage through that date, and this record cannot establish that no later return occurred. [PDF pp. 4, 20–22]Figure 3. Recovery is reported, with no return transfer hash-anchored in the report. The payout classifications, NEAR-side validation and complete downstream routes still require reconciliation. Sources: PDF pp. 13–16, 20–22.What would close the evidence gapsThe report’s priorities are concrete: obtain return hashes, receiving addresses and per-asset amounts; reconcile the two payout classifications; resolve the CoW order’s settlement; and complete the downstream paths with a NEAR-capable source where needed.The follow-up provides a useful accounting-failure explanation and a detailed BNB Chain record. A defensible conclusion preserves the boundary between reported recovery, transaction evidence and unresolved source differences. That boundary is essential to understanding what this postmortem actually establishes.Source note: SentinelTX, CASE-ASYNCE30, compiled 18 October 2026, 25 pages. Explorer links use exact BNB Chain transaction hashes printed in the PDF and are supplied for reference; they do not represent a separate verification pass. The PDF and detached verification manifest document the compiled artifact’s provenance. They do not resolve the substantive qualifications described above.

Cover: Gamdom wallet trace. Ethereum trace and unresolved endpoints. Published analysis date: 17 October 2026.A SentinelTX report on the reported Gamdom hot-wallet incident documents a clear Ethereum sequence: three source addresses funded one receiving account, which exchanged its recorded USDT, USDC and USD1 intake for DAI through seven CoW Protocol settlements on 13 October 2026. The report identifies no custodial-exchange deposit in those traced routes.The account's controller remains unknown. Its narrative ledger records 949,428.481298 DAI received and no DAI sent, but a separate current-balance query returned an empty token list. That makes the apparent DAI holding unverified. The trace also leaves a small bridge transfer unresolved, so it cannot establish where every asset ultimately ended up.This article summarizes the supplied SentinelTX report. It is an account of that source's findings and qualifications, rather than a new chain investigation.What the report coversThe investigation starts at Ethereum address 0x4b304741599c125a244e498d14562487d7109ab8, referred to here as the receiving account. Its attribution-database entry was unlabeled.The approved scope was Ethereum, 10 October 2026 at 00:00 UTC through 17 October at 11:20 UTC, with two inbound and five outbound hops. The executed query record is broader: 10 September 2026 at 11:23:39.121577 UTC through 17 October at 11:23:39.121577 UTC. The report explicitly warns that the executed records do not establish enforcement of the requested historical window or block cutoff.The retained evidence contains 84 movement rows across seven addresses, with timestamps from 13 October at 16:00:23 to 18:17:47 UTC. Movement rows are not a count of distinct transactions. The abstract's one-hop maximum describes its cited routing rows; it does not define the investigation's authorized tracing depth. Upstream reads were also skipped for high-volume wallets, leaving their own funding sources unestablished.The report gives $6,051,923.89 as the value of movements it could price. This is gross traced movement, with value counted along multiple legs, and cannot be presented as Gamdom's loss or the receiving account's balance.Three source addresses supplied the receiving accountThe narrative groups direct receipts as follows. Quantities retain the units and displayed precision of its sender summary.Source A, 0x0067cc2416f792cf0ec5629f5506324ac508f859: 74.266886 ETH in three transfers; 316,809.689210 USDT in six; 468,830.099059 USDC in seven; and 20,077.942699 USD1 in two. The address had no database label.Source B, 0x580450dff316ae00d0fbef9621a304020a046ce2: 10.994222 ETH in two transfers; 109,231.124988 USDT in three; and 34,171.291810 USDC in one. This address was also unlabeled.Source C, 0xd5fbda4c79f38920159fe5f22df9655fde292d47: 1.695248 ETH and 738.148859 DAI, one transfer each. A search-result snippet displayed the nametag “Gamdom: Hot Wallet,” but the attribution database did not supply that label.The narrative's first DAI receipt is at 16:00:23 UTC, in transaction 0xb2cca150592b3ba9344ff17a6f39888a40a855fc1619e8946b8b87e17217578f. Its first listed ETH receipt follows at 16:10:47 UTC, in transaction 0x178957dc5339430fef6c8e460f54722968b59d06dcc899d1ca1cfdf5bedd19ae. Both came from Source C. These timestamps distinguish the earlier token receipt from the ETH activity cited in the account profile.At 16:16:47, Source A sent 262,237.892832 USDT and Source B sent 92,182.438003 USDT. Source A subsequently supplied 62.204364 ETH at 16:18:35 and large USDC transfers, including 216,144.339953 at 16:22:59 and 175,442.114752 at 16:49:35.These source groups establish observed transfers. They do not establish that all three senders belonged to Gamdom or shared a controller.Seven settlements converted the recorded stablecoin intakeAll seven swaps used 0x9008d19f58aabd9ed0d60971565aa8510560ab41, labeled “CowProtocol, Exchange” in the report. Each transaction sent USDT, USDC or USD1 from the receiving account and returned DAI to that same account.The following entries reproduce the report's six-decimal swap summary. All times are UTC on 13 October 2026; the routing evidence retains greater precision for some token transfers.16:23:35 — Sold 354,420.330835 USDT; received 354,092.632978 DAI. Transaction: 0x00ce1e32059de820e307f65aaac3d790a95fcab2a48b82be768c9f5ab07b2441.16:26:23 — Sold 250,492.462571 USDC; received 250,484.456553 DAI. Transaction: 0x2b2a4ce1aa3f910d44b1425718429c8c7d1c5440729acf046fd26586b72356bb.16:38:59 — Sold 56,130.912559 USDT; received 56,078.550875 DAI. Transaction: 0xf00e7510ce52f85fbde1066922dc9f18fadb5710892d972bf62532c21792d52e.16:39:47 — Sold 20,077.942699 USD1; received 20,061.011520 DAI. Transaction: 0xf13d17c1b8a167aa087ed6402e1788de0244772dd39b78b9d377e38232bd7af9.17:17:11 — Sold 246,251.441288 USDC; received 246,243.742960 DAI. Transaction: 0x3ea5d430d9966ecc19a58ff3433129eaea619cd4f95038e9e34b6ad403bc8000.17:57:11 — Sold 15,489.570804 USDT; received 15,472.826473 DAI. Transaction: 0xc9a9ae19e7ec220ac5e310a986cd819542a5259406a2f307600e7b8ea4c4b842.18:00:11 — Sold 6,257.487010 USDC; received 6,257.111080 DAI. Transaction: 0xced9badc65a23f72a9462d427ae8350c87710bf3d4b32b8763738ba6375d1367.The report reconciles these sales to the narrative intake: 426,040.814198 USDT, 503,001.390869 USDC and 20,077.942699 USD1. It records 948,690.332439 DAI returned by the settlements. For the largest swap, the underlying transfer amount is 354,092.632977884068510689 DAI; the list above uses the rounded narrative figure.Seven swap transactions returned DAI to the receiving account. A protocol's “Exchange” label does not establish a deposit into a custodial trading account.The automated trace marked 15 “cash-out legs” complete. The narrative explains that these counted both sides of each of the seven swaps, plus one bridge leg. After deduplication, there are seven settlements and one bridge interaction, rather than 15 separate exits.Figure 1. Seven settlements returned 948,690.332439 DAI to the receiving account on 13 October 2026. Labels use the six-decimal summary in SentinelTX CASE-ASYNCE53, page 6; quantities are DAI, not dollar losses.ETH accounting and the DAI balance gapThe report's completed provider ETH list records six inbound transfers totaling 86.956356111770671236 ETH, two outbound transfers totaling 0.014 ETH, and gas fees of 0.000498820354746462 ETH. Subtracting the recorded outflows and fees gives 86.941857291415924774 ETH.The methodology calls this arithmetic over the provider's returned history, rather than a direct balance measurement. That distinction also matters for DAI. The narrative adds 948,690.332439 DAI from swaps to 738.148859 DAI from Source C, giving 949,428.481298 DAI received with no recorded DAI outflow. Its separate balance query returned no tokens, and the report explicitly says the holding needs a direct recheck.The broader generated movement summary also includes a 3,012.335110 DAI row in its traced-origin grouping. That section explicitly describes evidence-set activity without establishing incident connection, and the report does not reconcile the row with its receiving-account narrative. It is not added here to the seed ledger or to a loss total.Two small ETH transfers and an unresolved bridgeAt 17:42:23 UTC, the receiving account sent 0.01 ETH back to Source C in transaction 0x90d15c162609522d1229818adfe352d48270db57050e7179a0c0d779a6c1fc0e. This is the address carrying the snippet-only Gamdom nametag.At 18:16:11 UTC, it sent 0.004 ETH to 0x0439e60f02a8900a951603950d8d4527f400c3f1, labeled “Metamask Bridge, Exchange,” in transaction 0xc6365a438054089c9f796643f4ec99ee4bb3ef57a02a39728e511d7638cf8507, at block 26185303.The destination chain and destination address were not resolved. Eight protocol-explorer checks failed to respond. The report suggests the small amount could represent a gas top-up, but labels that interpretation as an assessment. The incomplete lookup cannot establish that all funds remained on Ethereum.The report also records a connection with Relay.link, 0xf70da97812cb96acdf810712aa562db8dfa3dbef. Its narrative describes a direct edge and a shared CoW counterparty, while saying no separate value transfer appears in the seed's transfer ledger. That interaction remains unresolved. The full retained dataset extends to 18:17:47 UTC, later than the narrative's final own-account action at 18:16:11.Figure 2. Three source addresses funded the receiving account. Seven CoW settlements returned DAI; 0.01 ETH went back to Source C and 0.004 ETH reached MetaMask Bridge. The destination chain and address remain unresolved. Source: report pages 5–8. Full addresses appear in the address key.What the evidence says about control and intentThe receiving address had contract code. The report describes a programmable smart account and raises possible EIP-7702 delegation, based on self-calls with selector 0xe9ae5c53. Its code prefix was not read, so delegation is unestablished. A successful call or verified transfer does not identify the signer, authorization or motive.The report's expert assessment considers a hot-wallet compromise followed by rapid conversion into DAI plausible. It also says an operator-initiated emergency sweep cannot be ruled out. The return of 0.01 ETH to the Gamdom-nametagged address and the unidentified receiving-account controller preserve that ambiguity. Shared counterparties among source wallets do not resolve it.Incident-wide loss claims in the report range from more than $2.3 million moving out of hot wallets to a founder statement of “just over $3m” and independent reporting near $4.2 million. Those claims came from search-result snippets, rather than full-page verification. The Gamdom and Romer X posts were not read. Claims that user funds were safe were also unverified.Reported activity on Solana, BNB Chain, Tron and the XRP Ledger falls outside this Ethereum review. Neither those loss claims nor the report's $6.05 million gross-movement figure can be substituted for a verified loss calculation.The defensible conclusionThe strongest finding is the seven-transaction conversion of the narrative's recorded USDT, USDC and USD1 receipts into DAI, with proceeds returned to one identified Ethereum account. The reviewed routes show no identified custodial-exchange deposit. Ownership, current DAI holdings and the bridge's destination remain open questions.The report's priorities follow directly from those limits: recheck the DAI holding, establish whether Gamdom controls the relevant addresses, inspect the account's delegation code, resolve the bridge destination and monitor any later custodial-exchange deposit. Further work on the other reported chains would require a separate scope. Until those questions are answered, the trace supports a documented conversion sequence, not a definitive attribution of theft, a final loss total or proof of recovery.Figure 3. The report documents the conversion sequence but leaves the controller, current DAI holding and bridge destination unresolved. The narrative ledger is not a verified current balance. Source: report pages 7–9; broader generated movement totals are discussed separately in the text.Address keyReceiving account: 0x4b304741599c125a244e498d14562487d7109ab8 Source A: 0x0067cc2416f792cf0ec5629f5506324ac508f859 Source B: 0x580450dff316ae00d0fbef9621a304020a046ce2 Source C, snippet-only Gamdom nametag: 0xd5fbda4c79f38920159fe5f22df9655fde292d47 CoW settlement: 0x9008d19f58aabd9ed0d60971565aa8510560ab41 MetaMask Bridge: 0x0439e60f02a8900a951603950d8d4527f400c3f1 Relay.link: 0xf70da97812cb96acdf810712aa562db8dfa3dbefSource notePrepared from SentinelTX case CASE-ASYNCE53, report generated 17 October 2026 at 11:27:49 UTC. The source narrative and sender/swap summaries are on pages 4–9; transaction-routing evidence on pages 10–16; generated movement totals on pages 17–19; and collection limits and executed query bounds on pages 20–21. Token symbols are as reported and do not independently verify token identities. No additional external verification was performed for this article.