커뮤니티

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.

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 = 175000000

SentinelTX’s examination of the zkLink Nova withdrawal incident follows one Ethereum signer from preparation to a single transaction that paid ETH and eleven token types, then through conversions and dispersal to three recipient accounts. The execution sequence is visible in the report, but the forged-root explanation, wallet controllers and incident-attributable share of later holdings are not established.The report also contains conflicting confidence labels and material amount warnings. This article preserves those qualifications: the observed DAI balances are not presented as traced cash-out, and the FixedFloat-labelled destination remains an unverified lead rather than a confirmed exit.1. Scope and roles before the numbersThe seed account is the wallet at the centre of the examined withdrawal, not an identified person. Contract roles below distinguish what the call trace shows from identities or functions supplied by public reporting.Label / RecordNetwork and collection: Ethereum mainnet (chain ID 1) only. Collection: 29 October 2026, approximately 13:24–13:31 UTC; chain tip moved from block 26298676 to 26298706. Other chains were not screened.Seed account: 0xaca0655a11200a80d33d0e48786317304cde5718. An externally owned account (EOA): signer of the examined transaction, withdrawal recipient and disperser. Its real-world identity is unknown.Execution contract: 0xd5f162b68a0281686e8dc76db8d67d2f3e6aff07. Created by the seed account and called in the examined transaction.Payout contracts: 0x5fd9f73286b7e8683bab45019c94553b93e015cf paid ETH and was consulted before token transfers; its core/escrow role is an inference. 0xad16edcf7deb7e90096a259c81269d811544b6b6 supplied eleven token types; its zkLink Nova ERC20 bridge identity is reported, not label-verified.Recipient shorthand: 0x211b…9c6a = 0x211b4aebefea02470587286b398ed28fb7e09c6a; 0x75dc…c0f3 = 0x75dcf3395b6cbefc6b66b28d6d93f193b58dc0f3; 0x2d5a…afb0 = 0x2d5a8aabf7af4022e314eb2a54753ba2402bafb0. Similar behaviour does not establish common control.Meaning of an amount: A receipt or transfer is a movement; a balance is a snapshot. Gross movement counts value again at each hop. None is automatically the incident loss, a cash-out total or a recoverable amount. Unlike assets are not added together.Public reporting collected by SentinelTX described a forged batch root injected through a public relayer and attributed detection to Blockaid. The report records estimates from USD 778,625 to about USD 786k; the USD 805k upper bound in the referral did not appear in its search results. These are reported estimates, not a loss calculated by the investigation. Only search snippets were read, not publisher pages, Blockaid’s primary publication or the Defimon Telegram channel.2. From preparation to the withdrawalAll event times below are UTC block timestamps. The report describes a short wallet lifecycle on 28 October 2026:15:49:11, block 26292232: the seed received a reported 0.02723853 ETH from a database-labelled FixedFloat address. The funding hash is not cited in the narrative, and the amount is unverified.15:59:59–17:49:11: preparation included a reported 0.00045-ETH swap for 1.045988 USDC, a zero-value USDC call, a reported deposit of 0.00032933333342 ETH plus 1.0 USDC to the ERC20 bridge, and a reported 0.0021-ETH payment to a contract later seen in the call path. The preparation amounts carry the report’s unverified-amount qualification.18:51:11, block 26293139: the seed created its execution contract at nonce 4.22:21:35, block 26294188: the seed called that contract in position 0 of the block. The transaction succeeded, carried zero native value, used 1,109,471 gas and paid a fee of 0.001161701384313756 ETH. The report records an internal payment of 22.431294525563808989 ETH to the seed plus eleven token types. [E01]The seed then sent itself a zero-value transaction at position 1 of the same block. The narrative gives its fee as about 1 ETH, an unverified amount. A builder-priority-payment interpretation is the report’s assessment, not established intent.The main conclusion treats the withdrawal as block-anchored because its hash is not cited in that section’s prose. Appendix A does list the full seed-transaction hash; it is retained in the evidence register below. That additional reference does not establish whether the withdrawals were authorised.3. What the execution sequence actually showsThe call trace has 100 frames, a maximum depth of 9 and no revert. The seed’s contract first read the ETH-paying contract, then made two relay-path calls through several contracts. Those calls reached the ETH-paying contract before the payout. Next came the ETH payment and eleven calls to the ERC20 bridge. Each token call consulted the ETH-paying contract before ending in a token transfer. [E01]Diagram 1. Simplified execution order within the seed transaction. Solid arrows indicate sequence, not a separately proven funds route. A forged batch root, bypassed checks and a public-relayer identity are not established.Color and line key: slate marks observed execution stages; amber marks claims not established by the record. Solid arrows indicate execution order.Address/role key: seed = 0xaca0655a11200a80d33d0e48786317304cde5718; execution contract = 0xd5f162b68a0281686e8dc76db8d67d2f3e6aff07; ETH-paying contract = 0x5fd9f73286b7e8683bab45019c94553b93e015cf; ERC20 payout contract = 0xad16edcf7deb7e90096a259c81269d811544b6b6. The role of 0x0fdc28e64772a70109d10fd068f859cfa7dea2c6 as a public relayer remains reported, not established.Source: SentinelTX native PDF, CASE-ASYNCEA1, pp. 14–15; seed control record on p. 35.This ordering has the shape of a message or root submission followed by withdrawal finalisation, which is the report’s inference. No selector, event log or calldata was ABI-decoded. The trace therefore does not establish that a root was submitted, that it was forged, or which validation checks were bypassed. No owner-signature execTransaction calls were present; the seed account, not the bridge or protocol, signed the transaction.4. Token receipts and the conversion sequenceThe receipt table records the following eleven token types. Quantities are reproduced at the table’s precision, without adding unlike assets or turning them into a new USD total:pufETH: 245.73789885106106. The two described conversion legs were 132.0 pufETH to the null address with 141.9532103998426 WETH received, then 113.73789885106108 pufETH to a counterparty contract with 123.264115827052162383 ETH returned. Both pufETH leg quantities are flagged unverified. [E02] [E03]USDC: 18,113.448053 received. The later conversion sent 18,113.494041 USDC and returned 18,109.0636110923 DAI. The report explains the larger outgoing USDC amount as the receipt plus 1.045988 USDC bought during preparation, less the 1.0 USDC deposit. [E04]WBTC: 0.17360197 received, followed by a conversion returning 14,048.682073834 DAI. [E05]Renzo Restaked ETH: 12.569253862270157, forwarded to 0x211b…9c6a at 22:55:35. Its subsequent conversion is possible but unverified.rsETH: 6.86647159999; STONE: 6.299750644063014; USDT: 3,360.898152; rswETH: 0.500000001; wstETH: 0.4659585510407948. The report lists sales through MetaMask Swap between 22:42:35 and 22:44:47, but does not itemise their proceeds.mswETH: 2.4826191990067406; mstETH: 2.6372057700999996. These were not moved in the report’s account and remained at the seed at collection.There is a source inconsistency in the pufETH receipt section: its table gives 245.73789885106106 pufETH, while the opening sentence separately describes an unverified receipt attributed as 132.0 pufETH. Both statements remain in the PDF; this article does not substitute the smaller figure for the table total or silently reconcile them.The USDC and WBTC conversions are described as producing 32,157.7456849263 DAI. The seed forwarded a reported 32,157.745684926304 DAI to 0x75dc…c0f3 at 23:03:59; that forwarding amount is flagged unverified. A 22:57:35 WETH-contract call is consistent with an unwrap by its selector, but its amount is not established. Two further zero-value pufETH calls were not decoded.5. Three recipients, with amount and control limitsThe chronology labels three native-ETH dispersals as signer-verified. The conclusion and warning appendix nevertheless mark their quantities unverified. The entries below therefore retain the report’s numbers as qualified source figures, not independently confirmed amounts:22:58:35, block 26294373: 101 ETH to 0x211b…9c6a; amount unverified in the conclusion. [E06]23:00:11, block 26294381: 100 ETH to 0x2d5a…afb0; amount unverified in the conclusion. [E07]23:01:23, block 26294387: 102.061003174173709298 ETH to 0x75dc…c0f3; amount unverified in the conclusion. [E08]The narrative’s gross total is 303.061003174173709298 ETH, subject to the same component-amount qualifications. The recipients then converted ETH into DAI through MetaMask Swap and Uniswap during the first hour of 29 October. Several swaps lack cited hashes or established inputs. Similar timing and sizes support the report’s description of splitting, but do not identify controllers or prove structuring intent; slippage management is an alternative explanation given in the PDF.At 0x75dc…c0f3, the report describes roughly 270,847.79 DAI of inflows and 49,000 DAI leaving: a flagged 24,000-DAI MetaMask movement plus an unresolved approximately 25,000-DAI candidate leg. At 0x2d5a…afb0, the narrative includes an unverified 5,000-DAI transfer and two MetaMask movements of 4,895 DAI and 11,750 DAI. The approximately 25,000-DAI and 5,000-DAI onward legs remain unresolved in its conclusion. [E11] [E12]6. What the recipient balances meanThe report’s balance snapshot is separate from its flow tracing. It records the following holdings at collection; no incident-attributable share was computed, and control of the three recipients is not established.Holder / Observed balance and measurement0x211b…9c6a: 268,344.091493 DAI; 0.012780831346009828 native ETH.0x75dc…c0f3: 221,847.790589 DAI; 0.304521672474179225 native ETH.0x2d5a…afb0: 211,962.663173 DAI; 0.293706861952877501 native ETH.Same-asset totals: 702,154.545255 DAI; separately, 0.611009365773066554 ETH. These are observed balances; no case-attributable share was computed and address control is not established.Seed account: 0.000927 ETH at approximately 13:26 UTC; 2.482619 mswETH and 2.637206 mstETH. These are the PDF’s displayed balance figures, not the higher-precision receipt quantities.Measurement boundary: DAI contract: 0x6b175474e89094c44da98b954eedeac495271d0f. DAI read at approximately 13:30 UTC on 29 October 2026; token-balance block not recorded. The three recipient ETH balances are at block 26298706. Source: PDF pp. 10, 21–22.Figure 2. Observed DAI balances read at approximately 13:30 UTC on 29 October 2026. The token-balance block was not recorded. These balances are not traced proceeds, attributed cash-out or an established recoverable amount.Color key: slate bars show DAI quantities on a common linear zero baseline. Labels preserve the exact reported balance values.Address/role key: 0x211b…9c6a = 0x211b4aebefea02470587286b398ed28fb7e09c6a; 0x75dc…c0f3 = 0x75dcf3395b6cbefc6b66b28d6d93f193b58dc0f3; 0x2d5a…afb0 = 0x2d5a8aabf7af4022e314eb2a54753ba2402bafb0. Recipient control is not established.Source: SentinelTX native PDF, pp. 10, 21–22 and 37. The PDF flags the aggregate 702,154.545255 DAI against a structured traced ceiling of approximately 270.8K DAI; it also explicitly describes the larger number as a commingled destination balance, not attributed cash-out.The warning and the balance description coexist in the source. The larger balance must not be converted into a claim that all 702,154.545255 DAI was traced from this withdrawal. Nor does the smaller approximately 270.8K DAI ceiling establish a recoverable balance, a total incident loss or the status of the separate ETH exchange lead.7. The FixedFloat-labelled lead is not a confirmed exitThe report describes a path from 0x75dc…c0f3 through 0x05b38c2d3c66031d72c990753f464271a7fd6def to 0x4e5b2e1dc63f6b91cb6cd759936495434c7e972f, which its attribution database labels FixedFloat. It gives the two legs as 5 ETH and 4.99999664 ETH, respectively; both amounts carry unverified-quantity qualifications. The second transaction is placed at 01:58:59 UTC on 29 October, block 26295266. [E09] [E10]The PDF’s confidence wording is inconsistent. The executive summary calls this path “anchored end to end,” and a table prints a deposit transaction hash. The cash-out confidence paragraph nevertheless calls the destination an “Unverified lead,” says no inbound hash anchors it, and states that the path cannot be confirmed. The warning appendix repeats that downgrade. This article retains the unverified-lead status and discloses the stronger wording rather than choosing one statement as a repair.Exchange identity is label-based, not a finding about a person. The report also says the incident-derived fraction was not computed because the native-ETH account implies other inflows. The same labelled address reportedly funded the seed earlier; that earlier payment was a withdrawal from the venue, not a deposit. No other exchange-deposit leg was identified, and Uniswap or MetaMask interactions are on-chain swaps, not custodial deposits.8. Mimic records and the remaining evidence gapsThe report excluded four apparent ETH movements after checking their full transaction records. Each was signed by a third party, 0x80d04079ffc53eb14edbeeb37279d126f45552df, carried zero native value and called a third-party contract, while the transfer listing mimicked a case transfer. Other exclusions include token-symbol mimics “ЕТН”, “DAl.” and “ERC ”, look-alike recipient addresses, unsolicited OVER receipts and small apparent ETH receipts that were not signer-verified.That distinction matters because a similar-looking address or symbol does not identify the genuine asset or recipient. The report set aside a DAI branch attributed to a look-alike address. Whether the candidate 5,000-DAI movement was intentional or a poisoning-induced mis-send remains unresolved. [E12]The report’s remaining boundaries are specific:Mechanism and coverage: one withdrawal transaction and one signer were examined. Other bridge withdrawals on 28–29 October were not screened. No cross-chain bridge deposit was identified among observed reachable deposits; this was not a screen of every chain.Trace depth and attribution: onward tracing reached four of five planned steps; 13 of 41 traced transactions are itemised in the retained view described by the narrative; 11 counterparties have no attribution result. The seed’s internal-transaction history was only partly readable. The deterministic cash-out propagation did not complete and was not relied on.Amounts and onward movement: unresolved items include the approximately 25,000-DAI and 5,000-DAI legs, the Renzo Restaked ETH disposition, the ETH inputs to 0x211b…9c6a’s swaps, the seed’s MetaMask proceeds and the WETH unwrap amount. The narrative also describes unexplained native-ETH inflows; these are not assigned to the incident.Measurement and valuation: token balances lack a recorded block. The report’s broader movement inventory includes repeated hops and unidentified token symbols, so it is not a loss total. Its pricing appendix says 53 movements have a USD value, with no price source recorded for 24; six symbols could not be priced.9. Response priorities and conclusionThe report prioritises preservation of the relevant FixedFloat order records, monitoring of the recipient and lead addresses, decoded protocol events and confirmation of contract roles. It also proposes asking the mswETH and mstETH operators whether the residual seed balances can be blocked or recovered; that capability was not verified. These are the report’s proposed actions, not actions taken for this article.Its expert opinion is that the sequence matches a bridge proof or message-forgery exploit with rapid conversion and splitting. The supporting record remains narrower: one examined Ethereum withdrawal, later movements with amount qualifications, observed DAI holdings without established control, and a disputed exchange-destination confidence label. The report’s recovery discussion depends on negotiation, legal identification or later movement to a custodial venue, not on treating the balance snapshot as secured funds.Figure 3. The report’s recorded execution and material limits. The forged-root mechanism and wallet controllers remain unestablished; some transfer quantities are unverified. Observed balances are not attributed cash-out, and other bridge withdrawals were not screened.Color key: slate identifies recorded execution; amber identifies unestablished claims; sage identifies amount and scope limits. The meaning is also stated in text.Source: SentinelTX native PDF, pp. 11, 14–15, 20–23 and 37–38. Its FixedFloat confidence text treats the destination as an unverified lead despite stronger wording elsewhere; that contradiction is preserved above.10. Evidence appendix and source limitations10.1 Selected transaction registerThe evidence IDs in the article link to transaction pages built from hashes printed in the PDF. These links are navigation aids, not a claim of a fresh explorer check. The register states the use, UTC time, block, quantity and source qualification for each selected record. It is not an exhaustive ledger.Evidence ID and use / PDF record and limitationE01 — Seed execution: 28 October 2026, 22:21:35 UTC; block 26294188. Zero native transaction value; the narrative records an internal payout of 22.431294525563808989 ETH and eleven token types. Status: successful control transaction in Appendix A; the main conclusion calls the withdrawal block-anchored. Mechanism and authorisation remain unestablished. PDF pp. 4, 14–15, 21, 35. Full transaction: 0x4f3c23e75b9134e8cae5a462550daad42fbbc19242567fcc34c0a035e297462cE02 — First pufETH leg: 28 October 2026, 22:24:35 UTC; block 26294203. Narrative: 132.0 pufETH to the null address and 141.9532103998426 WETH received. Status: pufETH quantity flagged unverified; the routing table separately prints a verified row. PDF pp. 7, 27, 37. Full transaction: 0xc6918af5df66ff7b632216bd0d01389a888d8c28d83c2572858f85bde4b573b3E03 — Second pufETH leg: 28 October 2026, 22:28:47 UTC; block 26294224. Narrative: 113.73789885106108 pufETH to the counterparty contract; 123.264115827052162383 ETH returned. Status: pufETH quantity flagged unverified. PDF pp. 7, 28, 37. Full transaction: 0x123bd9627d3c06f73498bd466100a62d4f7db76783ef9cd5ce5906a1e4fe4460E04 — USDC conversion: 28 October 2026, 22:30:47 UTC; block 26294234. Narrative: 18,113.494041 USDC sent and 18,109.0636110923 DAI returned. Status: conversion listed; the article uses narrative precision, without substituting the routing table’s additional digits. PDF pp. 7, 25. Full transaction: 0x2ddf70327a009c55960dd4d68fe308df772ef2816ca91215b25546f5c9d306f3E05 — WBTC conversion: 28 October 2026, 22:33:59 UTC; block 26294250. Narrative: 0.17360197 WBTC sent and 14,048.682073834 DAI returned. Status: conversion listed. PDF pp. 7, 25. Full transaction: 0x58bbdeebc886bfab35fa83366905fdf8c370c9ba1f9ff2dc4c39f7991c8cb239E06 — First native dispersal: 28 October 2026, 22:58:35 UTC; block 26294373. Narrative: 101 ETH to 0x211b4aebefea02470587286b398ed28fb7e09c6a. Status: signer-verified in the chronology, amount unverified in the conclusion and warning list. PDF pp. 8, 20, 28, 38. Full transaction: 0x2522281fbc77a612193e78e27f8cddd8147c605759216b67ce40320b9c8ff56eE07 — Second native dispersal: 28 October 2026, 23:00:11 UTC; block 26294381. Narrative: 100 ETH to 0x2d5a8aabf7af4022e314eb2a54753ba2402bafb0. Status: signer-verified in the chronology, amount unverified in the conclusion and warning list. PDF pp. 8, 20, 28, 38. Full transaction: 0x5696e2178bf680110d927d9bf71bdf05fcc22a282ad8a15bbdb938e5f852de44E08 — Third native dispersal: 28 October 2026, 23:01:23 UTC; block 26294387. Narrative: 102.061003174173709298 ETH to 0x75dcf3395b6cbefc6b66b28d6d93f193b58dc0f3. Status: signer-verified in the chronology, amount unverified in the conclusion and warning list. PDF pp. 8, 20, 29, 38. Full transaction: 0x04c207b1b0e181fa3aa6eb5f2ee35cdd629db5d706a555ac8e0e2a26c0b0e3bcE09 — Pass-through leg: 29 October 2026, 01:57:35 UTC; block 26295259. Narrative: 5 ETH from 0x75dc…c0f3 to 0x05b38c2d3c66031d72c990753f464271a7fd6def. Status: amount unverified in the conclusion; the routing table separately prints a verified row. PDF pp. 9, 20, 30, 38. Full transaction: 0x8b6d9b0a7696857ae7b956e458a1999891dcd3f73236fc7d9a10703468fbe8c1E10 — FixedFloat-labelled destination: 29 October 2026, 01:58:59 UTC; block 26295266. Narrative: 4.99999664 ETH to 0x4e5b2e1dc63f6b91cb6cd759936495434c7e972f. Status: destination called an unverified lead in the confidence text; amount unverified; label-based exchange identity and partial case attribution. Stronger wording and verified table rows elsewhere conflict with these qualifications. PDF pp. 4, 11–12, 19–20, 24–25, 37–38. Full transaction: 0x0268cf861201bbec96285c54cf25d66d058100a4ebd81021eeab2747dbe0127cE11 — Candidate onward DAI leg: 29 October 2026, 02:08:35 UTC; block 26295314. Narrative candidate: 24,999.999999999996 DAI to 0xdf410542aa35dab5e1ff3f46fcbd671d5e243977. Status: unverified lead; onward movement not established, despite a verified 25,000.0 DAI row in the routing table. PDF pp. 9, 21–22, 30, 36–37. Full transaction: 0x7c6955ba4e2a9e954966975a3d63187784a75c092a7013de447260e6e1c9d3ffE12 — Candidate 5,000-DAI leg: 29 October 2026, 01:32:35 UTC; block 26295135. Narrative: an unverified amount attributed as 5,000 DAI to 0x791a1cff9f9431ef98ca25c2e31ecb92a8ac2f25. Status: unresolved in the narrative; the hash appears in the routing and control records. Whether this was intended or a poisoning-induced mis-send is unresolved. PDF pp. 10, 16–17, 22, 31, 36. Full transaction: 0x8f0796105a30c02fffe21ae8410217dbc385d653578ef2fa3445073356eec3e010.2 Source and method registerPrimary source: SentinelTX’s 41-page native investigation report, CASE-ASYNCEA1, dated 29 October 2026. Its document-integrity block prints generation time 2026-10-29T13:53:18Z. Use: source for this article’s findings, figures and evidence references. Limitation: the PDF retains its own warnings and conflicting confidence statements. The executive summary also carries the separate case reference CASE-20261029-0001; neither identifier has been silently substituted for the other.Narrative and exhibits, pp. 3–23: used for chronology, call sequence, balances, exclusions, assessments and recommendations. Limitation: reported public accounts, inferred roles and qualified amounts remain distinct from established execution facts. The pufETH receipt wording and FixedFloat confidence wording are internally inconsistent, as described above.Path Routing Evidence, pp. 23–32: used to retain transaction references and their printed fields. Limitation: some rows are marked “verified” and show readable transfer amounts even where the narrative or warning appendix calls those quantities unverified. These conflicting labels are not resolved by this adaptation; no replacement totals or attribution shares were computed.Methodology, pp. 33–36: one recorded 90-day query window, 31 July–29 October 2026. The 217 retained rows with readable timestamps span 28 October 15:49:11 to 29 October 07:35:59 UTC; three retained rows have no readable timestamp. A query window is not the evidenced event span. Provider-wide account lists and the rows followed by a trace are different populations; they are not interchangeable funding or balance totals.Control records, pp. 34–36: used for the creation and call references, including [E01]. Limitation: a selector and successful status do not alone establish storage changes, contract control, actor intent, a loss or cash conversion.Warnings and integrity record, pp. 36–39: the report records one downgraded claim and 19 findings flagged for review, then lists one INV-12 entry and eighteen INV-13 entries. A signed manifest identifies the compiled source; it does not remove the substantive qualifications. Exact material warning wording is retained below.10.3 Exact source warningsThe following is the report’s own warning record, with line wrapping normalised only. Its practical consequences are the unconfirmed destination, unverified transfer quantities and prohibition on treating the full destination balance as attributed cash-out. Where other source passages disagree, those disagreements remain disclosed rather than repaired.PDF p. 3: INTEGRITY GATE — the integrity gate downgraded 1 claim in the text and flagged 19 findings for review. See the appendix at the end of this document for the full list.PDF p. 4, repeated inline amount qualification: [⚠ unverified amount — auto-check: a retained transfer this line names has no readable quantity, so no retained amount bounds this figure]PDF p. 4, holdings qualification: [⚠ exceeds the traced amount — auto-check: the structured evidence traces at most ≈270.8K DAI]PDF p. 20, opening conclusion label: unverified (auto-downgraded) (transaction-hash anchored in this section): the cited transfer of 101 ETH is unverified, as its token scale or symbol was not retrieved andPDF p. 37: [INV-12] Cash-out endpoints (every exchange-deposit leg in the evidence) — a row naming a confirmed freeze target / cash-out deposit address carries no inbound TX hash anchor (a label and co-occurrence cannot establish a destination) → downgraded to an unverified leadPDF p. 37: [INV-13] Case narrative (time order, UTC block timestamps) — the cash-out / attributed amount '702,154.545255 DAI' exceeds the structured evidence's traced ceiling (≈270.8K DAI) by 2.6× → likely a destination's commingled total deposits counted as traced taint; auto-downgraded (re-state against the traced amount)PDF p. 37: [INV-13] Case narrative (time order, UTC block timestamps) — the cited transfer amount '0.00045 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] Case narrative (time order, UTC block timestamps) — the cited transfer amount '0.00032933333342 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] Case narrative (time order, UTC block timestamps) — the cited transfer amount '0.0021 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] Case narrative (time order, UTC block timestamps) — the cash-out / attributed amount '4.99999664 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] Seed receipts in the seed transaction and their disposition — the cash-out / attributed amount '132.0 pufETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] Seed receipts in the seed transaction and their disposition — the cited transfer amount '113.73789885106108 pufETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] 0x75dcf3395b6cbefc6b66b28d6d93f193b58dc0f3 — the cash-out / attributed amount '32,157.745684926304 DAI' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] 0x75dcf3395b6cbefc6b66b28d6d93f193b58dc0f3 — the cited transfer amount '1.0 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] 0x75dcf3395b6cbefc6b66b28d6d93f193b58dc0f3 — the cited transfer amount '24,000 DAI' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 37: [INV-13] 0x75dcf3395b6cbefc6b66b28d6d93f193b58dc0f3 — the cited transfer amount '25,000 DAI' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 38: [INV-13] 0x2d5a8aabf7af4022e314eb2a54753ba2402bafb0 — the cash-out / attributed amount '100 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 38: [INV-13] 0x2d5a8aabf7af4022e314eb2a54753ba2402bafb0 — the cited transfer amount '49.8 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 38: [INV-13] 0x211b4aebefea02470587286b398ed28fb7e09c6a — the cited transfer amount '101 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 38: [INV-13] 8. Recommendations — the cited transfer amount '4.99999664 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 38: [INV-13] Findings by evidence tier — the cited transfer amount '100 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 38: [INV-13] Findings by evidence tier — the cited transfer amount '102.061003174173709298 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)PDF p. 38: [INV-13] Findings by evidence tier — the cited transfer amount '5 ETH' names a retained transfer with no readable quantity (its token scale or symbol was not retrieved, or its amount is unusable), so no retained amount bounds it → auto-downgraded (state it against a retained transfer's amount, or as unverified)Source qualification, PDF p. 22: “Treat these as unverified amounts until corroborated against the sealed evidence table.” The same page states that the 702,154.545255 DAI figure is an observed commingled destination balance and must not be presented as traced or attributed cash-out. Labels are database attributions, not identity findings.

