Community

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

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

A UNCX vesting-pool transaction on Ethereum moved five tokens into an execution route on 14 October 2026. Four were converted into ETH that afternoon. The fifth, ZC, remained in the executor until the following morning, when a withdrawal and a separate sale completed the selected route.Three roles make that sequence easier to follow. The shared vesting pool held tokens for scheduled releases. The initiating wallet submitted the transaction. The executor was a contract created during that execution, which received tokens and later forwarded them for conversion. These role names describe addresses in the records, not identified people.The confirmed path is shared vesting pool → executor contract → token conversions → the initiating wallet. The two conversion sessions paid that wallet 21.155286011908665958 ETH in total. A separate 0.29 ETH return from the executor was not another token sale. Understanding that distinction matters more here than attaching one large dollar estimate to every transfer.This is a bounded Ethereum investigation, not a reconstruction of every UNCX-related drain. The account below separates transaction records, arithmetic and external reporting, then follows the transitions in time order.ScopeBoundarySelected incidentEthereum seed transaction on 14 October; five subsequent token salesObservation cutoffBlock 26,210,180 · 17 October 2026, 05:27:59 UTCConfirmed sale receipts21.155286011908665958 ETH; before gas and execution costsCounting ruleCount each final ETH receipt once. Keep capital returns, token movements and balances separate.Follow-upInitiating wallet and funding address; bounded native-ETH tracing up to two outward hops, not continuous coverageBefore the numbers: who does what?Vesting is a schedule for releasing tokens over time. A shared vesting contract can hold tokens for many positions. Here, “pool” means the address whose token balances changed in the selected transaction; it does not mean that every position holder has been identified. A net outflow means recorded outgoing tokens minus incoming tokens within that transaction—not the sum of all transfers displayed by an explorer.The initiating wallet submitted the seed transaction. It called an entry contract, which created an executor: a contract that carried out further interactions and received tokens. The executor is a distinct address, not a second name for the wallet. A funding address supplied ETH beforehand. These are roles in the records, not names for people or proof that one operator controlled all of them.Role on EthereumFull addressInitiating wallet0x78c9b11853e4f183a34c63ffd1924d2319a2f5b3Entry contract0x6cebdf095172b355121b93962017975c4601f26cExecutor0xf6d072254eb8a9b06e0ba21221b498332c1bc35eShared vesting pool0xa98f06312b7614523d0f5e725e15fd20fb1b99f5Funding address0x6d2afff4fc6ff46564467762c4aa35812680d606Three findings guide the investigation. The pool’s five token net outflows reconcile to the executor and other net recipients. The fifth conversion happened on the following day, so stopping on 14 October misses a material receipt. Finally, the sale receipts, returned execution capital and later wallet balance answer different questions. The chronology below explains why.Start Figure 1 at the pool and follow the top arrow to the executor, then down to the initiating wallet receiving tokens for conversion. Read the lower boxes as the two conversion sessions: their arrows point back toward the wallet because it received the final ETH. They are not additional recipients to add to the wallet.Figure 1. Solid arrows indicate asset direction or grouped conversion paths, not transaction calls, ownership, quantity scale or elapsed time. All amounts shown are rounded to six decimals. The public receipts and exact tables govern the quantities.The overview shows a route with a pause, rather than a single immediate cash-out. It also stops at the receiving wallet: a sale on a decentralized route does not itself establish a deposit with an exchange. The first chronological question is how the initiating wallet was funded.14 October, 14:47–15:15 UTC: funding arrives before executionThe funding address sent 0.1, 0.9 and 2.5 ETH to the initiating wallet at 14:47:35, 14:56:59 and 15:15:35 UTC, respectively. Together these transfers supplied 3.5 ETH before the seed transaction. ETH is Ethereum’s native asset; it can pay transaction fees as well as contract payments. First funding; second funding; third funding.15:49:59 UTC: five token balances fall in one seed transactionThe successful seed transaction sits in block 26,191,745. Its receipt contains 136 logs, including 64 ERC-20 Transfer events. An ERC-20 token keeps its own ownership ledger; a Transfer event records a movement in that ledger. Several movements can occur inside one transaction, including borrowed tokens going in and back out. Seed transaction and receipt.To avoid counting borrowed principal twice, this review summed the raw integer amounts in the transfer events by token and address. Token decimals translate those integers into readable units: 18 decimal places for four tokens, and nine for PAAL. For every token, the pool’s net outflow equals the sum of the positive net receipts at the executor and the other recipients.TokenPool net outflow (rounded)Executor net receipt (rounded)EDGEN57,344,850.92155,601,598.708ZC9,131,678.0459,055,847.638pepeCoin42,200.53340,155.284LO0P65,826.00065,372.217PAAL115,945.630113,657.767The difference between the two columns is not an unexplained second theft. The receipt records net amounts at a fee recipient and, for three tokens, other counterparties in the execution. Those quantities are preserved separately in the appendix. Do not add the executor’s receipt to the pool’s outflow: they are two views of the same movement.This reconciliation establishes token movements. It does not reconstruct every vesting position or prove the vulnerability’s cause. The incident-time implementation and storage were not replayed here, so the exact accounting defect remains unconfirmed by this analysis. The evidence supports the selected outflow route more directly than it supports a complete root-cause claim.16:41–17:01 UTC: returned capital and four salesAt 16:41:11, the executor returned exactly 0.29 ETH to the initiating wallet. The seed had supplied 0.8 ETH; ten 0.05 ETH payments and one 0.01 ETH payment account for 0.51 ETH, leaving 0.29 ETH. The exact conservation and later return support reading it as unused execution capital. The complete executor history and code semantics were not independently replayed, so this interpretation remains narrower than a full contract audit. Capital return.Three minutes later, the first selected token sale paid ETH to the wallet. Four conversions followed in order: pepeCoin at 16:44:35, EDGEN at 16:56:47, LO0P at 16:58:59 and PAAL at 17:01:11. A swap route can wrap ETH into WETH and unwrap it again. WETH is a token representation of ETH; counting each internal hand-off would inflate the sale receipt. Here only the final ETH receipt at the initiating wallet is counted.14 October UTC / saleETH received16:44:35 · pepeCoin2.19369786395594791616:56:47 · EDGEN8.56791624420310002516:58:59 · LO0P3.46310648888943786317:01:11 · PAAL0.411886429218097850The four receipts sum to 14.636607026266583654 ETH, before costs. The LO0P sale was submitted by a different address, even though ETH reached the initiating wallet. A third-party transaction submitter can execute an order for a recipient. That fact does not identify a co-attacker, and the third party’s transaction fee must not be subtracted from the initiating wallet’s funds without checking who paid it. LO0P receipt.At 17:09:35, after these four sales, 3.5 ETH went back to the funding address. That return connects the two addresses financially, but does not establish a real-world identity, common control or an ultimate cash-out destination. It also does not mean that the sale receipts disappear from the ledger: it is a later movement of ETH, not a negative token sale. Return transaction.15 October, 07:28–07:35 UTC: ZC completes the selected conversion routeAt 07:28:35 the executor sent 9,055,847.637887682268154756 ZC to the initiating wallet. This was a token withdrawal, not yet a sale. At 07:35:11—six minutes and 36 seconds later—a separate successful transaction converted that amount and paid 6.518678985642082304 ETH to the same wallet. ZC withdrawal; ZC sale.The sale used LI.FI routing. A router is a contract that forwards a swap through trading venues and other contracts. It is an intermediary, not necessarily the buyer or the final recipient. The sale included a token fee of 4,527.923818943841134077 ZC. The remaining 9,051,319.714068738427020679 ZC moved onward to the router. The route ultimately unwrapped WETH and delivered ETH through routing contracts to the wallet. These intermediary transfers explain how the conversion completed; they are not extra sale proceeds.A call trace breaks one transaction into the contract calls made while it runs. Each call appears as a frame, so several frames can describe successive steps involving the same funds. The trace displayed 150 of 204 call frames. Original explorer transfer records therefore supplement the quantity check, but this is not a complete execution replay: the transaction was not independently rerun to verify every internal step.Stopping the account on 14 October would therefore omit more than 6.5 ETH of selected sale receipts. Conversely, adding the 0.29 ETH capital return would overstate those receipts. Figure 2 separates the two accounting categories before showing the later balance snapshot.Figure 2. Read the green sale box and amber capital box separately. The connecting arrows identify receipt categories reaching one wallet; they do not instruct the reader to add them as profit. The lower gray panel is a later balance observation. Amounts are rounded to six decimals.The five sale receipts total exactly 21.155286011908665958 ETH. This is a gross conversion receipt, not net profit, a dollar loss or the wallet’s entire balance. Gas, execution payments, starting funds and other transfers need their own accounting. One unsolicited incoming wei and a successful zero-EDGEN transfer are excluded from sale proceeds. The remaining question is where the observed ETH stood at a defined cutoff.17 October: a fixed-block snapshot, not a final destinationAt block 26,210,180, timestamped 05:27:59 UTC, the initiating wallet held 20.237222755363802454 ETH and the funding address held 7.459202396392388 ETH. These were read at the same historical block through Ethereum JSON-RPC, not inferred by subtracting a selection of transfers. The block hash is preserved in the appendix. Cutoff block; RPC endpoint documentation.A balance belongs to an address, not to one incident. The funding address’s balance in particular is not an additional UNCX loss. Within the bounded native-ETH follow-up, no custodial-exchange deposit, bridge exit or mixer deposit was identified from these two addresses. Provider coverage and labels are incomplete; this is not proof that no outside-scope movement exists or that the funds can be recovered.One account detail also deserves care. The initiating wallet’s code at the cutoff is an EIP-7702 delegation marker pointing to a separate implementation. EIP-7702 lets an account authorize delegated code execution. A nonce is an account’s sequential counter; it helps distinguish an authorization or transaction from an earlier one. The ZC sale’s authorization used nonce 25, while its outer transaction used nonce 24; an authorization can increment the authority’s nonce inside that transaction. It is not evidence of a separate later transaction, a compromised key or a specific operator. Sale authorization; EIP-7702 specification.What connects the route—and what remains openThe strongest connections are direct: the executor was created inside the seed execution, token events reconcile its receipts, the next-day ZC withdrawal names the same sender and recipient roles, and the five sale receipts pay the initiating wallet. These are transaction-level links. The funding relationship is a different level of evidence: it establishes value moving between two addresses, not common ownership. Similar patterns or shared service labels cannot fill that gap.Blockaid’s broader alert reported approximately $1.49 million across four chains and 11 drains including copycats and MEV activity—automated attempts to extract value from transaction execution or ordering. That is external incident context, not this report’s verified net loss. This review does not independently aggregate BNB Chain, Base or Robinhood activity, price every token at the incident time, or assign every affected vesting position to a victim. Blockaid update; published transaction list.The transfer-event arithmetic was independently reconstructed from Etherscan receipts. SentinelTX supplied call traces and bounded address follow-up; fixed-block balance and code reads were checked separately through Ethereum RPC. These are complementary evidence sources, not interchangeable confirmations. The selected record is reproducible, but neither the root cause nor a complete multichain victim ledger has been established by this analysis.Response points specific to this caseThe first response question is which vesting positions were affected. Investigators need the incident-time position state and decoded deposit/withdrawal events, not only the shared pool’s balance change. That would connect the reconciled token outflows to individual claims and avoid confusing fee or lending-counterparty receipts with executor gains.The second is why those movements were accepted. Investigators would need to rerun the seed using the contract code and stored state from block 26,191,745. This would test whether an accounting rule was violated. Such a rule is called an invariant: a condition that should remain true as the contract runs. This review has not identified and reproduced a specific invariant failure. A current implementation page or a matching exploit pattern is not an adequate substitute.The third is whether the receiving wallet later crosses into a service with a verifiable destination record. Any new exchange, bridge or mixer label needs the actual transaction, chain, asset and time attached. A historical funding source is not an onward route for proceeds created later. Until such a record is linked, the report should stop at the observed wallets rather than draw a speculative cash-out arrow.The defensible conclusion is therefore specific: five tokens left the shared pool in the selected Ethereum transaction, and five later conversions paid 21.155286011908665958 ETH to the initiating wallet across two days. The 0.29 ETH executor return is separate capital, and the 17 October balance is a snapshot. Those distinctions preserve what the evidence explains without turning unanswered questions into findings.Evidence appendix: exact quantities and identifiersAll addresses below are on Ethereum. Wallet and contract links open address-detail pages; transaction links open transaction-detail pages. Values are unrounded unless explicitly labeled otherwise. Raw token quantities were summed as integers, using each token’s recorded decimal precision.EDGEN: seed-receipt reconciliationRecordExact token amountPool incoming475444753.754326574116796226Pool outgoing532789604.674988572932369396Pool net outflow57344850.920661998815573170Executor net receipt55601598.708417972560603048Fee-recipient net receipt425556.138682232937672685Counterparty net receipt1317696.073561793317297437RoleEthereum addressToken contract0xaa9806c938836627ed1a41ae871c7e1889ae02caFee recipient0xd45dd91df475bfd944335160f538c1a14888dc1cCounterparty0x4b2c930f88a87d1bffac291b6a7e01c9f13dd03eZC: seed-receipt reconciliationRecordExact token amountPool incoming93872336.744096272206179873Pool outgoing103004014.788650621140667962Pool net outflow9131678.044554348934488089Executor net receipt9055847.637887682268154756Fee-recipient net receipt75830.406666666666333333RoleEthereum addressToken contract0x4e67db19044549ff420860834c91b45bad298722Fee recipient0xd45dd91df475bfd944335160f538c1a14888dc1cpepeCoin: seed-receipt reconciliationRecordExact token amountPool incoming658778.146282755355639233Pool outgoing700978.678959483212162252Pool net outflow42200.532676727856523019Executor net receipt40155.284285661160205717Fee-recipient net receipt446.139542453412314759Counterparty net receipt1599.108848613284002543RoleEthereum addressToken contract0xa9e8acf069c58aec8825542845fd754e41a9489aFee recipient0xd45dd91df475bfd944335160f538c1a14888dc1cCounterparty0xddd23787a6b80a794d952f5fb036d0b31a8e6affLO0P: seed-receipt reconciliationRecordExact token amountPool incoming560996.296306472266672982Pool outgoing626822.296306472260110494Pool net outflow65825.999999999993437512Executor net receipt65372.217059159993437512Fee-recipient net receipt453.782940840000000000RoleEthereum addressToken contract0x00000000000050806673b532d7486ac114c1de3fFee recipient0xd45dd91df475bfd944335160f538c1a14888dc1cPAAL: seed-receipt reconciliationRecordExact token amountPool incoming988136.434511398Pool outgoing1104082.064395937Pool net outflow115945.629884539Executor net receipt113657.766933968Fee-recipient net receipt799.291296850Counterparty net receipt1488.571653721RoleEthereum addressToken contract0x14fee680690900ba0cccfc76ad70fd1b95d10e16Fee recipient0xd45dd91df475bfd944335160f538c1a14888dc1cCounterparty0x2a6c340bcbb0a79d3deecd3bc5cbc2605ea9259fExecution and routing addressesRoleEthereum addressSeed fee recipient0xd45dd91df475bfd944335160f538c1a14888dc1cSeed builder-payment recipient0x396343362be2a4da1ce0c1c210945346fb82aa49LO0P transaction submitter0x8d10551fbb0da1eadf34b25210fe75f278fa9321LO0P relay0x52b335fd4d229c4b4ffa6190526e4b5fb8e3fb09UniswapX reactor0x00000011f84b9aa48e5f8aa8b9897600006289beLI.FI route0x1231deb6f5749ef6ce6943a275a1d3e7486f4eaeZC router0x22ec88b9ff78c6f2458ab1a7aa8bb99d84bd4b86ZC ETH routing intermediary0x28bf6006d87de7f44445905aa4f5cb8c0d8cba02Uniswap v4 Pool Manager0x000000000004444c5dc75cb358380d2e3de08a90EIP-7702 delegate0x63c0c19a282a1b52b07dd5a65b58948a07dae32bChronological transaction register (UTC, 2026)Time and evidence roleFull transaction hash14 Oct 14:47:35 · 0.1 ETH funding0x52fe1a5aa857a3e6f6f0c12f559019da382c294238601b967a74b03c01c5b93b14 Oct 14:56:59 · 0.9 ETH funding0x351b5d9728c51ffbefd951b3536ab9c61e6e0de9dfa738830d560eb82fb6992e14 Oct 15:15:35 · 2.5 ETH funding0x56db74daaa13475dbb3360c86bf150ad2430556500cd803e47590f3b32b75e8b14 Oct 15:49:59 · seed · block 261917450x352065378c4a41b77e5b6a1e5b5616cd2886c3e1a2c87ed3db8e5ddddc23823d14 Oct 16:41:11 · 0.29 ETH return0x1527757f77288fafc68ab8f2d20e7061ee9941fe8214e188d6810882661fbc3210-14 16:44:35 · pepeCoin sale · block 261920180xf758582096ed80fbd4b80bc3dbd44e3edabdfd116b15ad9d16af459e38b09be510-14 16:56:47 · EDGEN sale · block 261920790x60becfc7e652d79182402bc3a8ce43ad433b06b5c401d239a4b10b97bb4a722110-14 16:58:59 · LO0P sale · block 261920900x35672ee02483b580acc443657ec6f5326e0fcea35912d6042335ed8f70010d0410-14 17:01:11 · PAAL sale · block 261921010x4ac0a349988c0e87a7d4d8f5fe94ae4886b165b56e931b6f485c57e2db8bcb4c14 Oct 17:09:35 · 3.5 ETH to funder0xa32b5eefca3e3dc8891f9e07fcd585c5ce1762f5d67035fc3e61acaa818f92bd15 Oct 06:40:47 · unsolicited 1 wei0x3d08bda0a282249b2cd05685962c2d7bc21ec2a23a4da4d2191c7d48123b96ac15 Oct 07:27:11 · zero EDGEN · block 261964140xe806726d883cef3dac91fe782ea1bfe8f451f08c40d3990fee8b4a42443c371115 Oct 07:28:35 · ZC withdrawal · block 261964210x8eab147f6e0f34e807c584d69873b2a2f7b4791b691f9a60c9d1ffd347eafcb015 Oct 07:35:11 · ZC sale · block 261964540x13a26824dd3f1135b35852333922f4573e0a8c2542a3d6884655471283a490fcCutoff and counting notesObservationExact valueFive sale receipts21.155286011908665958 ETHZC sale receipt6.518678985642082304 ETHReturned executor capital; excluded from sales0.290000000000000000 ETHInitiating-wallet native balance20.237222755363802454 ETHFunding-address native balance7.459202396392388 ETHBlock / UTC26210180 / 2026-10-17 05:27:59Block hash0x98c78f93c1b3d7de09694f161d922b2c219b68205f87626f224d70301fa672deThe five-sale total excludes the 0.29 ETH capital return, the unsolicited wei, repeated internal route legs and gas. No net-profit or dollar-loss total is asserted. The selected pool-net figures do not establish per-position losses. Findings reflect the stated cutoff and scope, not a live assurance about later funds.

