Defend Against Cybercrime with the Power of Community

SentinelTX’s report on the October 8, 2026 X7 Finance / X7Pioneer incident describes a transaction-scoped net outflow of 6.793749214542107991 ETH from the contract publicly attributed to X7Pioneer. Of that amount, the report records 6.780267629238261652 ETH reaching its starting address. The subsequent Ethereum transfers divide into three paths: 3.3 ETH to a Tornado.Cash-labeled address, 1.723 ETH to an unlabeled wallet, and 1.75 ETH to an intermediary used in a reported bridge route.Those quantities answer different questions. The contract’s net outflow, the recipient’s receipt, a repaid principal amount and transfers repeated across multiple hops should remain separate. The report also distinguishes retrieved transfers from the attribution of a mechanism, an operator or a service account.This article follows SentinelTX case CASE-ASYNC643, dated October 19, 2026. The report retrieves individual transfers but leaves several wider conclusions unverified. A retrieved transfer does not, by itself, establish who signed it, whether it was authorised or the nature of a token. One proposed connection cannot represent incident proceeds: the 0.15 ETH payment occurred before the transaction said to fund it. It is therefore excluded from the proceeds trail. The bridge settlement also remains unverified. The source notes below retain the report’s exact warnings and other material discrepancies.The transaction at the center of the reportThe seed transaction is 0xc98056d6ab55ef898189da5fa1fb08b968cb84ca99528d171f8240836b21766d. SentinelTX places it on Ethereum mainnet, chain ID 1, at block 26146922, transaction index 45, on October 8, 2026 at 09:55:59 UTC. The reported status is success, with no revert in the trace.The narrative identifies 0xc79352119a7cf6efbfabbd7e6b013b79687bacf2 as the signing externally owned account, or EOA. It describes a nonce-2 contract-creation transaction that deployed 0x021f832b9ce6685b1135f4a3b55f2b317f95f55c, which in turn deployed the helper contract 0xaa0cad88ac3f76beb9a0f1ba661916d7716d5f4a in the same transaction. The report presents these signer and deployment statements as unverified conclusions.The reported native-ETH value frames show the following sequence:The WETH contract, 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2, sent 26.963170607692677032 ETH to the helper.The helper sent 26.963170607692677032 ETH to 0x70000299ee8910ccacd97b1bb560e34f49c9e4f7, the contract attributed to X7Pioneer in the report’s public sources.That contract returned 33.756919822234785023 ETH to the helper.The helper sent 26.976652192996523371 ETH back to WETH.The helper sent 6.780267629238261652 ETH to the EOA.SentinelTX calculates the contract’s transaction-scoped net outflow as 6.793749214542107991 ETH. The difference between this figure and the EOA’s receipt is 0.013481585303846339 ETH, which the report identifies as excess ETH re-wrapped into WETH. The helper’s gross inflow and gross outflow are each 60.720090429927462055 ETH; its net native-ETH change in the transaction is zero.The call tree contains 830 frames and reaches depth 8. Its summed frame value, 121.44018085985492411 ETH, counts forwarding hops repeatedly. It is therefore unsuitable as a loss figure. The separate gross-movement total of 130.274148 ETH across 20 transactions also recounts value across hops and is not an incident-loss estimate.What the report says about the mechanismThe reward-accounting explanation comes from third-party search snippets cited by SentinelTX: a SlowMist TI Alert result carried by KuCoin and DeFiHackLabs pull request #1299. The report says these pages were not read. Their snippets attribute an approximately 6.78 ETH loss to a flaw in X7Pioneer’s claimRewards() path; the SlowMist snippet also describes an ETH donation that amplified the accounting delta.SentinelTX describes value movements consistent with that account: the helper’s incoming payment to the attributed X7Pioneer contract, a long sequence of repeated calls, and a larger payment back to the helper. It notes 148 consecutive calls with selector 0x5eac6239 among the 169 displayed frames of the 830-frame trace. The selectors were not ABI-decoded in the evidence, so the report does not establish their function names or the exact accounting formula.The financing explanation is also an assessment. SentinelTX describes a call sequence through 0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2 and 0x4d5f47fa6a74757f35c14fd3a6ef8e3c9bc514e8, a callback into the helper, WETH unwrapping and subsequent re-wrapping. It interprets that shape as a flash loan with principal of approximately 26.963170607692677032 ETH and an excess repayment of 0.013481585303846339 ETH, roughly 0.05% of principal. The lender was not identified and the selectors were not decoded. The report keeps the flash-loan reading as an inference and excludes the repaid principal from retained proceeds.Three downstream Ethereum pathsThe report records 6.773 ETH in post-incident outflow from the EOA. The earliest listed transfers went to an unlabeled wallet; mixer-labeled transfers followed, then the intermediary associated with the bridge route. All times below are UTC on October 8, 2026.Unlabeled wallet: 0.001 ETH at 10:04:23 and 1.722 ETH at 10:05:23 went to 0x1572cc5a965e6c2f980eca7f6cc63971a9b80eb3, totaling 1.723 ETH. SentinelTX describes the first payment as a test transfer. Its October 19 provider record lists two inflows and no outflows, with in minus out minus gas of 1.723 ETH.Tornado.Cash-labeled recipient: six transfers to 0xd90e2f925da726b50c4ed8d0fb90ad053324f31b totaled 3.3 ETH. Three 0.1 ETH transfers occurred at 10:11:23, 10:12:23 and 10:12:59; three 1.0 ETH transfers followed at 10:13:35, 10:14:11 and 10:15:59.Bridge intermediary: 1.75 ETH went to 0x314b7e4e69fc3ed0b519b5fd835a4adc9abbf335 at 10:23:59. The report assigns no entity label to that address.Figure 1. The report groups nine post-incident transfers from the starting address into three Ethereum branches: 3.3 ETH, 1.723 ETH and 1.75 ETH, totaling 6.773 ETH. The 0.15 ETH sent at 09:11:59 UTC preceded the seed transaction and is excluded. These bars compare transfers; they do not establish a loss or a current balance.Color key: Slate bars show ETH sent by the starting address. A, B and C directly identify recipients; the amounts share a zero baseline.Address/role key: Starting address = 0xc79352119a7cf6efbfabbd7e6b013b79687bacf2. A = 0xd90e2f925da726b50c4ed8d0fb90ad053324f31b, with Tornado.Cash labels recorded in the report; B = 0x1572cc5a965e6c2f980eca7f6cc63971a9b80eb3, unlabeled wallet; C = 0x314b7e4e69fc3ed0b519b5fd835a4adc9abbf335, bridge intermediary.Source: SentinelTX PDF, CASE-ASYNC643, pp. 6–8, Transaction Chronology. Report-level confidence qualifications: pp. 4 and 19.Two different label records appear for the mixer recipient: “Tornado Cash: 10 ETH (Sanctioned)” and “Tornado.Cash, Mixer, Tornado.Cash: Router, Sanctioned.” SentinelTX reproduces both and says the observed deposit sizes are consistent with the Router role. It treats this leg as a privacy boundary and does not trace it further. The methodology says the recipient’s outbound list was not read because it was a high-volume wallet; an absence of outbound edges in the traced set should be read within that collection boundary.The reported bridge route and its receipt qualificationAt 10:24:47 UTC, the intermediary sent 1.75 ETH to 0x1231deb6f5749ef6ce6943a275a1d3e7486f4eae, labeled “LifiDiamond,” in transaction 0xa892aab832796dddd384289179364eaa40f5674a47e77eb9f0347ee0c127f810.The bridge lookup describes a LiFi route using Mayan, also indexed as Socket (Mayan), with the same intermediary address as destination on Arbitrum, chain ID 42161. It reports delivery of 4,475.922884 USDC, with token contract 0xaf88d065e77c8cC2239327C5EDb3A432268e5831. The lookup’s basis is the transaction hash, but the destination-side receipt remains unverified, and the report does not cite the settlement transaction hash.The next reported movement is a transfer of 4,475.922884 USDC at 10:25:31 UTC from the intermediary to 0x2df1c51e09aecf9cacb7bc98cb1742757f163df7, labeled “HyperLiquid, Dex.” Its transaction hash is 0x3d0d18b844f5ebfad3d157702713d48f6233094640b9bf21460d0b89f82e1d6d, at block 512852763. The routing table marks that transfer verified. This separate row does not remove the bridge receipt qualification.Diagram 2. The report describes 1.75 ETH routed via LiFi/Mayan to the same intermediary address on Arbitrum as 4,475.922884 USDC, followed by a transfer to an address labeled “HyperLiquid, Dex”. The bridge settlement remains unverified, and the destination settlement hash is not cited. The onward transfer hash is cited. No custodial cash-out or account ownership is established.Color key: Slate nodes are the intermediary on Ethereum and Arbitrum; the sage node is the HyperLiquid-labeled destination. The dashed arrow denotes the reported, receipt-unverified settlement; the solid arrow denotes the reported onward USDC transfer. Equal-width arrows do not encode amounts.Address/role key: Intermediary on both chains = 0x314b7e4e69fc3ed0b519b5fd835a4adc9abbf335; LiFi router on Ethereum = 0x1231deb6f5749ef6ce6943a275a1d3e7486f4eae; HyperLiquid-labeled destination = 0x2df1c51e09aecf9cacb7bc98cb1742757f163df7. The diagram condenses the bridge service into the first connection.Source: SentinelTX PDF, CASE-ASYNC643, p. 7, Transaction Chronology; pp. 10–11, Transaction Typology; p. 13, Conclusion.SentinelTX identifies the HyperLiquid-labeled address as a DEX endpoint rather than a custodial exchange deposit. Whether the value can be attributed to a particular account at the venue remains an unverified lead. The narrative calls this transfer the third-hop scope boundary; the routing table labels the USDC row hop 1, while the abstract says the cited routing rows reach at most two hops. These are different source presentations, not interchangeable measures of coverage.Funding before the seed transactionThe report places the EOA’s earliest observed value receipt at 09:11:23 UTC, from 0xe7351fd770a37282b91d153ee690b63579d6dd7f, labeled “deBridge Finance, DinDestination, Bridge.” Its narrative gives the amount as 0.160966947216380443 ETH, displayed as 0.160967 ETH, in transaction 0x72d94e8367a25c27d7b381ec899711115489468ffa3eeca2556c17149e3fa56b. The originating chain and depositor are unresolved.At 09:11:59 UTC, the EOA sent 0.15 ETH to 0xb2ecfe4e4d61f8790bbb9de2d1259b9e2410cea5 in transaction 0xda55fd68dce40896726207c74cf9618d8cd727d00d7f822af04d68470b3baeec. The chronology explicitly separates this transfer from incident proceeds because it preceded the seed transaction. It is not included in the three post-incident paths above.A receipt of 15.0 tokens reported as “SEND” at 09:18:23 UTC is recorded but excluded from the value trail. SentinelTX did not classify the token contract or assign a value, and it claims no link to the operator. Three later look-alike-address transfers are similarly recorded but excluded from tracing. The report classifies them as address-poisoning noise without an evidentiary link to the operator.The source limits that matterSentinelTX reports 22 traced movements across 15 addresses. Its two executed query windows each cover 41 days, from September 8 to October 19, 2026 UTC. The 18 retained movements with readable timestamps span October 8 from 09:11:23 to 10:42:47 UTC; four retained rows lack readable timestamps. The methodology says the query interval does not establish complete transaction coverage or enforcement of a requested historical window or block cutoff.The report itself contains several material qualifications and inconsistencies:Verification wording: the executive summary says five claims were downgraded and one finding flagged for review. Its “unverified (auto-downgraded)” heading coexists with a conclusion using “confirms” and a routing table marking transfers verified. This article attributes the analysis to SentinelTX and preserves the abstract’s narrower definition of transfer verification.Pre-incident routing: warning INV-5 identifies a time-inverted path from block 26,146,922 to block 26,146,702. The latter contains the 0.15 ETH payment made before the seed transaction. The report’s chronology already says it cannot be incident proceeds; the warning remains part of the source.Funding quantity: the narrative gives the deBridge receipt as 0.160966947216380443 ETH, while the routing table’s Transfer amount is 0.160966773016380443 ETH. Both are preserved here without choosing a replacement figure.Look-alike transfer quantities: the narrative and Amount column describe three transfers as 0 ETH or 0.0 ETH. The corresponding Transfer amounts are 0.000000172200000000 ETH, 0.000000001000000000 ETH and 0.000000001000000000 ETH. SentinelTX distinguishes recorded Amount from retained-unit Transfer amount and says a difference alone does not establish case attribution.Endpoints and scope: the abstract says terminal endpoints are not recorded in its evidence subset, while the body lists terminal addresses in the traced set. A traced-set terminal denotes a boundary in those records; it does not establish a final beneficiary, an absence of later activity or conversion to cash.The October 19 snapshots also remain separate from traced movements. The report gives the EOA’s snapshot balance as 0.00298 ETH and its provider-list inflow minus outflow minus gas as 0.002980011244414113 ETH. The intermediary’s Ethereum residual is 0.001423268336660466 ETH. Its provider list includes 1.7515 ETH of inflow, with the sender of the additional 0.0015 ETH above the EOA’s 1.75 ETH payment unidentified in this evidence. These figures are dated observations, not current balance claims.The leads SentinelTX leaves openThe report’s conclusion identifies three principal leads: the deBridge funding order, the USDC sent to the HyperLiquid-labeled address, and the unlabeled wallet recorded with 1.723 ETH and no outflows. Its recommended follow-up is specific to those boundaries.For deBridge, SentinelTX recommends obtaining the funding order’s source chain, depositor address and order ID. For LiFi / Mayan, it recommends obtaining the routing record and Arbitrum settlement to corroborate the delivered amount and any integrator metadata. For the HyperLiquid-labeled transfer, it recommends a preservation and information request through the venue’s compliance channel, including any attributable account and subsequent withdrawals.It also recommends monitoring the 1.723 ETH wallet, the intermediary on Ethereum and Arbitrum, and the pre-incident recipient. For the mixer leg, it treats any future withdrawal attribution as a separate lead. Before an evidentiary filing, the report recommends decoding the seed transaction’s selectors against verified ABIs and reading the event logs to move the mechanism beyond its present attributed, code-level-unverified status.Figure 3. The report’s conclusion states a seed-transaction contract net outflow of 6.793749214542107991 ETH and a signer receipt of 6.780267629238261652 ETH; the image rounds these to approximately six decimal places. It attributes the reward-accounting mechanism to SlowMist and DeFiHackLabs without decoded code-level semantics, does not establish operator identity, and identifies no custodial exchange deposit within three hops. Five broader claims remain unverified. A payment made before the incident cannot be proceeds of it, and the bridge settlement is still unverified. These limitations remain part of the conclusion.Color key: Slate headings organize quantities, interpretation and report qualifications. Confidence is stated in words, not encoded by color.Address/role key: Net-outflow contract = 0x70000299ee8910ccacd97b1bb560e34f49c9e4f7, attributed to X7Pioneer by public reports; signer = 0xc79352119a7cf6efbfabbd7e6b013b79687bacf2.Source: SentinelTX PDF, CASE-ASYNC643, pp. 4–5, Executive Summary; pp. 9–10, Transaction Typology; p. 13, Conclusion; p. 19, Automated Integrity Check. Incomplete evidence scope: pp. 1–2 and 17–18.The central finding is a reported contract net outflow of 6.793749214542107991 ETH, a receipt of 6.780267629238261652 ETH by the starting EOA, and the three downstream Ethereum paths described above. The report attributes the incident to X7Pioneer and a reward-accounting flaw through its cited public snippets, while keeping the exact code semantics and operator identity unresolved. The unverified bridge settlement, excluded pre-incident payment and incomplete collection scope limit what these findings establish.

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.