Nine ETH deposits are the clearest endpoint in SentinelTX’s report on the reported Arkadiko / StackSwap incident. Between 04:05:59 and 04:11:23 UTC on 23 October 2026, the report records 213.3 ETH moving from one address into a Tornado.Cash Router-labelled address. That is a specific Ethereum transfer sequence—not a complete reconstruction of the Stacks attack, proof of an operator’s identity, or a measure of the incident’s total loss.The distinction matters because the report also leaves cross-chain links unresolved and marks several earlier amounts as unverified. This analysis follows its recorded sequence while keeping those limits attached to the claims they affect. Its source is the 37-page SentinelTX report CASE-ASYNCF7B, generated on 26 October 2026 UTC.The reported governance attack and the Ethereum investigation are different layersSentinelTX recounts a reported governance-capture mechanism on Stacks. A proposal presented as a routine vault update was followed by a large DIKO purchase shortly before voting. The reported sequence is precise: a 3.39 million DIKO purchase at 15:03 UTC on 22 October; a vote of 4,573,197 DIKO at 15:06; voting closed at 16:04; and movements of sBTC and stSTX followed at 16:06 and 16:09. The account says the newly enabled contract’s fund-moving functions did not check the caller. Arkadiko reportedly switched the contract off at 18:08.The same account describes an earlier StackSwap takeover through proposal 4 on 20 October and the draining of 49 pools. These are reported incident details in the PDF, not findings independently established by its Ethereum trace. The report does not anchor the Stacks proposal, vote, drain or USDCx burn transactions. It also does not establish the identity of the controller behind either incident.Diagram 1. The governance mechanism is reported context: buy voting power, pass the proposal and enable code, followed by reported asset movements and USDA minting. It is not a verified Stacks reconstruction. Source: SentinelTX CASE-ASYNCF7B, pp. 4 and 15.Reported losses are presented as $1.16 million overall, including $1.09 million for Arkadiko and $70.5 thousand for StackSwap. The PDF explicitly does not reconcile those valuations to its on-chain quantities. They should not be added to, or substituted for, the ETH and USDC movements below.Stablecoins move through conversion venuesOn Ethereum, the report describes a main seed address with older activity and a separate staging address first active on 22 October. The staging address routed two USDC quantities through the MetaSwap router, with the token legs delivered to a shared contract:21:09:23 UTC, 22 October: 28,521.796245 USDC.22:04:35 UTC, 22 October: 32,204.864217 USDC.Address key: staging address = 0x425679fa1ab564815df9cbd91be68fc27c644073; main seed = 0x9a868f1db69d609a8efe14d979c53ebddd2a3875; MetaSwap router = 0x881d40237659c251811cec9c364ef91dc08d300c; shared recipient contract = 0x74de5d4fcbf63e00296fd95d33236b9794016631. Labels and token symbols follow the report and do not establish ownership or independently verified token identities. Source: pp. 5–7 and 10.The main seed’s conversion activity includes transfers to an address labelled “Rizzolver, Unknown” and interactions with the MetaSwap router. Those roles are distinct from a custodial exchange account. The report leaves onward movements from the Rizzolver-labelled address and the shared recipient contract unresolved.The PDF cites 244,594.20828 USDC arriving at the main seed through zero-address credits, but expressly downgrades that amount as unverified because the retained evidence does not supply a readable quantity that bounds it. A mint-style credit alone also does not establish which Stacks burn, if any, produced it. The source-chain burns and corresponding attestations remain missing links.Consolidation is described, but its exact amounts carry qualificationsThe report describes an ETH transfer from the staging address to the main seed, followed by two transfers from the main seed to a dedicated onward address. It characterises the latter sequence as a small probe followed by a sweep. Its quoted figures are 36.389030808813688987 ETH for the staging transfer, then 0.1 ETH and 213.262264545555095065 ETH for the two onward transfers. Each of these amounts is explicitly marked unverified in the compiled report; they are reproduced here as qualified source figures, not confirmed proceeds totals.There is a second limitation: the staging wallet’s native-ETH record contains its onward transfer, but that transfer is not among the four top-level calls the report lists for the wallet. The signing path is therefore not established. The interpretation that its ETH credits came from the two USDC swaps is an inference, rather than an itemised conversion reconciliation.These qualifications prevent the earlier stages from being treated as a fully reconciled, end-to-end value chain. They do not turn the separate nine-deposit sequence into an incident-wide loss estimate, nor establish what happened after mixer entry.Nine deposits, four denominationsThe report records the onward address sending nine transfers to the Tornado.Cash Router-labelled address on 23 October. The sequence uses four denominations:Two deposits of 100 ETH: 200 ETH combined.One deposit of 10 ETH: 10 ETH.Three deposits of 1 ETH: 3 ETH combined.Three deposits of 0.1 ETH: 0.3 ETH combined.Together, those nine deposits total the report’s 213.3 ETH. The first occurs at 04:05:59 UTC and the last at 04:11:23 UTC. This is the composition of that deposit sequence only; it is not a breakdown of all stolen assets, all Ethereum receipts or all cross-chain exits.Figure 2. Nine deposits into the router-labelled address, grouped by denomination. Values are ETH; group values are deposit count × denomination. Source: SentinelTX CASE-ASYNCF7B, pp. 10–11 and 15. Total: 213.3 ETH. No incident-wide loss denominator is implied.Address key: onward sender = 0xe8cbdc3bb8e7af91f0b7aa91696c5624b4d05006; recipient = 0xd90e2f925da726b50c4ed8d0fb90ad053324f31b. “Tornado.Cash, Mixer, Tornado.Cash: Router, Sanctioned” is the report’s returned label. The report calls for checking current sanctions status before relying on that label in a filing; this article makes no current sanctions determination.Mixer entry is an endpoint in the traced record, not evidence of a completed cash-out or a recovered balance. The report describes any matching withdrawal pattern as a lead only and says deposit-to-withdrawal matching is probabilistic. It does not identify a person controlling the sender or recipient.Earlier service activity is not automatically incident proceedsThe trace also reaches service-labelled activity outside the immediate deposit sequence. SentinelTX lists 11 legs to “Metamask Bridge, Exchange” and one to a Binance hot-wallet-labelled address. Its own interpretation is important: the former is a bridge/swap routing service despite the “Exchange” tag, and its destination networks remain unresolved.Ten of the 11 routing-service legs precede the reported drain. They cannot carry proceeds from that later event. The one post-drain leg is dated 25 October, but its sender is not cited in the report, so its relationship to the main seed is not established. The listed Binance deposit also predates the drain. The PDF consequently states that no custodial exchange deposit of drain-period proceeds is anchored in this report.The report separately excludes suspected address-poisoning and spam transfers. Look-alike addresses and tokens imitating the “ETH” symbol are not evidence of common ownership. Its ETH narrative uses native-ETH records rather than indiscriminately adding every token carrying an ETH-like symbol. Likewise, gross movement totals recount value at successive hops and are not loss figures.What the conclusion supports—and what it does notThere is a material tension within the source. Its conclusion calls the Ethereum sequence a “complete proceeds path”, while its own limitations leave the Stacks linkage partial, parts of the conversion chain unresolved and several amounts unverified. Those statements are not equivalent. We retain the narrower distinction: the PDF describes a specific Ethereum sequence culminating in nine mixer deposits, but it does not establish a complete, reconciled route from the reported Stacks drain to every destination.The report’s practical next steps follow those boundaries: obtain issuer mint and attestation records to connect source-chain burns to Ethereum credits; seek relevant routing-service or solver settlement records through appropriate channels; and examine the reported Bitcoin branch separately. The reported 4.86 BTC exit is not established by this Ethereum investigation, and no link between the cited Bitcoin address and the Ethereum seeds is proved here.Figure 3. Conclusion: 213.3 ETH in nine recorded mixer deposits; the Stacks linkage remains partial, the Bitcoin leg and controller identity are not established, and several upstream amounts remain qualified. Source: SentinelTX CASE-ASYNCF7B, pp. 15–16, 20–21 and 33–34.The useful result is therefore a bounded transfer trail, with transaction anchors and clear questions still open. Keeping reported mechanism, recorded movement, amount verification and ownership separate makes that result more useful—not less—than presenting a single headline total as the whole investigation.Selected transaction anchorsFirst staging USDC leg: https://etherscan.io/tx/0x0f3d50a9551fbcbac726f54067d880bc7b80353b189fc6b9d62fea54eeab353bSecond staging USDC leg: https://etherscan.io/tx/0xbeaa599afdea60457e240160325843d0b69e5b2938840da7495669a0295dbb87First mixer deposit, 100 ETH: https://etherscan.io/tx/0x0fade4caf7576e09a05d73a6706f08529087d7d771dd0645415a03ddf2b5707aLast mixer deposit, 0.1 ETH: https://etherscan.io/tx/0x0ac46a58ac0704d364ca6bc0a167cfd7b09965019cc3d96c5978c8d30257ebafSource and limitations noteAdapted from the actual SentinelTX-generated PDF CASE-ASYNCF7B, 37 pages, generated 26 October 2026 UTC. This is a faithful editorial adaptation, not an independently reproduced investigation. The report’s focus is 22–26 October with earlier funding context; its abstract separately gives an executed query window of 15 September–26 October. Those descriptions are not treated as interchangeable. Explorer links use hashes printed in the PDF and do not establish ownership.The PDF’s reported-incident source name and domain are missing in the rendered text on p. 4. We have not silently repaired that attribution. Its link to Arkadiko’s statement is reproduced below; the PDF says the statement was not independently reviewed for that report. The reported governance mechanism and loss estimates remain attributed to SentinelTX’s account, rather than presented as separately confirmed facts.Arkadiko statement cited by the PDF: https://x.com/ArkadikoFinance/status/2113367201722044512Amount qualification: the PDF flags seven findings under [INV-13] (pp. 33–34), auto-downgrading quantities whose retained transfer record has no readable amount that bounds the claim. Its exact inline warning is: “unverified amount — auto-check: a retained transfer this line names has no readable quantity, so no retained amount bounds this figure”. The affected claims are listed below. A number appearing elsewhere in a table does not remove this qualification.[INV-13] Case narrative — cash-out / attributed amount: 244,594.20828 USDC — auto-downgraded; unverified in the compiled report.[INV-13] Case narrative — cited transfer amount: 36.389030808813688987 ETH — auto-downgraded; unverified in the compiled report.[INV-13] Case narrative — cited transfer amount: 0.1 ETH — auto-downgraded; unverified in the compiled report.[INV-13] Case narrative — cited transfer amount: 213.262264545555095065 ETH — auto-downgraded; unverified in the compiled report.[INV-13] Stablecoin arrival and conversion (22–23 October 2026) — cash-out / attributed amount: 35,843.240369 USDC — auto-downgraded; unverified in the compiled report.[INV-13] Consolidation and mixer entry (23 October 2026) — cited transfer amount: 0.039606555354493989 ETH — auto-downgraded; unverified in the compiled report.[INV-13] Limitations (evidentiary) — cited transfer amount: 36.399562631044986312 ETH — auto-downgraded; unverified in the compiled report.The source also describes 213.3 ETH as 127.7 ETH plus 85.2 ETH in its assessment (p. 17). Those components do not sum to 213.3 ETH. We do not invent a missing component or use that passage as a reconciled allocation. The nine-deposit total above follows the separate deposit chronology, not that proposed origin split.