On 15 October 2026, a single Ethereum transaction moved 2.309861111111111114 ETH out of KolanHook and ultimately paid 1.279914429958618589 ETH to its initiating address, according to the body of SentinelTX report CASE-ASYNC95E. Those figures describe different things. The first is the hook's gross native-ETH outflow; the second is the surplus paid after borrowed principal was returned.That distinction is the starting point for understanding this case. The transaction also involved a 6.7 WETH flash loan and a larger Pool Manager payout. Treating every transfer as a separate loss, or calling the entire payout profit, would misrepresent the reported flows.This article adapts the report's findings for the ChainBounty community. It preserves the distinction between recorded movements and the report's interpretation of the mechanism. It also explains the source's scope and evidentiary limits.The incident ledger: follow the amounts separatelyThe report's body places the successful transaction at 11:06:11 UTC on 15 October 2026, in Ethereum block 26197504. It reports 78 call frames and a maximum call depth of eight. The seed transaction and relevant full addresses appear in the reference key below. [1]The seed-transaction ledger is:Borrowed principal: 6.7 WETH, unwrapped into 6.7 ETH.Principal returned: 6.7 ETH re-wrapped into WETH and repaid within the same transaction.First hook payment to the Pool Manager: 2.050000000000000001 ETH.Second hook payment to the Pool Manager: 0.259861111111111113 ETH.Combined hook native outflow: 2.309861111111111114 ETH.Pool Manager payout to the helper: 7.979914429958618589 ETH.Gross surplus paid by the helper to the initiator: 1.279914429958618589 ETH.Maximum transaction-fee estimate: 0.000487737331891920 ETH.Gas-adjusted proceeds: at least 1.279426692626726669 ETH.The payout reconciles exactly as reported: 7.979914429958618589 ETH minus 6.7 ETH equals 1.279914429958618589 ETH. The hook outflow is larger than that surplus. The report attributes the difference to netting against swap legs inside the Pool Manager; these categories should remain separate.The gas-adjusted amount is a lower bound, not an exact net-profit figure. The report multiplies the gas limit of 3,105,267 by the gas price of 157,067,760 wei to obtain a fee ceiling. It does not provide the seed transaction's gasUsed in the cited evidence. [2]Figure 1. Zero-baseline comparison of hook native outflow and initiator gross surplus. The repaid 6.7 WETH principal is a separate annotation. The two bars measure different things and are not additive; the exact ledger above governs any shortened chart labels.How the transaction unfoldedThe report describes Kolan as a fixed-supply KLN token whose supply sits in a native-ETH/KLN Uniswap v4 pool. In the published design summarized by SentinelTX, the hook is the sole liquidity provider. Buyers pay a premium for a cancellation “window,” during which a purchase can be cancelled and ETH refunded. This design context comes from the report, rather than a separate review of the protocol's code. [3]The reported execution sequence has five useful stages:Deployment. The initiating address created an operation contract, which created a helper contract. The helper carried out the interactions.Funding. The helper borrowed 6.7 WETH from the address labelled Balancer, then unwrapped it into ETH.Initial pool interaction. The helper entered the Uniswap v4 Pool Manager and paid it 6.7 ETH. The Pool Manager invoked KolanHook callbacks.Repeated hook calls. The helper called the hook twice using selector 0x19b05f49. The first call triggered four Pool Manager calls with selector 0x5a6bcfda; the second triggered seven. The hook made the two ETH payments listed above during these hook-driven frames.Exit and repayment. The helper interacted with the Pool Manager again, received 7.979914429958618589 ETH, re-wrapped and returned the 6.7 ETH principal, then paid the remaining 1.279914429958618589 ETH to the initiator. [2]SentinelTX assesses this pattern as consistent with flash-loan-funded price-and-liquidity manipulation of the hook's internal accounting. Its interpretation is that the initial swap displaced the pool price, the hook interactions changed liquidity placement or withdrawal around that price, and the reverse swap captured a difference.That is an assessment, not a fully decoded root-cause demonstration. The report says selectors were not ABI-decoded. It cannot establish whether 0x19b05f49 represents buy, cancel or accept, or whether 0x42966c68 is a burn. The broader classification as a logic/accounting exploit rather than a key compromise is also the report's assessment. A decoded trace and relevant hook events remain important missing evidence. [3]Figure 2. Five-stage incident sequence, from deployment and funding through pool and hook interactions to repayment and surplus. The sequence is reported evidence; the proposed accounting mechanism remains an assessment. Pre-incident transfers do not belong in this flow.Where the traced value stoppedSection 7 names the initiating address as the endpoint in the traced set: one inbound movement and no outbound movement in that set. The body also says the initiator's transaction list was read to its end and no later outbound value transfer was identified as of the analysis. No exchange-deposit leg was identified. These are bounded findings, not a guarantee about future activity. [4]A later contract-creation transaction at 16:48:59 UTC on 15 October is described separately. It involved other contracts and no KolanHook value-bearing frame. Its proceeds are excluded from this incident ledger.The initiator's displayed native balance was 1.539598 ETH at analysis time. Appendix A gives the full address-level reconciliation as 1.539598271282627379 ETH. That balance combines unrelated activity; it is not an isolated balance of Kolan proceeds. Similarly, the report's 0.0 ETH native-balance reading for the hook does not establish its total assets or liabilities, because KLN and Pool Manager claim balances were not read. [4]Earlier transfers are context, not the exit routeThe report records three 1 ETH transfers to an address labelled Tornado.Cash Router and DAI/PAXG transfers to an address labelled Relay.link on 12 October. They happened three days before the seed transaction. They cannot be an onward route for proceeds generated on 15 October.Some source figures combine incident flows with earlier or unrelated activity. Visual proximity and connecting arrows should not override chronology. This article does not adopt the report's sanctions tag as a statement of current legal status, and does not infer a real-world identity or insider involvement from the address history. [5]Important limits inside the sourceThe abstract limits its statements to the evidence available to that summary: it does not supply a transaction date or record terminal endpoints, and its definition of “verified” does not establish the signer. The body separately gives the incident date, block and reported tx.from address (§§1 and 3), and lists the initiator as an endpoint within the traced set (§7). These are different levels of scope and detail, not competing dates or proof of a final cash-out destination. This article attributes the specific transaction details to the body and preserves the source's limits on identity, ownership and onward tracing.The abstract also defines “verified” narrowly: the transaction was retrieved and names the addresses. It explicitly says that this does not establish authorization, ownership or even that a reported asset symbol identifies the intended asset. That label should not be read as independent confirmation of every narrative claim.Appendix A records an executed query from 15 September 2026 at 11:43:17.968656 UTC to 16 October 2026 at 11:43:17.968656 UTC. Of 51 retained movement rows, 44 lack readable timestamps. The seven timestamped rows span 22 September to 12 October; separately, the body supplies the incident timestamp. Query bounds are not proof of continuous transaction coverage or enforcement of a requested historical cutoff. The report also leaves KLN quantities and the impact on individual window holders unquantified. [6]The community takeawayThe useful conclusion is specific: SentinelTX reports a repaid 6.7 WETH loan, two hook payments totaling 2.309861111111111114 ETH, and a 1.279914429958618589 ETH surplus payment to the initiator in one transaction. The proposed manipulation mechanism needs decoding; the traced endpoint does not establish a later cash-out route.For community reporting, retain those boundaries. A stronger explanation would require the decoded hook calls and WindowOpened, WindowClosed and Taxed events identified by the report. Until then, the exact ETH ledger is more informative than a single dramatic “loss” number, and the unanswered questions belong alongside the findings.Figure 3. Reported movements, assessed mechanism, unresolved impact. No later cash-out route or real-world identity is established by this adaptation.Reference key and source notesSeed transaction: 0x7b131926e6f06491ae1aead3e419b208c8aa70ed7898e8c5a33d9f52e40915a9Initiator / reported tx.from: 0x8df735014eab81905e76b87ef0c069bd8e0ae382KolanHook: 0x0136fecf49e0217bfd2d9551e8e7b05f174ba8ecHelper: 0x4d6a41f2b80fe75facf27f9d0b3dc8bd0ebc835fOperation contract: 0xebea460c6496e1a2565aab488eb005473bde5f79Uniswap v4 Pool Manager: 0x000000000004444c5dc75cb358380d2e3de08a90Balancer-labelled lender: 0xba12222222228d8ba445958a75a0704d566bf2c8WETH: 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2Adapted from SentinelTX report CASE-ASYNC95E, generated 16 Oct 2026; findings and limitations as of that report.Source sections: [1] §1 and §3B; [2] §3B and §3D; [3] §1 and §5; [4] §1, §3C, §7 and Appendix A; [5] §3A and source-figure captions; [6] Abstract, §3D and Appendix A.Explorer links are reader-navigation links constructed from the report's exact identifiers. Explorer content was not used as an additional factual source. This adaptation does not claim independent verification of the report's evidence signature.

