Defend Against Cybercrime with the Power of Community

On 1 November 2026, a wallet called the same execution contract twice, one second apart. In those transactions, collateral moved out of six source contracts, passed through option pools, and was partly converted into ETH. The execution contract then paid ETH to the wallet that submitted the calls. This review follows that Arbitrum sequence and the sender’s next nine ETH payments. It keeps the reported Bitcoin exit separate from the route directly observed here.Premia is an options protocol. An option gives its buyer a right to trade an asset on agreed terms; a vault can place depositors’ assets behind those obligations. An option pool is the contract in which the associated positions and collateral are recorded. The distinction matters: collateral leaving a vault, leaving a pool, changing asset and reaching a wallet are different stages of the same movement, rather than losses to add together.Blockaid’s original alert described newly created empty pools, flash loans and options purchases that directed vault collateral into those pools before a liquidity withdrawal. That is the security firm’s mechanism assessment. The records below support a transaction sequence, but this review does not independently establish the precise code defect. Blockaid’s alert.1. The actors and the limits of the routeThe transaction sender signs the call and pays its fee. The execution contract receives the call and performs the contract interactions. The source contracts hold the collateral that later appears in the pools. These are roles in the records; they do not identify people or prove who controlled a destination.Role / chainFull addressTransaction sender · Arbitrum0xbeBa8CEfD0D75d747C5AD966Dc17C0Bb60D84dBdExecution contract · Arbitrum0x577168C8c6fA937495C3D6961f1d7D734b2d785fThe directly reviewed route is source contracts → option pools → execution contract → transaction sender → nine Arbitrum recipients. A separate public claim extends the trail to Ethereum and Bitcoin. No solid arrow in the diagrams below represents that unconfirmed cross-chain extension.Scope / measureValue / interpretationIncident anchors1 Nov 2026, 03:14:37–03:15:40 UTC; setup and two successful callsSource-contract net outflows3.64410382 WBTC; 43.472545677315167985 WETH; 48479.358725 USDC.e; 46,215.428616328829808 ARBETH paid to transaction sender191.775520770266156270 ETH, two internal paymentsSelected onward payments191.823 ETH, nine Arbitrum transactions; not an exact loss allocationEvidence checkedArbiscan overview / all and net transfers; Blockscout individual transaction details and wallet listings. Direct explorer review; no SentinelTX result is assertedReview boundarySelected records read on 2 Nov 2026; no claim of full-history or current-balance coverage2. Preparation came before the two callsWhat was already in place when the collateral moved? At 03:14:37 UTC, the sender called the execution contract in a successful transaction that the explorer records as creating six contracts. The same record shows small transfers into those newly created addresses and option-position mint and burn entries. A mint creates a token record; a burn removes one. Neither entry alone proves that a separate person deposited or received assets.UTC · 1 NovRecord / meaning03:14:37Setup transaction · block 520166285; six created addresses listed03:15:39First attack anchor · block 520166479; same sender and execution contract03:15:40Second attack anchor · block 520166483; same sender and execution contractThe setup predates the first reviewed outflow by 62 seconds. The two later calls are four Arbitrum blocks apart and one second apart by their displayed UTC timestamps. The wallet listing displays the same selector, 0xbcea0a12, for both later calls. A selector is the first four bytes used to indicate a contract function; it is not a decoded explanation of what that function does. Timing connects the sequence, but it does not by itself explain which condition in the vault or pool code permitted the withdrawal.3. What left the source contractsWhich amount measures the collateral movement without counting it again at each step? For this question, the table uses each source address’s net ERC-20 outflow inside its relevant attack transaction. “Net” means transfers out minus transfers back to that same address in the same record. It is not a complete balance reconciliation or a final depositor-loss calculation.Source · ArbitrumNet outflowAnchor0x45dF5EA836A15B561937Ae8373ab9eE984aea5313.64410382 WBTCFirst0xbae43c546DFADC69576aE73C68e0694A54F08e1B43.472545677315167985 WETHFirst0xD46993F25D298ebbCD31E941156C66f7e628A52a21,333.613826 USDC.eFirst0x6A1FC0E1c60BA6564CDe4910A425F1F1a1d18C1F20,215.067131 USDC.eSecond0xDC631d88dbB5eb39f5c4Bf8B4e5298d098912fFf46,215.428616328829808 ARBSecond0xBe3E229319f86F5EE96EE1Dc0B6D55e8b68a439e6,930.677768 USDC.eSecondThe three USDC.e rows sum to 48,479.358725 USDC.e. USDC.e denotes the bridged token contract in these records; it is not silently substituted with native USDC. WBTC and WETH are token representations of Bitcoin and ether. Their token outflows should remain separate by asset, and the explorer’s changing dollar display should not be used to manufacture a single historical loss price.Read Figure 1 from the source group into the central execution contract, then down to the transaction sender. Solid arrows summarize transfers within the reviewed Arbitrum records; arrow width is not proportional to amount. The key observation is that different collateral assets converge into two ETH payments. The next question is how those payments relate to later outgoing ETH.Figure 1. The reviewed Arbitrum route. Source amounts are net outflows; the two ETH payments describe a later stage and are not added to them. Exact quantities and source links appear in the adjacent tables.4. Working capital is different from proceedsThe first transaction shows the Balancer-labelled vault sending 0.9 WBTC, 11 WETH and 6,000 USDC.e to the execution contract, with matching token repayments in that same transaction. A flash loan supplies temporary working capital that is borrowed and repaid within one transaction. The matching round trips support that description; they are not separate victim losses.After the first call, the explorer’s net-transfer view shows 3.62484902 WBTC and 21,223.508226 USDC.e retained by the execution contract. Its second-call net view shows those same quantities leaving it, with swap counterparties receiving those tokens and sending WETH. The second record includes WETH receipts of 124.023037246690632576, 21.175933432587279601 and 3.338052413673076108. Their sum is the 148.537023092950988285 WETH unwrapped in that call. Second call: transfer and unwrap record. This supports the asset-conversion sequence without treating the retained tokens and resulting ETH as two losses.Call / stageETH paid to senderFirst call43.238497677315167985 ETHSecond call148.537023092950988285 ETHCalculated total191.775520770266156270 ETHEach payout is visible as an internal ETH transfer from the execution contract to the sender. The same transaction also shows the corresponding WETH unwrap. Unwrapping changes the form of ether; it is not another independent theft. These payouts also differ from the source-contract net outflow amounts because trading, premiums and other transfers intervene. They are not a gas-adjusted profit statement.5. Nine onward payments, not nine proven cash-outsWhat happened to the sender’s ETH next? Nine selected transaction details show successful outgoing ETH payments between 03:18:09 and 03:30:58 UTC. The timestamps below are normalized from Blockscout’s explicitly displayed +09:00 offset; the original display is retained in the evidence files. These transactions total 191.823 ETH.UTC · 1 NovETHTransaction03:18:09100x5027bfc48c6b7ba29182aaf03dd1e3ce0f616c39736570649fe9f9d74e359d3c03:19:18100x731dabd98f5761de0ba13982e5d0ebaa21a5c0b49e437ee056ec03fb958a5d6a03:22:30200xe45b834091218960383c8383fa64b5d793d572194072e28424044a703432639403:23:34200x31cb4ec03ae836e68fa10cf626f001a915e72ea3a577d23293a07bc50dad8c5603:26:08200xd31eccc1175164508fdd06348b386e01fc089312bbbb0b70c9b092dd89a4b8bd03:27:19200x281fe73a4d11453b560bdb0b970ac6ea39d80e2098b02419bc6d675484aee5c103:28:23300x39da76ea9396abaa7e589460baee088d7e181fd24d73fe914cedac8d950d512a03:29:42300x7db39a7cfa5c64fb87d1ee21f8c8509cb25d463dfc9e437af5752ff42d67714f03:30:5831.8230x2e0fef226cbb105c01b4ff5155117a818aa9c71eee02c8ab9117caf5e4e7f0e6The outgoing total exceeds the two reviewed attack payouts by 0.047479229733843730 ETH. This arithmetic difference does not establish a second theft, a service fee or a missing bridge payment. A pre-event internal-transfer listing also records 0.05946476252970877 ETH entering the sender at block 520146086 from an address labelled “Across Protocol: Spoke Pool.” The listing establishes an earlier inflow lead, not the identity of a depositor or a verified cross-chain origin. Its parent transaction has not been independently decoded in this review. Internal-transfer listing.Read Figure 2 from the two payout boxes into the sender, then outward to the onward-payment group. Solid arrows describe observed Arbitrum movements; the dashed boundary marks the reported cross-chain continuation. The larger outgoing total warns against assigning every outgoing wei to this incident. Finding which service request corresponds to each recipient is the next evidentiary step.Figure 2. Payouts and onward payments use separate denominators. The earlier funding listing prevents a claim that the entire later total is a directly measured incident loss. Dashed links represent a public report, not verified bridge delivery.Blockscout’s transaction details include “Sent to Ethereum Mainnet” and a commitment transaction as part of the L1 status of these Arbitrum transactions. That is rollup publication and confirmation information. It is not evidence that the recipient received the payment on Ethereum or that a bridge delivered the stolen assets there.6. Where the reported Bitcoin exit remains openPeckShield’s original post gives an estimate of $464.6K and reports movement from Arbitrum to Ethereum followed by conversion into BTC through Chainflip and NEAR Intents. This is an attributed security-firm finding, not a route independently completed by the records reviewed here. PeckShield’s original post.A payment to a deposit address does not by itself prove service completion. A payment may be a deposit attempt, a transfer to another wallet, or a step in a service route. Those alternatives remain open unless a request or payout record identifies its role. An independently established cross-chain route needs the source deposit, its service request or message identifier, and a matching destination payout. A Bitcoin destination also requires its actual address and payout transaction. Matching amounts, close times, explorer labels or the same hexadecimal address on two chains cannot replace those records.The $400.5K alert and $464.6K later estimate therefore remain separate source claims. This article does not average them, add them or imply that their difference is a newly discovered loss. No price-at-block conversion, definitive vulnerable function, patch verification, recovery or compensation is established here.7. Incident-specific response pointsFor protocol operators, the question raised by the sequence is how an option-writing vault accounts for collateral when a newly created pool has little or no independent liquidity. A meaningful review would reproduce the full first-trade and withdrawal sequence against the deployed implementation, test whether collateral ownership is preserved, and compare any proposed fix against that same sequence. This is an analysis priority, not a verified diagnosis of a particular function.For investigators and relevant services, the useful handoff is the exact sender, execution contract, source transactions and nine recipient payments below. A service-specific deposit or request record could connect a payment to its eventual payout. Until that connection is obtained, recipient ownership, common control, completed Bitcoin swaps and recoverable balances remain open.8. Evidence appendixThe pre-event funding listing names 0xe35e9842fceaCA96570B734083f4a58e8F7C5f2A as the sending contract and 0xd07a31b62136d22c461b1d2aa383bd530b6ccc01f7c03d0108be3270b01cde04 as the parent transaction. This is a listing-level observation; its original depositor and cross-chain source remain unconfirmed.All addresses below are on Arbitrum One and link to that chain’s address detail pages. Full transaction hashes are preserved above and in the anchor register below. Explorer labels are descriptions of displayed roles, not independent identity evidence. The nine onward recipients are not labelled as accomplices or proven service wallets.Onward paymentFull Arbitrum recipient03:18:09 UTC · 10 ETH0x3f70716B99d0fb4df24c02404190045D7d617FD503:19:18 UTC · 10 ETH0x673310E15136C97dDa90C2853b01743C346B551703:22:30 UTC · 20 ETH0x480863ab3521AFa2c7E51273646bf265f850334D03:23:34 UTC · 20 ETH0x979A3892232CDdD740EE04BC44c86245E8191Bf203:26:08 UTC · 20 ETH0xA8e24E87b224abd6977Dc2Aa0e0285D71E784f2F03:27:19 UTC · 20 ETH0xe4c4A88Be8F6fCB5bbD2dc28f6a53E35fCC5b02C03:28:23 UTC · 30 ETH0xbc065c9Da182Ab8909eFE4FeC873ac19Cfe0f52403:29:42 UTC · 30 ETH0xdD49933388DD59f087d2319F65c9AE8Fbc66987a03:30:58 UTC · 31.823 ETH0x42F2B5B9A2B9859FE7b0cc74bB2A016966d4A7DBAttack transaction anchorsRecordFull transaction hashSetup0xe3c263fcae544954367998e48e13112875cfd38a3b9a240e7818bb96313831f5First attack anchor0x64602cbbeba5d3c7a5e2cff4f98cc118886fc6051c56fa50458abec2c90441acSecond attack anchor0xd7e8086df0570c5389ca27eb9bcdff290e810c094155b410a42e5bad2b3244ffThe direct checks cover the displayed explorer records and exact arithmetic described in this article. They are not an execution replay or an independent RPC receipt verification. The precise contract defect, service-request mappings, destination-chain transactions and Bitcoin receipt remain outside the verified route. No conclusion about the identity of an operator follows from the observed flow alone.