On 24 October 2026, X100’s Ethereum Freezer contract executed a sequence of governance proposals that moved treasury assets and withdrew liquidity. The crucial question is how addresses that acquired voting weight could use it immediately. The checked receipts show two supporting votes out of three Senate seats, followed by execution within the same transaction. The displayed source explains why that sequence was possible.This report follows three execution transactions, then a narrower onward route from the first USDT recipient through two conversions and one ETH distribution address. It separates the transaction sender, the contract doing the work and the address receiving the proceeds. Those roles are not proof of a person’s identity. E1, E2, E3.1. Before the numbers: what each participant didThe Freezer is the asset-holding governance contract. In the reviewed source, “frozen” tokens are tokens counted as stake for Senate membership; freezing here does not mean a stablecoin issuer or law-enforcement agency blocked an address. A helper contract is an address used during execution to hold stake and cast a vote. A bundler submits transactions for other operations; its presence does not identify the ultimate beneficiary.RoleEthereum addressFreezer: governance and treasury0x79F35A33FE2813414851c4Ae8daeacD14d822A46X token; 6 decimals0x100A2C7F45Fd48e217fdcE72e658dc78Fd43A100USDT token; 6 decimals0xdAC17F958D2ee523a2206206994597C13D831ec7First sender and final USDT recipient0x7ec2afdF3eC5964899894f8D58afa95cbB8FfD63Second transaction sender; explorer labels it ERC-4337 Bundler0xfc3fAcD67138966aB0c841E905B0C4BCA1AbE92FSecond final recipient0xEDac2D8905bF2Bf0033872D420C4ec6ef1dDd0c8Third transaction sender0xDAB137F390dF77caA97fd492540E973fd5e2F8c8Third final recipient0x0A67804462F04B0be1c433fB1C2F7fb76e5166F2Blockaid and Chainalysis supplied the public incident framing and transaction leads. The tables below use independently opened explorer records for movement and event facts. Their public estimates of roughly $4.7 million and roughly 4.85 million USDT are source snapshots, not interchangeable accounting totals. Public statement 1; Public statement 2; Public statement 3; Public statement 4; Public statement 5.2. Scope and the three findingsQuestionChecked scopeChain and event dateEthereum mainnet; 24 October 2026 UTCExecution window14:11:47–14:40:47 UTC; three selected receiptsOnward-route cutoffFour selected 400 ETH transfers through 14:43:59 UTCMethodPublic explorer receipt/log review and displayed exact-match verified source; not an independent node replayAccounting boundary4,848,017.339222 USDT paid to three selected recipients; not a whole-incident loss estimateReview date25 October 2026 KST; historical transactions, not a current-balance snapshotFirst, the governance boundary did not require the proposal to wait until its expiry: the first checked receipt creates, votes on and executes proposal 7 in one transaction. Second, the later executions use the same two newly observed helper addresses as senators, even though transaction senders and execution contracts differ. Third, the first recipient’s USDT payment is exactly matched by two subsequent USDT spends, while the ETH relay receives slightly more ETH than those two conversions produced. That difference prevents an all-funds provenance claim.3. How voting weight became an immediate treasury instructionWhat turned stake into execution permission? In the first receipt, each of two helper addresses receives 19,100.000001 X. Each sends 19,000.000001 X into the Freezer and a further 100 X as a candidacy fee. Frozen, Registered and Ranked events precede proposal creation. This ties the explanation to the actual receipt rather than assuming that any large holder could control the contract. E1.First execution evidenceObserved recordHelper holding stake and voting0xe08107E7Dc7c4540D139392e9D0FEA99ca019F37Second helper holding stake and voting0x176D1eA0ee9569783C6f6E455f7Be6171566619cProposal 7Selector 0xa4376352; v3Swap in the displayed permitted-method sourceVotes at execution2 votes for / 3 Senate seats; ProposalExecuted log 37Treasury leg400,000 X sent to the newly created pool; 35.675313 USDT received on the reverse legPool for that leg0x9A03c41c539880b51508bEbbc2Dde7B738f6f075Read Figure 1 from top to bottom. Arrows show the order of events within the first transaction, not an extra transfer of money. The observation to carry forward is that stake acquisition, voting and treasury execution happen together. The next question is which source checks permit that timing.Figure 1. Event sequence in E1. This is a governance sequence, not an asset-value chart. Full helper addresses and the transaction are in the adjacent table and evidence appendix.In Senate.sol, propose records the proposer’s supporting vote immediately. vote checks current Senate membership. execute tallies the current ranked list and accepts support when support × 2 is greater than senateSize. _state leaves a proposal open until it expires; expiry is a deadline, not a compulsory delay. execute then calls the permitted proposal data on the contract itself. DexTreasury.sol permits v3Swap and v3Decrease and forwards those operations to its module. Freezer.sol obtains voting stake from frozenOf. Displayed verified contract source.This source path and the receipt agree on the narrow failure mode: voting weight could be acquired and used immediately for treasury operations. The reviewed first proposal passes zero as its minimum output parameter; its observed 400,000 X leg receives only 35.675313 USDT. The later swap output elsewhere in the receipt is a different leg, not the treasury’s sale proceeds. We have not independently replayed historical storage, compiled the bytecode or audited every module path, so this is not a comprehensive code audit.4. Three executions do not establish three independent peopleAt 14:35:59 UTC, the second transaction executes proposals 8–13, including five liquidity-decrease instructions and one swap. The receipt creates a different execution contract and two helpers. It ultimately pays 96,381.883491 USDT and 9,894.892631 X to its final recipient. The sender is the bundler-labelled address, not that recipient. At 14:40:47 UTC, the third execution uses the same two helper senators seen in the second receipt, and pays a different recipient. This is a direct operational link, but does not resolve who controlled those addresses. E2; E3.ExecutionVerified final recipient paymentE1 · 14:11:47 UTC4,749,726.096973 USDTE2 · 14:35:59 UTC96,381.883491 USDT + 9,894.892631 XE3 · 14:40:47 UTC1,909.358758 USDT + 549,915.546932 XSelected USDT subtotal4,848,017.339222 USDT; no conversion of X to USDThe first USDT amount is the final transfer to the sender after the observed flash-loan repayment, not the larger gross swap output. An Aave FlashLoan event records a 1,942,457.637245 USDT principal and 971.228819 USDT premium in E1. The gross 6,693,089.638357 USDT swap output must therefore not be called net profit or added to the final payment. Likewise, repeated transfers between execution contracts and recipients are the same funds moving through a route. Native ETH gas is outside this USDT subtotal.Governance executionsReceipt evidenceE1 · proposal 72 / 3; execution log 37E2 · proposals 8–132 / 3 each; execution logs 484, 496, 508, 520, 532, 542E3 · proposals 14–172 / 3 each; execution logs 18, 28, 38, 59Raw final-payment checksE1 log 54: 4749726096973 USDT units; E2 log 554: 96381883491; E3 log 71: 1909358758Raw X check in E3Log 66: 549915546932 units; 6 decimal placesThese are selected recipient payments, not an independently reconciled loss across all treasury assets and all transactions. X-token residuals, changing pool prices and any other incident-linked activity remain outside that conclusion. The first explorer receipt is successful but also displays an internal reverted-call warning; “Success” does not mean every internal attempt succeeded.5. Following the first recipient into ETHWhere did the first USDT payment go? Two later transactions show the first recipient spending 2,000,000 USDT and 2,749,726.096973 USDT through a UniswapX settlement route. Their sum exactly matches the 4,749,726.096973 USDT received in E1. Internal native-asset transfers pay 851.542914929444388864 ETH and 1,170.472889392738131465 ETH back to that recipient. The transaction senders are settlement participants, not automatically the beneficial owner. S1; S2.RecordAmount and meaningS1 · 14:16:35 UTC2,000,000 USDT out; 851.542914929444388864 ETH inS2 · 14:17:47 UTC2,749,726.096973 USDT out; 1,170.472889392738131465 ETH inTwo conversion receipts2,022.015804322182520329 ETH received in totalR1 + R2 · 14:18:59 / 14:19:23 UTC2,022.856704743507502222 ETH sent onwardDifference0.840900421324981893 ETH more sent onward than these two conversions producedThe first recipient then sends 1,000 ETH and 1,022.856704743507502222 ETH to the same distribution address. Because that total exceeds the two conversion receipts, it cannot all be assigned exclusively to those conversions. Other ETH already present or received can mix with converted proceeds. This review proves the selected transfer sequence, not a unique per-wei attribution. R1; R2.Read Figure 2 from the first recipient to the central distribution address, then outward to four branches. Solid arrows are checked native ETH transfers. The top panel reports the separate conversion total and the mixing boundary. The four equal branch transfers are the key observation; their later disposition is the next unanswered question.Figure 2. Historical ETH transfers on 24 October 2026 UTC. Labels use evidence IDs and rounded ETH values for readability; exact quantities and full identifiers are preserved below. No current balances or common ownership are asserted.Distribution roleFull Ethereum addressCentral distribution address0x8296721489d0a7E934edd66ea27159B1C88A42e5D1 · 400 ETH · 14:39:47 UTC0xF637DCeE7Dd96E8FDaB926C5993D558B52D635eaD2 · 400 ETH · 14:40:35 UTC0x6790cF09ba33D05aDA2C13cBB4104F5b8B666391D3 · 400 ETH · 14:43:35 UTC0x64b135Af3d80733c9C290D58873e2CCcb34a81AeD4 · 400 ETH · 14:43:59 UTC0x4fDB9F9A44b356c8A9c2Ea060a40Fb7a9cAaBef3Each of D1–D4 is a successful 400 ETH transfer from the central address, for a selected distribution total of 1,600 ETH. The second and third execution transactions overlap this distribution window; the chronology is not three isolated phases. No outbound activity from the four recipients was exhaustively reviewed. Their historical receipts do not prove that they still hold 400 ETH each, that an exchange accepted them, or that anyone cashed out.6. What the evidence does not establishA shared helper pair links the second and third governance receipts, but shared infrastructure alone does not prove one operator, and different senders do not prove different people. No personal identity is established here. Explorer service labels are navigation clues, not legal findings. There is no verified recovery, asset freeze or exchange account attribution in this bounded review.The source displayed at the Freezer address is exact-match verified, and its creation receipt predates these transactions: 23 October 2026 at 14:25:59 UTC, block 26255911. That does not substitute for a complete historical-state or implementation-change analysis. The reviewed code and the selected emitted events support the immediate-governance path; unreviewed configuration changes and module branches remain limitations. Contract creation receipt.7. Incident-specific response pointsThe governance evidence points to a concrete control question: can newly acquired, currently ranked stake authorize treasury DEX operations before other holders have time to respond? A meaningful remediation review would need to test delayed execution, a prior-state voting snapshot and limits on treasury price execution against this exact same-transaction sequence. This report does not claim that any of those changes have been deployed.For tracing, preserve E1’s recipient payment, the two USDT settlement records and R1/R2 as one route rather than counting each hop as new loss. Preserve D1–D4 as separate historical outputs, with their exact hashes, before making a service-exposure claim. The outstanding recovery question is what happened beyond those four outputs; this review does not answer it.8. Evidence appendix8.1 Selected transaction inventoryAll times below are explorer-displayed UTC on 24 October 2026. Full hashes are deliberately retained. E1’s internal reverted-call warning is a qualified success; the other selected transaction detail pages display Success.Evidence E1RecordTransaction0x38c60844f1923d53fdce7d99e9bc2a2d8c73a08e793341dfbb479f8cc74d81d0UTC / block2026-10-24T14:11:47Z / 26263022Observed factFirst execution; final payment 4,749,726.096973 USDTStatusSuccess; explorer also shows an internal reverted-call warningEvidence S1RecordTransaction0xb861b3710531230449711b04b416cc65ccff87e6dab0457e373e5dbb637e5dd5UTC / block2026-10-24T14:16:35Z / 26263046Observed fact2,000,000 USDT out; 851.542914929444388864 ETH received by first recipientStatusSuccessEvidence S2RecordTransaction0xb25ae55fded129da667ba5375d23fc1c611167e5444b0d20751e86b51668accdUTC / block2026-10-24T14:17:47Z / 26263052Observed fact2,749,726.096973 USDT out; 1,170.472889392738131465 ETH received by first recipientStatusSuccessEvidence R1RecordTransaction0x9a3f04912e1e52ad04fc00ac72efb3169e4a4c73596d1a5d7c055375397cc0dcUTC / block2026-10-24T14:18:59Z / 26263058Observed factFirst recipient → distribution address; 1,000 ETHStatusSuccessEvidence R2RecordTransaction0x3a8908f55e86af180559aed1051f9acc6145dad5e3292ffa48582f5b8bb9e1f2UTC / block2026-10-24T14:19:23Z / 26263060Observed factFirst recipient → distribution address; 1,022.856704743507502222 ETHStatusSuccessEvidence E2RecordTransaction0x77c46e1aa9037ed4fbc9cc7e00d199dcd752acf576b4b5d3446e785dc45235c0UTC / block2026-10-24T14:35:59Z / 26263143Observed factSecond execution; final payments 96,381.883491 USDT and 9,894.892631 XStatusSuccessEvidence D1RecordTransaction0xa08147bbd6cd279678327faf43af3e7f96323aed376f5bdbe44ed9fbef2898e5UTC / block2026-10-24T14:39:47Z / 26263162Observed factDistribution address → branch 1; 400 ETHStatusSuccessEvidence D2RecordTransaction0x5954deb30f637cd2d789403dce8a03caa9a89f2c088f7963976927948804953eUTC / block2026-10-24T14:40:35Z / 26263166Observed factDistribution address → branch 2; 400 ETHStatusSuccessEvidence E3RecordTransaction0x7c49bf28865defd5c1345f6527210360d635e510fa49279d0b62e6e02cfad99aUTC / block2026-10-24T14:40:47Z / 26263167Observed factThird execution; final payments 1,909.358758 USDT and 549,915.546932 XStatusSuccessEvidence D3RecordTransaction0x09c7e5feac1a466c67f9b6816bf82f8f2f16297acfe282e7592b0dbd749366bfUTC / block2026-10-24T14:43:35Z / 26263181Observed factDistribution address → branch 3; 400 ETHStatusSuccessEvidence D4RecordTransaction0x8f2bfb1391244540283d009e05dcd49988452d0ea456a7edba4dd331394cbbd9UTC / block2026-10-24T14:43:59Z / 26263183Observed factDistribution address → branch 4; 400 ETHStatusSuccess8.2 Execution and voting address registerRoleFull Ethereum addressE1 outer contract0x89e903e4512F8a315ceBD99c29a1e40EeE6Fe2C9E1 execution contract0x37541Fc4A6F1eC86889bA506F51DC39f2BeDd10AE2 execution contract0x515Ca27BB80325cdc56f0ad3B9dE69829C869A51E3 execution contract0x554B49369E0e612bC56088E355D3a087006e0C64Helper senator in E2 and E30xC2f69b21BeA8F0C64cbd4597f262C80c993073BASecond helper senator in E2 and E30xb21F45868DCAAe3bE7c842971Ae61DD93D4C7CdEOther seat in checked event lists0xA13a935dce629FbbA304D3EbdA8d96459B05716E8.3 Source and evidence boundariesFreezer verified-source viewer: reviewed functions are listed in the code discussion above. X token metadata and USDT token metadata each display 6 decimals. Public analyst statements establish attribution and reported context; selected explorer receipts establish transfers and events. Arithmetic subtotals are calculations over that stated scope. Ownership, full loss, current holdings and recovery remain unverified.