Autheo says it discovered unauthorized issuance of its THEO token on October 12, followed by transfers to Base. Its October 13 notice describes a halt to origin-chain block production, validator nodes and the affected cross-chain relayer. The project has not yet confirmed the complete token count or financial impact. Autheo’s incident notice.The public records examined here answer a narrower question: what can be established from two Base mints, a later sale, a bulk token transfer and an identified cross-chain payment? They show 19 million and 100 million THEO issued to the same wallet, a successful sale that returned ETH to that wallet, and a Relay deposit whose request identifier also appears in an Ethereum transaction paying that same address. A later transfer sent 93,510,011 THEO to a separate address. These are stages to distinguish, not quantities to add into one loss figure.The main ETH route in brief is token issuance on Base → the receiving wallet’s sale through a swap contract → ETH deposited with Relay on Base → ETH paid to the same address on Ethereum. The bulk THEO transfer is a separate branch. The sale record is one selected conversion, and the cross-chain record is one selected deposit and payment. Neither is presented as the complete incident ledger. The 119 million figure is the exact sum of two mints to one recipient, not every mint on the route or a verified dollar loss.ScopeBoundaryIncident contextOctober 12, 2026; official notice published October 13Direct evidenceSeven selected transactions: six on Base and one Ethereum payoutReview checkpointOctober 14, 2026, 00:14 UTC; selected-record review, not continuous chain coverageCounting ruleMinted THEO, ETH sale receipts and bridge stages kept separate; gas excluded from asset amountsThree findings guide the account. First, the two selected mint receipts establish 119 million THEO issued to one address, extending the initial 19 million alert without establishing a campaign-wide total. Second, an exact identifier match and the Ethereum payment logs connect one Base deposit with actual destination delivery. Third, neither that delivered amount nor the wallet’s whole balance establishes the incident’s net proceeds. The chronology below explains the evidence behind each distinction.First, separate the token record from the people involvedTHEO is a token: its contract keeps a ledger of who owns how many units. Minting creates units in that ledger. A transfer from the all-zero address is the usual accounting sign of a mint; it is not evidence that a real wallet at that address funded the recipient. ETH, or ether, is the native asset used on Base and Ethereum. Receiving ETH after a sale is a different event from receiving newly issued THEO.The transaction submitter, the token contract and the mint recipient also have different roles. A wallet submitted a message-processing call to a contract on Base. The token contract recorded the issuance. A separate wallet received THEO and later submitted the sale. Calling the first wallet “the attacker” solely because it submitted a message would erase the unresolved question of whether it was a legitimate relayer processing an unauthorized origin-side event.A relayer carries information between chains. It does not necessarily move the same physical token from one ledger to another. A destination system can act on a message and issue a local token representation. Establishing whether that issuance was authorized requires the source message and the verification rules in force at the time, not just a destination-side Transfer event.Figure 1 is a route overview before the chronological account. Start with the blue issuance box, follow it to the receiving wallet, then read the two selected branches. The green branch pairs THEO sold with ETH received; the amber branch is a token transfer to another address. The layout groups roles rather than placing all transactions in time order.Figure 1. Selected Base records, not a complete supply reconciliation. Equal-width arrows show issuance and transfer direction. Colors distinguish record roles, not levels of certainty or asset value. The sale amount is rounded to approximately 9.501 million THEO and its ETH receipt to six decimals; the native text and tables retain exact values. Sources: mint receipts, selected sale and bulk transfer in the appendix.The overview shows why a receiving address is not automatically an owner cluster. THEO reaching a second address establishes a transfer, but not its control or consent. The next sections follow when the issuance, conversion and cross-chain payment actually occurred.17:06:59 UTC: a message-processing call records a 19 million THEO mintAt Base block 52,517,736, a successful transaction called the function displayed by BaseScan as process(bytes _metadata, bytes _message). Its receipt contains a Process event with origin domain 2127, a ProcessId event, a ReceivedTransferRemote event and a THEO Transfer from the zero address to the receiving wallet. The last two events contain the same raw amount, 19000000000000000000000000. Dividing by the token’s displayed 18-decimal precision gives exactly 19,000,000 THEO. Mint receipt; token precision.These logs place message processing and issuance inside the same successful transaction. The explorer’s decoded metadata field is empty. That observation does not, on its own, prove a verification bypass: a security module may use other state or caller rules. The origin domain and sender fields are data accepted in this execution, not independent proof of a corresponding backed transfer on the origin chain.The next question is therefore about authority. Which security module and remote sender were configured at this exact block, and what origin-side record justified this message? Current proxy implementation fields cannot substitute for a historical configuration check. The selected receipt establishes issuance, while that authorization question remains open.17:10–17:16 UTC: an unsuccessful attempt precedes a successful saleThe receiving wallet submitted a swap call at 17:10:21. It failed with the custom error SwapFailed. Its gas expenditure is real, but the failed transaction must not be counted as a completed token sale. Failed attempt.At 17:16:13, a different call to the same swap contract succeeded. The overview records 9,501,032.606830209368510124 THEO moving from the wallet to that contract and 189.059271901143347167 ETH returning from the contract to the wallet. The transaction includes many intermediary token conversions and an internal-error warning, but its overall status is Success and its final transfers are recorded. An internal failed route is not the same thing as failure of the whole transaction. Successful conversion.This is evidence of a conversion and a final ETH receipt, not a reason to add every intermediary USDC, WETH and ETH movement together. It also does not establish that every THEO unit sold originated in the selected 19 million mint. Earlier holdings and other token movements need their own reconciliation. The sale’s input is not simplified to exactly 9.5 million THEO in the evidence register.Selected conversionExact asset amountTHEO sent to swap contract9,501,032.606830209368510124 THEOETH returned to the wallet189.059271901143347167 ETHTransaction fee, not sale output0.000089389210983019 ETH17:18:15 UTC: ETH enters Relay on BaseTwo minutes and two seconds after that successful conversion, the wallet sent 280.448146679916230118 ETH to an address BaseScan labels Relay: Depository. The deposit exceeds the ETH receipt from the single sale just discussed. It must therefore be read with the other receipts and starting funds, rather than attributed wholly to that one conversion.The successful deposit’s log 227 names the sender, the exact native amount and a 32-byte request identifier. A request identifier is a reference that can help distinguish one cross-chain operation from another. It is stronger linking evidence than two transfers happening a few seconds apart or having similar amounts. Base deposit and request ID.A deposit is still only the source-side record. It does not prove what arrived on Ethereum. To answer that question, the investigation must locate an actual destination transaction and check both its recipient and the reference connecting it to the deposit.Eight seconds later: the Ethereum transaction records actual deliveryAt Ethereum block 26,177,837, timestamped 17:18:23, a successful solver-submitted transaction paid 278.520848939786734261 ETH from the Relay: Router V3-labeled contract to the same hexadecimal address as the Base depositor. Logs 54 and 55 record the recipient and exact amount. The source deposit’s 32-byte identifier also appears as the final 32 bytes of this transaction’s input data. Ethereum payout logs; input data.The destination’s decoded FundsMovement metadata is a different value. The matching source identifier was found in the transaction input, not in that event. This distinction matters for reproducibility. The evidence is an exact byte match plus an actual destination payout, rather than a claim that the explorer decoded the same identifier into both events.This supports linking the selected deposit and payment without relying only on their timing. It is not a replay of Relay’s settlement system or a complete audit of its order records. The original order response would make the identifier’s service-level meaning independently checkable as well.StageETHMeaningBase deposit280.448146679916230118Source native amount in RelayNativeDepositEthereum payment278.520848939786734261Actual recipient amount in payout logsArithmetic difference1.927297740129495857Not independently classified as a pure bridge feeThe two native amounts should not be added as separate losses. Nor should their difference automatically be called the bridge fee: solver conversions, price movement and fees can affect the delivered amount. Determining that breakdown requires the quoted route and settlement accounting.Read Figure 2 from the Base deposit at the top to the Ethereum payment at the bottom. The middle panel identifies the linking evidence: the source request ID is also present in the destination transaction input. The arrows represent the selected linked stages, not a scale of value or elapsed time.Figure 2. One source deposit and one actual payout on October 12, 2026. Values are rounded to six decimals; the table above preserves full precision. The source identifier is found in destination calldata, not in the destination FundsMovement metadata. Other deposits and their fulfillment status are outside this figure. Sources: Base deposit and Ethereum payout links above.The destination evidence goes further than a source deposit alone: it records an actual payment. It still leaves the remaining orders and the wallet’s pre-existing funds to reconcile. The chronology now returns to Base, where a second, larger mint followed.17:45:03 UTC: a second mint adds 100 million THEOAt Base block 52,518,878, the same submitter called the same message-processing target. The successful receipt again includes Process, ProcessId, ReceivedTransferRemote and Transfer events. Log 249 records 100000000000000000000000000 raw units issued from the zero address to the same receiving wallet: exactly 100,000,000 THEO at 18 decimals. Its message ID is different from the first mint, so these are two distinct transactions rather than two views of one issuance. Second mint receipt.The two mints are 38 minutes 4 seconds apart and sum to 119,000,000 THEO. This expands the observed issuance beyond the 19 million in the early alert. It does not establish the entire route’s incident-wide mint total or whether matching collateral existed on origin domain 2127. Those are separate scope and authorization questions.17:57:55 UTC: 93,510,011 THEO reaches a separate addressA later successful transaction, Base block 52,519,264, records 93,510,011 THEO moving from the mint recipient to a second address. The token’s log 591 contains the full sender, recipient and raw amount 93510011000000000000000000. Bulk transfer receipt.BaseScan displays an ENS name for that recipient. A displayed name is not evidence that the recipient shared control with the sender or knowingly participated in the incident. The diagram stops at receipt rather than extending an ownership accusation. This selected-record review does not establish the recipient’s current token balance or its later disposition.What these records do not establishPeckShield’s original alert associated the incident with 19 million minted THEO and 700.8 ETH swapped or bridged. The Ethereum address overview displayed approximately 700.8 ETH during this review, but the same address has signed activity predating the selected mint. A whole-address balance is not a transaction-specific proceeds ledger. This report does not reproduce that headline as an independently verified loss total. Original alert; Ethereum address history.The Base address list also shows several other Relay deposits and multiple swap calls. The selected payment is one linked branch, not evidence that every deposit had the same destination or was fulfilled on the same terms. A complete account reconciliation would separately identify all successful sale receipts, failed attempts, initial funds, fees, source deposits and request-linked destination receipts.The observed route does not establish a real-world operator, a completed exchange cash-out, recovery or a freeze. It also does not establish whether the minting failure was inside Autheo’s route configuration, an origin-side authorization failure or a broader messaging-system compromise. The historical verification module, approved remote sender and corresponding origin-chain message remain the specific records needed to test those explanations.The next evidence should address authority and accounting separatelyFor the mint, the useful package is the origin-chain transaction, its message identifier, the destination’s incident-block implementation and the verification-module configuration that accepted it. Comparing those records would test whether an authorized relayer handled a false or unauthorized message, rather than assuming that the transaction submitter was itself the exploiter. Autheo’s announced shutdown is a response action, not evidence resolving that cause.For the proceeds, the next step is to reconcile every successful sale receipt against the wallet’s earlier THEO and ETH holdings, then pair each Relay deposit with its own order record and destination payment. This would separate newly realized value from older receipts and explain conversion costs without assigning every unit in the Ethereum balance to this event. Any service request should name the exact deposit, payout and identifier; there is no verified exchange-freeze target in the selected records.The central finding is consequently bounded but useful: two selected mints issued 119 million THEO to one recipient, and the records distinguish an actual sale receipt, one identifier-correlated Ethereum payment and a separate bulk THEO transfer. The complete issuance scope, the authorization failure and the incident-specific net proceeds remain separate questions. Following one value-bearing route does not answer all three.Evidence appendix: selected transaction anchorsMethod and provenance: SentinelTX was used to identify investigation leads; the seven transaction anchors below were then inspected directly in BaseScan and Etherscan, including the relevant mint, deposit and payout logs. The official notice supplies the project’s incident account; explorer records supply transaction facts; arithmetic and identifier comparisons are this report’s analysis. This is a selected-record reconstruction, not an exhaustive account audit or a determination of operator identity. Explorer address labels are service annotations, not proof of ownership. The review checkpoint above is when this selection was checked, not an inferred provider-query cutoff.UTC on October 12RecordFull transaction hash17:06:59 · Base 5251773619,000,000 THEO mint0x4fdbbc5e7d18e92790a6b21d6711a12a5cbb0557b829efde3901e682cd73cd8817:10:21 · Base 52517837Failed swap; excluded from proceeds0x4f0cdcaecf1b55abf8d363b35ce705bfe965c132157f3dffce692294d6a130e017:16:13 · Base 52518013THEO input and ETH receipt0x9d2a604246abdd8b8a847049f114a670218d307a3160d37a0c4e567edde73fcb17:18:15 · Base 52518074Relay native deposit0x88728afe998c34a50f7dcbfb8e1afe1ae62e13a2952f1a30dd08b8589722215417:18:23 · Ethereum 26177837Actual native payout; source ID in calldata0x1041849f2e569c355623ecac29c99105dd7afc2638ef4b518de8d7f664b3a55717:45:03 · Base 52518878100,000,000 THEO mint0x8c8dc4d6ae3db970339eabb498e19eeaa6555999d4752f54bfdbc1483a66073017:57:55 · Base 5251926493,510,011 THEO transfer0x3662883f9f4c072566dba4f1aade3e93ae2c43dee3a7eb83e5382de9f984dfa1Address roles by chainRole and chainFull addressMint transaction submitter · Base0xeF305Ec5DF4054B15295A0389787bf671Ab930CEMessage-processing target · Base0x14b8591b00671835A2d5bb7A3B6822319e853EA7THEO token · Base0xebE516a20238F79DC20b07eaD6768e08891Ed309Mint recipient / seller / depositor · Base0x3048b4Ee5A070F33b73E3401829847255079E0ADSwap target · Base0x599bFa1039C9e22603F15642B711D56BE62071f4Relay: Depository label · Base0x4cD00E387622C35bDDB9b4c962C136462338BC31Relay: Router V3 label · Ethereum0xb92fe925DC43a0ECdE6c8b1a2709c170Ec4fFf4fActual payout recipient · Ethereum0x3048b4Ee5A070F33b73E3401829847255079E0ADBulk THEO recipient · Base; ownership unestablished0x690d7552375Fcd23Bd2a5E1d74f7445FAdfc6c83Identifiers are not transaction hashesThese values identify the selected deposit or accepted message, not a wallet or transaction. The source deposit ID is the byte sequence compared with the Ethereum input.IdentifierFull valueBase deposit request ID0x4828b9e98b0c7cf339bd2b70b8f15e34556b541dfcae90b7348e899d2ec2c0b1First mint message ID0x90f1798b12b66ceed4570ecdbea9e5e74c20f0daf9efdc4c25d4195918a2f2d8Second mint message ID0xb83af7f85b67993adf0c2ae4fdb9befa88983d1ec1890810640d89bb798b20d2