ChainBounty · Investigation analysis · 31 October 2026A SentinelTX report records 1,013,353.611686 USDC leaving an Avalanche contract at 00:00:03 UTC on 28 October 2026, followed by forwarding to a wallet and two subsequent USDC burns. Public reports cited in the PDF associate the contract with a TranchePool linked to Fence Finance, Valinor Digital and Oatfi. Those affiliations are reported leads, not independently established ownership findings.The strongest story is not a seamless trail across three chains. It is an Avalanche sequence alongside a separate Ethereum activity record, with the connection between them unresolved. The PDF also contains conflicting confidence labels and a route whose timing cannot support its stated direction. This article keeps those limits visible rather than presenting a complete, verified cash-out path.1. Roles before routesThe report distinguishes the contract that sent the USDC, the intermediate contract, and the wallet that received it. These are on-chain roles—not identified people. Short reference IDs below organize the PDF's records; the full identifiers appear in the appendix.Role: A1 — source contract — Description in the report: Sender of 1,013,353.611686 USDC. Its identification as the victim TranchePool comes from attributed search snippets.Role: A2 — intermediate contract — Description in the report: Received the source-contract transfer and forwarded 1,013,353.611687 USDC to A3 in the same transaction, E1.Role: A3 — Avalanche wallet — Description in the report: Recipient of that forwarding transfer; recorded creator of A2; sender in the two later burn transactions E2 and E3. Identity not established.Role: A4 — Ethereum address — Description in the report: Reported receiver examined separately. The PDF does not establish common control with A3 or an end-to-end path from the Avalanche burns.Role: Report scope — Description in the report: Narrative examines 27–31 October 2026; the query appendix reports broader 34-day lookbacks. Neither is a claim of complete coverage.The difference between the two E1 amounts is retained exactly: 1,013,353.611686 USDC left A1; 1,013,353.611687 USDC reached A3 from A2. They are distinct transfer legs, not interchangeable loss figures. The report states incident loss using the first leg only. It does not add the forwarding, burn, mint, swap and mixer figures together.2. What the Avalanche record describesOn 27 October, A3 received 100.0 AVAX at 22:42:23 UTC and 11.8294 AVAX at 22:45:24 UTC from an address labelled “KuCoin, Exchange” in the report's label database. The direction was exchange-labelled address to wallet. It is a funding relationship, not proof of an account holder's identity or exchange involvement in the incident.The report's transaction-list record places A2's creation at 23:41:49 UTC. A staging call followed at 23:56:41 UTC. Its retained rows describe a USDC cycle involving an Aave-labelled contract, A2 and A1, with 1,013,353.611686 USDC on three legs and 1,013,860.288492 USDC returned on another. The PDF interprets the difference, 506.676806 USDC, as consistent with a flash-loan premium. Raw receipt logs were not returned for this staging transaction, so that interpretation remains qualified.E1 is recorded at 28 October, 00:00:03 UTC, immediately after the UTC day boundary. The PDF describes the source-contract transfer to A2 and the forwarding to A3 in that same transaction. It then records two later burns:Burn record: E2 — Quantity and time: 250,000.175563 USDC at 00:03:41 UTC on 28 October 2026; block 98731831.Burn record: E3 — Quantity and time: 763,374.836640 USDC at 00:05:22 UTC on 28 October 2026; block 98731940.Burn record: Combined burns — Quantity and time: 1,013,375.012203 USDC. This is an outgoing-flow total, not an additional loss.Burn record: Difference from A3's E1 receipt — Quantity and time: Burns exceeded the 1,013,353.611687 USDC receipt by 21.400516 USDC. The report does not establish the source of that additional amount.Figure 1. The two USDC burn amounts recorded for A3. The total is a disposition flow, not a second incident-loss figure.Color key: slate marks the first burn; sage marks the second. UTC labels and exact quantities distinguish them without color.Source: SentinelTX, CASE-ASYNCFF1, 31 October 2026, pp. 6–8 and 19–21. Source confidence qualifications are retained in the note below.In each burn transaction, the PDF describes a transfer to a Circle-labelled address, a burn event and a transfer to the zero address. Both message payloads contained matching destination words and the ASCII string “cctp-forward.” The report interprets the byte layout as consistent with a destination on Solana, but it did not obtain a decoder result or establish that the destination word matched the reported Solana address.Diagram 2. The report's same-chain transfer and burn sequence. Equal-width arrows show sequence and direction, not value or elapsed time. The onward cross-chain connection is not established; no continuous Avalanche-to-Ethereum route is asserted.Color key: slate marks the source outflow and forwarding; sage marks later burns. Color does not indicate verification.Address / role key: the graphic's P1 corresponds to A1, C1 to A2 and W1 to A3 in this article. B1 denotes burn operations through `0xfd78ee919681417d192449715b2594ab58f5d002`, with transfers to the zero address—not an attributed owner. Full A1–A3 addresses are in the appendix.Source: SentinelTX, CASE-ASYNCFF1, pp. 4–7, 19–20 and 33. The earlier staging transaction must not be treated as downstream proceeds of the later drain.3. A separate Ethereum record, not a completed bridge traceFor A4 on 28 October, the PDF records six USDC mints totalling 1,021,502.948496 USDC, five transfers to a CowProtocol-labelled settlement contract, and eleven deposits totalling 432.2 ETH into four Tornado.Cash-labelled pools. The mint aggregate, the five settlement-leg amounts and the mixer aggregate are explicitly marked unverified for exhibit purposes in the report's limitations.The five settlement quantities are 100,005.0; 200,000.0; 300,000.0; 350,000.0; and 71,497.948496 USDC. The recorded ETH deposit pattern is four deposits of 100.0 ETH, three of 10.0 ETH, two of 1.0 ETH and two of 0.1 ETH. These figures describe the Ethereum address's recorded activity. They do not establish that all of it came from the Avalanche incident.The PDF makes three boundaries explicit:No established bridge completion. Solana activity was not read, and the Avalanche-to-Solana-to-Ethereum connection is not transaction-hash anchored.No reconciled provenance. The reported Ethereum mint total exceeds the Avalanche burn total by 8,127.936293 USDC. The source does not resolve the difference or attribute the entire Ethereum amount to this case.No identified common controller. No retrieved shared gas funder, common deployer or domain cluster establishes that A3 and A4 were controlled by the same party.The report describes CowProtocol settlement as non-custodial, despite the database's “Exchange” label. It does not report a custodial exchange deposit by a case wallet within the traced scope. Likewise, a Tornado.Cash label identifies the report's attributed destination; it does not identify a depositor or establish a current legal designation.4. Mechanism: three hypotheses, not a proven root causeThe source offers three explanations from attributed search-result snippets: a day-rollover settlement calculation, inflated tranche shares minted using flash-loan capital, and a permissionless “double-draw” caused by borrowing logic that failed to subtract unpaid matured principal. It attributes these respectively to SlowMist, Blockaid, and DeFiHackLabs/web3VE reporting. The source pages were not read by the investigation, and none of these hypotheses was verified against contract source code.SentinelTX treats the hypotheses as potentially complementary. The timing at 00:00:03 UTC and the earlier staging cycle are the observations behind that interpretation; they do not by themselves prove the contract defect. The PDF also preserves a date discrepancy: one cited snippet dates the drain to 27 October, while its recorded block timestamp places it just after midnight on 28 October.A separate timing problem matters more than the calendar label. One route in the report places a later hop at block 98731443 before the block 98731606 flow that supposedly feeds it. That ordering cannot establish the claimed causal path. The earlier staging activity should not be presented as proceeds of the later drain, and this article does not use that route to connect the two.5. Conclusion: a bounded record, with the missing connection still missingThe PDF records the Avalanche source-contract outflow, forwarding and two subsequent burns. It also records separate Ethereum mint, settlement and mixer activity. The unresolved link between them is central—not a minor footnote. The report does not establish the identity behind the addresses, the definitive root cause, activity at the reported Solana receiver, or common control across the Avalanche and Ethereum wallets.Its proposed next leads are issuer-side attestation and forwarding records, exchange withdrawal records for the initial funding, and a completed Solana record. Those are recommendations in the source, not actions completed for this article. No recovery or freeze outcome is claimed.Figure 3. What the report records and what it leaves unresolved. Its narrative conclusion and structured transfer rows carry conflicting confidence labels; this summary does not upgrade either into a clean end-to-end finding.Color key: slate distinguishes headings only; it is not a confidence or risk scale.Source: SentinelTX, CASE-ASYNCFF1, pp. 19–20 and 33.6. Reference appendix and source qualificationsSelected transaction recordsReference: E1 — source outflow and forwarding — PDF record: Avalanche transaction `0x3f6b23292a2e9c2956c7ac56d0b1f79b0271b49edec2156d2675ddf1de058c77`; 2026-10-28T00:00:03Z; block 98731606. A1 → A2: 1,013,353.611686 USDC. A2 → A3: 1,013,353.611687 USDC. PDF pp. 4–7 and 20.Reference: E2 — first burn — PDF record: Avalanche transaction `0x0e974743161ddb166d5ad698b9a2b0c9ca2ddf5f569a532e6c5665ce2c92218b`; 2026-10-28T00:03:41Z; block 98731831; 250,000.175563 USDC. PDF pp. 6–7.Reference: E3 — second burn — PDF record: Avalanche transaction `0x51bb85e171585a2ec7ec7bd918cd6a08e916e38f79cf2a17b5e5211ee3b9f397`; 2026-10-28T00:05:22Z; block 98731940; 763,374.836640 USDC. PDF pp. 6–7.Address and role registerReference: A1 — Address and qualified role: `0xe25cb545bdd47a8ec2d08001cb5661b00d47621a` — Avalanche source contract; victim-TranchePool attribution is a reported lead.Reference: A2 — Address and qualified role: `0xf09dcf4ede2a88bd316ff355dfc333a281a57805` — Avalanche intermediate contract.Reference: A3 — Address and qualified role: `0x6ff1c3ffa622e1062168f3497a275be9cc2b1246` — Avalanche wallet receiving E1 forwarding and sending E2/E3.Reference: A4 — Address and qualified role: `0xdc3d7cc5383e0f1ac46d2c693aad1a19859a2deb` — separately examined Ethereum address; connection to this case remains partial/inferred.Reference: Reported Solana receiver — Address and qualified role: `C5L5EtcZmTKFc4D7Ntfqi7MtohnHVh4xZn93a5dBhB8` — not read; neither activity nor absence of activity is established.Source and limitations noteSource: the 36-page SentinelTX-generated PDF CASE-ASYNCFF1, generated 31 October 2026. This article adapts that report; it is not an independent on-chain audit. The PDF contains no external hyperlinks. No public PDF URL is supplied here.Confidence conflict: the routing table labels the E1 transfer rows “verified,” while the conclusion begins “unverified (auto-downgraded).” Those source labels are not silently reconciled. The report states that its integrity gate “downgraded 11 claims in the text and flagged 4 findings for review” (p. 4).Material route warning: “[INV-5] (report-wide) — Hop 0 (block 98,731,606) → Hop 2 (block 98,731,443) is time-inverted” and describes “a causally impossible path (the cash-out tx precedes the deposit tx)” (p. 33). The practical consequence is that this path cannot demonstrate that the earlier payment was funded by the later receipt.Amount qualifications: seven amounts are unverified for exhibit purposes: the 432.2 ETH aggregate, five CowProtocol legs and 1,021,502.948496 USDC mint aggregate (p. 18). The final warning appendix also flags 432.2286 ETH, 5.0 OVER and the conclusion's 1,021,502.948496 USDC as not bounded by a readable retained quantity (p. 33).Coverage: the narrative's examined window is 27–31 October, but Appendix A reports two 34-day query windows spanning 27 September–31 October and 138 timestamped retained movement rows from 27 October 22:42:23 to 30 October 22:52:47 UTC. Appendix A both lists timestamped bounds and says exact bounds were not retained; it does not establish that the requested cutoff was enforced. The article does not claim exhaustive period coverage.Other boundaries: two Solana reads failed; four Avalanche bridge-correlation attempts were unresolved, not negative; Avalanche internal traces were unavailable; the staging transaction lacked returned receipt logs; external reporting was available only as attributed snippets. Graph-wide totals include unrelated flows and are not incident loss. A successful PDF export or signed manifest does not remove these source limitations.