Four token payouts, a sequence of conversions and one short relay define the Ethereum trail associated with the reported WAX Multi-Chain Bridge incident of 22 October 2026. SentinelTX’s case report follows that trail to an address labelled “HitBTC, Exchange”. The destination is an investigative lead, not proof of a completed cash-out or the identity of the person controlling the funds.This analysis focuses on the Ethereum transfers documented in SentinelTX report CASE-ASYNC3FA, compiled on 24 October 2026 UTC. It distinguishes recorded movements from venue labels and incident-level assessments. Amounts remain in their native asset units; no incident-wide dollar loss is calculated here.Four payouts in less than a minuteThe report records four transfers from the same Ethereum contract to the same recipient between 10:05:35 and 10:06:11 UTC on 22 October. The assets and quantities were:21,558.252354 USDT at 10:05:35 UTC.840.2750339 DAI at 10:05:47 UTC.2.54669928 WETH at 10:05:59 UTC.0.10993227 WBTC at 10:06:11 UTC.Address key: payout contract 0x24b22b031ae1b5a6b09f9a0fd33613a40e0d70e6; recipient 0x01664e199991b2f3fe412c2de5b9b7a0dcdc5070. Token symbols follow the report’s trace labels and are not a separate token-identity verification.Figure 1. Four Ethereum payout quantities, shown separately because the units differ. Source: SentinelTX CASE-ASYNC3FA, pp. 4–5 and 17. These are transfer amounts, not a total loss calculation.The contract’s role as the bridge’s release side is an assessment in the report, not a returned address label. Similarly, the recipient’s alleged attacker-side role depends on the broader incident interpretation. A transaction trail establishes movements between addresses; by itself it does not establish the identity or authority of the signer.From token balances to an ETH relayThe report’s chronology describes token-conversion activity after the payouts. It records two unsuccessful USDT swap attempts before a successful KyberSwap route at 10:16:11 UTC. The WBTC movement followed at 10:18:35, then WETH at 10:20:23 and DAI at 10:22:23. The WETH and DAI routes are attributed to Velora; the WBTC interaction is with an unlabelled contract.These swap venues should not be confused with the eventual exchange-labelled destination. They are intermediate interactions in the account’s conversion sequence, not evidence that the exchange received each original token.At 10:24:23 UTC, the recipient transferred 15.58 ETH to 0x62907e044ffe22a24aa8794ff2a6ea20598227bb. At 10:43:47 UTC, that relay sent 15.5799958 ETH to 0x80787af194c33b74a811f5e5c549316269d7ee1a, which the report labels “HitBTC, Exchange”. The report displays the second amount rounded to 15.579996 ETH in its chronology and summary.Figure 2. The Ethereum sequence described in the report: token payouts, conversion activity, an ETH relay and an exchange-labelled destination. The 15.579996 ETH endpoint figure is rounded. The report does not itemise each swap’s ETH output, so the full conversion-to-deposit attribution remains a partial path, rather than an exact per-token reconciliation.Flow address key: A = 0x01664e199991b2f3fe412c2de5b9b7a0dcdc5070; B = 0x62907e044ffe22a24aa8794ff2a6ea20598227bb; C = 0x80787af194c33b74a811f5e5c549316269d7ee1a (HitBTC label as returned).The distinction matters. The two ETH transfers are recorded movements. The interpretation that the 15.58 ETH combined the four swap proceeds with a small pre-existing gas balance is the report’s assessment. It does not support treating every wei of that transfer as independently reconciled proceeds of the incident.What the destination does, and does not, establishThe report describes the relay as a single-use pass-through within the inspected ETH record. Its onward transfer gives investigators a concrete transaction to present to the service associated with the destination label. It does not reveal a customer account, establish the wallet type, or demonstrate a fiat withdrawal.The destination label is therefore a route for further inquiry, not an allegation that HitBTC participated in the incident. The report’s recommended next step is preservation and lawful review of any relevant credited-account, access and onward-withdrawal records. Whether funds remain available, whether the label maps to a particular account and whether recovery is possible require information beyond this public transfer trail.The reported bridge mechanism remains a separate questionSentinelTX cites third-party reporting of a negative-fee input-validation issue in WAX’s eth.token withdrawal mechanism. In that reported model, a negative max_fee could offset the requested quantity while a full withdrawal was still recorded. The report does not include WAX-chain action records that independently establish the mechanism or map individual source-chain withdrawals to these Ethereum payouts.Its narrative also describes a Solana USDC branch. That is context for the reported multi-chain incident, not a basis for treating this Ethereum-focused analysis as a complete cross-chain reconstruction. No value transfer linking the Ethereum and Solana recipients is established in the report, and common control is presented as an inference rather than an on-chain connection.Accordingly, this article does not combine the branches into a loss total, identify an operator, claim that all affected funds have been located, or describe the underlying WAX mechanism as independently confirmed. The report itself leaves onward Solana movement unresolved.The evidence that would strengthen the caseSource-chain linkage: WAX withdrawal actions, quantities, fee arguments and transaction identifiers matched to destination-chain payouts.Conversion reconciliation: executed ETH outputs for each token swap, kept separate from gas funding and residual balances.Destination attribution: confirmation of the exchange-labelled address’s role and any relevant account records obtained through appropriate channels.Earlier infrastructure: the origin of the ETH used to fund the recipient’s initial gas, without assuming that funding alone proves common ownership.Figure 3. The report supports a specific Ethereum transfer trail. Operator identity, source-chain linkage, exact per-swap reconciliation and any completed cash-out remain separate evidentiary questions. Source: SentinelTX CASE-ASYNC3FA, pp. 8–16 and 17–18.Conclusion: a useful endpoint, not the end of the investigationThe clearest result is narrow and actionable: four recorded Ethereum token payouts were followed by conversion activity, a 15.58 ETH relay transfer and an onward transfer displayed as 15.579996 ETH to a HitBTC-labelled address. The amounts, timing and transaction anchors make that trail more useful than a headline loss estimate.The remaining work is to connect that trail to the source-chain actions and, where legally available, the account-level records behind the labelled destination. Keeping those questions separate preserves the difference between following funds and identifying who controlled them.Transaction anchorsUSDT payout: 0x7c6e4bf4efff995981b8b0f7fa1434cc85063e95c0f7460c71277e0a3f9c14d0DAI payout: 0x58960a7afccf78725e8bcfcf7c1f38cac9e08f2a556da81ec7ee1c5023fc79c6WETH payout: 0x9a55cd6c9e9067ac2bf8d33dff233a3e3dd3739c56206444b8a5e79daabb4ff5WBTC payout: 0x6e1553e7d932d8019f59ea6a3bd09c3071b41d538975686cf3f7e785f9e6716015.58 ETH to the relay: 0xd3f4c1c672eb8c3cdbc00216b0215fc72a16bc659a2e48b8a90241b4f165fe80Relay to the HitBTC-labelled address: 0x64c65d0296fbe983c365646eb5bbb788d6cdd21b2bc54c365e296aef26c885acSource note: Adapted from the SentinelTX platform-generated report “Investigation report CASE-ASYNC3FA”, compiled 24 October 2026 UTC. This article is an attributed analysis of that report, not an independently reproduced investigation. Explorer links use transaction hashes cited in the report; they are not proof of address ownership or the broader incident interpretation.