On October 9, 2026, BitBay’s StableVault on Polygon transferred 14,838.466608989136 DAI to a newly deployed contract. In the same transaction, that contract delivered 14,813.548248 USDC to the address that had deployed it. The USDC left that address 39 seconds later, passing through a MetaMask-labeled router to an unlabeled contract where the report’s incident trail stops.SentinelTX assesses the transaction as a flash-liquidity-assisted vault accounting exploit, consistent with a reported flaw that allowed a full withdrawal when liquidity equaled zero. The recorded DAI payout and USDC receipt anchor that finding. Their conversion relationship is inferred, and the report does not decode the vault’s ABI or the conversion swap.A later 4,156.374927 USDC receipt followed the same exit route. Its relationship to BitBay remains unresolved, so it is kept separate from the seed vault loss throughout this article. The receiving address’s total USDC activity is broader than the value attributed to the vault.This article adapts “BitBay StableVault Incident — Polygon Investigation Report,” SentinelTX case CASE-ASYNCA99, dated October 12, 2026. All case findings and qualifications come from that PDF. Times are UTC, and the chain is Polygon PoS, chain ID 137. The report’s “verified” transfer status means the transfer was retrieved; it does not by itself establish who signed it or whether it was authorized.Funding and deployment preceded the vault payoutAt 02:00:17 on October 9, the starting externally owned account, or EOA, 0x59ae3c…e9884b, received 2,461.5991 MATIC from 0xc1d134…18a1b5. The report identifies this as the EOA’s only inbound native transfer on Polygon in the provider list it read to its end.The funding contract is unlabeled in the consulted label database. A public-documentation search snippet associates the same address string with a Bridgers contract on Avalanche. SentinelTX treats this as a single-source lead consistent with a cross-chain payout. Its bridge check found no correlated source swap, leaving the funding chain and originating address unresolved.The EOA’s first outgoing transaction, at 02:15:12, deployed 0x8eac46…330f43b. No subsequent EOA call to that contract appears in the transaction list. SentinelTX suggests it may have been a test or failed build; its purpose remains unresolved.At 02:18:45, the EOA deployed the contract used in the incident, 0xc2c6f4…3c23e2. At 02:23:42, block 95204942, it called that contract with selector 0xde463630. This successful, zero-native-value call is the seed transaction for the report.Within that transaction, BitBay’s vault 0x048e88…f2e5a0 paid 14,838.466608989136 DAI to the deployed contract, and the contract sent 14,813.548248 USDC to the EOA. These are different assets and different quantities. The report’s vault-loss figure is the DAI payout, rather than the USDC that reached the EOA.The call sequence supports an accounting exploit assessmentThe PDF cites press snippets reporting SlowMist’s account of the flaw: StableVault’s _withdraw() function permitted a full withdrawal when liquidity == 0. In that description, a zero-liquidity reading became permission to release the full position. The primary SlowMist X post is not quoted in the report.SentinelTX’s recorded call tree contains 221 frames, reaches a maximum depth of 10, and has no revert. Its reconstruction proceeds through the following stages:Initial reads. The deployed contract reads the vault and its own DAI balance.First liquidity source. It calls Uniswap-labeled 0x5645dc…40a8cf, which transfers 106,411.49245613333 DAI to the deployed contract and calls back into it.Nested liquidity source. Inside that callback, it calls Balancer-labeled 0xba1222…6bf2c8, which supplies 1,453.5690015255825 DAI and makes another callback.Vault deposit. Within the nested callback, the deployed contract approves DAI and calls the vault. The vault pulls DAI, then interacts with Uniswap-labeled 0x673667…3e5cd6 through a session containing liquidity, take, settle and swap-type calls.Direct pool interaction. The deployed contract opens its own session with that same Uniswap-labeled address, including a USDC take and a DAI transfer.Vault withdrawal. It calls the vault again. The vault opens another pool session and receives DAI. The recorded seed movements include the vault’s 14,838.466608989136 DAI payout and the contract’s 14,813.548248 USDC payout to the EOA.Other seed-transaction receipts into the deployed contract include 93,037.23599691519 DAI and 107,843.364597 USDC from 0x673667…3e5cd6. These larger execution flows are not the reported vault loss. Adding them to the DAI payout would mix liquidity used during execution with the value attributed to the affected vault.SentinelTX assesses this as flash liquidity funding a vault deposit, followed by a direct change to the underlying position’s state and then a withdrawal. That sequence is consistent with the reported liquidity-zero flaw. The PDF leaves important parts undecoded: repayment to the liquidity sources, the vault ABI, and the swap connecting the extracted DAI to the USDC delivered to the EOA. The conversion is an inference from the observed amounts.Diagram 1. The seed transaction on October 9, 2026 at 02:23:42 UTC. The PDF separates a press-reported liquidity-zero withdrawal flaw from the observed transfer of 14,838.466608989136 DAI from the vault to the exploit contract and 14,813.548248 USDC from the contract to the EOA. It treats the DAI-to-USDC conversion as an inference, not a decoded swap, and does not decode the repayment legs. Equal-width arrows indicate mechanism or transfer direction, not value.Color key: Slate identifies the vault’s DAI payout; sage identifies the first-wave USDC delivered to the EOA. Neutral text shows the press-reported mechanism.Address/role key: Vault = 0x048E88311ca84876aeA086125825492e2AF2e5A0; exploit contract = 0xc2c6f4f7e1425be1dcb996175cf7852bf53c23e2; EOA = 0x59Ae3c8dd50063429D86BdaEBbC350fB64e9884B.Source: SentinelTX, BitBay StableVault Incident — Polygon Investigation Report, CASE-ASYNCA99, October 12, 2026, pp. 8–9, §5 “Transaction Typology.”The first USDC receipt left in 39 secondsAt 02:24:21, the EOA called 0x3a0b42…3d7a16, labeled MetaMask, immediately after an approval call to the USDC contract. The exit transaction moved 14,813.548248 USDC from the EOA to 0xfb7c74…86b025.The report describes the recipient as an unlabeled, high-volume contract. A search snippet showing a fee event supplies a possible router or settlement-address lead, but no verified operator attribution. “MetaMask-labeled” describes the router label consulted by SentinelTX; the onward recipient is a separate address.The incident’s USDC route is therefore established to that receiving contract. Its destination network and eventual recipient are not established. Bridge-correlation checks on the two USDC exits and the later MATIC exit found no correlated destination. SentinelTX assesses the pattern as typical of a swap-or-bridge exit, while retaining that unresolved boundary.A later USDC receipt cannot be added to the BitBay lossAt 03:36:48, the same EOA deployed 0x5e5b9d…ad4606. Five calls with selector 0xbb2bd489 followed between 03:38:15 and 03:41:54.At 03:42:59, block 95208113, another call to that contract produced 4,156.374927 USDC from the Uniswap-labeled 0x673667…3e5cd6 to the EOA. The transaction has 13 call frames involving the newly deployed contract, that Uniswap-labeled address, USDC and the unlabeled 0x3a9a81…20fc34. The BitBay vault does not appear in this call tree.SentinelTX assesses the pattern as settlement of a position in 0x3a9a81…20fc34, possibly built by the five preceding calls. Whether that position represents BitBay value, a second victim’s assets or the operator’s own capital is unresolved.At 03:43:27, the EOA forwarded all 4,156.374927 USDC through the same MetaMask-labeled router to the same receiving contract. The repeated route connects the activity operationally, but does not establish the source of the second receipt.Figure 2. Two separately scoped USDC receipts at the same EOA on Polygon: 14,813.548248 USDC at 02:23:42 UTC and 4,156.374927 USDC at 03:42:59 UTC on October 9, 2026. Bars share a zero baseline and an axis measured in USDC. The later wave’s relationship to BitBay is unresolved; these receipts are not a combined BitBay loss total.Color key: Sage identifies the first-wave USDC proceeds from the seed transaction; amber identifies the later USDC receipt whose BitBay relationship is unresolved.Address/role key: EOA = 0x59Ae3c8dd50063429D86BdaEBbC350fB64e9884B; first-wave sender = exploit contract 0xc2c6f4f7e1425be1dcb996175cf7852bf53c23e2; later-wave sender = Uniswap-labeled 0x67366782805870060151383f4bbff9dab53e5cd6.Source: SentinelTX, BitBay StableVault Incident — Polygon Investigation Report, CASE-ASYNCA99, October 12, 2026, pp. 4–5, §1; p. 7, §3; p. 9, §5.Keep the account totals separate from the lossThe report’s quantities describe different parts of the record:Seed vault loss: 14,838.466608989136 DAI, paid to the deployed seed contract.First EOA payout: 14,813.548248 USDC, received in the seed transaction and forwarded at 02:24:21.Later EOA payout: 4,156.374927 USDC, received at 03:42:59 and forwarded at 03:43:27, with its relationship to BitBay unresolved.Total EOA USDC movement: 18,969.923175 USDC received and 18,969.923175 USDC forwarded; net movement over the traced scope is 0. This is account-flow accounting, not an additional loss figure or a queried current balance.MATIC funding and disposal: 2,461.5991 MATIC received; 2,443.061934040620841817 MATIC sent to the MetaMask-labeled router at 03:43:51; 18.515648776563152138 MATIC spent as gas in the provider-listed rows.MATIC accounting remainder: 0.021517182816006045 MATIC, calculated as provider-list inflows minus outflows minus gas. Appendix A expressly says these provider-list totals are not a balance.The PDF’s narrative and quantity summary print the seed loss as 14,838.466608989136 DAI. Its evidence table retains additional precision in the “Transfer amount” column: 14,838.466608989135865711 DAI. This article preserves the report’s narrative figure for the main finding and identifies the more precise table value here.The whole recorded sequence runs from funding at 02:00:17 to the MATIC exit at 03:43:51, approximately 1 hour 44 minutes. The report finds no fund return, negotiation message or bounty transfer in the EOA history it describes. It identifies zero exchange deposits in the examined evidence, leaving any later exchange deposit or fiat cash-out undetermined.The exit boundary defines the next useful evidenceThe last receiving contract in a trace does not establish a final cash-out destination. At 0xfb7c74…86b025, the report records 4,467 rows read and left unwalked, a page limit and a provider page that did not answer. The router’s outbound read and the funder’s inbound read stopped at high-volume boundaries. These collection limits matter when interpreting the missing onward path.SentinelTX prioritizes routing records for the three exit transactions. It recommends seeking the route adapter, destination network and recipient from the router operator, identifying the receiving contract’s operator, and obtaining settlement records for the two separate USDC legs. These are proposed next steps, not completed information requests or established recovery routes. No exchange freeze target is anchored in the report.The funding lead is separate. SentinelTX recommends obtaining a source-chain record for the 2,461.5991 MATIC payment and examining the same address’s existing Relay history on Ethereum and BSC under a separate scope. The PDF records those cross-chain leads without linking their transaction hashes to the Polygon incident.For wave 2, it recommends classifying 0x3a9a81…20fc34 and decoding the five preceding calls. For BitBay, it recommends pausing or deprecating the affected vault, auditing sibling vaults with the same liquidity-zero withdrawal logic, and publishing a post-mortem reconciling the full vault-side loss. The report does not contain the vault’s full token history, so loss in other transactions remains unresolved.Figure 3. The PDF’s conclusion separates the seed-transaction loss of 14,838.466608989136 DAI from the traced USDC endpoint. The onward network and recipient are unknown. No exchange deposit is identified in the examined evidence; a later exchange deposit or cash-out remains undetermined. Wave 2’s relationship to BitBay is unresolved, and the full vault token history is outside the report. The priority next step shown is the report’s request for router routing records.Color key: Slate marks section headings only; conclusions and limits are stated in text.Address/role key: Unlabeled settlement contract = 0xfb7c744da69aef11dfb54f31d9db12a3b086b025; MetaMask-labeled router = 0x3a0b42ce6166abb05d30ddf12e726c95a83d7a16.Source: SentinelTX, BitBay StableVault Incident — Polygon Investigation Report, CASE-ASYNCA99, October 12, 2026, pp. 12–13, §9 “Conclusion.”Continue from the documented boundaryThe useful continuation is to establish what happened beyond the two USDC exits while preserving the distinction between the seed loss and the later receipt. In SentinelTX, start from the seed transaction and the report’s unresolved routing boundary. A focused investigation prompt is:Investigate the BitBay StableVault incident on Polygon PoS, chain ID 137, using transaction 0x5b795dc5c5e1665b712c7ccf478c1d8c59a162d698f4e0bfb40bd303e04a7ff2 and case CASE-ASYNCA99 as the October 12, 2026 baseline. State the query time, window and collection limits. Trace the onward destination of the two USDC exits, 0x397c0c95e3bea5966d9bec90bf752b7850809b8e82ff1b82b95d30011562f821 and 0xcc6be3077e62cba412d790e074e81030f4ecc188ff9d0f1408affb765d4dabb4, and the MATIC exit 0xa48e780331293f52ef5928ffeb29d5298d679861f1decc12289828ff1b96792c. Keep the 14,838.466608989136 DAI seed loss, 14,813.548248 USDC first payout and unresolved 4,156.374927 USDC wave separate. Can the route adapter, onward network and recipient be established, and what supports any exchange or bridge attribution? Distinguish retrieved transfers, decoded execution, assessments and provider-list accounting.Source and scopeThe sole factual source is the 20-page native SentinelTX PDF, “BitBay StableVault Incident — Polygon Investigation Report,” case CASE-ASYNCA99, dated October 12, 2026 and generated at 00:28:56 UTC. Its executed query windows span September 9 to October 12. The 11 retained movement rows run from October 9 at 02:00:17 to 03:43:51; a query window is not continuous transaction coverage.The article follows the PDF’s incident quantities and explicit qualifications, rather than treating every edge in its figures as incident loss. The PDF warns that a drawn edge also totals other transfers between the same addresses. That aggregate is not used here.