Updated 2 November 2026. The original 29 October Ethereum investigation is preserved below. A dated follow-up after its evidence appendix examines the separate 30 October BTC/TRON-to-ETH convergence route. The quantities and receiver roles in the two investigations must not be combined into a single loss total.On 29 October 2026, a Binance-labelled Ethereum account was associated with a delegation transaction, followed by a large transfer of ETH and tokens to one receiver. A later transaction sent USDC from a different asset-holding account to that same receiver. The important question is how signing authority reached more than one pool of assets—and what the transaction records can actually prove.This investigation follows that narrow Ethereum route: an operator calls a delegated account; assets converge at a receiver; the receiver splits USDT into two branches, and one branch makes a further transfer. A further USDT source also sends directly to the receiver with its own transaction sender, which is a separate signing path. The account labels describe explorer annotations. They do not independently establish custody, a person’s identity or the signing system that produced the authorization.Scope and evidenceThe selected transaction records below, excluding the explicitly attributed internal call path, are direct browser observations of Etherscan overview pages and receipt logs. SentinelTX adds a bounded trace and hypotheses; statements by Binance and an external analyst remain attributed statements. “Direct” here means the explorer record was read, not that a separate Ethereum node independently reproduced it.MeasureVerified scopeNetworkEthereum mainnet onlyFirst selected event29 October 2026, 20:20:59 UTC; block 26300753Last selected direct transfer29 October 2026, 21:52:47 UTC; block 26301210USDT seed amount1,615,409,498.973240 USDT; log 519Separate USDC transfer780,000,000.000000 USDC; log 685SentinelTX historical token readBlock 26301950; 30 October 2026, 00:21:23 UTCIndependent explorer review30 October 2026; official follow-up read 31 October. This is a historical transaction selection, not a live balance or restriction audit.ExcludedAll-chain valuation, full incident loss, complete onward balances and victim returnsUSDT and USDC are dollar-linked tokens, while ETH is the network’s native asset. Token quantities are preserved separately. These quantities are movements in different assets, not a dollar-loss total. The 500M, 200M and 175M transfers below are later movements of USDT; adding them to the seed amount would count funds again. No balance is inferred by subtracting this selected list from an inflow.The three findings that survive cross-checkingFirst, the explorer records a delegation before the sweep, but the evidence does not explain how its authorization signature was obtained. Second, the large USDC transfer starts from a different asset account, so the transaction caller and the asset sender must be kept separate. Third, USDT branches are directly visible, while a wBETH token-contract call is not proof of a custodial exchange deposit. The sections below explain each finding in time order.Before the sweep: what changed at the account?An Ethereum externally owned account normally authorizes actions with a signature. EIP-7702 allows such an account to delegate execution to code. That makes a signature about execution authority different from an ordinary payment: later calls can run the delegated code in the account’s context. This is the relevant mechanism described by the official EIP-7702 specification; it does not by itself establish this incident’s root cause.At 20:20:59 UTC, the authorization transaction succeeded. The saved explorer table displays 50 authorization rows, of which one is marked True and 49 False. A nonce is an account sequence number used to prevent an authorization from being reused. The True row has nonce 18914809 and names the delegate in the appendix. These are explorer observations; signer recovery, chain-ID validation and historical account-code reconstruction have not been independently reproduced in this report.The delegate’s current code page shows unverified runtime bytecode containing the operator address, and a creation link naming that operator. A matching byte sequence is not a complete control-flow audit or a historical proof. The analyst’s original thread describes an operator restriction and a rejection test, but those tests were not independently rerun. Key theft, signing-service misuse and a malicious authorization request remain alternative explanations, not findings.Three minutes later: which assets actually moved?At 20:24:23 UTC, the selected sweep transaction shows a successful outer call from the operator to the delegated account with zero ETH in the outer transaction’s value field. This does not mean no ETH moved: the explorer separately displays an internal transfer of 167,464.247856558836135296 ETH from that account to the receiver. The USDT receipt log records the same source and destination, with raw value 1615409498973240 and six token decimals.The transaction overview counts 63 ERC-20 transfers. This report does not present an independently decoded 63-token inventory. A reverted child-call warning is also visible alongside outer success. SentinelTX reports a failed token-transfer frame inside a larger call tree; that supports checking individual subcalls rather than treating the entire sweep as reverted.A different transaction sender appears 24 seconds laterAt 20:24:47 UTC, another transaction sends 55,739,800.500000 USDT from a Binance 16-labelled address to the same receiver. The outer transaction’s From address is this asset sender itself, and its call target is canonical USDT. Receipt log 37 contains raw value 55739800500000. This is a direct token call, unlike the earlier operator calling the delegated account.The shared receiver links the movement, but does not explain the signature. This record prevents an overly simple claim that every selected inflow came through one delegated-account execution path. It does not establish that a second key was stolen: an operational transfer, a misused signing service and other signing circumstances remain unresolved.After receipt: the USDT splitThe receiver sent 500,000,000 USDT at 20:30:11 UTC and 200,000,000 USDT at 20:33:23 UTC to two different addresses. Both canonical USDT Transfer logs were read directly. Following Branch A forward for one selected movement, it later sent 175,000,000 USDT to a third address at 20:59:11 UTC. This is one selected onward transfer within two transfers from the central receiver, not a complete account history.UTC, 29 OctoberMovementEvidence20:30:11Receiver → Branch A; 500,000,000 USDTTransfer log 70020:33:23Receiver → Branch B; 200,000,000 USDTTransfer log 91620:59:11Branch A → next recipient; 175,000,000 USDTTransfer log 389Begin Figure 1 at the central receiver. The arrows show token transfers; the separate continuation from Branch A shows only the selected 175M movement. They do not show a sale, a freeze or an exchange deposit.Figure 1. The 175M movement is part of the earlier 500M branch. It is not an additional incident inflow.The split is consistent with dispersal, but round amounts do not prove a laundering intent or common control of recipients. Etherscan’s editorial Insight points to a third-party tracker describing later freezes and OTC activity. Those descriptions were not adopted as verified conclusions: a transfer alone cannot identify the consideration received, the counterparty or the legal status of funds.Later, a separate USDC account reaches the same receiverReturning to the other source account at 20:41:23 UTC, after the two initial USDT branches, the separate USDC transaction records 780,000,000 USDC reaching the same receiver, but from a different asset-holding address. Figure 2 selects the main delegated source and the separate USDC source for comparison; the direct-signed USDT movement described earlier is not drawn. Read from the two source cards toward the central receiver. Solid arrows represent the selected observed asset movements, not account ownership or signing permissions.Figure 2. Two independently checked sources converge on one receiver. ETH is rounded in this figure; exact quantities, accounts and hashes are preserved in the evidence appendix.The independent receipt confirms the USDC asset source and amount. A function selector is the first four bytes of a contract instruction; it is not a verified function name. The final SentinelTX response additionally returns a seven-frame execution path for this exact transaction. A CALL asks another account to execute; a DELEGATECALL runs implementation code while retaining the calling account’s context. That distinction explains why an implementation address is not another recipient of the 780M USDC.Stage in returned traceObserved call / evidence limitOperator → delegated accountRoot selector 0x043ff9d2Delegated account → separate USDC walletCALL; selector 0xb61d27f6USDC wallet → wallet implementationDELEGATECALL; same selector 0xb61d27f6Wallet execution → USDCFailed 0x01ffc9a7 interface probe, followed by 0xa9059cbb transfer through the USDC implementationThe trace comes from SentinelTX and was not independently re-executed. Its source, destination and transfer quantity match the independently read USDC receipt; that corroborates the movement, not every execution frame. Function names for the two wallet selectors, owner/executor storage and historical privilege assignments remain unknown. It would be premature to call the delegated account the wallet’s owner, or to infer an allowance exploit from the transfer alone.Why the wBETH leg is not an exchange-deposit findingAt 21:52:47 UTC, the wBETH transaction calls the wBETH token contract. Its receipt log transfers 29,934.013163146020067927 wBETH from the receiver to a separate recipient. The called contract and the asset recipient are different addresses. Treating the token contract’s Binance association as a deposit destination would misclassify the movement.SentinelTX’s narrative corrects an earlier exchange-deposit classification; the independent receipt-log check supports that correction. No custodial exchange deposit has been established in the selected verified paths. That is a coverage-limited conclusion, not evidence that no such deposit occurred elsewhere. DEX interactions returned by the wider trace are also distinct from custodial deposits and do not establish fiat cash-out.Frozen, recovered and returned are different statesIn its statement published on 29 October at 23:22 UTC (30 October, 08:22 KST), Binance says its verified frozen total is USD2.54B and that an older USD1.8B figure is outdated. This is a historical company aggregate, not the latest total. It has not been reconstructed here from issuer event logs, asset quantities and a common valuation time.In Security Incident Update #2, dated 30 October, read on 31 October, Binance reported approximately USD3B frozen on-chain. It also said it had identified additional breach points and had found no evidence at that stage that wallet private keys had leaked. These are company statements, not conclusions from this report’s selected Ethereum transactions. They neither establish how the observed authorizations were obtained nor turn a freeze into a verified return of assets.A blacklist restriction can prevent movement of a token at an address. It does not itself prove that the assets were transferred to a recovery custodian or returned to users. The initial SentinelTX issuer-event queries failed. The final follow-up response lists prior-session blacklist events, but omits re-anchored transaction hashes and says current blacklist state was not read. It also reports only 15 of 55 Blacklisted-topic rows displayed. This incomplete list is retained as a lead, not a verified issuer inventory. Authorization signer recovery and USDC owner/executor privileges also remain unresolved. No zero-event or “not frozen” conclusion is drawn from a failed query.Connections, alternatives and response pointsThe strongest links are the exact asset sender, recipient and Transfer log in each selected transaction. The same operator and called account provide additional execution context. Explorer tags, shared timing, similar amounts and token-contract branding provide weaker context and are not beneficial-ownership proofs.QuestionEvidence needed / bounded actionWhat authorized execution?Recover and validate the authorization tuples; preserve signing-policy and signer audit records. A valid signature does not identify how it was obtained.Why did another wallet send USDC?Returned call path is available from SentinelTX; verify wallet rules and historical owner/executor storage before claiming an owner role or allowance.Can the stablecoins move?Read address-specific issuer events and state at explicit blocks; separate event time from a later status snapshot.Where did ETH go?The selected receiver inflow does not establish the onward ETH path or an exchange endpoint.What can be called recovered?Require a verified recovery transfer and custody/return evidence; do not equate freeze with restitution.These are evidence-preservation and verification priorities, not proof of a person’s responsibility. No issuer, exchange or law-enforcement message has been sent as part of this investigation.Coverage and remaining uncertaintyThe original SentinelTX trace reports 525 transactions and 52 addresses. Its live graph displays 71 nodes, which is a different representation and not a verified count of recipients. One displayed call tree contains 191 of 192 frames; 17 label queries and two address-history reads were incomplete. Only selected transactions were independently cross-checked for this report. A later continuation reports 23 incompletely read addresses; that belongs to the follow-up’s different coverage and is not merged with the initial graph counts.The original report also contains different temporal boundaries: a query window from 29 September to 30 October 00:19:56.232761 UTC, a snapshot header through block 26301901, selected displayed routing rows through block 26301699, and a later token read at block 26301950. Those records are preserved separately. They cannot be presented as one exhaustive incident cutoff.Bitcoin, TRON, full all-chain valuation, all 63 token transfers, complete receiver balances, onward ETH movements, final incident loss and user restitution are outside the independently verified scope. The observed 204-second interval between authorization and sweep is not the full attack duration. The evidence establishes a narrow sequence of authority-related activity and asset movements; it does not yet establish the signature’s origin or the final recovery outcome.Evidence appendix: accountsRole on EthereumFull addressOuter transaction operator / sponsor0x7C8601d4645b93cea45F71e118A729332e6B5CA0Delegated account; selected ETH and USDT sender0x28C6c06298d514Db089934071355E5743bf21d60Central receiver0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8cExplorer-reported delegation target; current bytecode page read0x63e842B054Bd624a465454D533C33F573e9c6fAeSeparate 780M USDC asset sender0xEe7aE85f2Fe2239E27D9c1E23fFFe168D63b4055Branch A0x9749292D74Fd460982d0912eA9515EA24736C762Branch B0x0Ddf0480016e6bCb2C1F5d190D221FBA1320697eSelected next recipient from Branch A0x811f15855476156Ebf86ba3b84faFb8Ceaa4e84CCalled token contract; not deposit recipient0xa2E3356610840701BDf5611a53974510Ae27E2e1Actual wBETH Transfer recipient0x7f9DC988B46336aD536828fAD50fa8fA1E5415E3Direct USDT transaction sender; explorer label Binance 160xDFd5293D8e347dFe59E90eFd55b2956a1343963dWallet implementation in SentinelTX-returned USDC trace; not an asset recipient0xd206ac7fef53d83ed4563e770b28dba90d0d9ec8USDC implementation in returned trace; not an asset recipient0x43506849d7c04f9138d1a2050bbf3a0c054402ddUSDT token contract; six decimals0xdac17f958d2ee523a2206206994597c13d831ec7USDC token contract; six decimals0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48Evidence appendix: transaction anchorsRecord / UTC on 29 OctoberFull transaction hashDelegate creation referenceExplorer creator link; event time not separately recorded in this review0x97408e7562eb2b28efcd24ba01609607b5749bc89448d007fa8b50ecf290329cAuthorizationBlock 2630075320:20:59 UTCExplorer authorization table; no independent signer recovery0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298bDirect-signed USDTBlock 2630077220:24:47 UTCUSDT log 370xd4e08d3ef0cb02a75922913c61984fbf7fe4bbc4b95324735ef27f908fd6c49cSeed sweepBlock 2630077020:24:23 UTCUSDT log 519; internal ETH displayed separately0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3Separate USDCBlock 2630085520:41:23 UTCUSDC log 6850xdc102dd89dded5a83f1008906883ffb7c81ff3b7d7965d8c7277d170b5e17481F08Block 2630079920:30:11 UTCUSDT log 7000x68d7d69deaeb9750c38020b4f8d3728146ca8d2267eba1e38cf9b56722ad659aF09Block 2630081520:33:23 UTCUSDT log 9160x1fc0ef33a767132edad434834a5555b30fcb5a171206c03b86175ef6dafac81cF10Block 2630121021:52:47 UTCwBETH log 4860xc19a2dcc7508e45f2743558cebefa50140fe68d9450ab18d14fd34039eb4bce2F11Block 2630094220:59:11 UTCUSDT log 3890x1fb992f92a45afec23d7d5740c7958a644fb90ef0cba19ca39bd2c6534fb670bEvidence appendix: exact token quantitiesAnchor / assetRaw value → normalized unitsDirect-signed USDT55739800500000 ÷ 10⁶ = 55,739,800.500000Seed / USDT1615409498973240 ÷ 10⁶ = 1,615,409,498.973240Separate source / USDC780000000000000 ÷ 10⁶ = 780,000,000.000000F08 / USDT500000000000000 ÷ 10^6 = 500000000F09 / USDT200000000000000 ÷ 10^6 = 200000000F10 / wBETH29934013163146020067927 ÷ 10^18 = 29934.013163146020067927F11 / USDT175000000000000 ÷ 10^6 = 175000000Follow-up, 2 November 2026: BTC and TRON routes meet on EthereumZachXBT reported on 30 October 2026 that funds associated with the Binance and Bitget incidents had converged through THORChain. This follow-up tests the transaction route behind that claim. It follows Bitcoin and TRON payments into one Ethereum wallet, then separates the verified transfers from the still-open question of where the source funds were stolen. Original research lead.The route is straightforward to read: a Bitcoin payment and a TRON USDT payment enter THORChain, a protocol that exchanges assets across blockchains. The protocol pays ETH to the same Ethereum destination. The source transaction notes name that destination, and the Ethereum payout events refer back to the input transaction hashes. The refunds travel back to the input senders and must be counted separately.Figure 3. Read the Bitcoin and TRON action panels separately, then the common Ethereum destination panel. Each panel records a matched input/action/payout, not common attacker identity. All times are UTC on 30 October 2026; full wallets and transactions follow.The two highlighted payouts total 16.45427314 ETH and arrived twelve seconds apart. That confirms a common destination for these swaps. It does not, on its own, prove that the two original thefts had the same operator or that each source-chain input came from one of those thefts.1. The wallets and the questionsRoleChain / full wallet addressWhat the record establishesConvergence destinationEthereum0x15104a9ce0f08a8f0075a0869ae80e795fe0feb7Recipient of both highlighted payoutsBitcoin input senderBitcoinbc1qxtl05lnr7jewlcg95yjq8k8llenyhsem0hdpp0Sent the 1.2 BTC input; also used the earlier 3 BTC actionTRON input senderTRONTDNF7CwfcKvgtaRPrMg4isijtf73kr8uRASent 15,800 USDT; received a partial refundTRX conversion walletTRONTQrzMj8eKRAhizejiejaQVjiL95XsbxcADConverted TRX through SunSwap and forwarded USDTTRX source under reviewTRONTQXm9qEL64YmGAzZoMspM8qyWPZ3tbqt6XFunded the conversion wallet; theft provenance unresolvedRole names describe observed activity, not the legal identities of operators. Times in this report are UTC. The requested upstream investigation window was 1 September–2 November 2026 at 09:32 UTC; later explorer and blocklist retrievals are separately identified as checks made on 2 November.2. Before the convergence: an older Bitcoin depositThe older Bitcoin deposit had an output of 18.49993081 BTC, first broadcast on 25 October at 16:04:37 UTC, in block 973,094. Four inputs totalled 18.49996221 BTC; the transaction paid a 0.00003140 BTC fee and produced one output to the Bitcoin sender used below. The explorer displays this in local time as 26 October 01:04:37 GMT+9. 94ecb34cd3b98ee23c4eafee4a737cc76815911b710bf06bdfd50b17ee7ebd0e.This particular deposit predates the reported 29 October Binance theft. It cannot have originated in a theft that happened four days later. That timing does not identify it as Bitget proceeds, and it does not resolve every later deposit into the same wallet. The upstream address was bc1qeeld470e89fuuqtce7wc2jy457z8e8nr82atq5.3. The TRON conversion and partial refundThe TRON branch begins here with an observed TRX transfer, rather than an assumed theft label. The source wallet sent 1,639,708.064722 TRX to the conversion wallet. At 03:40:09 on 30 October, that wallet submitted 100,000 TRX to SunSwap and received 35,897.388895 USDT. USDT is the dollar-linked token moved on TRON in the following steps. A later transfer forwarded 15,897.388898 USDT to the input sender. Because the account could hold other funds, the small difference between those figures is not forced into a single-deposit allocation.Figure 4. Read the panels top to bottom: TRX funding, SunSwap conversion, USDT forwarding and the THORChain action. The last panel separates the ETH payout from the USDT refund. Panel spacing is schematic, not proportional to time or value.30 Oct UTCObserved movementTRON transaction03:40:09100,000 TRX submitted; 35,897.388895 USDT received0cfb2593350a06c9c0d1a32caf9c36c2866c4900a5f3506b345edc8628568cbf03:51:1515,897.388898 USDT forwarded193e17d5b69429e1a3948b81648f5f7c565c6978e0bdd5f123f021afc708a13103:55:4515,800 USDT submitted to THORChain109b6b6aa31dcbef72d5bef49521b4beb80fdad23a16bf7d0e74d756186cdde2At 04:02:59, THORChain paid 2.62587605 ETH to the convergence wallet in Ethereum block 26,303,052. The TransferOut event carries an OUT memo matching the TRON input hash. The action record also lists 10,279.140244 USDT returned to the input sender. Thus 15,800 minus the refund is 5,520.859756 USDT not returned in this action; it should not be described as the exact swap principal without separately accounting for protocol fees. Action record · 0x102045ad108be2c912b6c9376c2fe881157b89930e8cbaea47000b57df90511a.Initial TRX funding transaction: 5c3290b2c534d59a8fff2172b16f6e567d2984ed3b22e018d552428f3da0ba77. USDT refund: 6a0925f5865e233eb6875c7ca62735dd9b2a55969aaef4c1c75414f9d35b6c91.4. Twelve seconds later, the Bitcoin payoutThe Bitcoin input was broadcast at 03:49:58 and included in block 973,768. Six inputs totalled 1.20131636 BTC. The transaction sent 1.2 BTC to a THORChain vault, returned 0.00128312 BTC as change and paid a 0.00003324 BTC network fee. Its OP_RETURN note, the small data field attached to the transaction, names the same Ethereum destination as the TRON note.RecordExact quantityTransactionBitcoin input1.2 BTCa5e9f776289fd0fa15e2b4a20578ea1e35e33b47abea1ead8fced82bfbdb771704:03:11 ETH payout13.82839709 ETH0x876b846d552debfe75ec893e6fd0c5021cd579ecfabc1b521550463aab8687fcBTC refund0.79998965 BTC02acbc1642e52ad4ca9724c571c0cc4da41273675a69d4040d6669b61213c81eThe Ethereum TransferOut event in block 26,303,053 refers to the Bitcoin input hash, and the protocol action lists both its payout and refund. The arithmetic amount not returned is 0.40001035 BTC, before interpreting any protocol charges. The Bitcoin input, change, fee and refund are distinct entries; adding them together would inflate the value transferred. Action record.The same Bitcoin sender had supplied an earlier 3 BTC action, which paid 71.44903933 ETH at 00:30:11 and refunded 0.92726220 BTC. Different swap hashes from the same sender are not independent evidence of two theft origins. 0xba7cf41cd97b070972712ea1d35cd5b3f1040760d0a2cc90d647569c67b1b58f · Earlier action.5. What the Ethereum wallet sent onwardThe convergence wallet also received ETH from ordinary wallet transfers. One later receipt was 123.318271716662290889 ETH at 06:11:35 from 0x415e50C7CC3f5a77B2Ec13494507B425D44A8f60. Its immediate upstream wallet, 0x3a2c6BBE9775FfF0CC8ADA21d2c565928C5B8a65, had received 0.1 ETH from the convergence wallet for fees. This establishes a funding relationship; it does not establish that all 123.318 ETH was returning principal. The upstream USDT came through service-labelled infrastructure, whose branding alone cannot identify September Bitget theft proceeds.At 06:11:59, the convergence wallet sent 166.87 ETH to 0x3912c37412baae4c7aBE2E969298B9C55a6C912F. The recipient appears in the FBI’s 31 October Binance incident address list. The transfer is directly observable; the FBI classification is official external attribution. Neither fact establishes a fiat sale, a seizure or a freeze. 0xa4b5eb66976d209d7bbe6fd55b5b7908657b7f5fbccb247d8b9ebf122e0d38a3.Figure 5. Read the receipt panels first, followed by outgoing value, wallet-paid fees and calculated net change. These are ETH accounting categories. Gross receipts can include returning value and are not a theft total; the exact quantities are in the following table.Wallet accounting itemETHInterpretation15 THORChain payouts387.03923888Gross protocol payments, not incident-specific proceedsOther internal receipts0.000000002222 small entries retained in the accounting43 normal records: incoming187.864231185348482145Includes tiny receipts and six substantial receiptsNormal outgoing transfers574.9011 transactionsFees paid by convergence wallet0.001064349368636665Exact detail-page fees; incoming sender fees excludedCalculated net change0.002405718179845480Incoming + internal − outgoing − own fees; not a verified opening/current balanceThe numerical reconciliation covers all 43 normal records and 37 internal records exposed in the one-page explorer lists. Internal transfers are value movements made during contract execution, not additional signed transactions; their parent hashes are preserved in the appendix. Zero-value and small lookalike-address transfers do not establish legitimate counterparties. Their ETH values remain in the arithmetic, while their apparent relationships are excluded from attribution. A complete incident-specific reconciliation still needs the token swaps and cross-chain origins of the other receipt wallets.6. External attribution versus theft provenanceA locally downloaded copy of Elliptic’s Binance blocklist contained 9,862 lines on 2 November. An exact, case-sensitive check matched the TRON input sender TDNF7CwfcKvgtaRPrMg4isijtf73kr8uRA. The BTC sender and the upstream TRX source did not match that retrieved list. EVM comparisons were made case-insensitively. This check concerns only the explicitly tested addresses, not all addresses in the investigation graph; the saved comparison records the full tested set and retrieval hash.The match adds an independent external classification for the TRON branch. It does not reveal the transaction that first took the funds from Binance. Conversely, a non-match cannot clear an address or exclude an indirect connection. The unresolved Bitget side requires a documented value path from a theft anchor through every intervening conversion into the BTC source used here. A shared THORChain vault cannot fill that gap: a public protocol vault serves unrelated customers.Expanded list comparisonThe downloaded file was also compared with 62 complete address strings visible in the two completed source-investigation snapshots and two directly verified TRON intermediaries. Eleven matched, all on TRON. This is a comparison of the available text subset, not the complete backend graphs. Several upper-branch addresses therefore have external Binance classifications, although the exact theft-to-deposit transaction chain remains incomplete.TRON address on Elliptic’s retrieved listEvidence levelTDNF7CwfcKvgtaRPrMg4isijtf73kr8uRAExternal list membership; upstream transaction context is preserved in the source-query evidence.TGSXgPzRmYtWkC1Vwf6xdHwft9bp2Xni7tExternal list membership; upstream transaction context is preserved in the source-query evidence.TKfpgAebbY8vbtUWqPFAasnPSs9gXYFquDExternal list membership; upstream transaction context is preserved in the source-query evidence.TLczmZHmwgJWcZQab7Rxj9f1B5LV9M3JzcExternal list membership; upstream transaction context is preserved in the source-query evidence.TMi4ZgR8UDiju8Tc55ERfTTCWNSEfVUGZgExternal list membership; upstream transaction context is preserved in the source-query evidence.TNj7bvEgtMCiTP343AcPeKveJf1XhepTfgExternal list membership; upstream transaction context is preserved in the source-query evidence.TNjTaArFd5XvKMC48L7MMuSkVjZGtov2y5External list membership; upstream transaction context is preserved in the source-query evidence.TPh3Q74aZR15oVVTkNSj5NvhJrojEqMQ8JExternal list membership; upstream transaction context is preserved in the source-query evidence.TQ91dTyDgM4EaNuLJZsF6XNecoB1fnigTFExternal list membership; upstream transaction context is preserved in the source-query evidence.TX7bGvaAgGy9xz9rTS6Q3jpHuspjKmQ8ovExternal list membership; upstream transaction context is preserved in the source-query evidence.TXf49xZWJkZQRgkaYLSxf7kUf5bQKesA5vExternal list membership; upstream transaction context is preserved in the source-query evidence.7. Findings and the remaining boundaryQuestionFindingEvidence classDid BTC and TRON inputs pay the same ETH wallet?Yes; source notes, protocol actions and payout events match.Direct recordsAre the two highlighted payouts close in time?Yes; 12 seconds apart, total 16.45427314 ETH.Calculated from direct recordsIs the TRON sender on Elliptic’s Binance list?Yes in the retrieved 2 November file.External attributionHas each theft origin been reconstructed end to end?Not yet; upstream gaps remain.UnresolvedDoes convergence prove one original attacker?No; common destination is established, operator identity is not.Inference boundaryAre all receipts unique stolen proceeds?Not established; refunds and possible returning value must be separated.UnresolvedThe next useful records are specific: the Bitget theft-to-BTC conversion joins, the initial Binance theft-to-TRON path and the token/cross-chain origins of the six larger ordinary ETH receipts. Those records would let the route be assigned to incident-specific quantities. Until then, the defensible finding is a verified shared destination with external attribution on one branch, rather than an independently proven merger of two theft balances.Evidence appendix: Ethereum movementsTHORChain payouts and small internal receiptsUTC / directionETHFull transaction and counterparty2026-10-30 0:30:11 / in71.449039330xba7cf41cd97b070972712ea1d35cd5b3f1040760d0a2cc90d647569c67b1b58f0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 0:39:35 / in151.620463470x81e679bc4a2f8cb93e81f8971b91fdb708742d05a5b8b4afe74d205865e852e80xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 1:59:59 / in36.416447490x6df56b1587e2322cd727a162b9960bb011ca00e0f2681cd637efbc0709657afa0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 3:15:35 / in26.96212090xb114ecac7a51fa7ee4df1ab67bd87fed03afe3ad4d8294743df628cf26275a7a0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:02:59 / in2.625876050x102045ad108be2c912b6c9376c2fe881157b89930e8cbaea47000b57df90511a0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:03:11 / in13.828397090x876b846d552debfe75ec893e6fd0c5021cd579ecfabc1b521550463aab8687fc0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:08:35 / in0.277473790x0c3a17e55969362be7bd7365bbfcf9af29cc27411a7155dbaba33c62f3084cf30xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:09:23 / in3.272411190x117dd9b4af1d1eed4e09de714dce3f5d59b78cc95c7019017c4d56ba1228ab590xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:22:23 / in1.442923490x8ae57f51cc3970b2470b9e0edaaa32c78aa12395f7c6d0b37eb955db7707507c0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:34:47 / in29.898862650xf7df5031d038dfc7220b33da9f3a9df6b0718c83d76a352fa1706b3dc02294b80xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:43:11 / in6.140586010xf9ca3c47d5799f21fb59e028a613cebfc91d889c8200096b8251b5c9288f535a0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:49:11 / in1E-100x518a85ebe1404adffe4a5ae255a8b37bbf3a95af3fadb8135b453a02019f85ec0xE5c28AF04CDd6cB95414dd0C9506778E5e33AD292026-10-30 4:49:11 / in1E-100x518a85ebe1404adffe4a5ae255a8b37bbf3a95af3fadb8135b453a02019f85ec0xB1943998AaBdCEE56953e5a1f6B07D0D913DF92e2026-10-30 4:51:23 / in1E-100xcaf4e444b92e9207873a336128e2476c8dd43677d370eb39e9cf907dc902354b0x7dCA6D14A23b9f1ae029e5A14EE20be828a377e22026-10-30 4:53:23 / in1E-100x66b4db850588f09262c8fe66c14154729f1928187ab6eee596ab1a4e9b031a9b0xB1943998AaBdCEE56953e5a1f6B07D0D913DF92e2026-10-30 4:58:35 / in6.012717390xbd3d97e216e8ae6c230edcdba9d70c16380eb6de6a7f5fa1a53e5f77f02b6f0e0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 4:58:35 / in1E-100xf037cb8169086594261a216eeaa8575c32f6dd98a0a0675bfd2abb0f960a0b030xC9C4503c0e33A816B8201cF42a552aa5Db274C7c2026-10-30 5:03:59 / in1E-100x4f3d802624f3c42d80ea00e021f108a0557616cb0d55f3008998c771b47759c10xB1943998AaBdCEE56953e5a1f6B07D0D913DF92e2026-10-30 5:05:23 / in1E-100xda96f4a7985fa0fd38554c7c90876402c6c5f17da4f3c6d14df0aab7c05b60290xE5c28AF04CDd6cB95414dd0C9506778E5e33AD292026-10-30 5:06:23 / in1E-100x005df3bd53c85fba2f531de7e7b09de5d779622d441ca6adcb1ebcf93b4970d50xC9C4503c0e33A816B8201cF42a552aa5Db274C7c2026-10-30 5:07:47 / in1E-100xde9884c4fdedcbf9ddadf13fe723c101e97176fbd60197784be212493d2e96920x7dCA6D14A23b9f1ae029e5A14EE20be828a377e22026-10-30 5:16:35 / in1E-100xf29e73584413bd528ddb002373ff5ca706f90c6712a34594d85e2922069c27150xB1943998AaBdCEE56953e5a1f6B07D0D913DF92e2026-10-30 5:23:59 / in1E-100x13f473e9ff9df92b4ff8a77f48a158556c526a65224b8c0a088acedad97bcd980xd512742a8D47EFE70dcaD1bFC36c8863D25579b42026-10-30 5:25:59 / in13.14744920x2f058b456becc7744492b44e5c0c3e5a54291e43fe4d3f386be545f6042b62f00xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 5:31:47 / in1E-100xb82a6564f9bc2bd5386a2ef02a05961645ab844d3597c0e05ded910ca6673c940x1814e5241C5d57e0488fF7C2Beb813fC20c3E08E2026-10-30 5:46:23 / in1E-100xd9b3cb5cfb656664b08e817a50bf532e85fc5fb661817724707a57a95b1338600x3a2b40280F253C8E5058eAAC66bd8cc3605b8A652026-10-30 6:12:35 / in1E-100xa70987ea59ef5a24d9970280a8b74df6b3f515c2b310232241d908f1aaa72a0a0x3910e32A99C7E2e2Db8C35dA142340958F6c912f2026-10-30 6:43:11 / in0.468153780xbc878c77b80a9bbe1ad51c8da8cf58657b3dca1596260b5d755558d31b38d3c30xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 6:50:59 / in23.476317050xfd50e288eb057430a6e99b28262d32d08414a3b7cfe7c03c87c76a4c8ff2466b0xd37bbe5744d730a1d98d8dc97c42f0ca46ad71462026-10-30 7:02:47 / in1E-100xe84deee3c74f02d6b4d6e6b06b5743e459cc0c56d9e4771402b921f4bbe66d610x16449C2C5C9453388717c9aDF2502b6B554D9F1D2026-10-30 7:05:35 / in1E-100x3c72121a51031472f1924fe4ba28e529a59995d4d4c594edf122bda0c927dc590x16449C2C5C9453388717c9aDF2502b6B554D9F1D2026-10-30 7:49:23 / in1E-100x069eb69f68b3a6fe83755f197ad378a4e8bef3d872767a4f09b811ddb905dc090x3910e32A99C7E2e2Db8C35dA142340958F6c912f2026-10-30 7:58:23 / in1E-100xb3fa6b36ac16a0f8bb8173fa195da3f544191f1abd629ca7802a7ee8033893860x3910e32A99C7E2e2Db8C35dA142340958F6c912f2026-10-30 8:22:35 / in1E-100x52997a50c9ba09a6a004ea2af5792ac231c04f4e1e608d21ea1a120db46675970x3a7E5D263DAafed6B3ce2Fa53b2897dB16c4248d2026-10-30 8:24:11 / in1E-100xfe230d5219b14b8a2d736828f52c01b7025c9a851d4e97b26d99f9827a376ae40x3a7E5D263DAafed6B3ce2Fa53b2897dB16c4248d2026-10-30 8:27:47 / in1E-100x11bae97bf5d6a57ab587358a8835582b1d18f0ac3b1501db7987c5226a3c91900x3a7E5D263DAafed6B3ce2Fa53b2897dB16c4248d2026-10-30 8:59:47 / in1E-100x7189d8ea9084f7250eca59d2697b2a233a673d8f253d069496e0b8b635ee3a7a0xC9C4503c0e33A816B8201cF42a552aa5Db274C7cNormal wallet transactionsUTC / directionETHFull transaction and counterparty2026-10-30 2:03:23 / out2590x7fd8ac8965dc69f012c48ad0192a9145570dccdc247e173163a8bdfe1593ab910xE5CeC77934a9aa7a5C63692965A1f07AB933AD292026-10-30 2:17:35 / out0.10xa9e9a7342a0c17ce7d6fb43dc1db41512b90acfb1c2b7affc34e01dccf6980cd0xB196981c37Cfe105506613d1BD4153B9E63DF92E2026-10-30 4:03:59 / in12.8655434306606539260x07a589f5e22b8e487f7f1c9937a25a99408bd57237999d5e1bbb733833260d330xB196981c37Cfe105506613d1BD4153B9E63DF92E2026-10-30 4:33:23 / out610xad7af2e65741ab70feb8eec26e2d6b117ba99692dd42f7fe08d9ab1930935d7f0x7dCb564ae3aB5F25FDa877882A4739E597a377e22026-10-30 4:37:23 / in00x3d80df89f8811089d48e530eda563c77570efae954fbebd27523e1d91c1c53070x7dCB2Cc588125D94591ed279d81B7F41a18277E22026-10-30 4:37:59 / out30.550x9d196876f24e03c447e4824b79466aaea784f2c9697242543a8448e4d838f5d30xC9cd1054d89D6FaF75b22F0bd0c0FEF44a274C7C2026-10-30 4:50:23 / out0.10xe5bcc5e6ab52d0680558118fcd07dfd1e4a5fe9f5d8c21ecae010e7fd0828e040xB196981c37Cfe105506613d1BD4153B9E63DF92E2026-10-30 4:52:35 / in1E-90xf723a4c0cc6504668603124354320f172a01ec11e843d6f9a664f803e5461a180xE5Ce5A18d53902d89B8cFe3b3252722CE51a1D292026-10-30 4:54:59 / in1E-90x637d9a7883b1ea6a91a4bf840c7c0ac44ecc199a17a662c9e5c60c01e09bf4730xC9cdeC075e753f6Df427FbCa8D019Ddf93246C7C2026-10-30 4:56:11 / in1E-90x3dda2bce131fde10c4893a21ab03ef876e28d83cf66e5f31dd1d2fe411c535580x7dCb73d11E06eE9a112a3E24D8350aD4C91277e22026-10-30 4:58:35 / in00x7fd0c50ff6cd5740cc2a2feb5d6bc6b676319ad208c9d101ba77abdcc9f68f5c0x7dCB2Cc588125D94591ed279d81B7F41a18277E22026-10-30 5:15:47 / in8.0217238208405707480x86a2ba468124098078116dd145b9ceef9428853640bfb0b3ce67785b66f5d01d0xB196981c37Cfe105506613d1BD4153B9E63DF92E2026-10-30 5:23:35 / out0.10x5673f0446debd00c7bd3fa0436901e3d5ef889266f5e2571d0d2ca8c127b10070xD51Fca94212E644B4a01f4a5bCf64AC61b5579b42026-10-30 5:29:35 / in6.310x0031e22b2241b6fae38078b1e3e5dffcbed4529fd7d47b2ded6b8d76cb358e5e0x3FECFdF6Ba478287ff9246DDb9C3028c9f1F76242026-10-30 5:31:11 / out33.130x1f1c4d4216adbe19b84fa88ed9115c8b3cfb378d4e635574beeb245f98712fa30x181a9D83f78e38C573C824088879Da346cC3E08e2026-10-30 5:32:35 / in1.3449026240084336170xcd6b6c67f947303aa451a7af72f7a096bf37d395184925008526a052889e0a3d0x3FECFdF6Ba478287ff9246DDb9C3028c9f1F76242026-10-30 5:45:47 / out0.10x21baa8cb02bd0c446c591d3888952a9660cb544c8b715eef49cfa739227b41160x3a2c6BBE9775FfF0CC8ADA21d2c565928C5B8a652026-10-30 5:55:11 / in36.0037875841765329650xa3db0a998e71e59edbfff8b620483453348a5226275706734e17255f094c9a970xF86BD1865945b1d86dedB03Ce40d2D9b3A14358F2026-10-30 6:11:35 / in123.3182717166622908890xc799b4f2b3a7f566bddc7170ed33c650d6c111dc029ed04aec2233260cc170020x415e50C7CC3f5a77B2Ec13494507B425D44A8f602026-10-30 6:11:59 / out166.870xa4b5eb66976d209d7bbe6fd55b5b7908657b7f5fbccb247d8b9ebf122e0d38a30x3912c37412baae4c7aBE2E969298B9C55a6C912F2026-10-30 6:42:23 / in00x2592d1478bc96ef3f22ddbb40e29c28d0013d963081ccecc4472b50db71a483f0xD51F80f41975dbeCc98591b229b63dCD941979B42026-10-30 6:42:23 / in1E-90x06aa352257bb3a89e7039c699e6667e7cc57c4ef4ab3db62aa53e9bf997a57020x181A44A740c3501Dfb41743ba8914682F3c1E08E2026-10-30 6:42:23 / in1E-90x3a986058c4b65ee9c0dec4c6fa283788f75b6cab175e8103e0bd5b3be1664e630xB1960934b5b3E9393231cEa639d976802D10f92e2026-10-30 6:42:23 / in00x8490eb8b959c1cab68f6f9c56ab0651ab3849fdb911feace2693f2b6521294ec0x3a2c7eb8626F393f3aDF67F5171024b230358A652026-10-30 7:01:47 / out0.10x4fc4dc286eed93f27cc0368347585d84180e8dc2643a366c04522f6d0c6414910x1645Dc4b3C9d6fd8Ec9D21dCc07099C6924d9f1d2026-10-30 7:04:59 / in1E-90x7d3971060c773d79da7deae606cf4ad945a9be8da286d995560ca1ce978127820x164560349E7FdB582b82d1520832769284179F1d2026-10-30 7:48:47 / in0.0000010x7674ca872ae1321a923a7cd97420a53775171ba18df669773d90882386a0d99e0x39122CD7E220f80Da6c59c7a1Aca3cbD381e912F2026-10-30 7:57:47 / in1E-90x6aca294b73c18da342241fecbb49e5462599f9556964997330c57323a6eceb6f0x39121617eAaC2eD380ee67EbB5a43D97E780912F2026-10-30 8:21:35 / out23.850xeaaea9a99493c12cfc2c65f1282254996d0220d7d97f70151522d4c1a39ced020x3A793B6FfEa212AcC8E2D2B9b45A3DB7C9c4248d2026-10-30 8:23:23 / in0.0000010xfb46bee5d5866f719f44020427f30366b7d9efc7ee6e95330e877b2434e7b0790x3a799d6769ba53BC125Fd9ec163E80124ce0248D2026-10-30 8:27:11 / in1E-90x1406e317a097574d6f76d096aeef4fc49712c40d4696653d5fb7d1cf7da511c80x3a790f97679916C0dFf9f8F132e6bF37DeC2248d2026-10-30 8:57:35 / in1E-90xcc6c8479d0acc0b7e48a72d324e5d3b20c8828bcbd3bf16818c10e259a8128630xC9CDb9961e1fD51B4229984478EFC2638A344c7C2026-10-30 8:58:11 / in00x85d5b98671812998d9b4f3ae1d8807b99bee090a9acfe671a6ca7d3472c95ebc0xe5CE8231a4af7cca9884F41Ee0704Df60F05ad292026-10-31 3:12:35 / in00xfa4fbe9ec28de33126dd8ba9dc03dcc6b70fd48e44a6b3e0c25343456149799a0x16A639a55782c80D3B16DBC5F8Ef5F72364d9f1d2026-10-31 3:14:47 / in00x79e92ceeb95b81e8c69b810c516c977eb046e616eed41bb45ddc56b427efc9120x164560349E7FdB582b82d1520832769284179F1d2026-10-31 3:30:35 / in00x8006d2ff64d3b4cc354f2cb5c3492fddad0c48b51b2832d99b27f510dc44ffc60x3A2Ba6Bebc7F82886271afE37c6eC7e95e3b8a652026-10-31 3:32:47 / in00xa51fabc149d4815ca533d400952bacfa51d6a5a1314ef5aa77f3c8256e3e016b0x1813E63448b8693Fd76cdf3B36276bA87673E08e2026-10-31 3:32:47 / in00xbbbaea665606af7269818ebb3e83e49860cd8ec5d711aa3b90e32558fbd9e1d60x3a2c7eb8626F393f3aDF67F5171024b230358A652026-10-31 3:34:35 / in00x19642900ed30ad37fd256b714e7af475bdb2d1944cb164b77314e48561ef52070xd5096e342c4fB78FcC2A0446bC915658c35579b42026-10-31 3:35:11 / in00x2c5892036256586887eb0c1799281812f2a01a2cfeaf6bb32c2f25b983c5f8bc0x181A44A740c3501Dfb41743ba8914682F3c1E08E2026-10-31 3:36:47 / in00x4cc1418ea5ce5f9628c8f55fbabaf5a259fde4c48744fe1fc8c499f52f9082fc0xD51F80f41975dbeCc98591b229b63dCD941979B42026-10-31 3:38:35 / in00xb58ff14c78f48ef4996930245997349892afb5e061f33166fc165f287f5f9b7e0xB1a00Fb4918B9dFa84325b9EcA8D4A38493dF92E2026-10-31 3:40:47 / in00xdcae527cd0bbe15278e137b84a72682d1f089e668a98db4fcbc30a81204fd2ad0xB1960934b5b3E9393231cEa639d976802D10f92eSource records are the linked explorers and THORChain action pages, supplemented by SentinelTX’s bounded upstream results. Bitcoin coverage returned 2,280 transactions and 1,563 addresses; TRON returned 302 transactions and 211 addresses. Both were incomplete. These are tool graph counts, not independently confirmed theft counts. Public background: Bitquery’s Bitget investigation and Binance investigation. Missing source coverage does not establish absence, so theft provenance remains unresolved. The additional two-hop query into the older Bitcoin sender returned 66 addresses and 78 transactions; its UTXO lookup failed, so the four actual inputs were checked separately in the public explorer. The Bitget TRON anchor query did not reconstruct a continuous path into the source wallet. The address comparison above was performed separately against the downloaded public file.