Source: SentinelTX analysis.SentinelTX’s analysis records 726,307.1011248019 BSC-USD paid to the exploit-signing address, followed by a bridge route and Ethereum settlement activity. The reported loss, mechanism, and final ETH balance require different levels of qualification.This ChainBounty review draws on SentinelTX’s analysis of case CASE-20261024-NEM1. Recorded transfers, reported figures, and analytical assessments are distinguished throughout.The recorded proceeds and reported lossThe investigation concerns a BNB Smart Chain token called NEM, identified in the analysis as token contract 0x9cf0e3ad4efa7ab602d7b5a38c55795cfa777777. The name NemTokenV2 comes from press reporting cited by SentinelTX. The analysis establishes no connection to the separate NEM/Symbol blockchain project.Its central finding is a transaction dated October 21, 2026, at 03:28:50 UTC, in BSC block 128,866,147. The signing address, 0xfd929b0f270dfea6c4827262b4e2bf6ea50fe9b6, called an attack contract, 0x5e6d1f40be466dd2facc94a26818948ecd3b1ca2. SentinelTX classifies the resulting payment of 726,307.1011248019 BSC-USD to the signing address as confirmed. The full transaction hash and address register appear in the appendix.The widely reported loss of approximately US$821,920 is a separate source claim. It is not interchangeable with the recorded payment of 726,307.1011248019 BSC-USD. SentinelTX does not establish a complete reconciliation between the reported loss and the recorded proceeds, so neither figure should be substituted for the other.The analysis distinguishes the October 21 execution date from the October 22 alert and publication date. Its October 24 ETH balance observation is later still. These dates describe different events, not competing dates for one transaction.From preparation to the Ethereum exitAll transaction times below are UTC on October 21, 2026, as stated in the source analysis.01:00:17: The address described as the funder sent the signing address its first recorded gas funding, 0.007 BNB. The analysis flags this amount as unverified and requiring corroboration.01:28:16–03:27:26: Sixteen NEM transfers from the funder supplied approximately 767,818.31 NEM, also an unverified amount. A second gas top-up is recorded as 0.01 BNB. Six helper-creation records span 01:32:22–03:14:31.03:28:30: The signing address transferred 767,811.3061168424 NEM to the attack contract. The transfer is recorded, but its quantity is explicitly unverified.03:28:50: The exploit transaction executed. The analysis reports 1,608 receipt logs and approximately 473 million BSC-USD in transaction-level movement across several counterparties. That gross movement is not presented as the loss or the attacker's proceeds.03:38:38: The recorded 726,307.1011248019 BSC-USD payment was forwarded through a router labeled Socket OpenRouter. SentinelTX correlates a Relay bridge record to this source transaction.03:39:11: A sender labeled Relay.link delivered 725,384.763364 USDT to the same address on Ethereum. The analysis classifies the route as confirmed through the correlated bridge record and destination transfer, while marking the destination amount unverified.03:46:11–03:47:47: Three USDT legs went to a contract labeled CoW Protocol settlement. Their quantities are unverified.The analysis’s later balance read is dated October 24. It records approximately 296.19 ETH remaining at the signing address on Ethereum, with no outbound ETH in the retrieved ledger. This is an unverified historical balance observation, not a claim about the address's live balance when this article is read.The assessed mechanism: a skim-and-burn loopSentinelTX assesses the incident as a token-accounting and liquidity-pool reserve manipulation exploit. Its proposed sequence depends on reporting that transfers into the pair count as sell volume, while a function named flushLpSellRecycle() burns NEM held by the pair. Repeated skim() calls are reported to return the operator's tokens as the pool's NEM holdings shrink, before the retained inventory is sold against the altered pool state.That sequence is an assessment in the analysis. The token's source code and the individual burn, reserve, and skim-related events were not decoded there. The proposed sequence is therefore not an event-by-event proof of the vulnerability.The reported count of 42 cycles has a limited technical anchor: the transaction's calldata ends with 0x2a, or decimal 42. Without ABI decoding, that word does not by itself prove what the parameter controls or how many cycles executed. Likewise, 1,608 logs show extensive transaction activity in the analysis, but an unclassified log count cannot independently establish 42 repetitions of a particular mechanism.Flash-borrowed liquidity is another inference. SentinelTX describes large, same-transaction BSC-USD round trips involving Venus vUSDT, PancakeSwap, and two unlabeled contracts. It did not decode loan origination and repayment events. The analysis assigns the direct loss to the affected pair's liquidity providers, but does not provide a reconciled reserve-loss calculation matching the reported US$821,920.Diagram 1. Read the numbered rows from top to bottom, and each row from left to right. The analysis assesses a skim-and-burn reserve-desynchronization loop: transfers into the LP register pending sell volume, flushLpSellRecycle() burns NEM held by the pair, skim() returns the operator’s tokens, and repeated rounds precede a final inventory sale. This is a reported mechanism, not an event-by-event decoded proof. The reported 42-cycle count is only partially corroborated by the raw calldata word 0x2a, not ABI-decoded; no exact loop count is encoded in this schematic. Equal-width dashed arrows summarize the reported sequence, not token quantities.Slate labels identify the stated actions; arrows indicate the relationships written in each row, not quantities.NEM token: 0x9cf0e3ad4efa7ab602d7b5a38c55795cfa777777. LP/pair: 0x840e19dcca541ee0b55a3c67e900a39d523b12b8; its victim-pool role is a source claim consistent with the analysis’s records. Attack contract: 0x5e6d1f40be466dd2facc94a26818948ecd3b1ca2. Signer/proceeds recipient: 0xfd929b0f270dfea6c4827262b4e2bf6ea50fe9b6; operator identity is not established.Source: SentinelTX analysis. Source location: Transaction Typology → Mechanism: observed, inferred and claimed; Scheme description (assessment).Funding supports a relationship, not an identityThe funder, 0x96cb6bec56e43b2f16c05e1af4776fbc7b9713b5, supplied the initial gas and the NEM inventory later committed to the attack contract. Its first-seen date is October 20 in the analysis. The repeated funding, inventory transfers, and timing support SentinelTX's assessment that the two addresses were operated by the same actor or closely coordinated actors. Common ownership is not proven, and no person or organization is identified as the operator.Six helper contracts reportedly returned their NEM balances short by exactly 1 NEM each. SentinelTX interprets the similar interactions as rehearsal against mainnet conditions, an operational assessment rather than a separate finding of intent. Six listed WBNB recipients are classified as probable helpers; their mapping to the six creation records is not established.The inventory has another upstream lead. An unlabeled contract, 0xaee6b842f94281653dde98da97debd93007de2a1, reportedly sent the funder 780,757.29 NEM across 45 transfers. In itemized examples, NEM arrived with BSC-USD and the same BSC-USD quantity was returned shortly afterward. SentinelTX suggests a reward, staking, or distribution mechanism as a possible explanation, but the contract's function was not decoded.The contract’s ownership and any additional loss remain unproven. Shared first-seen dates with the token and pair do not establish ownership. The analysis also records a post-exploit sale by the funder through a TransitSwapRouterV5-labeled route, but its relationship to any additional loss remains unresolved.Following the exit without overstating the endpointThe analysis traces a BSC stablecoin payment into the router, a correlated Relay delivery on Ethereum, and three transfers to CoW Protocol settlement: 250,000.0 USDT, 250,000.0 USDT, and 225,384.763364 USDT. Each Ethereum quantity carries the source's unverified-amount qualification.SentinelTX attributes the difference between the routed and delivered quantities to bridge fees and spread. That remains an assessment: the amounts are in different token denominations, the destination quantity is unverified, and no itemized fee accounting is provided.The Ethereum native ledger is reported as four inbound transfers totaling 296.192678708450769578 ETH, no outbound ETH, and 0.000205413793461084 ETH used for gas. Its resulting balance is 296.192473294657308494 ETH. All of these ETH figures are unverified. The counterparties and hashes of the four incoming ETH transfers are not itemized in the analysis, so the article cannot supply a complete leg-by-leg conversion reconstruction.The recorded endpoint is an address holding native ETH. It is not evidence of fiat cash-out. The WBNB contract's Binance-related label does not make it a Binance customer deposit address, and the CoW settlement contract is described as a non-custodial venue. No custodial exchange deposit is established by the analysis.The BSC exit also contains an EIP-7702 authorization that delegates execution to another address. SentinelTX records that field but treats its batching interpretation as an assessment. Delegation on Ethereum is not established. These technical roles do not identify a beneficial owner.Diagram 2. Read the numbered rows as the reported route, not three independent totals. The analysis records 726,307.1011248019 BSC-USD from the attack contract to Recipient A and the same quantity forwarded through the Socket router on October 21. A correlated Relay record reports delivery of 725,384.763364 USDT to the same address on Ethereum; that destination quantity is unverified. Three CoW settlement legs follow. The October 24 balance read reports 296.192473 ETH, while the analysis’s ledger calculation gives 296.192473294657308494 ETH; both are unverified. Display values are approximate. The four inbound ETH counterparties are not itemized, so the final arrow summarizes the analysis’s conversion sequence and later balance, not a fully reconstructed transfer leg. Equal-width arrows are schematic; the BSC-USD, USDT and ETH values are not summed or treated as interchangeable loss amounts.Slate: 1 · BSC collection and router exit; Sage: 2 · Relay delivery and CoW swaps; Amber: 3 · Later Ethereum balance read. Equal-width arrows show stated routes, not quantities.Recipient A on both chains: 0xfd929b0f270dfea6c4827262b4e2bf6ea50fe9b6. BSC attack contract: 0x5e6d1f40be466dd2facc94a26818948ecd3b1ca2. Socket router: 0x50cfe7c1938db66a1a6d2e86d36f39fbef3d5c4a; the analysis’s literal attribution includes “Socket OpenRouter (Ethereum)” despite the BSC transaction. Relay-labeled Ethereum sender: 0xb92fe925dc43a0ecde6c8b1a2709c170ec4fff4f. CoW settlement recipient: 0x9008d19f58aabd9ed0d60971565aa8510560ab41. No operator identity or custodial exchange deposit is established.Source: SentinelTX analysis. Source location: Executive Summary → Exit; Transaction Chronology → Fund-flow sequence and Gross versus forwarded amounts; Exchange-deposit and venue legs.Why the look-alike transfers were excludedThe original source distinguishes real funding from records it classifies as suspected address poisoning. At 01:07:18, a look-alike of the funder sent 0.007 units of a token whose symbol imitated BNB using non-Latin characters. Its amount mirrored the real gas funding, but the analysis found no value-bearing onward movement and excluded it.A mirror-image record named a look-alike of the signing address. The two full addresses are distinct, and the mirror-image record’s transaction hash is not provided. Neither poisoning record is used as evidence of common control or an economic connection.The analysis also excludes unsolicited airdrops as spam, including two tokens recorded with a burn-address emitter and other tokens with miscellaneous names. An appearance in a transaction history is not enough, within the source's own methodology, to include a transfer in the traced proceeds.Recovery implications and analytical limitsSentinelTX's practical priority is the last recorded Ethereum holding and any later onward transfer. The analysis describes potential investigative leads in the funder's upstream financing and in request metadata that infrastructure operators might hold. The availability of that metadata and any resulting recovery action are not established.The source rates near-term recovery prospects as moderate, but that is its expert assessment, conditional on an unverified balance observation. It is not a recovery probability, an assurance that funds remain available, or a promise that a service provider can freeze native ETH. The analysis’s legal-process and negotiated-return suggestions require case-specific decisions by the affected parties and their qualified advisers; they are not legal instructions from ChainBounty.Important analytical limits remain: the mechanism has not been decoded cycle by cycle, flash liquidity is inferred, the funder's earlier history is not itemized, two in-transaction counterparties lack an onward trace, and the four ETH receipts lack individual detail. The reported loss remains unreconciled with the recorded proceeds. The analysis does not specify its complete query windows; its conclusions are limited to the records discussed. No personal identity, custodial deposit, or connection to NEM/Symbol is established.Figure 3. The analysis supports a reported route from BSC proceeds through Relay to Ethereum and CoW settlement, subject to its quantity and balance qualifications. Approximately US$821,920 is a publicly reported loss claim; 726,307.1011248019 BSC-USD is the analysis’s recorded proceeds payment. These differently denominated figures are not directly interchangeable, and the source does not reconcile the loss gap. The mechanism is not decoded cycle by cycle; no personal or organizational identity, custodial exchange deposit, fiat cash-out, or connection to the unrelated NEM/Symbol project is established. The October 24 balance observation of 296.192473 ETH remains unverified and is not a statement of a live current balance. Rounded display values are approximate.Slate identifies section headings, not certainty or risk.The balance observation and Recipient A role refer to 0xfd929b0f270dfea6c4827262b4e2bf6ea50fe9b6 on Ethereum, not the separate poisoning look-alike identified in the analysis.Source: SentinelTX analysis. Source location: Key findings and certainty; Transaction Chronology → Coverage against the claim and Cash-out endpoint; Transaction Typology; source limitations.Sources and scopeThe transaction findings, address roles, and analytical assessments in this review are attributed to SentinelTX’s analysis of case CASE-20261024-NEM1. The appendix preserves its full address and transaction references. It should be read as a source register, not as independent verification of the underlying blockchain records.The press context in SentinelTX’s analysis comes from search-result snippets attributed to TokenPost, DEV Community, KuCoin, PANews, TechFlow, and CryptoBriefing. These are attributed reporting references, not claims that the complete pages or underlying SlowMist posts were reviewed for this article.Amounts described as unverified require corroboration. Service labels identify the roles assigned to addresses in the analysis; they do not establish ownership or custody. The mechanism and recovery assessments retain their stated qualifications, and the October 24 balance observation must not be treated as a live balance.Appendix: full identifiersThe following register lists 31 full addresses and 21 full transaction hashes cited in SentinelTX’s analysis. It is not a complete transaction ledger. Address roles and service labels do not establish operator identity.Full addresses1. 0xfd929b0f270dfea6c4827262b4e2bf6ea50fe9b6 Exploit transaction signer and proceeds recipient on BSC; same address receives the reported Ethereum delivery. The analysis records BSC delegated code. Operator identity is not established.2. 0x5e6d1f40be466dd2facc94a26818948ecd3b1ca2 Attack contract on BSC and payer of the recorded 726,307.1011248019 BSC-USD proceeds.3. 0x9cf0e3ad4efa7ab602d7b5a38c55795cfa777777 NEM token contract on BSC. NemTokenV2 is a press-source name, not independently verified here.4. 0x840e19dcca541ee0b55a3c67e900a39d523b12b8 Contract identified by press as the USDT/NEM pair on PancakeSwap. The analysis considers its victim-pool role consistent with the recorded transfers.5. 0x96cb6bec56e43b2f16c05e1af4776fbc7b9713b5 Funder on BSC: recorded source of the signing address’s first gas and NEM inventory. No operator identity established.6. 0xaee6b842f94281653dde98da97debd93007de2a1 Unlabeled BSC contract recorded as the funder’s NEM source. Its function is not decoded; a project-side mechanism is only an assessment.7. 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b EIP-7702 delegate named in the authorization list of the BSC exit transaction. No label; type not classified in the analysis.8. 0x50cfe7c1938db66a1a6d2e86d36f39fbef3d5c4a BSC bridge-exit router identified as Socket OpenRouter in SentinelTX’s analysis. This entry concerns the recorded BSC transaction.9. 0xb92fe925dc43a0ecde6c8b1a2709c170ec4fff4f Sender of the reported Ethereum USDT delivery. Exact source label: “Relay.link.”10. 0x9008d19f58aabd9ed0d60971565aa8510560ab41 Recipient of the three Ethereum USDT legs. Exact label: “CowProtocol, Exchange.” Described by the analysis as a non-custodial settlement contract.11. 0x07964f135f276412b3182a3b2407b8dd45000000 Route used for the funder’s post-exploit NEM sale on BSC. Exact label: “TransitSwapRouterV5.”12. 0xfd5840cd36d94d7229439859c0112a4185bc0255 BSC in-transaction BSC-USD counterparty. Exact label: “Venus USDT, vUSDT, DEX.”13. 0x238a358808379702088667322f80ac48bad5e6c4 BSC in-transaction BSC-USD counterparty. Exact label: “PancakeSwap.”14. 0x92b7807bf19b7dddf89b706143896d05228f3121 Unlabeled in-transaction BSC-USD counterparty on BSC; onward movement not established.15. 0x4f31fa980a675570939b737ebdde0471a4be40eb Unlabeled in-transaction BSC-USD counterparty on BSC; onward movement not established.16. 0x370a7e2d300c14d79d4a7ee07aaca46c4b3012cf Listed with the following address under submitter and target of the Ethereum delivery transaction. The roles and attribution are unverified.17. 0xccc88a9d1b4ed6b0eaba998850414b24f1c315be Listed with the preceding address under submitter and target of the Ethereum delivery transaction. The analysis does not separately verify the mapping or attribution.18. 0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c WBNB contract on BSC. Exact label: “Binance, WBNB Token, Token Contract.” Not a Binance customer deposit address in the analysis’s account.19. 0x2db7fca7a84a4ae69d41aec8d74b96b679c8ac5e First of six listed WBNB recipients on BSC, classified as probable helpers. Their mapping to helper-creation records #1–#6 is unresolved. The reported 0.0001 WBNB quantity is unverified.20. 0xbae2628c3f926971d4fc66c16120b2c7e0dce42a Second listed WBNB recipient on BSC; probable helper, with creation-record mapping unresolved.21. 0x0c3dac1d3b6f870b5bca16b7926631b525216865 Third listed WBNB recipient on BSC; probable helper, with creation-record mapping unresolved.22. 0xe1a9d2ecfb453be4608c126ef95ee71faec7f9cc Fourth listed WBNB recipient on BSC; probable helper, with creation-record mapping unresolved.23. 0x07d792806989300cd3b5d05329fea154a32ad96b Fifth listed WBNB recipient on BSC; probable helper, with creation-record mapping unresolved.24. 0xa16f9a316a2b9ef97994cd47991b72ecbebfd7db Sixth listed WBNB recipient on BSC; probable helper, with creation-record mapping unresolved.25. 0x50c4e75a512f2a14a7b304787adf79c4531a5909 Unlabeled code-bearing recipient of the residual BNB route at 03:40:52 UTC on BSC. The source does not provide that transaction’s hash.26. 0x97caca78ac2a94c67643d07843f85afaa44a3ea5 Unlabeled BSC-USD source to the funder and address appearing in residual-route calldata. The source explicitly treats a swap-route executor role as an unverified lead, not established funding attribution.27. 0x96cb0a81cd849f21e512f5d6eda78bdf1c0713b5 Look-alike of the funder, excluded as suspected address poisoning. Distinct from the real gas-funding address.28. 0xfd92b74d57b02814ea2591bd963d1fae390fe9b6 Look-alike of the exploit signer/proceeds recipient, excluded as suspected poisoning. It is distinct from the address receiving the recorded proceeds.29. 0x058941553ea64444077522d6b5edc2e09655ef66 Token contract used by the suspected poisoning record; symbol imitates BNB using non-Latin characters. Not native BNB.30. 0x5c718fc9c1bc1ca6d55b3c9c564153d98faff2d0 Unsolicited token identified among excluded spam records with a burn-address emitter.31. 0x1303753839659cd4ca526a9c2e7091cc68be26ab Second unsolicited token identified among excluded spam records with a burn-address emitter.Full transaction hashesTimes below refer to October 21, 2026, UTC. Transaction references and classifications are attributed to SentinelTX.1. 0x57b1847f6f2cf3d1676f6ba38064c0756d1fbec9b502c5dc662e35a2307fb0dd BSC. First gas funding, October 21 at 01:00:17 UTC; 0.007 BNB, unverified amount.2. 0xe9827bcce1262daf9a6026afdce9a4d51bf7e28dcd7d3ba767c9684fc8523468 BSC. Second gas top-up, stated as 0.01 BNB. The analysis places it in the preparation interval but does not give an exact time.3. 0xcbcdc77b393a30bf3212f80a8afdc334af642dc9615d47582cc5302f739da924 BSC. Anchor cited for NEM inventory funding. The analysis does not itemize all sixteen NEM transfer hashes.4. 0x54842ae0334a6b4bd2b24fbbe0251ea2c302f2ab253f87f2340b7462a7d8a4cb BSC. NEM transfer into the attack contract at 03:28:30 UTC; 767,811.3061168424 NEM, unverified amount.5. 0xfb093c96c0094cbcca10801f97ed2e5ed3d96550ce64b544df5a349545723f91 BSC. Exploit transaction, block 128,866,147, 03:28:50 UTC. SentinelTX classifies the payment of 726,307.1011248019 BSC-USD to the signer as confirmed.6. 0x4da49613a58f3d872c5991c0b7fc1a3d4ebb6b2b3c55fab768c490e57b104a68 BSC. Router exit, block 128,867,454, 03:38:38 UTC; source hash used to correlate the Relay bridge record. SentinelTX records EIP-7702 type-4 execution.7. 0xc4acd18a0e8f4b4f24b47ce6e57a7c936b148108327236125daac250d07bc8bb Ethereum. Reported bridge delivery, block 26,238,334, 03:39:11 UTC; 725,384.763364 USDT, unverified amount.8. 0xfc7fc1af22358f55ea4f3847efb7a70514e81b4d0d8c5da392c7874609ab2533 Ethereum. First CoW settlement leg, 03:46:11 UTC; 250,000.0 USDT, unverified amount.9. 0x0757d2285bd862798c3b52181e919e8853d6037e8096e4fdf7456a7e3269ab0d Ethereum. Second CoW settlement leg, 03:47:11 UTC; 250,000.0 USDT, unverified amount.10. 0xbcef08a442ca7bba882c43ebf61fbc6fc285a70d7d207238bbea797b17817cfb Ethereum. Third CoW settlement leg, 03:47:47 UTC; 225,384.763364 USDT, unverified amount.11. 0xf66fa8c86299c9de6798556d42966fb9fa8c6b47b0d1eb8080344685af3668fa BSC. Funder’s post-exploit NEM sale, 03:37:01 UTC, through the TransitSwapRouterV5-labeled route.12. 0x38739784a8b13de37666e5770de7d2603a92ee50f233789b97ddd7c468300ed2 BSC. Example inbound cycle to the funder, 03:26:19 UTC, including 12,571.42 BSC-USD and NEM, as stated in the analysis.13. 0x57a6519c13ad203c479d3166fea6ddefc46ad994d14e665c939778ab12f97d57 BSC. Example corresponding BSC-USD return, 03:26:45 UTC.14. 0xce77892c0e98a893f0b109d0f905c9423337addec5142edaf75be07eb3a73f53 BSC. WBNB transfer to probable helper 0x2db7fca7a84a4ae69d41aec8d74b96b679c8ac5e.15. 0x645edaec509f12f493ca15a42e793fc731dfc0610da85b7a1ee59dd7c609f0d7 BSC. WBNB transfer to probable helper 0xbae2628c3f926971d4fc66c16120b2c7e0dce42a.16. 0x0e714d980478f9f636eae18d81ec5399e66eeee6926c113e886b243818e553df BSC. WBNB transfer to probable helper 0x0c3dac1d3b6f870b5bca16b7926631b525216865.17. 0xec0de15f90e82015087eae522d2771de1ee8ac192cd91b8a851fa802079d34c6 BSC. WBNB transfer to probable helper 0xe1a9d2ecfb453be4608c126ef95ee71faec7f9cc.18. 0xa3b2e00ade40364427fbcc08803fe9fa3c7de8aac45dcd92986e140890150ea9 BSC. WBNB transfer to probable helper 0x07d792806989300cd3b5d05329fea154a32ad96b.19. 0xfb5384ed31469f13842a77a05ca0511402b7bad0d8af5f858de5acb9155e7124 BSC. WBNB transfer to probable helper 0xa16f9a316a2b9ef97994cd47991b72ecbebfd7db.20. 0xcf4469e6214a085023251542c924fc468be8856a144075ddaf47360fcc8792e3 BSC. WBNB transfer to attack contract 0x5e6d1f40be466dd2facc94a26818948ecd3b1ca2.21. 0x2b407b29b19baf491bfbcdd2a2e9c67f939e17bae22ffff6bd8f6287646326f8 BSC. Suspected address-poisoning record at 01:07:18 UTC. Excluded from economic tracing and attribution.Other explicit identifiersCase reference: CASE-20261024-NEM1.Chains: BNB Smart Chain, chain ID 56; Ethereum, chain ID 1.Exploit calldata selector: 0x05d546ef. Final raw word: 0x2a, decimal 42. No ABI-decoded meaning is established.BSC exit observed byte pattern: 0x095ea7b3, described in the source as an approve pattern; inner router call not ABI-decoded.Control-call selector: 0xe9ae5c53. Ethereum delegated-code status is not established.BSC authorization nonce: 0x32. BSC transaction nonce: 0x31.Reported route text: "Source":"BUNGEE_AUTO", "AmountInUSD":"6.781519". This describes the residual BNB route, not an added valuation of the main proceeds.Helper-creation record identifiers: #1–#6; source block range 128,850,621–128,864,238. Full creation hashes are absent from the original narrative.Ethereum first control-transaction block: 26,238,366; nonce 0. Its hash is not supplied.Residual BNB transaction block: 128,867,751, at 03:40:52 UTC. Its hash is not supplied.Coverage of the identifier registerThe full set of sixteen inventory-funding transaction hashes is not enumerated.The full set of 45 inbound NEM transfer hashes for the upstream contract is not enumerated.The four inbound ETH receipt hashes and counterparties are not itemized.The helper creation transaction hashes are not itemized.The WBNB wrap transaction hash at 01:31:59 UTC is not provided.The mirror-image poisoning transaction hash, burn-emitter address, and remaining spam-token identifiers are not supplied in full.The full residual BNB route transaction hash and all control-transaction hashes are not provided.These omissions limit reconstruction of the individual movements and the helper-creation mapping. The register does not infer missing identifiers.