On October 9, 2026, an Ethereum address received 7.477952467865157 WETH and 43,855.90219627576 VISTA in a transaction that made two swap-selector calls against an EtherVista liquidity pair. SentinelTX’s report follows the subsequent disposal: VISTA went to the burn address, while ETH unwrapped from WETH was converted into 18,590.716460 USDC. Its detailed chronology lists three later transfers totaling 11,000 USDC to a pre-existing wallet; a broader flow-summary figure differs.The sequence gives the approximately US$18,600 public incident estimate a concrete proceeds trail. It also leaves important boundaries. The pair’s reserve changes are not quantified in the report, the reported overflow mechanism remains an assessment, and the two ending USDC positions are calculated from flows rather than measured balances. No exchange deposit, bridge deposit, or mixer interaction was identified in the traced flow.This article adapts “EtherVista Pair Incident — Ethereum Investigation Report,” SentinelTX case CASE-ASYNC2B8, dated October 10, 2026. All incident findings and qualifications come from that PDF. Times are UTC. The report’s stated incident window ends at 00:00 on October 10; the positions below describe its record, not a current balance check.A short setup preceded the pair transactionThe starting address, 0xbbf8f3…2018fa, was a new externally owned account, or EOA. At 03:37:59, it received 0.046448 ETH in the report’s narrative accounting from an address labeled “HitBTC, UnionChain.ai.” That label is a funding lead; it does not identify the person behind the new account or establish the funding address’s wallet type.At 03:42:23, the EOA’s first transaction deployed the helper router 0x469424…83b120. The deployment establishes the reported creator relationship; it does not by itself establish continuing administrative control.A small purchase at 03:43:59 sent 0.004008 ETH through a different intermediary and returned 0.005864694170948497 VISTA. The EOA then made a VISTA-contract call at 03:47:11 using selector 0x095ea7b3, which matches the standard ERC-20 approval signature. The report does not decode the spender.The distinction between the two routers matters. The newly deployed helper executed the incident transaction. The intermediary used for the small purchases, 0x9bd63c…94a72a, also served an unrelated trader. SentinelTX assesses it as a public EtherVista router. Its appearance in the route does not make it part of the operator’s infrastructure.At 03:47:59, block 26152259, the EOA called its newly deployed helper. The report records two calls from that helper into EtherVistaPair 0xfdd055…f02041, followed by the WETH and VISTA receipts that anchor the case narrative.The two-swap structure explains the mechanism assessmentThe report describes a 35-frame call tree that did not revert. First, the helper queried the factory and pair, then called the VISTA token with a selector matching transferFrom. Its first pair call used selector 0x022c0d9f, matching the standard swap signature; within that call, the pair transferred WETH and read the two token balances.Between the two swap-selector calls, the helper called WETH’s transfer selector and the pair’s 0xfff6cae9 selector, which matches sync. Another WETH transfer preceded the second pair call, during which the pair transferred VISTA. A final WETH transfer from the helper is consistent with the reported payout to the EOA. These function names are signature matches, not ABI-decoded meanings.SentinelTX interprets the pattern as two crafted swaps with an intervening reserve update. In the model described by the report, a Uniswap V2-style pair compares an adjusted post-swap balance product against the product of its stored reserves. If the reserve multiplication can overflow its integer type, the comparison can use a wrapped, artificially small value. A manipulated reserve state could then allow a swap to pass with a disproportionately small input.The reported quantities fit that interpretation: the EOA had received only 0.005864694170948497 VISTA before the transaction, yet the transaction returned 7.477952467865157 WETH and 43,855.90219627576 VISTA. The report treats the WETH receipt as a lower anchor for extracted WETH and assesses the pair as its most plausible source.The overflow attribution remains SlowMist’s, cited through the secondary reporting retrieved by SentinelTX. The PDF does not reproduce the pair’s source code or its exact pre- and post-transaction reserves. Its call-sequence interpretation is consistent with the reported overflow, but does not independently prove that root cause or establish the pair-side net loss.Diagram 1. The report’s interpretation of the two-swap sequence. This is an explanatory adaptation of the call structure, not a screenshot of the investigation graph. Selector names are signature matches; the report qualifies the call-structure finding as unverified.Color key: Slate = router-to-pair call sequence; sage = final WETH payout. Arrows show the labeled calls, sequence, or payout, not quantities.Address/role key: EOA 0xbbf8f3…2018fa; helper router 0x469424…83b120; EtherVistaPair 0xfdd055…f02041.Source: SentinelTX, “EtherVista Pair Incident — Ethereum Investigation Report,” October 10, 2026, pp. 5–6 and 12–13.VISTA went to the burn address; ETH became USDCAfter the pair transaction, the EOA made several small VISTA purchases and a 2.0 VISTA sale. The chronology’s 03:54:11 row lists 0.006027 ETH outgoing, 2.0 VISTA sent to the pair, and 0.000341 ETH returning through the intermediary. The report interprets this activity as probing the pair’s post-incident state. Across the observed record, the EOA received 43,932.080656851984 VISTA, including the incident receipt and the small purchases, and sent 2.0 VISTA back to the pair.At 03:55:47, it sent the remaining 43,930.080656851984 VISTA to 0x000000…00dead. SentinelTX assesses the burn as destruction of that token value and describes VISTA as having no exit market for the operator through its evident liquidity venue.The WETH leg followed a different path. Six withdraw-selector calls between 03:59:35 and 04:05:11 returned 1.0, 2.0, 2.0, 2.0, 0.46, and 0.017 ETH, totaling 7.477 ETH. The report calculates 0.000952467865157 WETH as the difference between the original WETH receipt and the quantity unwrapped. That is an accounting difference, not a separately queried token balance.The EOA then used the Uniswap Universal Router to convert ETH into USDC through V3 and V4 liquidity. The three transactions were:04:41:59: 3.0 ETH for 7,469.156952 USDC04:43:11: 3.362307 ETH for 8,369.649164 USDC04:44:11: 1.105714 ETH for 2,751.910344 USDCThe report’s total is 7.468021 ETH converted into 18,590.716460 USDC. This realized USDC quantity is consistent with the approximately US$18,600 public estimate. It is not a reserve-delta calculation of the pool’s loss. Nor should the report’s gross movement totals be used as loss figures: those recount value as it moves between addresses and can include movements outside the incident’s proceeds accounting.Figure 2. USDC received in the three reported ETH conversions. The bars compare proceeds in the same unit, begin at zero, and follow transaction order; their spacing does not encode elapsed time. Exact quantities appear in the native list above. The report flags the conversion claim as unverified.Color key: Slate = USDC received.Source: SentinelTX, October 10, 2026, pp. 6 and 9, “Quantity accounting” and “Transaction Chronology.”Three transfers identify a recipient, not its ownerThe next leg consists of three identified USDC transfers to 0x043c8f…f842d3: 1,000 USDC at 05:36:47, 5,000 USDC at 05:41:47, and 5,000 USDC at 05:43:47. The chronology and quantity accounting total these transfers at 11,000 USDC. The generic Fund Flow Analysis separately lists 22,000 USDC across six transfers for the same address pair. The figures are not reconciled in the PDF. This account uses the three individually identified transfers and does not treat the generic summary as a second, established proceeds total.The receiving EOA predates the incident. SentinelTX first dates it to April 14, 2026, and records two USDC transfer calls on April 19, at blocks 24910327 and 24910339. Its earlier history makes it a useful investigative lead. It does not establish that the incident operator owns it.The report’s connectivity test found the direct USDC link, but no common funders or shared counterparties other than the pair. It therefore leaves common control unresolved. The transfer establishes where the reported funds went; the recipient’s role beyond receiving them remains open.At the end of the observed record, SentinelTX gives two flow-derived USDC positions:Receiving wallet 0x043c8f…f842d3: 11,000 USDC received in the three identified transfers, with no outbound transaction in its traced windowStarting EOA 0xbbf8f3…2018fa: 7,590.716460 USDC inflow minus outflowThe EOA’s recorded signed history ends with the third transfer, at nonce 22 and 05:43:47. Neither figure is a live balance reading. The report calls for balance confirmation before using these positions in a recovery request.Look-alike activity sits outside the proceeds trailThe PDF retains several misleading-looking transfers but excludes them from incident accounting. The report distinguishes these suspected poisoning and spam events from the movements it attributes to the incident.At 04:09:23, an event showed 43,930.080656851984 units of a token labeled “ERC” going from the EOA to a look-alike of the burn address. Its amount mirrored the genuine VISTA burn. The report says this event was emitted by a third-party contract and was absent from the EOA’s signed transaction list. It classifies it as suspected poisoning or spoofed spam.At 05:41:23, a different address that resembled the starting EOA sent 0.0001 USDC to the receiving wallet. That transfer occurred 24 seconds before the EOA’s 5,000 USDC transfer. SentinelTX classifies it as suspected address poisoning aimed at the counterparty. The small transfer does not establish a related actor or add to the incident’s three-transfer consolidation.An unsolicited receipt of 1,000,000 “PVC” was also excluded because its token contract was unclassified and the evidence supplied no value basis. These exclusions preserve the distinction between activity appearing around an address and proceeds attributed to this incident.The report’s recovery priorities follow the USDC and the funding leadSentinelTX identifies the two USDC positions as its immediate recovery targets and recommends an issuer freeze request accompanied by current balance confirmation. It records no exchange-deposit leg from either the EOA or the receiving wallet, and no bridge, mixer, or cross-chain continuation. Those are findings within the traced scope; the report does not establish where the funds may have moved after its cutoff.The funding transaction provides a separate identification lead. The sending address, 0x963737…b2ef9a, carries the label “HitBTC, UnionChain.ai.” SentinelTX recommends asking the exchange to confirm the address’s nature and the account record behind the 0.046448 ETH funding transfer. This is conditional on confirming that it was an exchange withdrawal wallet. The label alone establishes neither the account holder nor an exchange cash-out from the incident.The receiving wallet’s April history is the other priority. Its earlier counterparties could help distinguish an operator-controlled wallet from a third party. The PDF also recommends monitoring the starting EOA, receiving wallet, and helper router for the next outbound movement, approval, or bridge interaction.On the protocol side, the report recommends identifying sibling pairs that share the affected swap code and addressing their liquidity exposure. It establishes the incident against one pair only. Its requested next evidence includes verified source, the relevant Swap and Sync events, and a post-mortem quantifying reserve changes. Those steps are the report’s proposed route to establishing the arithmetic root cause and pool-side net loss more firmly.Figure 3. The report’s ending positions and next steps. The two USDC figures come from its incident quantity accounting and are flow-derived, not balance readings. The 11,000 USDC subtotal covers the three identified transfers; the report’s differing generic flow-summary figure is unreconciled. They do not establish a completed freeze, a recovery, or common control of the addresses.Color key: Sage = recipient accounting; slate = starting-EOA accounting; amber = report recommendations. Color does not grade certainty or guarantee recovery.Address/role key: Starting EOA 0xbbf8f3…2018fa; receiving wallet 0x043c8f…f842d3.Source: SentinelTX, October 10, 2026, pp. 7, 9–11, and 16–18, “Positions at the end of the observed record,” “Recommendations,” and “Conclusion.”Follow the next value-bearing movementA useful continuation begins with the incident transaction, then asks whether the two USDC positions changed after the report’s cutoff. Keep the three identified transfers distinct from look-alike activity, and distinguish a new receiving address from an established exchange or bridge endpoint.Request SentinelTX access or sign in, then use this starting prompt:Investigate the EtherVista pair incident on Ethereum mainnet (chain ID 1), using transaction 0xb2c7332d9e1be6a86d9d37083aa4cc0d94b60eb95cc9b29494555a3c09764930 as the seed and case CASE-ASYNC2B8 as the October 10, 2026 baseline. State the exact query time and cutoff. Follow value-bearing activity after 2026-10-10 00:00 UTC from 0xbbf8f3fe8e4fdf6b594e6107144d78293d2018fa and 0x043c8f2df89612f9da2d91a92d30d3295cf842d3. What happened after the three identified USDC transfers, and is there a supported exchange, bridge, issuer-freeze, or recovery event? Distinguish measured balances from the baseline’s flow-derived positions, retain suspected poisoning exclusions, and do not infer common control from the transfers alone. Include transaction links, query limits, and the basis for each endpoint label.Source noteThe sole factual source for this adaptation is the 39-page native SentinelTX PDF, “EtherVista Pair Incident — Ethereum Investigation Report,” case CASE-ASYNC2B8, dated October 10, 2026, with the document generation time printed as 00:28:05 UTC. The article uses the report’s explicit incident chronology and quantity accounting. Token names and classifications follow the report.The narrative’s incident window ends at October 10, 00:00 UTC, exclusive. The executed query record also includes historical lookbacks ending during the October 10 retrieval; these do not establish uninterrupted historical coverage. The PDF marks several central findings as unverified and flags a time-inverted routing path. This article preserves their status as reported findings. Its root-cause attribution, unestablished recipient ownership, and flow-derived ending positions remain qualified here.