A large USDT transfer drew attention to CoinDCX-linked deposit addresses in October 2026. CoinDCX later described a failure in the process used to collect deposits from retired addresses. The chain can help test the transfer sequence. It cannot show the exchange’s internal customer credits or diagnose its collection software.This review follows one large-source address into a receiving address, then its six first-hop recipients and three selected onward transfers. Before following those departures, it reads a small deposit-and-collection sequence from the same day. Address names below describe observed roles, not proven people or organizations.The verified route is large-source address → receiving address → six first-hop recipients, with only three onward transfers examined in detail. The operational question is separate: a sampled deposit address still made a collection transfer on 21 October. This does not identify when another address, or the wider system, stopped collecting deposits.What the address names meanUSDT is a token intended to track the US dollar. This review follows the canonical TRON USDT contract, rather than trusting a token’s ticker alone. TRX is TRON’s native coin, used to pay transaction costs. A sweep is a transfer that collects deposits into another address. A transfer can fit that pattern without proving which software or person submitted it.A Transfer event is a record emitted by the token contract when tokens move. A solidified receipt is the network record of an executed transaction after it has become final. Matching these records checks the asset movement; it does not identify the person behind an address.Role used hereFull TRON addressLarge sourceTQKJQrWok6fsBqZi3mkLkL6qX4YEgjqWUyReceiving address / collectorTAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTSampled deposit addressTMRgWCMJ5CL82GypJMDrGemUs5r1zh51k1Fee-source addressTFLxNHunhEizmeEdiMyA3r2XGLSKaEznGdCollection-pattern destinationTU7BbAsb8t371eMijQeiGXsiLvY1vZbsFsBranch ATMJMTCvtPgMRQmLBYUTmdwfEozoveccUjqBranch BTFaHkHcMGWLnnBCaGVpHBHufb1DNNHbadhBranch CTUNxeav4BWVoFGGaE97ygHkKYdKLJTHkbUCoinDCX’s 22 October follow-up names the TQKJQ wallet and says deprecated, previously compromised deposit addresses remained exposed to user deposits. It attributes operational losses to a sweep failure and says affected users were credited. These remain company statements, not findings from customer-account records.Scope before the numbersMeasureCoverageIncident records21–22 October 2026; earlier source history used only as contextEvidence cutoff23 October 2026 06:30:00 UTC; not a live balance assessmentDirect execution checks27 USDT Transfer logs in solidified receipts, plus 2 native TRX transactionsIndexed contextSix address/time-bounded canonical-USDT histories, plus one sampled deposit-day history. History rows are not all separately receipt-verified.DepthSix first-hop recipients; three selected second-hop transfers. No complete downstream reconstruction.Before the incident: collection was observable, but a failure interval is not4 May: a large-source deposit moved onward in 39 secondsThe large source received 300,000 USDT at 05:39:57 UTC on 4 May. At 05:40:36, it transferred the same amount to the collection-pattern destination. Both records have successful, solidified token-transfer logs. The 39-second interval shows a quick collection-like pair; it does not reveal the program that handled it. Deposit · Onward transfer.The bounded history contains 183 canonical-USDT transfer entries for this address from 1 January through the cutoff. Its last indexed departure before 21 October is at 05:45:33 UTC on 4 May. No further entry appears before the October departure in that returned range. This is an observed gap in one token’s transfer history. It is not a dated outage log, proof of a software failure since May, or proof that every deposited unit had remained untouched.21 October: a different address still made a collection transferAt 12:13:45 UTC, the sampled deposit address received 9.67 USDT. Twelve seconds later it received 15 TRX from the fee-source address. At 12:14:06 it sent 9.67 USDT to the same collection-pattern destination used in the May pair. The token deposit and onward movement are 21 seconds apart; the TRX transfer precedes the onward movement by 9 seconds. The fee transfer supplies a separate asset and must not be added to the USDT amount. Deposit · 15TRX · Collection transfer.Read Figure 1 from its first timestamp downward. Its arrows show chronological order, not tokens passing through every box. The blue-gray panels are observed records; the beige panel separates funding of the receiving address from the sampled collection pair.Figure 1. A chronology of the sampled address and fee-source records. All times are UTC; spacing is schematic. The 168.63 USDT departure is not the earlier 9.67 USDT deposit being counted again.The important observation is coexistence: a collection-like transfer occurred that day, before later departures to the receiving address. At 12:19:33, the fee-source address sent 100 TRX to that receiving address. At 15:15:21, the sampled deposit address sent 168.63 USDT there. The sequence does not prove that the same operator made all these transactions. The earlier funding of the 168.63 USDT is outside this day’s sample, so the two token amounts are not treated as a single deposit.What remains missing is the operating record: which addresses the sweeper was configured to watch, when jobs failed, whether retries were attempted, and how deposits were credited. An absence of later USDT transfers at one address cannot supply those answers. The company’s statement does not give exact outage start and end timestamps.21 October 15:35:54 UTC: the large transfer reaches the collectorAt 15:35:54, the large source sent 15,819,002 USDT to the receiving address in block 87307956. The token’s Transfer event matches both full addresses and the raw amount 15819002000000. With 6 decimal places this is 15,819,002 USDT. The separate 6.7735 TRX transaction fee does not reduce the token-transfer quantity. Large-source transaction.This establishes delivery of the tokens. It does not establish who controlled either key, whether the transfer was authorized, or what proportion of customers’ balances it represented. The receiving address also has other USDT inflows in the queried range. Its later departures must therefore be read as movements out of a shared token pool, not as uniquely identifiable units from this one deposit.From 17:05 UTC: the collector distributes USDT to six addressesThe first verified outgoing transfer in this window was 10 USDT at 17:05:27 to the address used here as Branch A. A 2,000,000 USDT transfer followed to that same address at 17:07:18. This ordering can be consistent with testing before a larger transfer, but intent is not recorded. Other branches followed later that evening and overnight.All 18 outgoing USDT entries returned for the collector in this window were checked against solidified Transfer logs. They total 15,991,414.313412 USDT across six distinct recipients. That is the collector’s observed outgoing volume, not an independently established incident-loss total. Its 64-entry indexed history also contains 46 incoming entries. Their relationship to the incident has not been individually established. Small receipts remain in the context data rather than being automatically assigned to the incident. Full addresses, not shared prefixes or suffixes, define each counterparty.Start Figure 2 at the receiving address and follow each solid arrow into a recipient panel. Each panel aggregates only collector-to-recipient transfers, without adding any later forwarding as new loss. Colors separate panels rather than claiming different levels of guilt or ownership.Figure 2. Observed first-hop USDT transfers through 23 October 06:30 UTC. Solid arrows show verified token direction; line width and spacing are schematic. No exchange identity, cash-out, or common control is asserted.First-hop recipientVerified collector departuresTMJMTCvtPgMRQmLBYUTmdwfEozoveccUjq7,135,881.313412 USDT in 4 transfersTFaHkHcMGWLnnBCaGVpHBHufb1DNNHbadh4,000,000 USDT in 2 transfersTUNxeav4BWVoFGGaE97ygHkKYdKLJTHkbU3,000,000 USDT in 1 transferTB3U9KPtffSxrNqjvKz3AMYcaT1UWh3Grq1,013,312 USDT in 5 transfersTHkMta6QMbbxNqiX9MifqGjRoDc5xyiYyA822,221 USDT in 5 transfersTVK3dRqe9Aqfcdxvp9fWScAMdGmDBHyG6L20,000 USDT in 1 transferThe diagram shows distribution, not a final destination. Three selected onward records extend the review by one more step. Branch A sent 100,000 USDT to a further address at 17:16:39 on 21 October (record); Branch C sent 1,000,000 USDT at 19:46:15 (record); Branch B sent 1,000,000 USDT at 05:52:27 on 22 October (record). These are selected continuations, not the complete onward history. Their recipients are preserved in the appendix without service labels because independent evidence for such labels was not established here.Once value is pooled with other inflows, a matching amount or a later transfer alone does not earmark particular units from the large-source deposit. A service label, if later confirmed, would identify an investigative contact point—not a person, a completed sale, or recoverable funds.23–24 October: a reported freeze and a narrower state checkAMLBot reported on 23 October that Tether had frozen about $2.2 million linked to this incident. That is AMLBot’s attributed estimate, not a frozen-value total reproduced by this review. A blacklist restricts a token’s use at an address; it is not evidence that funds have been returned to customers.A separate read-only query of the canonical USDT contract shortly after 23:33 UTC on 23 October checked two addresses already in this report. The function isBlackListed(address) returns whether an address is currently on that token’s blacklist. It returned true for the collector’s 20,000-USDT first-hop recipient and false for the selected Branch C onward recipient. These are latest-state responses, not measurements pinned to a historical block or a verification of the blacklist transaction, its timing, or a frozen balance.Existing TRON addressUSDT blacklist response at the follow-up readTVK3dRqe9Aqfcdxvp9fWScAMdGmDBHyG6Ltrue; the 20,000-USDT first-hop recipientTTb34rZMrTi3gHNKeFLg1qaaTqXsdyG48vfalse; selected Branch C onward recipientThe two responses do not reproduce AMLBot’s wider address set or estimated total. A false response also does not mean an address is safe or that every asset is unrestricted. Figure 2 remains a historical transfer map through its stated cutoff, not a map of current restrictions. The sweep failure’s exact interval and cause, ownership, customer credits, and the complete net loss remain unresolved.What the records support, and what they leave openThe narrow result is stronger than a transaction alert but smaller than a full incident reconstruction: a large source-to-collector transfer is verified, the collector’s six first-hop recipients are reconciled, and three further transfers are anchored. A separate deposit sample shows a collection-like transfer on the incident day. None of these records diagnoses the sweep failure described by CoinDCX.QuestionEvidence boundaryWas there a transfer?Yes: canonical token logs and solidified execution receipts match the selected full identifiers.Was the entire sweep system stopped?Not established. A sampled collection transfer occurred on 21 October; address-specific configuration and job logs were not available.Was this a newly compromised active wallet?Not established. Company attribution to deprecated, previously compromised addresses is kept separate from the transfer facts.What was the total loss?Not determined here. Collector volume includes other receipts and cannot replace full incident/net-loss reconciliation.Were users credited or funds recovered?CoinDCX says affected users were credited. Internal credits, recovery transfers and full customer allocation were not independently checked.Who operated the recipients?Unknown. No identity or completed cash-out conclusion follows from these selected records.Where a response can be specificFor the operator, the relevant review is address lifecycle management: compare the retired-address list with the actual watch list, fee-funding rules and collection-job failures. The 12:13–12:14 sample is a useful timestamped control point for that comparison, not proof that every address was functioning. For affected deposit reconciliation, each customer’s original transaction must be matched with the exchange’s internal credit record.For investigators, preserve the 18 collector departure hashes and request account-level evidence only where a recipient’s service attribution can be independently established. An unlabelled downstream address should remain unlabelled. The next technical step is selective service-endpoint verification, not expanding every address into a supposed attacker cluster.Evidence appendixAll addresses below are on TRON. Address links retain the full string and point to address pages; transaction links retain the complete hash. Block times are UTC. USDT quantities exclude separate TRX fees. This appendix contains the selected 27 receipt-verified USDT transfers and 2 native TRX records, not every indexed context entry.AddressRole and ownership boundaryTFLxNHunhEizmeEdiMyA3r2XGLSKaEznGdFee-source address; observed role only; beneficial owner not verified.TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTReceiving address / collector; observed role only; beneficial owner not verified.TMJMTCvtPgMRQmLBYUTmdwfEozoveccUjqFirst-hop recipient; observed role only; beneficial owner not verified.TFaHkHcMGWLnnBCaGVpHBHufb1DNNHbadhFirst-hop recipient; observed role only; beneficial owner not verified.TUNxeav4BWVoFGGaE97ygHkKYdKLJTHkbUFirst-hop recipient; observed role only; beneficial owner not verified.TB3U9KPtffSxrNqjvKz3AMYcaT1UWh3GrqFirst-hop recipient; observed role only; beneficial owner not verified.THkMta6QMbbxNqiX9MifqGjRoDc5xyiYyAFirst-hop recipient; observed role only; beneficial owner not verified.TVK3dRqe9Aqfcdxvp9fWScAMdGmDBHyG6LFirst-hop recipient; observed role only; beneficial owner not verified.TSC5MzYDNqtp3HDpqCNpTAs5pnT7wt4HrdSelected upstream or onward counterparty; observed role only; beneficial owner not verified.TQKJQrWok6fsBqZi3mkLkL6qX4YEgjqWUyLarge source; observed role only; beneficial owner not verified.TU7BbAsb8t371eMijQeiGXsiLvY1vZbsFsCollection-pattern destination; observed role only; beneficial owner not verified.TMRgWCMJ5CL82GypJMDrGemUs5r1zh51k1Sampled deposit address; observed role only; beneficial owner not verified.TBq7LMgo1CetQxBPGJbrTPnjtC77gsqgZcSelected upstream or onward counterparty; observed role only; beneficial owner not verified.TL8WBPjRHVdYRZ5oZRF8LbmzyFPbp1gPRYSelected upstream or onward counterparty; observed role only; beneficial owner not verified.TTb34rZMrTi3gHNKeFLg1qaaTqXsdyG48vSelected upstream or onward counterparty; observed role only; beneficial owner not verified.TJiGzdgjrSnCxAWYDdaN3CBhfw75vjDBk9Selected upstream or onward counterparty; observed role only; beneficial owner not verified.USDT execution records 1–7UTC / quantity / blockFull identifiers2026-05-04 05:39:57 UTC300,000 USDTBlock 8240168157daab0860df1112194d4dbf32adbfd3bbc1edd54af89a59a5fb3ec0b135ba45From TSC5MzYDNqtp3HDpqCNpTAs5pnT7wt4HrdTo TQKJQrWok6fsBqZi3mkLkL6qX4YEgjqWUyRaw token units: 3000000000002026-05-04 05:40:36 UTC300,000 USDTBlock 82401694d9819837a67c65a4768634f54bc55cb67de825a029047615ccf8af85f9694fc7From TQKJQrWok6fsBqZi3mkLkL6qX4YEgjqWUyTo TU7BbAsb8t371eMijQeiGXsiLvY1vZbsFsRaw token units: 3000000000002026-10-21 12:13:45 UTC9.67 USDTBlock 87303913400a5a0d7aecace98ac34614819b9d66840b52bf3870ef803b5572dd5fb2a30fFrom TJiGzdgjrSnCxAWYDdaN3CBhfw75vjDBk9To TMRgWCMJ5CL82GypJMDrGemUs5r1zh51k1Raw token units: 96700002026-10-21 12:14:06 UTC9.67 USDTBlock 87303920e9a0b6b4c05f7eb70719cd33fde5c84915d30b4b7271b6d6b478b10837dbdb75From TMRgWCMJ5CL82GypJMDrGemUs5r1zh51k1To TU7BbAsb8t371eMijQeiGXsiLvY1vZbsFsRaw token units: 96700002026-10-21 15:15:21 UTC168.63 USDTBlock 873075456833f9329980e375b1c2e437d470307e58891366578d539a463226bfc9c50326From TMRgWCMJ5CL82GypJMDrGemUs5r1zh51k1To TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTRaw token units: 1686300002026-10-21 15:35:54 UTC15,819,002 USDTBlock 873079566c555aa65b2a6f38454ad1a52fc2780d159d6338bef0f79b6c42e8b88b16779bFrom TQKJQrWok6fsBqZi3mkLkL6qX4YEgjqWUyTo TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTRaw token units: 158190020000002026-10-21 17:05:27 UTC10 USDTBlock 87309747b53b51b685f5f81d8048ddd9aafbf5a6be0aec59847e2be9602fcda12113f0beFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TMJMTCvtPgMRQmLBYUTmdwfEozoveccUjqRaw token units: 10000000USDT execution records 8–14UTC / quantity / blockFull identifiers2026-10-21 17:07:18 UTC2,000,000 USDTBlock 873097846b14f26ee642ee63509da738fd4c144c2293962f28aa510618b17a3c4f4fb34fFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TMJMTCvtPgMRQmLBYUTmdwfEozoveccUjqRaw token units: 20000000000002026-10-21 17:16:39 UTC100,000 USDTBlock 87309971a7161f359e33c0af883df044c41d82b1fe5e54e9c29e130e48514f7c36bcce44From TMJMTCvtPgMRQmLBYUTmdwfEozoveccUjqTo TBq7LMgo1CetQxBPGJbrTPnjtC77gsqgZcRaw token units: 1000000000002026-10-21 18:57:54 UTC1,000,000 USDTBlock 87311994e000e895a76f4db4dcdef67b33354e2965a94991d518a8e42b021da1c5d5a9f2From TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TFaHkHcMGWLnnBCaGVpHBHufb1DNNHbadhRaw token units: 10000000000002026-10-21 19:04:54 UTC3,000,000 USDTBlock 8731213451bfc70107a8ebb986e1c2211eca8c74e6a541bfeb5efa53c1ceffcb0ad5dbe1From TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TFaHkHcMGWLnnBCaGVpHBHufb1DNNHbadhRaw token units: 30000000000002026-10-21 19:05:30 UTC3,000,000 USDTBlock 873121461ed5c4b9fb1a6accb3ba42f0058903c3efb46fede062286d8a1127805a00ae1bFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TUNxeav4BWVoFGGaE97ygHkKYdKLJTHkbURaw token units: 30000000000002026-10-21 19:46:15 UTC1,000,000 USDTBlock 87312961ce73a1f9f25de7fa8d215265641ad0da8e63e886e01a8800a9ba06e7329f1783From TUNxeav4BWVoFGGaE97ygHkKYdKLJTHkbUTo TTb34rZMrTi3gHNKeFLg1qaaTqXsdyG48vRaw token units: 10000000000002026-10-22 00:51:54 UTC3,000,000 USDTBlock 873190724c698146c1f789fa270ff97dda75aceeeafa5a8d969872ffd824d500f61c6e29From TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TMJMTCvtPgMRQmLBYUTmdwfEozoveccUjqRaw token units: 3000000000000USDT execution records 15–21UTC / quantity / blockFull identifiers2026-10-22 01:17:30 UTC77,761 USDTBlock 8731958459142c2e93e530ff1d1b02c44bacd32ab21d5d1ed32fa8f3dc72f8e47145b6dfFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TB3U9KPtffSxrNqjvKz3AMYcaT1UWh3GrqRaw token units: 777610000002026-10-22 01:27:45 UTC155,521 USDTBlock 87319789c291280f4b5e7264be49bddbdddfc744d7d5f778da7fdd8a26779eca202f97c1From TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TB3U9KPtffSxrNqjvKz3AMYcaT1UWh3GrqRaw token units: 1555210000002026-10-22 01:43:45 UTC156,006 USDTBlock 8732010971fe854fb614adef3b342d79dbbc62bc8655d45dc378e14b7c81ea12c21f4757From TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TB3U9KPtffSxrNqjvKz3AMYcaT1UWh3GrqRaw token units: 1560060000002026-10-22 01:46:48 UTC76,190 USDTBlock 8732017031bebda0b472c20faef0ef7ee1a92e5c067666f3e40423f79651e1e1137bbcfeFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo THkMta6QMbbxNqiX9MifqGjRoDc5xyiYyARaw token units: 761900000002026-10-22 02:05:48 UTC111,111 USDTBlock 87320550ca3f2e28b425331e155cea10d07685a9395e90f669fe02869aa35d60c5ba139eFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo THkMta6QMbbxNqiX9MifqGjRoDc5xyiYyARaw token units: 1111110000002026-10-22 02:30:54 UTC158,730 USDTBlock 87321052c9429963005227a1dbb701b3f13e28813f871c47cc056ec454076dc0f48dcf6cFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo THkMta6QMbbxNqiX9MifqGjRoDc5xyiYyARaw token units: 1587300000002026-10-22 02:33:15 UTC312,012 USDTBlock 873210996cf9e0125ea448cf2e8502d78ac9b3675b260d4c0d4ecb2924817f7e17fcbe6dFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TB3U9KPtffSxrNqjvKz3AMYcaT1UWh3GrqRaw token units: 312012000000USDT execution records 22–27UTC / quantity / blockFull identifiers2026-10-22 02:41:24 UTC317,460 USDTBlock 87321262d23570456c6afa5bdf5f6e7806eba477b6e1b1c0829144a3761cc92e06a2a64aFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo THkMta6QMbbxNqiX9MifqGjRoDc5xyiYyARaw token units: 3174600000002026-10-22 03:06:36 UTC312,012 USDTBlock 873217666f79a3e8dfc06570296495b11363a6128234897ae9b25ba149f166c4490ca07bFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TB3U9KPtffSxrNqjvKz3AMYcaT1UWh3GrqRaw token units: 3120120000002026-10-22 03:12:24 UTC20,000 USDTBlock 873218821b8f2e07b69ef0a9d5bc9b5fb02310bee84c34dde3bb3ca0cd7c52d14ae8fc5aFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TVK3dRqe9Aqfcdxvp9fWScAMdGmDBHyG6LRaw token units: 200000000002026-10-22 03:20:51 UTC158,730 USDTBlock 8732205113ff3288c75bc63d3c86c52cafed16e61c7e7f0277e239175066e5b16736f05aFrom TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo THkMta6QMbbxNqiX9MifqGjRoDc5xyiYyARaw token units: 1587300000002026-10-22 03:22:03 UTC2,135,871.313412 USDTBlock 87322075845295436b162124dc1a1476bb1535a2ff9b92511e62caebdd8e8d16c83c2030From TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTTo TMJMTCvtPgMRQmLBYUTmdwfEozoveccUjqRaw token units: 21358713134122026-10-22 05:52:27 UTC1,000,000 USDTBlock 8732508303309f46ef625713dbff94755e97269770f28f6eb8e4c004db5b0d525eb38326From TFaHkHcMGWLnnBCaGVpHBHufb1DNNHbadhTo TL8WBPjRHVdYRZ5oZRF8LbmzyFPbp1gPRYRaw token units: 1000000000000Native TRX recordsUTC / quantity / blockFull identifiers2026-10-21 12:13:57 UTC15 TRXBlock 87303917b4dc7b6d4eb313f08ef4f7b8c63a4f43730f327d6e2a0925f78be960b3464d7eFrom TFLxNHunhEizmeEdiMyA3r2XGLSKaEznGdTo TMRgWCMJ5CL82GypJMDrGemUs5r1zh51k12026-10-21 12:19:33 UTC100 TRXBlock 8730402990258d083228e2e57b3e74394ff3dae4d10545db69e4634959a99d1ab9eb91f7From TFLxNHunhEizmeEdiMyA3r2XGLSKaEznGdTo TAg6SZ1HhgVVjUaKY1paQoFBUS2JFrg5bTSource and method registerSourceUse and limitationCoinDCX22October follow-upOfficial explanation and crediting claim; not independently audited operational records.Bitquery incident researchDiscovery source for address leads only. Its broad loss, ownership and service conclusions are not adopted here.TRON history documentationConfirmed canonical-USDT indexed history at explicit address/time/page bounds. Not a historical balance proof.TRON execution-receipt documentationSelected solidified receipts independently matched by token contract, full source/destination, event signature, raw amount and timestamp.TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6tCanonical USDT contract used throughout;6 decimal places.The research uses public TRON records and direct event decoding. No complete exchange-custody audit, key-forensics review or downstream recovery finding is implied.