On October 7, 2026, the 79th Vault project’s hot-wallet key authorized nine transactions that removed 2,520,000 79AU from a PancakeSwap pool on BNB Smart Chain without paying the pool. Recipients could then sell the tokens back into that same pool to extract USDT and convert the proceeds to BNB. The decisive capability was inside the token contract: an administrative function could move the pool’s tokens directly to a chosen recipient.The full incident extended beyond the first selling wallet described in the initial alert. SentinelTX’s October 9 investigation follows the wider nine-pull scope, the subsequent BNB consolidation and the on-chain negotiation. Its snapshot found approximately 17,881 BNB still held across three wallets, with no recovery recorded.This article adapts the native SentinelTX report, “79th Vault (79AU) Privileged-Function Exploit — Investigation Report,” case CASE-ASYNCAF7. All incident findings and qualifications below come from that report. Times are UTC; balances and recovery status are its October 9 snapshot.A token permission let 79AU leave the pool without paymentThe 79AU token contract, the PancakeSwap pool and the project hot wallet had different roles. The token contract contained the function. The pool held the tokens. The hot-wallet key had permission to invoke it.The function, identified by selector 0x2a2c5923, accepted a pool address, a recipient and an amount. A permitted caller could use those arguments to transfer 79AU from the pool to the recipient without a corresponding payment. The public analysis cited in the PDF describes this function as part of routine reward funding and says the deployer and hot wallet both held the permission when the drain occurred.That changed the pool’s balances before any sale took place. Removing 79AU reduced the token side while leaving the USDT side in place, raising the quoted token price. Selling the removed tokens back then drew USDT out. The report illustrates the price effect with a source-reported move from $8.15 to $22.73 across the two 500,000-token pulls at 07:41.Burning liquidity-provider receipts did not close this route. The PDF states that 79% of the pool’s LP receipts had been burned, protecting against liquidity withdrawal through those receipts. The token’s own permission still allowed it to move 79AU out of the pool.Diagram 1. A privileged token transfer changed the pool’s balances before the tokens were sold back. This is a simplified explanatory diagram based on the report, not a screenshot of the native investigation graph.Color key: Slate = privileged control; sage = 79AU movement; amber = USDT extraction.Address/role key: Hot wallet 0x019bD8ED…30c85cA3; token 0xC35ef056…eeBaa9Ca; pool 0x02D50b93…f08FDa09.Source: SentinelTX, “79th Vault (79AU) Privileged-Function Exploit — Investigation Report,” October 9, 2026, pp. 3 and 10.Nine pulls reached three recipientsThe first pull occurred at 07:25:23 on October 7: 10,000 79AU moved from the pool to the address the report calls Seller A. The transaction was signed by the hot wallet and called the privileged token function. Further pulls increased the amounts reaching Seller A, including a 500,000-token transfer at 07:38:40.At 07:41:04, a separate 500,000 79AU went to Seller B. Four seconds later, another 500,000 went to Seller A. A third wallet received 10,000 at 08:07:29, according to the source chronology reproduced in the report. The ninth and final pull, at 08:18:59, sent a further 500,000 to Seller A.The recipient totals define the scope:Seller A, 0xc3E90f78…4b80A099: 2,010,000 79AU across seven pullsSeller B, 0xf219d073…dd690938: 500,000 79AU in one pullThird wallet: 10,000 79AU in one pull; its purpose remains unexplained in the reportFigure 2. The initial withdrawals from the pool totaled 2,520,000 79AU across nine pulls. These are recipient token quantities, not dollar losses or balances after trading.Color key: Slate = Seller A; sage = Seller B; amber = the third wallet.Address/role key: Seller A is 0xc3E90f78…4b80A099; Seller B is 0xf219d073…dd690938. The PDF does not print a complete address for the third recipient.Source: SentinelTX, October 9, 2026, p. 7, “The nine pulls.”The initial CertiK alert summarized in the PDF covered Seller A: seven pulls, 2,010,000 79AU and approximately $12.5 million. The broader account adds Seller B and the third recipient, with approximately $14.35 million in USDT extracted. These dollar figures are the cited public write-up’s accounting of USDT that left the pool. They should not be added together or treated as a valuation of the tokens pulled.Seller A’s selling window ran from 07:28 to 08:29. The cited write-up counts 92 sales and approximately $12.60 million in USDT proceeds for that branch; the PDF includes a PancakeSwap router call at 08:28:15. Seller B’s later sale of 500,000 79AU, between 12:48 and 12:59, is source-reported as 21 transactions for approximately $1.75 million. Its retained on-chain route in the PDF establishes the incoming 500,000-token pull; it does not establish a verified Seller B-to-pool return leg.Seller B also existed before the incident. Its contract was created on August 23, six weeks before the drain. The cited analysis links its earlier gas funding to the wallet that funded Seller A on the morning of October 7. SentinelTX treats that as a pre-positioning indicator. It does not resolve the identity behind either seller.Seller A’s proceeds converged with the hot wallet’s remaining BNBAt 10:10:47, Seller A sent 16,249.117811 BNB to the collection wallet, 0x629b368c…fe8a6231. This is the consolidation transaction associated with the initial alert.Forty-one seconds later, at 10:11:28, the project hot wallet sent its remaining 3.790317 BNB to the same collection address. The shared destination links the pool-drain proceeds to the sweep of the hot wallet’s own BNB. SentinelTX assesses the sequence as evidence that the party controlling the key controlled both actions.The collection wallet then distributed the BNB. A secondary wallet received 1,302 BNB and sent eight transfers of 10–20 BNB through fresh one-hop relays between 10:22:24 and 12:52:40. At 14:40:46, 1 BNB went through the Tornado.cash proxy to its 1 BNB pool. At 14:58:23, 14,394.916171 BNB moved to the main holding wallet. The collection wallet was empty by the report’s snapshot.Figure 3. Selected onward BNB transfers from the collection wallet. Its cited incoming transfers were 16,249.117811 BNB from Seller A and 3.790317 BNB from the hot wallet. The diagram is not a complete reconciliation of every outgoing transaction, and arrow width does not encode amount.Color key: Slate = collection and routes; sage = holding destinations; amber = the Tornado.cash proxy.Address/role key: Collection 0x629b368c…fe8a6231; primary holding 0xa9537b40…b2174f89; secondary wallet 0x1e2a669e…f31216a3; Tornado.cash proxy 0x0d5550d5…859b17.Source: SentinelTX, October 9, 2026, pp. 7–8 and 10.The key-control evidence has a boundary. Chain data cannot settle whether an outsider stole the key or an insider misused it. The same key later signed the team’s negotiation message. The article therefore identifies addresses by their reported roles without assigning a real-world identity to the person who used the privilege.Small exit routes accompanied much larger parked balancesThree deposits of approximately 10 BNB each reached the same KuCoin deposit address, 0x635308e7…8c7553d9, on October 7 at 10:41:49, 10:53:49 and 11:02:49. Together they account for approximately 30 BNB. The PDF identifies this as the only custodial cash-out point anchored by deposit transaction hashes in the trace, making the receiving account a focused lead for a freeze or KYC-information request.A separate route reached a high-throughput cross-chain swap-service hub, 0xadd2b380…e792d1d. The report cites 10 BNB moving to a relay, followed by the onward leg and 7,619.37 USDT (BSC-USD), at 12:53:24–12:54:24. It assesses these funds as likely to have left BNB Chain. The destination-chain payouts are outside the screened scope, and the hub’s wider traffic cannot be assigned to this case.The 1 BNB Tornado.cash interaction is consistent with a test deposit in SentinelTX’s assessment. Other Tornado.cash contracts observed nearby were not part of the traced flow. Together with the small exchange deposits and the relay transfers, the report interprets the activity as staged cash-out preparation while most proceeds remained parked.As of October 9, the report listed:Main holding wallet, 0xa9537b40…b2174f89: 14,384.806266 BNBSeller B, 0xf219d073…dd690938: 2,284.478912 BNBSecondary wallet, 0x1e2a669e…f31216a3: approximately 1,212 BNBThe report summarizes these holdings as approximately 17,881 BNB. The earlier 14,394.916171 BNB transfer to the main holding wallet is a transaction amount; 14,384.806266 BNB is the later reported balance. A 10 BNB transfer on October 8 from that wallet to 0x789012dc…9233b935 has no established purpose in the report.The bounty negotiation had produced no recoveryThe on-chain conversation began on October 8. At 05:15:21, a message from the project hot wallet offered a 10% white-hat bounty, with 90% to be returned to a designated refund address and no further legal action.At 11:48:59, the holding wallet countered at 25% and demanded removal of the address label and a waiver of legal action. A further message at 13:27:59 requested private contact through Telegram.Those messages document negotiation. The designated refund address, 0x2bfcf047…262eb7b2, held 0.005274 BNB and no tokens in the report’s snapshot. SentinelTX recorded no returned assets. A bounty offer, a counter-demand and a request to continue talking did not establish a recovery.The remaining pull permission was the central preventive issueThe source chronology says the team removed the original hot wallet’s pull permission at 08:24 on October 7 and stripped its rights across all eight project contracts by 16:13. On October 8, between 12:37 and 12:40, the team multisig granted the same permission to a new wallet.According to the public write-up’s dry-run checks cited in the PDF, the deployer and newly added wallet retained or received the capability, leaving approximately 95% of the pool’s remaining 79AU pullable. SentinelTX’s preventive recommendation is to revoke that permission or migrate the contract before further user funds are exposed.The case therefore leaves two practical priorities. On the investigative side, the three KuCoin deposits provide a specific custodial lead, while the large holdings and unresolved swap-service payouts remain important to follow. On the preventive side, the authority embedded in the token must be addressed. Replacing the wallet that holds a permission does not remove the permission’s ability to extract pool tokens.Figure 4. The report’s October 9 conclusion pairs unrecovered holdings with a concrete custodial lead and a continuing permission risk. The approximately 95% pullability assessment comes from the cited write-up’s dry-run evidence. The destination-chain payouts remain outside the report’s scope.Color key: Sage = holdings; slate = negotiation and recovery status; amber = investigative and preventive priorities.Source: SentinelTX, October 9, 2026, pp. 3, 11 and 13–14.Follow the holdings and unresolved outflowsA useful continuation starts with the collection transaction and asks what happened next to the identified holdings and exit routes. Keep the BNB Chain evidence separate from any proposed cross-chain match, and test a recovery claim against actual transfers to the designated refund address.Request SentinelTX access or sign in, then use this starting prompt:Investigate the 79th Vault / 79AU incident on BNB Smart Chain (chain ID 56), using transaction 0xee0e44167518ff0071ede02a03b3710a1a8438d52616aad4bf1d5e417b37b0df as the seed. Start with the October 7–9, 2026 activity described in case CASE-ASYNCAF7, then state the exact cutoff of any updated query. Follow the identified holding wallets and the cited KuCoin and swap-service outflows. Has there been a value-bearing continuation or a return to refund address 0x2bfcf0475e7b40cd68e91a7178cf5e43262eb7b2? Include transaction links and query times, distinguish directly supported findings from candidate relationships or inference, and keep any unestablished destination-chain payout outside the confirmed route.Source noteThe sole factual source for this adaptation is the native SentinelTX PDF dated October 9, 2026, case CASE-ASYNCAF7, “79th Vault (79AU) Privileged-Function Exploit — Investigation Report,” 34 pages. The incident occurred on October 7; the negotiation messages are dated October 8. The report’s October 9 query cutoffs fall between about 06:10 and 06:16 UTC; the PDF was generated at 06:33 UTC.Dollar estimates, selected chronology and the residual-permission dry-run assessment retain the PDF’s attribution to its cited public write-up.

A fake verification step can move the attack surface into an already authenticated browser page. In this case, the decisive analytical distinction is between evidence of a malicious bookmark, evidence of token transfers, and proof of how those transfers were authorized. Those are related questions, but they are not interchangeable.Our direct explorer review identified three USDC transfers from one source owner to the recipient named in SlowMist's original technical analysis. They total exactly 45,106.851598 USDC and span 63 seconds. That matches the reported 45,106.85 USDC total when rounded to two decimal places. The match makes them strong candidate incident anchors; it does not independently establish the source wallet owner's identity or the victim's consent.Scope and evidence boundaryMeasureValue / interpretationNetworkSolanaCandidate inbound total45,106.851598 USDC; three unique successful transactionsCandidate transfer window2026-10-04 08:58:45–08:59:48 UTCReview cutoff2026-10-09 00:32 UTC; historical transaction snapshots, not a complete chain auditPublic loss reportApproximately $48,000 in assets, as relayed by SlowMist; not equated with the exact USDC subtotalIndependent victim confirmationNot obtained; attribution remains a documented candidate matchThe review deduplicates by transaction signature and counts only the single USDC transfer in each candidate transaction. SOL network fees are recorded separately and are not added to the USDC amount. Address-wide activity is kept outside the candidate incident subtotal.Three findings that matter1. The reported withdrawal total has a specific, reproducible candidate matchQuestion: can the reported three withdrawals be distinguished from the recipient's other inflows? The three transactions below share the same source owner, destination owner, USDC mint and decoded transferChecked method. Their exact sum, count and destination fit the public report. The source wallet is therefore an investigative candidate, not a newly identified person.UTC on 4 OctoberUSDC transferredEvidence08:58:4532652.960737A01: transaction detail08:59:235002.490046A02: transaction detail08:59:487451.400815A03: transaction detailThe arithmetic is 32,652.960737 + 5,002.490046 + 7,451.400815 = 45,106.851598 USDC. The 0.001598 USDC difference from the two-decimal public figure is rounding, not a separately identified transfer. What remains uncertain is independent confirmation that these exact signatures correspond to the reported victim's withdrawals.Figure 1. Directly checked candidate transfers. A dashed co-signer panel is an authorization observation, not a money-flow edge. Downstream attribution is deliberately not shown.2. A co-signer label does not resolve the compromise mechanismQuestion: does the chain tell us whether an attacker exported a key or requested remote signing? Each candidate transaction lists the source owner and a second signer that Solscan labels “Fomo Co-signer.” That is evidence about transaction signers and a provider label, not proof of who initiated the request, which authentication material was used, or whether any signing service was compromised.RolePublic address / accountSource owner / transfer authority6R6stpcbSij7scSpD7Refq1eap2gN1Qj3omFeGu3gJPcSecond signer; Solscan label “Fomo Co-signer”AgmLJBMDCqWynYnQiPCuj9ewsNNsBJXyzoUhD9LJzN51Source USDC token accountBcxGQtcyAgX1VrM8sS94aMbFridPqkJ3u8qQx4e4X3PgDestination USDC token accountEpAjLMVnttREdDiXGddym5eYgsn5hH2oPPnQcarTKajMDestination owner named by SlowMistD783JqupQ2FYhkxUfGEd1gaFEoAJDXRX1NEb4aVH2hZ6The owner-level explorer summary and the decoded instruction describe different layers: the summary resolves wallet owners, whereas the instruction names the SPL token accounts being debited and credited. A token account must not be presented as a separate attacker wallet merely because it has a different address.3. A Privacy Cash transfer is verified; its victim attribution is notQuestion: can an address-wide service exposure be treated as this victim's recovered path? A separate successful transaction sends 212.492295 SOL from the named collection owner to a pool Solscan labels Privacy Cash Pool on 5 October at 07:46:10 UTC. This directly supports an address-to-pool transfer. It does not by itself show that those SOL were purchased with the three candidate USDC transfers.ObservationEvidence / limitTransaction4YM1bkC7UjJwLX8zc6FgPbg7yFViDLQfo2hgJ8u9iGAjDDxFv9crdwJ1JkZurmE13JsD56CneJibLtvekoieT3MxAmount and UTC212.492295 SOL; 2026-10-05 07:46:10 UTCPool destination4AV2Qzp3N4c9RfzyEbNZs2wqWfW4EwKnnxFAZCndvfGhProgram9fhQBbumKEFuXtMBDw8AaQyAjCorLGJQiS3skWZdQyQDAttribution boundaryAddress-history evidence only. No independently reconciled route from candidate USDC anchors yet.SlowMist's reported 1,568.33 SOL cumulative Privacy Cash outflow concerns the address's history. It is not substituted for the incident's 45,106.85 USDC subtotal, nor independently reproduced by the single transaction checked here. The intervening swaps, balances and other inflows must be reconciled before assigning a victim-specific downstream amount.How the bookmark crosses the trust boundaryAccording to SlowMist's original technical analysis, a token-page link led to a fake human-verification page that prompted a bookmark action. The saved JavaScript then ran in the logged-in FOMO context and targeted browser storage, IndexedDB and Privy session material. We did not execute the malicious sample or connect to its collection endpoint.Figure 2. Source-based mechanism reconstruction, not an independently replayed exploit or transaction trace. The unresolved signing step is dashed.The useful security conclusion is narrower than “a wallet connection stole the funds”: the described lure sought code execution within a trusted application session. Conversely, the source's conditional MFA logic and the victim's reported absence of 2FA do not establish a demonstrated MFA bypass. Initiating an enrollment flow would also not prove successful enrollment.Timeline: observations rather than invented milestonesUTCEvent and evidence level2026-10-04 08:58:45A01: 32,652.960737 USDC, directly checked2026-10-04 08:59:23A02: 5,002.490046 USDC, directly checked2026-10-04 08:59:48A03: 7,451.400815 USDC, directly checked2026-10-05 07:46:10T01: 212.492295 SOL to provider-labeled Privacy Cash pool; separate address history2026-10-08SlowMist public alert and analysis; not the attack dateThe attack's initial browser-execution time is not established here. The collection address's reported first activity on 17 September is not assigned as the incident start time.Alternative explanations and what would resolve themThe three-transfer match could be strengthened by an original withdrawal record or source confirmation naming the signatures. A transaction's valid signatures do not reveal whether the human account owner approved it. Application-side authentication, session revocation, withdrawal and signing logs would be needed to test competing key-export and remote-signing explanations.For downstream analysis, identical asset values or nearby timestamps are insufficient to prove a bridge connection. A defensible cross-chain edge requires a source transaction, bridge order or fulfillment record, and destination transaction. Ethereum and Bitcoin candidates mentioned by the source remain external leads until that chain of evidence is available; they are not drawn as verified branches here.Case-specific response pointsFor the affected account, preserve the bookmark URL and browser/session chronology without executing the bookmark again. Application operators can correlate the three candidate signatures with withdrawal requests and signing-policy decisions, then evaluate session and refresh-token revocation. A password change alone should not be assumed to invalidate every previously issued session artifact.For investigators, preserve the full source/destination token-account mapping and block references before expanding a cluster. For any service request, provide the specific transaction and account history being queried, and distinguish the verified transfer from a claim about stolen-fund ownership. Provider labels are leads for corroboration, not legal identity findings.Evidence appendixID / slotFull transaction signatureA01Solana slot 45320947444uGoQH6KQRyVDCLuDTUHW3KxR61j9pGnnWWKoGtWFh9b3jUFRQ9t5MMVHoFr5ZWFLgEgWKmgxuR5Wq8tS36XkzNA02Solana slot 4532096174pgANnxQ2Q5139ToXuc7LvHWqBZKKsBXwAVKA4eSi1wLnYdpukbgL2ZheTxXAMevU84HVKJCe1TBTTZ1VN2TZrH9A03Solana slot 453209712xM1eCwjwhV4h9ECr2dTpL4TTDq3YafKiME3qyJcCAiLM3iqZosCVSW3rdQPcUr8AXWhzDrJzd4JKDZDWBJ6q4KMT01Solana slot 4535158714YM1bkC7UjJwLX8zc6FgPbg7yFViDLQfo2hgJ8u9iGAjDDxFv9crdwJ1JkZurmE13JsD56CneJibLtvekoieT3MxToken / technical propertyValueUSDC mintEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1vCandidate instructionSPL Token Program transferCheckedPer-candidate fee0.00001507 SOL; separate from USDC principalSource basisSlowMist's original technical analysisReproducibility limitExplorer-decoded detail checked; no raw RPC replay, victim-account access or complete downstream reconciliation claimedThis report separates directly observed chain transactions, explorer-provided labels, external reporting and analytical inference. It does not identify an attacker or attribute every historical recipient transaction to this case.