After Railway disclosed possible exposure of customer secrets on 21 October 2026, researcher Taylor Monahan linked wallet drains to the incident and identified a suspected receiving address. This review follows two Ethereum branches leaving that address: ETH passes through one relay, and USDC through another. Both reach the same address labelled “HitBTC: Hot Wallet 4” by Etherscan.The checked routes are suspected receiving address → separate ETH and USDC relays → one explorer-labelled exchange endpoint, and a smaller, separately matched Ink USDC burn → Ethereum mint to the seed. One earlier Ethereum inflow to the seed is also checked below, without identifying its sender as a confirmed Railway victim. The record supports these transfers more strongly than it supports the cause of every incoming payment. It stops at the labelled endpoint: it does not identify a customer account, prove conversion to cash or establish that all of the seed address's funds came from Railway customers.Before the numbers: the service, the assets and the rolesRailway is a cloud application-hosting service, not the similarly named Railgun privacy protocol. An environment variable is a value supplied to a running application; it can contain a database password, an API token or a wallet private key. Access to such a value and an unauthorized blockchain withdrawal are different observations. Linking them for a particular victim requires both service-side evidence and that victim's transaction history.ETH is Ethereum's native asset and also pays transaction fees. USDC is a token designed to track the US dollar, but this report records token units, not a historical dollar valuation. A relay is simply an intermediate address that receives and later sends funds in the selected route. It is a reading aid, not a claim that the address was created for this incident. That role does not identify its operator. A block explorer is a public interface to blockchain records; its address labels are investigative leads rather than identity certificates.Role used hereObserved functionSuspected receiving addressThe researcher-supplied starting address; sends both first-hop transfers.ETH relayReceives the selected ETH payment and later sends ETH to the endpoint.USDC relayReceives and later sends the same USDC token quantity.Labelled endpointReceives both onward payments; exchange association follows Etherscan only.What this review coversScopeBoundaryChain / selected movement windowEthereum and one matched Ink transaction; selected records span 21 October 2026, 19:36:23 UTC to 22 October, 09:47:35 UTC. This is not the duration of the wider incident.Evidence checkedSeven successful transaction-detail records: one Ethereum inflow to the seed, four Ethereum relay-path transactions, one Ethereum mint and its Ink burn; raw USDC events and the CCTP message/attestation join.Verification date23 October 2026 KST. Historical transaction times in this article are UTC.Observation boundaryHighest selected Ethereum block: 26,247,354; selected Ink block: 59,138,264. Not a fixed historical cutoff or proof of complete coverage through that block.Counting conventionCount each endpoint receipt once; exclude gas from transfer quantities. Do not add the two hops as separate losses. No incident-wide USD loss calculated.Three findings guide the account. First, the ETH and USDC branches converge at the same labelled endpoint. Second, the USDC quantity matches to all six decimal places in both event logs. Third, an Ink burn now matches the separate Ethereum mint through Circle’s message record, but victim-origin attribution remains unverified. The chronology explains what each finding does—and does not—establish.21 October: the disclosure and the wallet allegation are separate sourcesRailway's official disclosure describes possible unauthorized access to encrypted environment variables and some decrypted contents, with the affected subset under review. It supplies cloud-security context, not an independently reconciled cryptocurrency loss ledger. Railway's 21 October disclosure.Monahan's original report identifies the suspected address and describes approximately $371,000 in drains, more than 500 transactions, more than 200 distinct addresses and activity across more than 19 EVM chains. It places the first known theft at 19:36 UTC on 21 October. These are attributed researcher findings, not counts or a valuation reproduced in this bounded Ethereum review. Original researcher report.The seed's explorer label refers back to the researcher. That is not a second independent proof of incident attribution. The original victim withdrawals, their authorization status and the relevant exposed credentials have not been reconciled here. Keeping this distinction visible prevents a verified transfer from silently becoming a verified explanation of why it happened. A narrow follow-up also read Monahan’s reply that she had multiple separate victim reports. The public thread inspected here did not supply a victim-confirmed full address and withdrawal hash that could be joined to a specific Railway exposure record. This adds attributed context, not independent victim-wallet proof. Researcher’s victim-report clarification.21 October, 19:36:23 UTC: an early inflow, not yet a victim linkCan a public transaction connect an affected Railway customer to the starting address? A newly located public research repository supplies an early Ethereum transaction as a lead. Reading that record directly confirms a successful transfer of 0.0008149978451301 ETH into the seed at 19:36:23 UTC on 21 October. Its full sender and hash are preserved as Anchor 7. This is an observed sender-to-seed connection, not yet an identified victim-to-attacker connection. Early Ethereum inflow.The transaction’s sender is the address that submitted the transfer. It has nonce 2, meaning the sequence number assigned to this transaction from that address, and empty input data (0x). These fields describe an ordinary ETH payment; they do not reveal whether its owner consented, where a signing key was stored, or how someone obtained authority to use it. A transaction signed from a wallet is not, on its own, proof that its private key was stolen rather than the owner being persuaded to sign.The repository calls incoming senders victims, but it is a separate researcher’s classification, not a customer confirmation or a Railway exposure log. In the public sources inspected for this follow-up, no owner-confirmed full address and withdrawal hash were joined to a corresponding Railway key-exposure record. The initial Railway disclosure still discusses possible exposure of customer secrets rather than confirming this particular wallet loss. A developer-theft article was located at its original publisher, but its body did not load in either browser checked; its headline is not used as victim evidence. The new transfer therefore narrows the movement question while leaving the hosting-to-theft cause open. Railway’s disclosure.That is why the inflow is not added to a verified incident-loss total or drawn as a victim-origin arrow in the diagrams. A useful next record would pair an affected operator’s explicit address and unauthorized-transaction report with evidence that the relevant key was present in an exposed Railway environment. The next selected record here is the later outbound ETH relay path.22 October, 00:00:23 UTC: ETH leaves for the first relayThe first selected transaction sends 14.337416437867723544 ETH from the suspected receiving address to the ETH relay. Its successful status, block, timestamp, sender, recipient, value and fee were read directly on Etherscan. A successful status means the transaction was accepted without an overall execution reversal; it does not mean the transfer was authorized by an affected user. First ETH transfer.At 02:43:59 UTC, the same relay sends 14.337414482241887922 ETH to the labelled endpoint. The elapsed time between these selected transactions is 2 hours 43 minutes 36 seconds. That measures a relay interval, not attack speed or time available for a freeze. Onward ETH transfer.ETH branch, 22 October UTCExact amount00:00:23 · seed → ETH relay14.337416437867723544 ETH02:43:59 · ETH relay → labelled endpoint14.337414482241887922 ETHOnward transaction fee, paid by relay0.00000097028232 ETHStart Figure 1 at the suspected receiving address at the top. Follow the left branch for ETH and the right branch for USDC, then read the shared endpoint below. The USDC branch occurs later in the chronology, but is shown alongside ETH to make that shared endpoint visible.Figure 1. Solid arrows indicate directly checked asset transfers; pastel colors distinguish address roles only. Amounts on the ETH arrows are rounded to six decimals; exact values are in the tables. Layout, arrow width and spacing do not encode value or time. Sources: the four relay-path transaction records in the appendix.The shared endpoint is a concrete connection between the branches. It does not prove that the relays share an owner, that a single exchange customer was credited, or that a withdrawal from the service followed. A separate bridge sequence begins at 02:37:55 UTC on Ink, before that onward ETH transfer, and finishes at 02:44:59 on Ethereum. We now step back to its source record so the burn and mint can be read together; the two asset branches should not be mistaken for one continuous timeline.02:37:55–02:44:59 UTC: an Ink burn matches the Ethereum mintDoes the smaller Ethereum receipt really correspond to a burn on Ink? CCTP, Circle’s Cross-Chain Transfer Protocol, moves USDC by destroying units on the source chain and creating corresponding units on the destination chain. The new source record changes this part of the earlier review: it is now a matched bridge sequence, not merely an explorer’s summary.At 02:37:55 UTC on 22 October, the same address string used by the Ethereum seed submits a successful depositForBurn call on Ink. The source explorer displays 11:37:55 at UTC+09:00; subtracting nine hours gives the UTC time used here. At Ink block 59,138,264, its USDC events record 129.491197 units passing to the token-minter contract and being burned. The DepositForBurn event specifies Ethereum destination domain 0 and the seed as mint recipient. A burn removes token units; the zero address in that record is not another person receiving them. Ink source transaction · Source event logs.The connection is not based on equal rounded amounts alone. A nonce is a message identifier; here it distinguishes this CCTP message from others. Looking up the nonce in Circle’s public message API returns the source transaction hash above. Looking up that source hash returns the same message. The returned 376-byte message and its attestation—the protocol’s signed approval of that message—match the bytes submitted in Ethereum’s receiveMessage call exactly. Circle’s documented domain mapping identifies 21 as Ink and 0 as Ethereum. This uses Circle’s service as one source and the two public explorer records as the on-chain cross-check; it is not an independent re-execution or a local cryptographic signature verification. Circle source-hash lookup · Official domains and contracts · Message format.Bridge stage, 22 October UTCChecked quantity / connection02:37:55 · Ink burn129.491197 USDC; source raw amount 129491197.02:44:59 · Ethereum mint to seed129.465299 USDC; destination raw amount 129465299.Separate Ethereum fee mint0.025898 USDC; message feeExecuted 25898.Reconciliation129.491197 − 0.025898 = 129.465299 USDC; 7 minutes 4 seconds between source and destination records.Message joinSource domain 21 → destination domain 0; same recipient and exact message/attestation bytes.Read Figure 2 from top to bottom: Ink burn, matched protocol message, then Ethereum delivery and the separate fee mint. The solid arrow denotes this checked bridge correspondence, not a direct ordinary-wallet transfer between chains. The bottom panel has no onward arrow because victim allocation and the relationship to the later 9,372.183919 USDC payment remain open.Figure 2. Pastel panels distinguish chain and protocol stages. All amounts are exact USDC units; arrows are schematic and not scaled to value or time. The 0.025898 USDC fee is separate from ETH transaction gas. Sources: Ink burn Anchor 6, Ethereum mint Anchor 3 and the Circle message record. The gray panel states the remaining limit, not another transfer.The source transaction is submitted by the seed’s address on Ink and names that address as the Ethereum recipient. This establishes the recorded sender and intended recipient, not the real-world operator, lawful ownership or origin of those funds. On Ethereum the successful call mints the net amount to the seed and the separate fee amount to the other recipient in the appendix. These receipts are one bridge sequence, not two additional losses. The smaller net receipt cannot by itself be allocated to a Railway victim or said to finance the later, much larger USDC payment. Ethereum destination transaction.03:04:23–09:47:35 UTC: the USDC amount survives the relay unchangedAt 03:04:23, the seed calls the USDC token contract. The transaction's top-level recipient is therefore the token contract, while the token-transfer recipient is the USDC relay. Those are different fields. A token transfer updates a ledger inside its contract; looking only at the transaction's “to” field would miss the address that actually receives the tokens. First USDC transaction.The Transfer event at log index 150 names the seed as sender and the USDC relay as recipient. Its integer value is 9,372,183,919. USDC's explorer metadata specifies six decimal places, so dividing by one million gives 9,372.183919 USDC. At 09:47:35, log index 605 in the onward transaction names that relay as sender and the same labelled endpoint as recipient, with the same token contract and integer value. First event record · Onward event record.USDC event checkFirst hop / onward hopUTC, 22 October03:04:23 / 09:47:35Log index150 / 605Raw token value9372183919 / 9372183919Scaled quantity9372.183919 / 9372.183919 USDCTime between selected hops6 hours 43 minutes 12 secondsBoth logs use the Ethereum USDC contract listed in the appendix. The decimal setting was read from current explorer token metadata; this is not a historical contract-state call. The event comparison answers a narrow question—did the same quantity of the same token pass through the named relay? The match is stronger than a rounded visual similarity: the asset, amount and relay address agree at the raw-event level.Even an exact match is not a full accounting of the relay's history. It supports this selected two-hop route, but not the claim that every token ever held by the relay came from this seed or that all of its older activity belongs to this incident. The relay's historic service interactions are not added to the investigation's loss total.What should—and should not—be added together?Do the two relay steps represent twice the loss? No. The first and onward transfers describe the same route at different points. The endpoint receipts are 14.337414482241887922 ETH and 9,372.183919 USDC. They remain separate assets; there is no incident-time exchange-rate calculation that would justify turning them into one verified dollar-loss figure.Transaction fees are paid in ETH even when the moved asset is USDC, so USDC gas should not be deducted from the token quantity. The selected ETH input exceeds the onward ETH value by 0.000001955625835622 ETH. Subtracting the onward transaction's gas fee leaves 0.000000985343515622 ETH. That is selected-leg arithmetic, not the relay's measured balance. Its displayed normal history also contains two tiny incoming payments from look-alike addresses, and this review has not reconstructed every asset or internal movement.The useful conclusion is convergence, not a complete loss tally. Neither the mint receipt nor the relay input should be added to the endpoint receipts as new damage. Unanchored service-labelled payments found around the query are also excluded: a large transfer to a familiar exchange label is not a substitute for the missing seed-to-sender link.What connects the route, and what remains uncertain?Direct transaction fields connect the ETH branch; matching token events connect the USDC branch. Both end at the same full Ethereum address. Etherscan supplies its HitBTC label, while the researcher supplies the seed's incident association. These are different evidence classes and should not be blended into a single certainty level.QuestionMissing evidenceWhich seed receipts came from affected users?Victim-confirmed withdrawals, authorization history and corresponding cloud exposure records.Who controls the relays or endpoint account?Service records or other reliable ownership evidence; shared transfers and explorer labels are insufficient.Where did the Ink USDC come from?The burn-to-mint join is now matched; victim-origin allocation and the Ink address’s upstream asset history remain unverified.What happened after the endpoint?Account-specific credit and onward withdrawal records; no cash-out or recovery established.Does the selected route explain the reported total?A deduplicated multichain victim ledger with asset-specific quantities and pricing basis.Alternative explanations remain possible for parts of the surrounding activity: the seed may contain unrelated funds, a service address may serve multiple customers, and an intermediate address may already have other assets. These possibilities do not negate the four selected transfers. They limit what can be inferred about ownership, motive and incident-wide allocation.Response points tied to the evidenceFor affected application operators, the first concrete task is to preserve the relevant access, variable-read and deployment records alongside any wallet withdrawals. A hosting reset is not proof that an exposed blockchain signing key is safe to reuse. Whether a particular wallet key was present, accessed or used without authorization requires incident-specific evidence, not a generic address label.Railway's 22 October guidance distinguishes its own credential reset from work customers must still perform. It says bucket credentials were regenerated and dependent services need redeployment. GitHub account connections need reconnecting; registry tokens removed from Railway may still work on GitHub until revoked there. These are attributed service recommendations, not operations performed by this investigation. Official reset and redeployment guidance.For investigators, the four relay-path hashes and exact endpoint address form a narrow preservation package. Any authorized request to a service should distinguish observed address receipts from an unproven customer attribution. This report does not claim that a freeze, contact, recovery request or continuous monitoring operation has occurred.The defensible result is a reproducible Ethereum subset: two relay paths converge at one explorer-labelled endpoint, with exact USDC event agreement. The Ink-to-Ethereum join is now supported by the source burn, exact message and destination mint. The missing victim ledger and service-side account evidence are not minor details. They are precisely what separates the verified movement record from a complete explanation of the reported wallet drains.Evidence appendixFull Ethereum address registerRoleFull addressResearcher-supplied seed0xd9773325282874d18cb83f1fe50f14c39750b2eeETH relay0x78421155a6ff1adbb471672b501b715cf66ce065USDC relay0x676be7c17ac1d080d3274ab3f497620509293a44Endpoint: HitBTC label only0x80787af194c33b74a811f5e5c549316269d7ee1aUSDC token contract0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48Mint transaction called contract0x81d40f21f12a8f0e3252bccb954d722d4c464b64Separate mint recipient0x6efa3205a385420cf1cfd6b725b48f96117a7beeAnchor 7: early Ethereum inflow, sender not victim-confirmedFieldChecked valueHash0x6868f0c25cd63142a388b29ed48362305f4b537c52aa38398688eda2576c6c93UTC / block2026-10-21T19:36:23Z / 26243112Status / transaction feeSuccess / 0.000005396400429 ETHSender (not victim-confirmed)0xe56c1c45ba62733c430e8e21c148f58aad31e6cbRecipient0xd9773325282874d18cb83f1fe50f14c39750b2eeValue0.0008149978451301 ETHNonce / input2 / 0xWhat remains unverifiedOwner authorization, Railway use, storage/access of the relevant key and incident-loss allocation.Ink source register and bridge identifierInk role / identifierFull valueSource caller / intended Ethereum recipient0xd9773325282874d18cb83f1fe50f14c39750b2eeUSDC burn token0x2d270e6886d130d724215a266106e6832161eaedCalled TokenMessengerV20x28b5a0e9c621a5badaa536219b3a228c8168cf5dMessageTransmitterV20x81d40f21f12a8f0e3252bccb954d722d4c464b64TokenMinterV20xfd78ee919681417d192449715b2594ab58f5d002CCTP message nonce0x0c97ddd3c9c8696cb2172dfc3fa86860912377852c6fba4d692e56f99321933cAnchor 6: Ink USDC burnFieldChecked valueHash0x8160214bff5994b869ae814d1e5559f09674fd0fe6da2c4e2c5a52372811722eUTC / block2026-10-22T02:37:55Z / 59138264Status / transaction feeSuccess / 0.000000218583057777 ETH, including the explorer’s L1 fee component.Caller0xd9773325282874d18cb83f1fe50f14c39750b2eeCalled contract0x28b5a0e9c621a5badaa536219b3a228c8168cf5dBurn / destination129.491197 USDC / domain 0 (Ethereum)Event indices0: sender-to-minter Transfer; 1: Burn; 2: minter-to-zero Transfer; 3: MessageSent; 4: DepositForBurn.Source message versus attested messageThe source MessageSent has unset protocol fields. The exact-byte comparison is between Circle’s completed message/attestation and Ethereum calldata, not between the unfilled source message and destination calldata.Exact Ethereum transaction anchorsAnchor 1: ETH transferFieldChecked valueHash0xdee103b5b7a86f1a3ad367eadbf1139b697f494b7816dc11620b4bf4f6d90debUTC / block2026-10-22T00:00:23Z / 26244426Status / transaction feeSuccess / 0.000004054937502 ETHSender / caller0xd9773325282874d18cb83f1fe50f14c39750b2eeRecipient / called contract0x78421155a6ff1adbb471672b501b715cf66ce065Amount14.337416437867723544 ETHAnchor 2: ETH transferFieldChecked valueHash0x9ac5318283604417125cc42189a5205c75757411d0f228cfed1273fe2aa26788UTC / block2026-10-22T02:43:59Z / 26245244Status / transaction feeSuccess / 0.00000097028232 ETHSender / caller0x78421155a6ff1adbb471672b501b715cf66ce065Recipient / called contract0x80787af194c33b74a811f5e5c549316269d7ee1aAmount14.337414482241887922 ETHAnchor 3: Ethereum mint receiptFieldChecked valueHash0x00db8c04ad2ef4baf9cb00c58505279b90a6b723e915fc8c5f782526b01a324fUTC / block2026-10-22T02:44:59Z / 26245249Status / transaction feeSuccess / 0.000017076873502767 ETHSender / caller0xd9773325282874d18cb83f1fe50f14c39750b2eeRecipient / called contract0x81d40f21f12a8f0e3252bccb954d722d4c464b64Amount129.465299 USDC to seed; 0.025898 USDC separate mintAnchor 4: USDC transferFieldChecked valueHash0x1769d1c449c0b08ab5cee2117f250f967ad1d1cd775b918442ebd194c6fe6fd8UTC / block2026-10-22T03:04:23Z / 26245346Status / transaction feeSuccess / 0.000011594768181248 ETHSender / caller0xd9773325282874d18cb83f1fe50f14c39750b2eeRecipient / called contract0x676be7c17ac1d080d3274ab3f497620509293a44Amount9372.183919 USDCAnchor 5: USDC transferFieldChecked valueHash0xe1bf8a78e45daad9205cde0c8e86dc758d8352d372e83c40ca6fc70a0c27f93fUTC / block2026-10-22T09:47:35Z / 26247354Status / transaction feeSuccess / 0.000004503740002788 ETHSender / caller0x676be7c17ac1d080d3274ab3f497620509293a44Recipient / called contract0x80787af194c33b74a811f5e5c549316269d7ee1aAmount9372.183919 USDCFor the USDC transfers, the recipient above is the token recipient, not the top-level called contract. Both call the USDC contract in the address register. The seven anchors are a selected evidence set, not a complete address inventory or a new incident count. Direct checks here mean reading public explorer records and event data, not independently replaying execution on either chain.Update, 23 October 2026: the earlier source-unmatched wording and Figure 2 were replaced after the Ink burn and Circle message join were checked. The four Ethereum relay-path quantities and the victim-attribution limits are unchanged.Additional source check, 23 October 2026: Anchor 7 adds one directly read early inflow. It does not establish a victim’s Railway exposure or independently reproduce the public repository’s full wallet count, valuation or cause classification. The existing relay and CCTP quantities are unchanged.