Money moved out of a contract on Ethereum, reached a wallet, and then left that wallet in twenty equal transfers. The last transfer came 15 minutes and 24 seconds after the initial withdrawal.The amount was 200 ETH. ETH, short for ether, is the native asset of Ethereum. At the start of this path, it was held in a token form called WETH, or wrapped ETH. During the withdrawal, 200 WETH was converted into 200 ETH.That change of form matters: we are following the same-sized amount through several stages, not adding a new loss every time it moves.A security alert linked the event to an old auction program. We will first explain what that program did, then follow the recorded transfers, and finally separate what is known from what still needs checking.The route in brief: 200 WETH leaves a collateral contract → it becomes 200 ETH → a wallet receives it → the wallet sends twenty transfers of 10 ETH. The records examined here do not establish where the money went after mixing.Incident: October 6, 2026.Evidence cutoff: October 6, 2026, 21:55 UTC (October 7, 06:55 KST).Reading guide: Follow sections 1–6 for the story. Full transaction references and addresses are in the appendix.1. The auction was selling loan collateral, not NFTsWhy does an auction appear in this story? In MakerDAO, users can leave assets such as ETH as security for a loan. That security is called collateral. They borrow DAI, a token designed to track the value of one US dollar, against it.Think of borrowing against something you own. If its value falls too far, the lender may need to sell it to settle the debt. A liquidation auction performs that role here: it sells crypto collateral. The actual system has its own thresholds, fees, and settlement rules. Background: the official liquidation-system proposal.A keeper is software that automates tasks such as bidding in those auctions. It is not the borrower. The person borrowing against collateral and the participant buying it at auction have different roles. Background: the official Auction Keeper project.The next diagram follows the general process from borrowing to receiving the auctioned asset. Read it from top to bottom, paying particular attention to the final two steps.Figure 1. From borrowing to withdrawing collateralA simplified guide to the historical Flipper auction process, not a trace of this incident. The final two boxes separate settlement from external withdrawal. Detailed bidding rules and the wider current system are outside this diagram.Winning, settling, and withdrawing are separate steps. Winning determines the buyer. Settlement records the outcome. Withdrawal moves the asset out to an external address. Finishing one step does not mean all three have happened.In the published historical auction code, a function called deal settles the auction and credits the recorded winning bidder. The person who calls that function does not become the winner merely by calling it. This is general background, not proof of how the exact incident contract was configured. Source: the published Flipper implementation.With that distinction in mind, we can now follow the actual movement of funds.2. Meet the addresses before following the moneyYou do not need to memorize hexadecimal addresses. The names below describe what each address did in the records; they do not identify a person or prove who controlled it.The collateral adapter — 0x2F0b…042A. This contract is the first sender of WETH in the transfer records. Etherscan, the public transaction explorer, labels it “Sky: MCD Join ETH A.” Here, an adapter means a contract used to move collateral into or out of the system.Two intermediate contracts — 0xF09A…C170 and 0xEc997…1dcF. The WETH passes through these contracts. The first is created during the transaction; the second later sends ETH to the initiating wallet. A contract is a program on the blockchain, not necessarily a person's wallet.The initiating wallet — 0x01EB…A5FA. This address starts the transaction, receives the 200 ETH, and then sends the twenty later transfers. We use the same name throughout so that you can recognize it as the story continues.The WETH contract. This contract releases ETH when WETH is unwrapped. “Unwrapping” is the change from the token form to ETH; it is not a gain of another 200 ETH.One distinction will help when reading the next diagram: starting a transaction is not the same as sending every asset inside it. A wallet can instruct a contract, and that contract can trigger further calls and transfers.3. At 06:13:11, the wallet receives 200 ETHOn October 6 at 06:13:11 UTC, the initiating wallet submitted the withdrawal transaction. Within that one transaction, the collateral adapter sent 200 WETH to the newly created contract. That contract passed 200 WETH to the other intermediate contract.The intermediate contract then unwrapped the WETH. The WETH contract paid it 200 ETH, and it passed 200 ETH to the initiating wallet. These are several movements inside one transaction, not several separate withdrawal transactions. Check the withdrawal transaction.In the diagram below, start with the first blue asset-transfer box. Follow the blue WETH path until it becomes the purple ETH path. The gray strip at the top shows who initiated the call, not an additional payment.Figure 2. Separating WETH transfers from ETH paymentsFollow the numbered asset movements from top to bottom. Blue means WETH; purple means ETH. The gray call strip is not a payment. All stages belong to one transaction. Evidence: token logs 174, 176, and 177, plus internal ETH transfers.The important change is at the end: the initiating wallet now holds ETH that it can send onward. The diagram explains that route. It does not explain why the contracts allowed it or establish a system-wide compromise.You can compare the explanation with the explorer screenshot below. Look for the timestamp, the WETH transfer entries, and the internal ETH payments. “Internal” here means payments made during contract execution inside the transaction.Evidence 1. The withdrawal transaction on EtherscanOriginal explorer evidence: compare the timestamp, WETH transfers, and internal ETH payments. The displayed dollar values are not used as incident-time loss estimates. Open the withdrawal record.Several lines show the number 200 because the amount passes through multiple steps. Keep that in mind as we follow it out of the wallet.4. The same wallet sends twenty transfers of 10 ETHAfter receiving the ETH, the initiating wallet sent twenty transactions to the same Tornado Cash router. A router is an intermediate contract that forwards a request to another contract. Each transaction sent 10 ETH, making 200 ETH in total, excluding transaction fees. Check the wallet's transaction history.Tornado Cash is a mixer designed to make a deposit difficult to link directly to a later withdrawal. That is why observing money enter this route is not the same as knowing who later received it.The next diagram gives every transfer its own tile. Read left to right, then move to the next row. A block number identifies the block containing the transaction; the equal tile spacing does not mean equal time intervals.Figure 3. All twenty transfers in block orderOne tile equals one transfer of 10 ETH. Read left to right, then down. Tile spacing does not represent time. Individual transaction links are in Appendix A.The twenty tiles show repeated transfers to the router, all from the same wallet. You can check each transaction separately in Appendix A without interrupting the story here.The explorer screenshot lists the same type of entries in the opposite direction: newest first. Compare the destination and the 10 ETH amounts, rather than reading its rows as the diagram's order.Evidence 2. Repeated 10 ETH transfers from the same addressOriginal explorer evidence: the newest entries appear first. Compare the Method, To, and Amount columns. Open the wallet history.The final transfer shows one step furtherThe last transaction was recorded at 06:28:35 UTC. Its internal payment record shows the router forwarding 10 ETH to the contract labeled “Tornado.Cash: 10 ETH,” the pool in this final transfer. Check the final transaction.That extra check was made for the final transaction. The twenty outgoing transfers were reviewed, but this article does not claim a complete internal router-to-pool review of all twenty.Evidence 3. The final 10 ETH paymentOriginal explorer evidence: From is the initiating wallet; To is the router. Internal Transactions shows the final 10 ETH payment to the pool. Open the final transfer.We now have two verified endpoints: the withdrawal at 06:13:11 and the final transfer at 06:28:35. The difference is 15 minutes and 24 seconds. The next diagram places those endpoints around the transfers and shows where our evidence stops.Figure 4. The observed time window and the limit of the traceThe bracket spans 06:13:11 to 06:28:35 UTC: 15 minutes and 24 seconds. Intermediate spacing is schematic. Only the final transfer received a detailed internal router-to-pool check; the post-mixer path remains unestablished.The bracket measures withdrawal to final transfer. It is not the duration of the twenty transfers alone or of the entire incident. The separately labeled 2020 history comes from an external alert, which we examine below.The path ends at the checked pool payment because this article has not established a later destination. It does not show an exchange deposit, a cash-out, or the identity of the person controlling the wallet.5. Several movements do not mean several lossesWe have seen 200 WETH move, 200 ETH arrive, and 200 ETH then leave in smaller transfers. These are successive stages of the observed route, not separate amounts to add together.Instead, read the next diagram as a running account of the route: the asset changes form, reaches the wallet, and is sent onward. Each box describes what happens next to the same-sized amount.Figure 5. Following the same amount without counting it twiceRead top to bottom. The amounts describe successive stages, not separate losses to add together. Gas fees are excluded; this diagram makes no incident-time dollar valuation.The observed route is 200 WETH → 200 ETH → twenty transfers totaling 200 ETH. It is not an 800 ETH loss obtained by adding repeated entries inside the transaction, and the onward transfers are not another separate 200 ETH withdrawal.These totals exclude gas fees, the fees paid to execute transactions. Dollar prices displayed in explorer screenshots reflect the display at capture time; this article does not use them to calculate an incident-time dollar loss.The amount and route are now clear. The remaining question is different: what allowed the withdrawal?6. The route is visible; the reported cause still needs checkingDefimon Alerts attributed the event to a permission problem in an old MakerDAO auction keeper. According to its report, the keeper had won four auctions in 2020—numbers 1457 through 1460, each for 50 WETH—but had not settled them. The report says an external caller used an unprotected keeper function to settle and withdraw the collateral. Read the source alert.This explanation connects back to the separate steps in section 1. Settling an auction and deciding who may withdraw its assets are not the same permission question. A publicly callable settlement function is not automatically a flaw.The following comparison puts those two questions side by side. Read the left panel as general auction background and the right panel as the keeper-permission issue that needs verification.Figure 6. Settlement and withdrawal are different permission questionsThis comparison separates the general settlement mechanism from the externally reported keeper-permission issue. The dashed amber panels mark a question and an allegation, not an independently verified exploit path.The allegation concerns someone else being able to invoke a function that sends the keeper's collateral to an external address. To confirm that explanation, we would need the keeper's code and configuration at the time, together with the detailed execution record. The transfer amounts alone cannot answer it.The general Flipper source cited earlier is not assumed to match the exact deployed implementation. Likewise, the adapter's explorer label is not evidence that all of MakerDAO or Sky was compromised.What we can take awayThe records support a specific sequence: 200 WETH moved, it was converted into ETH, the initiating wallet received 200 ETH, and that wallet sent twenty transfers of 10 ETH to a router. The final transfer also has a checked 10 ETH payment from the router to the labeled pool.Use the final diagram to separate that observed route from the external explanation and the unanswered questions. The labels matter as much as the colors: blue is checked evidence, dashed amber is the reported explanation, and gray is unresolved.Figure 7. Verified records and unresolved questionsLabels and border styles distinguish the evidence levels as well as color. The dashed amber box contains the external explanation, not an independently verified cause. No speculative line connects the mixer to an unverified later address.The next investigation has four concrete tasks. Check the keeper's historical permissions and implementation. Verify the creation, bidding, and settlement records for auctions 1457–1460. Review the internal payments in the other nineteen transfers. Look for independent evidence before linking any later withdrawal to these deposits.We can follow the money to the limit of the examined records. We cannot yet turn that route into a proven cause, an identified operator, or a confirmed cash-out.This is the end of the narrative. The appendix below keeps the original records available for readers who want to verify the details.Appendix A. The twenty transaction referencesEach entry represents one outgoing transfer of 10 ETH from the initiating wallet to the router. The full transaction hash is its identifier; follow the link to inspect the original record. The list runs in block order.Order: 1Block: 26131503Amount: 10 ETHOriginal transaction: 0xb8ecff9c129d8d9331c85558eaeddff29a38c4c16b71a40986acbf8f6febefebOrder: 2Block: 26131507Amount: 10 ETHOriginal transaction: 0x01dd51eff5790bf070ae5abefc4a77f3df2b2476feebbe9aaa6ffa1fd48f8429Order: 3Block: 26131509Amount: 10 ETHOriginal transaction: 0x8c5fb4f50aa0f56cc701afdad377e56f53655e48e237f85aef8fe902797a4240Order: 4Block: 26131512Amount: 10 ETHOriginal transaction: 0x9a6ef7cce759e09f1d23115f974eb0707460a6834de0d30a55c3761a9c9dce6cOrder: 5Block: 26131514Amount: 10 ETHOriginal transaction: 0x725cdd6f23f7fc30d6ab43a6cf634aec791e5e2097151a09fc522408786da3ffOrder: 6Block: 26131516Amount: 10 ETHOriginal transaction: 0xaf1fb061f3d3db6cc6107219ea7bc5e0c6f86ba54c997e10bb062e0a3f7f7eedOrder: 7Block: 26131519Amount: 10 ETHOriginal transaction: 0xfd60254ab0a74ae6d51706023394190ca20646264d1da322998afa4682ae18b2Order: 8Block: 26131521Amount: 10 ETHOriginal transaction: 0xcc14212fc5d51d3d5ea7f0de9895264da8c0b5c779ca2947083f665f50f0bfbeOrder: 9Block: 26131523Amount: 10 ETHOriginal transaction: 0x31d6c9cb202306536c9f977a486bd2f5d2a16d0db9c7558ac132442fe58440f5Order: 10Block: 26131525Amount: 10 ETHOriginal transaction: 0x3ef864598198ff4d23f22a35d540e0437ba0ed3af7a77c3d23ae99f59f1bb96eOrder: 11Block: 26131527Amount: 10 ETHOriginal transaction: 0x4c10b56e2f5c37706fdcbe2b1c7da35de68661306971b32e8ea5ed95e7a02a7aOrder: 12Block: 26131529Amount: 10 ETHOriginal transaction: 0xa452e803014458dba087c82bf0a7e9432bf014337b59d34483bbbf232fe39d57Order: 13Block: 26131531Amount: 10 ETHOriginal transaction: 0xaddc6ea108b17f39beca57487fee55f878546c8f233bdb8c0736b03658e890d4Order: 14Block: 26131533Amount: 10 ETHOriginal transaction: 0x61e349fe5ce11d9b3b8f4d9813c3a1f74e6dd898d43f61c0139673540137b3e6Order: 15Block: 26131537Amount: 10 ETHOriginal transaction: 0x7167efdb6740e1c1a38983edd33e3a7446d01abe2fcf63874b80aa8f9f3f7ee6Order: 16Block: 26131539Amount: 10 ETHOriginal transaction: 0xe82b2082edd720801389e75cf2a6158f494f9e8b3ad3a7671bfc18f9e7c07538Order: 17Block: 26131541Amount: 10 ETHOriginal transaction: 0x48303767bec9e216fa06e79dd21f3f3257524dd613c976f3fe60132bcc38af52Order: 18Block: 26131543Amount: 10 ETHOriginal transaction: 0x0ac6195011bfea03360778ce3a05f8ed665a6fe2ce6ac10231c2be3dcbb99210Order: 19Block: 26131546Amount: 10 ETHOriginal transaction: 0x2cd7eb09abe21d07e36aedc5a93f6c6f99b5ab796b2b5632aa14c6278192396cOrder: 20Block: 26131548Amount: 10 ETHOriginal transaction: 0xf1db855a987c2fb5e0ea6184ae8f8ed3271cca98c80e627be4839e4b4ac8dcbfAppendix B. Full addresses and their rolesThese labels describe observed behavior or a role attributed by the source alert. They do not identify people or establish knowing participation in wrongdoing.Role: Transaction initiator and ETH recipientFull address: 0x01eb957e5c7dcddd60f3c875956ccc6fb9bda5faBasis: Withdrawal and subsequent transaction recordsRole: Intermediate contractFull address: 0xec997d2ad033277913d6002277353368e8321dcfBasis: Transaction target and internal paymentRole: Contract created during the transactionFull address: 0xf09a13072ed939b79bc25b66aa3a836ea6dcc170Basis: Creation record and WETH transfersRole: ETH-A collateral adapterFull address: 0x2f0b23f53734252bda2277357e97e1517d6b042aBasis: Explorer label and WETH transferRole: WETH contractFull address: 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2Basis: Token and withdrawal eventsRole: Affected keeper identified in the alertFull address: 0x9c05a05893ada984fc20d0da0c046de5cc0e8273Basis: Role attributed by DefimonRole: Tornado Cash routerFull address: 0xd90e2f925da726b50c4ed8d0fb90ad053324f31bBasis: Explorer label and subsequent transfersRole: 10 ETH pool in the final transferFull address: 0x910cbd523d972eb0a6f4cae4618ad62622b39dbfBasis: Internal payment in the final transactionAppendix C. Source records and review scopeThe review covers the initial withdrawal, the twenty outgoing transfers, and the internal payment in the final transfer. The historical auction story and the alleged permission failure remain externally reported claims rather than independently established findings.Withdrawal transaction, timestamp, token transfers, and internal ETH transfersWithdrawal transaction event logsInitiating address and subsequent transaction historyFinal deposit transactionDefimon Alerts report of the alleged causeOfficial liquidation-system proposal, MIP45Published Flipper source for the general settlement mechanismOfficial Auction Keeper project