A transaction-level review of October 20-21, 2026. Public explorer records checked October 22, 2026. All times are UTC.At 18:39:51 on October 20, a successful Base transaction paid 19,820.734002 USDC and 8.716935563284127414 ETH from the contract identified as Slice's FundsModule to the transaction sender. A subsequent swap returned 8.052201613921397406 ETH to that sender, which then transferred 16.788 ETH to another address. These are different stages of a route, not amounts to add together as separate losses.The distinction becomes more important across chains. The public records establish five later Base departures and separate Ethereum receipts. They do not, by themselves, establish the bridge request linking each departure to an arrival, or how much of a mixed address's later activity belongs to this incident.SlowMist's incident database describes a FundsModule issue involving release amounts returned by a caller-selected contract and reports an approximately US$41,000 loss. That is attributed incident context, not a loss estimate reproduced by this review. We did not replay the proposed mechanism or verify a patch. SlowMist incident recordWhat the initial transaction establishesThe seed transaction, 0x02b039…8d790a, succeeded in Base block 52,866,122. The USDC Transfer log records 19,820.734002 tokens from FundsModule 0x61bcd1…eacaaf to the sender, 0xc34572…8c892f. The independently retained RPC receipt matches the token contract, recipient, and integer amount. BaseScan's internal-transfer display separately shows an 8.716935563284127414 ETH payment between those addresses. Seed transactionThe transaction's top-level value is 0 ETH. That field measures the value submitted with the outer call, not all ETH moved by contracts during execution. It does not contradict the displayed internal payout. BaseScan also flags a reverted internal execution while marking the overall transaction successful; success should not be read as a claim that every nested call succeeded.“Sender,” “FundsModule,” and “recipient” describe roles in the selected records. They do not identify a person or establish who controlled an address. The selected payouts are also not a complete reconciliation of the module's other transfers, user liabilities, or incident-wide net loss.The swap changes the asset, not the amount of lossAt 18:41:17, the sender submitted 19,820.734002 USDC to the swap route. The token-transfer list also shows 0.000001 USDC returned to it. The resulting net USDC sent in that transaction is therefore 19,820.734001, not the full submitted amount. Swap transactionThe ETH records reconcile as follows:WETH unwrapped and passed into the payout route: 8.123274552931009529 ETH.ETH paid to the transaction sender: 8.052201613921397406 ETH.ETH paid to a separate recipient, 0xe25c63…272e42: 0.071072939009612123 ETH.The two payouts sum exactly to the unwrapped amount. The separate recipient's role is not established here, so its payment is not labeled a gas fee or a proven service fee. The sender's ETH receipt is a payout, not a gas-adjusted profit calculation. Nor should the submitted USDC and the resulting ETH be counted as two losses.Figure 1. The selected Base sequence, with the sender's actual ETH payout distinguished from the larger unwrap. Rounded ETH values carry an approximation sign; exact quantities appear in the text. The swap returned 0.000001 USDC. The later 16.788 ETH transfer came from an address that had also received pre-event funding. Sources: the seed, swap, funding, and onward-transfer records linked in this article.Why 16.788 ETH is not an exact incident allocationAt 18:45:47, the sender transferred 16.788 ETH to 0xfba873…81364a. Before the seed, at 18:26:57, it had already received 0.0195 ETH from a different address. Both transfers are visible in BaseScan. Pre-event funding · Onward transferETH is pooled in an address balance. These records show that the outgoing payment followed the incident receipts, but they do not assign an exact fraction of each prior receipt to it. We therefore report 16.788 ETH as an observed transfer, not as an independently measured amount of incident proceeds, a protocol loss total, or a recoverable balance.Two chains, two levels of evidenceBetween 23:57:03 on October 20 and 00:03:15 on October 21, 0xfba873…81364a sent five Base transactions with values of 0.5, 5, 5, 5, and 1.287 ETH. The explorer shows their route through 0x333573…4a3333 and internal transfers to an address labeled “Relay: Depository.” Their total is 16.787 ETH on the source side.A SentinelTX working record pairs the first four departures with four Ethereum payments to the same hexadecimal recipient address. We independently checked the existence, successful status, amounts, recipients, and timestamps of those public transaction pages. The four source values total 15.5 ETH; the four cited Ethereum receipts total 15.496861123458983361 ETH.The pairing itself remains a separate claim. The reviewed overview pages do not supply a request-level record that independently proves each cross-chain link. Nearby timestamps, similar amounts, and a matching destination address support a lead, but are not substitutes for that record. The fifth 1.287 ETH source transfer is observed; its destination correlation is not included in the four-pair total.Figure 2. Individual source transactions and Ethereum receipts were checked in public explorers. Dashed links show pairings reported by the SentinelTX working record, not independently established request-level links. The fifth Base transfer is separate. Values on opposite chains are not added together as a loss figure.Sources: the four Base and four Ethereum transaction pages linked in the exact-records appendix. Pairing provenance: SentinelTX working record; request-level linkage not independently established.Explorer service labels help describe the displayed route. They do not establish ownership, complicity, or the intent of any service or address. This review does not turn the paired totals into an exact allocation of the earlier Slice payout.Where this review stopsThe firmest result is the transaction-level accounting: a USDC receipt and internal ETH payout, a subsequent swap with a small USDC return, and a later ETH transfer from an address with earlier funding. The cross-chain pages add independently observable records, while the request-level linkage remains qualified.We do not establish an incident-specific exchange cash-out, a recovery, a current balance, or the identity of an operator. This is a selected-record review, not a complete address history. A missing finding is not proof that no further movement occurred.Figure 3. Publicly checked transfers and unresolved attribution are different evidence categories. The initial USDC receipt also has an independent RPC check. A transfer's existence does not establish ownership or an exact share of commingled funds.Sources: public BaseScan and Etherscan records linked in this article; retained RPC receipt for the initial USDC transfer. The diagram distinguishes observed transactions from unresolved attribution.Sources and evidence appendixThis article is a new editorial reconstruction from the linked records, not an adopted or sealed SentinelTX report. Public explorer checks were performed on October 22, 2026. The independent RPC cross-check is limited to the seed receipt; it is not a replay of the full execution or an independent verification of every downstream internal call. Cross-chain pairing provenance is identified above. Automated aggregate totals from the working draft were not used as incident amounts or balances.The article's scope ends at the selected transactions below, rather than at an asserted complete-history cutoff. The exact identifiers are provided so readers can distinguish an observed record from a proposed relationship between records.Address registerTransaction sender, Base: 0xc34572ebb26b9a4c54854aae8d2347108e8c892fFundsModule, Base: 0x61bcd1ed11fc03c958a847a6687b1875f5eacaafUSDC token, Base: 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913Onward recipient, observed on Base and Ethereum: 0xfba873b1e5d0256301b87ce74f79a30d6781364aSeparate swap payout recipient, Base: 0xe25c6353a04f9375e9cbac224fda91a90c272e42Exact cross-chain recordsThe pair numbering follows the working record, not an independently authenticated bridge-request mapping.Reported pair 1: Base 0.5 ETH, 0x6ca60f5873a2290cf7284146b4f87ab673d51183d3ba5503ab606774b17e75bb; Ethereum 0.499890262307287644 ETH, 0x4c02a7aa31c6f05662211d69d1031e5f51b5bfc350d01143aba6bb89022abde0.Reported pair 2: Base 5 ETH, 0xa05f56d4fc8484ab69ebbeb4ac4d28e40de98a8eea7244c2dcf2ed5b20b41c86; Ethereum 4.998990272562388387 ETH, 0x7125d47d1d734c5f1c253170fd1edaa72d1901c61ea3902f46e2604682150609.Reported pair 3: Base 5 ETH, 0x4ab516ee7fdca7b0985a132182412f6a860051bebc6e25f5b06db8cb8d37b4f6; Ethereum 4.998990251886325914 ETH, 0xe7ecbc6d35d72e1ec95ea16ae9491b410bff6dfb5e833b6c8c2baefffd33c212.Reported pair 4: Base 5 ETH, 0x485808ce7f4fb6f087072b179decd40aebc1177397488ababfffc8a4f8cb3d1e; Ethereum 4.998990336702981416 ETH, 0xdca2cb6c3fe5542d0447b5a98f2318b62a5a5b8b5090ebdac071fa20b34c9934.Fifth source only: Base 1.287 ETH, 0xb7ff77b677a67d251052557f8c514daaec0b013d1c31142b8674fece02796050. Destination correlation remains unconfirmed in this review.