커뮤니티

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

ChainBounty · Investigation analysis · October 6, 2026A dormant third-party ETH-A keeper was exploited on Ethereum on October 6, 2026, according to SentinelTX's CASE-ASYNCADB report. The exploit released 200 WETH, which was unwrapped into 200 ETH and delivered to the attacker's externally owned account. That account then sent twenty transfers of 10 ETH each to a Tornado.Cash router between 06:19:35 and 06:28:35 UTC.SentinelTX locates the authorization weakness in the keeper's implementation contract. It classifies the incident as an exploit of a third-party liquidation bot, rather than a breach of the MakerDAO core protocol.Key findingsThe trace follows a 200 ETH native payout through the attack contract to the attacker's account, followed by twenty 10 ETH transfers to the same routerThe keeper proxy delegated selector 0x8804d1de to an unprotected exit path in its implementationThe router is the last recorded recipient on this route. Attacker identity and any exchange-deposit leg remain unestablished1. A funded account deployed two contracts before the drainThe first recorded step was gas funding. At 05:57:23 UTC, account 0x01eb95…bda5fa received 0.09783730488175 ETH from the address labeled Tornado.Cash's 0.1 ETH pool.The account then submitted three control transactions in order. At 06:09:23 UTC, nonce 0 created 0xa5c3a6…1fc552, a staging contract whose purpose remains unconfirmed. At 06:12:11 UTC, nonce 1 created the attack contract, 0xec997d…321dcf. At 06:13:11 UTC, nonce 2 called that contract with selector 0x0e763dd6 in block 26,131,471.The two deployments and the drain occurred within 3 minutes and 48 seconds. The deployment records contain no native value transfer; the 200 ETH payout followed in the drain transaction.The payout route contains two 200 ETH native movements in the same attack transaction. The WETH contract sent 200 ETH to the attack contract, and the attack contract forwarded 200 ETH to the externally owned account. The report interprets the first movement, following selector 0x2e1a7d4d, as the WETH unwrap.Figure 1. The reported native-ETH route. Two 200 ETH movements occur in the attack transaction; twenty later 10 ETH transfers carry 200 ETH from the account to the router. These are successive movements of the same principal, not separate losses. Arrows show direction, not proportional value or elapsed time. Separate gas funding is shown approximately; the exact transfer is 0.09783730488175 ETH.Color key: Slate: native payout hops. Amber: onward router deposits. Sage: separate gas funding.Address key: WETH contract 0xc02aaa…756cc2; attack contract 0xec997d…321dcf; attacker account 0x01eb95…bda5fa; router 0xd90e2f…24f31b. Full identifiers appear below.Source: SentinelTX, CASE-ASYNCADB, October 6, 2026, pp. 4–7 and 10–14. Simplified explanatory figure, not an original SentinelTX graph.2. The drain entered a third-party keeper implementationThe attack contract called keeper proxy 0x9c05a0…0e8273 with selector 0x8804d1de. The proxy then used DELEGATECALL with the same selector to implementation 0x68399e…6a5546. SentinelTX identifies the missing authorization check in this implementation path as the weakness that allowed the drain.The attack calldata includes the keeper proxy, the ETH-A collateral identifier, the WETH contract, the recipient account, and auction IDs 1457, 1458, 1459, and 1460. These identifiers align with the reported account of four legacy auctions holding 50 WETH each. SentinelTX interprets the history as a dormant keeper that had won the auctions but had not completed settlement, leaving collateral available to the unprotected exit path.Later calls pass through the auction and collateral contracts identified as Flipper, Vat, and GemJoin ETH-A, followed by the WETH operation and the 200 ETH payout. The call trace records the selector bytes and execution order. Function names such as GemJoin exit and WETH withdraw are interpretations based on matching signatures and surrounding execution, rather than decoder-confirmed names.The relevant core-contract calls executed without reverting. The report's conclusion that MakerDAO core operated as designed also depends on its interpretation of those contract roles and cited reporting; it did not cross-check the address identities against MakerDAO's public changelog. Its finding is therefore specific to the third-party keeper implementation, rather than a claim that “MakerDAO was hacked.”Diagram 2. The third-party keeper call path. The proxy delegates selector 0x8804d1de to its implementation. Function-name mappings remain interpretations, while the 200 ETH native payout is recorded directly in the call tree. This diagram simplifies the sequence.Color key: Slate: selected keeper call path. Sage: later WETH release/unwrap and native payout section.Address key: Keeper proxy 0x9c05a0…0e8273; implementation 0x68399e…6a5546. Contract roles follow the report's stated basis and qualifications.Source: SentinelTX, CASE-ASYNCADB, October 6, 2026, pp. 4 and 8–9.3. Twenty equal deposits moved the proceeds to the routerThe first 10 ETH transfer to the Tornado.Cash router was recorded at 06:19:35 UTC. The twentieth was recorded at 06:28:35 UTC. The twenty listed transactions each carry 10 ETH, totaling 200 ETH over nine minutes.This sequence started about six minutes after the drain. SentinelTX interprets the equal-size transfers as a structured mixer-deposit pattern.The recipient is labeled Tornado.Cash, Mixer, and Sanctioned. No exchange-deposit leg is recorded. The route ends at the router in the available evidence; that does not establish a final beneficiary or identify a corresponding mixer withdrawal.Figure 3. Cumulative deposits derived from the twenty 10 ETH transfers listed in the PDF. The steps reach 200 ETH at 06:28:35 UTC. Horizontal spacing represents actual time; the chart describes this deposit sequence, not the router's balance or downstream withdrawals.Color key: Slate: cumulative total derived from the twenty listed deposits. Sage: the final 200 ETH total.Source: SentinelTX, CASE-ASYNCADB, October 6, 2026, pp. 6–7 and 11–13. Cumulative totals are an editorial calculation from the listed same-unit transfers.4. Transfer activity is different from the incident amountThe activity summary totals 23 traced value movements involving five addresses and gross movement of 600.097837 ETH. This figure repeats funds at successive hops and is not a loss total. The 200 ETH payout is recorded from the WETH contract to the attack contract, again from the attack contract to the externally owned account, and then across the twenty router transfers. The small gas-funding transfer is separate.The incident quantity is 200 WETH, followed by 200 ETH after unwrapping. The approximately US$538,000 valuation comes from reporting and was not independently priced in the investigation. Native quantities therefore provide the clearest basis for following the funds.The timed movements discussed here run from 05:57:23 to 06:28:35 UTC on October 6. Later paths remain outside this documented route.ConclusionSentinelTX's conclusion is a third-party keeper authorization exploit followed by a 200 ETH payout and twenty mixer-router deposits. The useful boundary is specific: the keeper implementation is the identified weakness, the reported route reaches the router, and the attacker has not been attributed.Useful follow-ups include tracing the keeper and implementation deployers or owners, examining possible correspondence between the timed deposits and later withdrawals, and checking related proxies for similar exposure. These remain investigation leads, rather than established downstream matches.Any proposed downstream match or real-world identity would need its own supporting evidence.Figure 4. The report's conclusion and limits. The route accounts for a 200 ETH payout and twenty 10 ETH router deposits. Attacker identity and corresponding downstream withdrawals are not established; no exchange-deposit leg is recorded.Color key: Slate: keeper weakness. Sage: asset outcome. Amber: stated limits.Source: SentinelTX, CASE-ASYNCADB, October 6, 2026, pp. 4 and 8–10.Continue from the twenty deposit transactionsThe twenty timed deposits provide a concrete starting point for further tracing. The prompt below asks SentinelTX to assess possible later withdrawal correspondence, clearly separating supported links from candidates.Request SentinelTX access · Sign inCopy this starting prompt:Investigate the October 6, 2026 Ethereum route from 0x01eb957e5c7dcddd60f3c875956ccc6fb9bda5fa to Tornado.Cash router 0xd90e2f925da726b50c4ed8d0fb90ad053324f31b. Start with attack transaction 0xbb6940f7c2a1e68cafbae7bb9b94d09af9af06ec3a114f6996f2cab993f3a88c and the twenty 10 ETH deposits recorded from 06:19:35 to 06:28:35 UTC. The first deposit is 0xb8ecff9c129d8d9331c85558eaeddff29a38c4c16b71a40986acbf8f6febefeb; the last is 0xf1db855a987c2fb5e0ea6184ae8f8ed3271cca98c80e627be4839e4b4ac8dcbf. Assess whether available evidence supports any later withdrawal correspondence. Separate directly supported links from timing or amount-based candidates, do not infer common control from correlation alone, and include transaction links, the queried window, and query time. Keep the third-party keeper separate from MakerDAO core, and state when a path cannot be established.Source and address notesThis article adapts SentinelTX's CASE-ASYNCADB — 0x01EB957e…bDa5FA, dated October 6, 2026. The WETH mechanism rests on call-tree evidence; a separate token-event-log check was incomplete. Page references above identify the source of the article and explanatory figures.Attacker account: 0x01eb957e5c7dcddd60f3c875956ccc6fb9bda5faAttack contract: 0xec997d2ad033277913d6002277353368e8321dcfKeeper proxy: 0x9c05a05893ada984fc20d0da0c046de5cc0e8273Keeper implementation: 0x68399ed8aa33c5b43f863ee6782de492006a5546WETH contract: 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2Gas-funding pool: 0x12d66f87a04a9e220743712ce6d9bb1b5616b8fcRouter recipient: 0xd90e2f925da726b50c4ed8d0fb90ad053324f31bThe pool and router descriptions reproduce the report's labels. Account identifiers identify on-chain addresses, not the real-world identity of the attacker.

ChainBounty investigation · USDT token shown for context; no endorsement or attribution to the issuer.What the records show. One address initiated twelve USDT calls that debited nine token-holder addresses. Two collecting addresses later sent 51,000 USDT to a single destination. These are two distinct observations—not two amounts to add together as a loss total.The movements behind the reportBetween 7 and 28 September 2026, twelve USDT calls on TRON debited nine different token-holder addresses for a combined 15,864.609801 USDT. The calls had one feature in common: the same collecting address initiated every transaction. On 30 September, that address and a second collector sent a separate total of 51,000 USDT to one destination, 81 seconds apart.Public allegations concerning Tronify.rent / tron.store prompted the review. To understand what the ledger supports, this report follows three questions: who initiated the twelve calls, what their amounts measure, and where the collectors subsequently sent funds. It then separates those observations from the unresolved questions of authorization, consent and operator identity. The 51,000 USDT consolidation is not a verified loss total, and its provenance has not been fully reconciled with the earlier calls.MeasureResult / scopeReport version1.2 · structural and explanatory revision, 6 October 2026; evidence window unchangedNetworkTRON mainnet; TRC-20 USDTPrimary period1–30 September 2026 UTCFollow-up cutoff6 October 2026, 02:46:45 UTC, as stated by investigation sourceVerified payment subset12 transferFrom calls; 9 distinct token holders; 15,864.609801 USDTVerified consolidation2 transfer calls; 51,000 USDT received in 81 secondsPublic allegationsApproximately $69,651 / 80 victims; not reconciled or independently established────────────────────────────────Timeline — the ledger observations came before the public reportsUTC period / timeEventEvidence level7–28 SeptemberTwelve transferFrom calls in the verified subsetIndependently checked30 September 16:24:54–16:26:15Two collector sweeps into HIndependently checked1–5 OctoberNine additional TRX-seeded addresses reported; subsequent payments not establishedInvestigation source only5 October; exact post times not establishedInitial public allegations and subsequent infrastructure correctionPublic source attribution────────────────────────────────The three addresses followed in this reportC1 and C2 are labels for the two collecting addresses; H labels the destination of their later transfers. C2 has two observed roles: it submitted all twelve calls and received tokens in some of their events. These labels describe activity, not identity or ownership.RoleFull addressEvidence boundaryC2 · caller / collectorTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvOwner of every payment call; recipient in some eventsC1 · collectorTLv3iSnZxWghEmadLDzuAK2p5GkAwg7tpJRecipient in other payment eventsH · consolidationTDDfKDDttx6rFkq2YWzge83RZqQgerzs9MReceives the two later sweep transfers1. The address that called the contract was not the holder being debitedA token movement has more than one relevant actor. The transaction owner identifies the address that submitted the call; the From field in the token-transfer event identifies the address whose token balance was debited. Those fields need not name the same address. In all twelve inspected calls, the owner is C2, while the token-event From field names another holder. The calls use transferFrom rather than transfer, and all twelve are recorded as successful and confirmed. The USDT contract is TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.The distinction changes how these movements should be described. They were not twelve direct transfers submitted by the holders whose balances decreased: C2 called the contract to move those balances. The transferFrom method is a delegated-transfer mechanism, but the method name does not explain how authorization was obtained. Approval records and wallet interactions are needed to distinguish informed delegation from deceptive authorization; the calls alone do not establish which website, if any, induced it.Figure 1 — Delegated-transfer mechanism. Evidence P1–P12: C2 is the transaction owner; the token-event From field names the debited holder. Approval creation and consent remain unverified.────────────────────────────────2. What the 15,864.609801 USDT total measuresOnce the caller and the debited holders are separated, the next question is how much moved in this examined set. Adding each of the twelve transaction-event amounts once, using the transaction hash to avoid duplicates, gives 15,864.609801 USDT. Nine distinct holder addresses appear because some addresses were debited more than once. Twelve events therefore do not mean twelve victims—and the ownership and victim status of those nine addresses are not established by the count.Figure 2 — Full payment distribution. All twelve amounts use one linear, zero-based USDT scale. P5 dominates the inspected subset; the chart does not estimate total incident loss.Figure 3 — Magnified smaller events. A separate 0–700 USDT axis makes the eleven smaller events readable. P5 is excluded only from this panel, not the aggregate. Do not compare bar lengths between Figures 2 and 3.The largest event, P5, is 13,472 USDT: approximately 84.92% of this subset. Figure 2 shows that concentration on a single zero-based scale. Figure 3 uses a separate 0–700 USDT scale to make the other eleven events readable; it does not remove P5 from the total. No conversion to a contemporaneous USD price is applied. Unpaired inflows, recycled funding and later hops are excluded from the sum. The publicly reported approximately $69,651 and 80 victims describe a different, unreconciled population—not a larger total that this subset independently proves.────────────────────────────────3. Two collectors sent 51,000 USDT to one destinationThe next observed stage is a pair of direct transfers on 30 September. At 16:24:54 UTC, C1 sent 36,000 USDT to H. At 16:26:15 UTC—81 seconds later—C2 sent another 15,000 USDT to the same address. Unlike the earlier delegated calls, both transactions use transfer and are confirmed in the explorer. Together they establish that H received 51,000 USDT from these two collectors. They do not establish that all of those tokens came from the twelve earlier events, or that C1, C2 and H share an owner.UTC / blockMovementFull transaction2026-09-30 16:24:54 · 86704310E1 · C1 → H · 36,000 USDT501b95a1bd13510e495601f2b19e619763a5a73debc85619be2662301b5f48a92026-09-30 16:26:15 · 86704337E2 · C2 → H · 15,000 USDT63e05ce6c8739cdaf6357d3784e4d23d8d51947b6d9d7c0197990e696aee9bc3Figure 4 — Collection and consolidation network. P1–P12 are payment events, not twelve victims. E1 and E2 identify the two verified consolidation transactions below; E3 is a source-only lead. Arrow direction indicates token movement, not ownership.A later 100 USDT movement from H appears in the investigation output at e783e0a7579b27cd49f87c284b22fac22fea1f65e2fe7f415ec2fbe2fb20667d. Subtracting it from 51,000 does not establish a current balance of 50,900: a current balance snapshot and intervening activity are needed.────────────────────────────────4. A shared service is not evidence of a shared operatorThe public source corrected its inclusion of TDii6vao7xyWg2rKPbCPWVRpSmne8xcqYx and identified it as legitimate Tronify infrastructure. The correction is material: service usage must not be treated as proof of operator control or collusion. Public correction.Likewise, exchange labels observed on payer-side funding routes do not establish collector cash-out. Shared service use, timing proximity and a visually dense graph are not identity evidence.────────────────────────────────5. What is established, and where the evidence stopsEvidence classWhat it establishesWhat it does not establishP1–P12 · directly checkedSuccessful transferFrom calls, amounts and transaction ownerApproval origin, consent or victim statusE1–E2 · directly checkedTwo transfers into H; 51,000 USDT in 81 secondsTotal loss, current balance or common ownershipE3 · source-only leadReported later 100 USDT branch; hash retainedIndependent re-verification or remaining balancePublic reportingAttributed incident context and correctionOn-chain domain or human attributionThe records connect the twelve calls through a common transaction owner and connect the two collectors through transfers to H. That is an operational connection between transactions, not an identification of the people behind them. Delegated transfers occur in legitimate workflows as well as deceptive ones, so the method alone does not establish fraud, intent or a stolen private key. Claims about Gemini recommendations, AI videos or search manipulation concern off-chain inducement; transaction records alone cannot confirm them.The reported TRX seeding and short delays are investigative context. The seeding transactions have not all been independently checked in this report, so they are not used to establish a universal causal mechanism. The provider also contains conflicting first-activity dates and broader historical paths; those values are not used to date the operation or aggregate losses.────────────────────────────────6. The next investigation: authorization, inducement and destinationThe remaining questions require different kinds of evidence. Approval records address how C2 could move tokens; victim and service records address the alleged inducement; a timestamped balance and transaction ledger address what happened after consolidation. None can be replaced by the shape of the graph alone.Question to resolveRequired evidencePurposeHow was C2 authorized?USDT approval events, allowance history and wallet interaction recordsSeparate informed delegation from deceptive authorizationWhich domains induced transactions?Victim records, browser history and legitimate service order logsConnect on-chain movement to off-chain inducementWhere are consolidated funds now?Timestamped H balance and subsequent transaction ledgerDetermine actual remaining exposure without assuming a balanceWho owns the affected wallets?Voluntary victim evidence or lawful recordsValidate victim count and loss attributionThe immediate task is to connect the observed calls to their authorization history, test the alleged off-chain inducement, and reconstruct H’s subsequent activity. The table identifies the evidence needed for each question. Until that evidence is available, the report supports a description of delegated transfers and consolidation—not a complete victim census, a current balance, or a finding that funds were frozen, recovered or cashed out at an exchange.────────────────────────────────Evidence appendix — full identifiersEvery payment below was independently checked in the TRONSCAN overview. The method is transferFrom and the transaction owner is C2 in every row. USDT native precision is six decimals. The hash is the deduplication key.Common fields for P1–P12: TRON mainnet USDT; successful and confirmed transferFrom calls; transaction owner TV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rv. The tables separate movement from transaction anchors so full identifiers remain readable. Each P identifier refers to exactly one transaction hash.P1–P4 · token movementsEvidence / USDTToken holder · FromCollector · ToP1 · 100.0TGUfWzCTdYNwVbuzDzfAGKAARkdjCavPq5TLv3iSnZxWghEmadLDzuAK2p5GkAwg7tpJP2 · 485.447918TR1amRA6PTyQCn7p3y9r7NUtjLMWdWDtqhTLv3iSnZxWghEmadLDzuAK2p5GkAwg7tpJP3 · 412.0TCGZTBwNN6HXU9agUpeA49tSsRkGAr6yrdTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvP4 · 181.0TUibaVrq1ZYuDuUc8TVDpEbgespvpuTygcTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvP1–P4 · transaction anchorsEvidenceUTC / blockFull transaction hashP12026-09-07 19:51:06Z · 860462943c3b8a6fe26b69a760134f1bb3b944baa0ec049c89d3002a426bd3137784d035P22026-09-10 13:25:27Z · 861249036a93656feb2b32058214bc6e8eaebc697f4312132f30e982f4a66325f2e3f84dP32026-09-11 07:00:33Z · 86145999a521b4b148ca8a58b35438981df742a27ee64a988d4c8077384f3e9ceb409304P42026-09-12 15:18:09Z · 86184741b72f7690b7d5d8e92301018de4ac02c516b356b8d7ea9853564d3847b12977e5P5–P8 · token movementsEvidence / USDTToken holder · FromCollector · ToP5 · 13472.0TF3tXoQpgjokBLr6Qpsu3nixTcMgvtNY9nTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvP6 · 177.0TTPa48RruBqu2wvbYYskZASj2ox4iPvSXZTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvP7 · 61.372883THmHnytNudoV9FDiDdX9rfmq4UatB5TdwvTLv3iSnZxWghEmadLDzuAK2p5GkAwg7tpJP8 · 659.0TJBt8osXN8utgApfAfYdNBR4K5fHrmK9yzTLv3iSnZxWghEmadLDzuAK2p5GkAwg7tpJP5–P8 · transaction anchorsEvidenceUTC / blockFull transaction hashP52026-09-13 08:04:39Z · 862048658b003bd469b45956b430df31ad67b0c8d668a114808775e9897787b6e20ccbf6P62026-09-14 02:10:24Z · 86226573e1bbcbac8dd49284e9745757f555dc663b66da42555544fdf5b9c7e2a0a0119eP72026-09-14 20:14:42Z · 86248253877c9e0cb7ebccf7fe18ce63b0a9f4206aa32993b30c688679ad2f0a2bb83a65P82026-09-14 22:44:30Z · 86251249e6bc783dc6f2f180b576a044f037afe44f4c688b87cd534460f49b19cf145cb5P9–P12 · token movementsEvidence / USDTToken holder · FromCollector · ToP9 · 101.0TJBt8osXN8utgApfAfYdNBR4K5fHrmK9yzTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvP10 · 1.789TJBt8osXN8utgApfAfYdNBR4K5fHrmK9yzTLv3iSnZxWghEmadLDzuAK2p5GkAwg7tpJP11 · 210.0TAZ9AaA4qQc6T4WAuwAyMSjWcQgVMJz2HJTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvP12 · 4.0TAZ9AaA4qQc6T4WAuwAyMSjWcQgVMJz2HJTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvP9–P12 · transaction anchorsEvidenceUTC / blockFull transaction hashP92026-09-15 00:21:57Z · 86253196d52998a2a9f33af5894d50ab95cfa63a73427038ce4e059ffb5a14cba5b97a34P102026-09-15 00:22:33Z · 862532083a9d82c197147bfba3d89fe0a3541fed23bf722e51302d690a5c83a94878e4b6P112026-09-28 15:20:33Z · 86645460c0325bd4daa2c1c88668b8b9fbc7a670d1fec73c53a0ef63eb3c3cdc6b6837beP122026-09-28 15:33:48Z · 86645725c4d870bc9b0dc20802324b25641c721bca0a16840284b60d0915476f15f39e33────────────────────────────────Sources and methodologyPrimary public sources: initial disclosure, infrastructure correction, off-chain follow-up. Transaction claims are anchored beside the relevant findings and in the appendix. Public allegations are not independently established totals.The investigation output supplied candidate identifiers and contextual paths. This report independently compared all twelve payment calls and both consolidation transfers against visible explorer results, checked the aggregate and distinct-holder count, and corrected the direct-transfer interpretation. It does not claim a complete approval-history review, complete wallet balance audit or complete incident census.Revision note — 6 October 2026. Version 1.2 reorganizes the narrative around the observed sequence, explains address roles before the mechanism, and connects each finding to its limits and next verification step. Existing transaction identifiers, quantities, figures and source links are retained. This is an editorial revision, not a new on-chain verification; the evidence set and investigation cutoff are unchanged.

ChainBounty · Report analysis · CASE-10DA91A7Ethereum mainnet · Activity: September 30, 2026 · Source: SentinelTX report generated October 5, 2026SentinelTX’s MUSystem report follows four Ethereum transactions that combine supplied capital, repeated deposit-and-return cycles, and repaid flash loans. It reports a 5.335155071161390070 ETH reduction at the affected contract and a 3.190655071161390070 ETH increase at the initiating account before fees. A third address received 2.1445 ETH. The distinction between those amounts is central to the report: receipts, account changes, and an incident-wide loss answer different questions.Report status matters here. The exported PDF says its automated integrity gate downgraded six claims and flagged one finding. Its chronology and conclusion carry an “unverified (auto-downgraded)” label, and page 83 flags a time-inverted path. This article presents the report’s findings with those qualifications. The figures below adapt its bounded transaction narrative; they do not reproduce the flagged onward path or certify the report’s findings. (SentinelTX, pp. 4, 10, 17, 21, 83)The scope of the reportAll four transactions fall in Ethereum block 26,087,602, timestamped September 30, 2026, at 03:27:35 UTC. SentinelTX calls the first transaction the Run and the following three Sample 1, Sample 2, and Sample 3. The report’s accounting covers those four operations. It does not establish that they comprise the entire campaign or all activity involving the affected contract.The principal roles are the initiating and receiving externally owned account, or EOA; the contract it created and used to coordinate the operations; the affected MUSystem contract; and newly created helper contracts. The report calls the coordinating contract the attack contract. This article uses “orchestration contract” to make its execution role clear without suggesting a separately identified operator. The third recipient’s role and control remain unresolved.The report sets an observation cutoff of October 5, 2026, at 10:00 UTC. It separately identifies address-history, token, and balance observations retrieved around 10:11–10:15 UTC that day as later observations. That distinction matters when reading its statements about activity after the four transactions. (SentinelTX, pp. 4, 8, 18)The Run belongs in the calculationThe last three transactions produced receipts of approximately 5.9475 ETH, 5.0703 ETH, and 2.8368 ETH for the EOA. Together, those receipts total 13.854604425661360100 ETH. Looking only at that part of the sequence omits the EOA’s earlier contribution in the Run.In the Run, the EOA sent 10.7 ETH to the orchestration contract and received 0.036050645500029970 ETH back. Its net change for that transaction was therefore −10.663949354499970030 ETH before fees. The Run also contained the same repeated-cycle pattern seen later; it was more than a preliminary funding transfer.SentinelTX breaks the Run into a priming deposit and sixteen helper cycles. The orchestration contract first paid 44.101139073399812544 ETH to the affected contract. During that call, the affected contract sent 26.460683444039887526 ETH back to the orchestration contract and 2.1445 ETH to the unresolved third address. The report gives the affected contract’s net increase on this leg as 15.495955629359925018 ETH.The sixteen subsequent cycles reduced the affected contract’s ETH by 6.976506274859954988 ETH. Combining those two parts leaves the affected contract with a reported Run increase of 8.519449354499970030 ETH. The later sample transactions then reduce that amount. Including the Run is essential to understanding the four-transaction result. (SentinelTX, pp. 6, 10–11)Figure 1. The report’s four-transaction sequence in one Ethereum block. It records 16 helper contracts in the Run, 16 in Sample 1, 16 in Sample 2, and 11 in Sample 3, for 59 in total. These counts describe contracts, not independent people. All four transactions share the block timestamp; spacing shows sequence rather than elapsed time.Color key: Slate identifies sequence markers and the directly labeled helper counts.Source: SentinelTX, CASE-10DA91A7, pp. 4, 8, 10, 13–15. The chronology is marked unverified by the report’s automated gate. Transaction links appear in the source register below.One deposit, two returnsThe first helper cycle in Sample 1 provides a compact example of the pattern SentinelTX describes. The proxy at 0x8b0856e9b0787d09f9abded66bccc85feb5561d4 calls the affected contract with 53.355703172210117028 ETH. It receives an initial payment of 32.253522567601017211 ETH. After a second call, it receives another 21.502348378400678141 ETH.The two payments total 53.755870946001695352 ETH. The proxy then forwards that amount to the orchestration contract. The excess over the original deposit is 0.400167773791578324 ETH for this cycle. Repeated deposits and forwarding create much larger gross movement volumes, so adding every leg would obscure the net result. The report explicitly excludes gross helper forwarding and large graph aggregates from its economic totals. (SentinelTX, pp. 12, 15)Diagram 1. The ETH legs in Sample 1’s first helper cycle, as described in the report. The same proxy sends 53.355703172210117028 ETH and receives two payments totaling 53.755870946001695352 ETH, an excess of 0.400167773791578324 ETH. Artwork values are rounded. Equal-width arrows show the direction of each leg, not its relative size.Color key: Slate outlines the same proxy P in each row; sage outlines the affected contract. Slate amount text labels the deposit and sage amount text labels the two returns.Address key: Proxy = 0x8b0856e9…561d4; affected contract = 0x9bdf81e6…d9364. The proxy appearing in each row is the same account. MUS token movements are outside this native-ETH calculation.Source: SentinelTX, CASE-10DA91A7, pp. 12, 17–18; Sample 1 transaction. The report marks the cycle-pattern observation unverified and treats the root-cause explanation as attributed analysis.The proposed explanation comes from external research cited in the PDF. SentinelTX attributes to SlowMist a first-deposit bonus that was credited both in an immediate ETH refund and in the user’s MUS allocation, with same-transaction redemption allowing total ETH returned to exceed the deposit. It also cites the DeFiHackLabs reproduction. SentinelTX did not execute that reproduction, and it does not present the root cause as independently verified from the affected contract’s source code.The report distinguishes that explanation from its interpretation of the calls. It says the first selector matches the common deposit() signature, while the second selector’s ABI meaning remains undecoded. It treats the use of fresh proxies as consistent with a per-address first-deposit condition, rather than as decoded proof of that condition. In the example, the first and second payments are approximately 60.45 percent and 40.30 percent of the deposit. Those proportions describe this example; they are not a constant return promised for every cycle. (SentinelTX, pp. 17–18)Borrowed WETH supplied working capitalSentinelTX reports a Balancer Vault WETH loan in each transaction, with the principal returned in the same transaction. It also says the corresponding native-ETH unwrap and rewrap amounts match. These movements explain how substantial capital passes through the execution sequence without turning the entire principal into a reported loss.WETH principal borrowed and repaidRun: 70.940455629359925017 WETHSample 1: 53.355703172210117028 WETHSample 2: 45.486053167691556828 WETHSample 3: 38.777129899239648888 WETHThe report attributes a zero FlashLoan fee to the analyst’s receipt parsing, citing log indexes 276, 345, 414, and 463. It also notes a conflict with a comment in the public reproduction about attacker-owned capital and says it prefers the receipt evidence. These are the report’s stated source choices; this article does not claim to have rerun the reproduction or independently re-established the loans. (SentinelTX, pp. 7, 17)MUS remains a separate token record. The PDF describes a 49.75309010988246 MUS transfer, at display precision, from the affected contract to the orchestration contract in the Run. It calls this a transfer or allocation because the source is the affected contract rather than the zero address. It leaves token decimals, raw values, and log-level completeness unresolved in its anchored evidence. Neither that displayed quantity nor the WETH principal is added to native ETH when calculating the four-transaction changes. (SentinelTX, pp. 7–8, 21–22)From receipts to the net changeThe EOA’s three sample receipts exceed 13.85 ETH, but the preceding Run produces a negative EOA change of more than 10.66 ETH. SentinelTX’s four-transaction total incorporates both sides.EOA native-ETH change before feesRun: −10.663949354499970030 ETHSample 1: +5.947512945688151244 ETHSample 2: +5.070290034224630664 ETHSample 3: +2.836801445748578192 ETHFour-transaction change: +3.190655071161390070 ETHThe report separately attributes 0.005781774786752720 ETH in fees to these four transactions. Deducting those fees gives its stated EOA change of +3.184873296374637350 ETH. That number excludes other costs and any value associated with residual MUS. It is not an account balance or a campaign-wide profit figure. (SentinelTX, pp. 6–7, 21–22)Figure 2. The report’s native-ETH changes for the EOA across the four transactions, before fees. The negative Run and three positive sample receipts produce a reported total increase of 3.190655071161390070 ETH. Values in the artwork are rounded; the table preserves the PDF’s precision. The scope is a change across selected transactions, not the wallet’s starting or ending balance.Color key: Slate is the Run; sage is Samples 1–3. Explicit signs and the zero axis distinguish decreases from increases.Source: SentinelTX, CASE-10DA91A7, pp. 6–7, 21–22. The report’s conclusion marks these findings unverified (auto-downgraded). Full transaction links and hashes are listed below.At the account level, SentinelTX reports a reduction of 5.335155071161390070 ETH at the affected contract, an increase of 3.190655071161390070 ETH at the EOA before fees, and a 2.1445 ETH receipt at the third address. Its reconciliation assigns zero net ETH to the orchestration contract and the 59 helpers within each transaction. These net changes are an accounting summary; they do not identify the third recipient’s owner or purpose.The approximately $36,900 headline remains a separate, attributed claim. SentinelTX credits it to SlowMist and explicitly declines to reconcile it to the native-asset figures. The article therefore does not convert the report’s ETH changes into a new dollar-loss estimate. (SentinelTX, pp. 6, 8, 18, 21–22)The third recipient and the limits of the traceThe third address, 0xA30911099156608A32e35c11aCf2956258E0F645, receives its 2.1445 ETH during the Run’s priming-deposit call. SentinelTX does not establish whether the recipient is controlled by the attacker, unrelated to the attacker, a fee or referral recipient, or an existing participant. Its appearance in the sequence supports a reported payment, not one of those explanations.The PDF’s post-incident observations are also bounded. It says no outbound movement from the EOA was observed in the queried datasets through the later retrieval period around 10:11–10:15 UTC on October 5. It identifies no exchange deposit on the examined outbound paths of the EOA or orchestration contract. The report expressly says those observations do not prove unspent proceeds, recovery, a freeze, or current balances. Later blocks, other chains, and off-chain disposition fall outside those conclusions. (SentinelTX, pp. 8, 18, 22)Earlier funding history should be read in its own time. The report places the RAILGUN Relay Adapt receipt and LiFi departure before the incident, and it leaves the origin of the later Relay.link payout unresolved. It excludes that earlier history from incident proceeds and cash-out totals. The service labels do not establish who controlled the EOA or what anyone intended. These earlier routes are not drawn as an onward path in this article. (SentinelTX, pp. 10, 18)What the report concludesThe useful distinction in this case is between capital that passed through the contracts and the net changes the report assigns to the selected transactions. SentinelTX describes a repeated two-payment cycle and reports a positive EOA change after including the Run’s contribution. It keeps the repaid WETH principal, native-ETH account changes, and MUS transfer record separate.Its unresolved questions remain material: the third recipient’s role, activity outside the four transactions and outside Ethereum, the origin of the Relay.link payout, token-level details, and an additional orchestration-contract nonce increment. The PDF’s own proposed next steps include source and ABI decoding, a fuller log-level token ledger, and a dated valuation with an agreed incident scope. None of these is presented as completed work. (SentinelTX, pp. 18, 21–22)Figure 3. The conclusion and its limits, adapted from SentinelTX. The reported four-transaction amounts do not establish total campaign loss, real-world control of the third recipient, current holdings, recovery, or completed cash-out. The source PDF retains an automated integrity warning and labels the conclusion unverified.Color key: Slate labels the unresolved section; amber frames the directly stated report-integrity warning. Color does not indicate attribution or independently verified status.Source: SentinelTX, CASE-10DA91A7, pp. 21–22 and 83. The INV-5 warning concerns a time-inverted path in the report; that path is not included in these figures.Source register and report noteThis article adapts SentinelTX’s “MUSystem: Four-Transaction Ethereum Investigation — 30 September 2026,” case CASE-10DA91A7, an 85-page PDF generated on October 5, 2026, at 11:25:40 UTC. Page references above refer to that export. The source is the exported report, including its attributed claims and integrity qualifications; the article is not an independent on-chain audit or a certification of the report’s signature or custody claims.The four transaction identifiers in the PDF are:Run: 0xc6116f5ffa7935f3b06f71fc13e3ab0bf5e09a2b1091a134c79619447ce456f2Sample 1: 0xfe28118e48c64b275b587c90da472fc13b8c3dbed9d3cded1e18c1e7a7fc0392Sample 2: 0xaa172fcaa4800b14826daed1a78c9d6dcd8f26ae45ce5f31786d55768b709ec6Sample 3: 0x905af4e8cdaf32c183605358c97181e9ad57393bd4ed1d945baf6d6eebe983feExternal analysis cited by the report:SlowMist’s MUS disclosure, for the attributed mechanism and approximately $36,900 headlineDeFiHackLabs’ MUS reproduction, which the report cites but did not executeAddress key, using the roles in this article:Initiating / receiving EOA: 0x1a083ADf234a8f67ad65A9B9B616853ACf5998E5Orchestration contract, called the attack contract in the PDF: 0xD1a7A2A3c27962E80E9B6B46D54094F93267e988Affected contract: 0x9bdf81e6066d32764b7e75a1b5577237e06d9364Third recipient, role and control unresolved: 0xA30911099156608A32e35c11aCf2956258E0F645Sample 1’s first proxy: 0x8b0856e9b0787d09f9abded66bccc85feb5561d4Balancer Vault: 0xBA12222222228d8Ba445958a75a0704d566BF2C8WETH contract: 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

ChainBounty · Investigation analysisBase mainnet · Activity: October 4, 2026 · Reviewed: October 5, 2026Six transactions moved 1,783.067 aBaswstETH from a Base vault to an intermediate contract on October 4. The selected records then show receipt-token forwarding, a withdrawal of the underlying wstETH, and two Base-side bridge initiations totaling 1,001 wstETH. This reconstruction follows those movements through 20 transaction records, separating the token route from the reported exploit mechanism and the still-unverified destination-chain receipts.Key findingsSix vault outflows transferred exactly 1,783.067 aBaswstETH to a contract deployed by the same address that submitted the outflow transactions.Eight forwarding transfers preceded a pool withdrawal that released approximately 1,783.067 wstETH.Two Base bridge initiations burned 1 and 1,000 wstETH. The events identify an intended recipient; this review has not established receipt on Ethereum.The review covers one contract deployment and 19 token-movement transactions. All times below are UTC. Approximate figures are marked in the text. The linked receipts retain full addresses and native token precision, and all 20 records are listed below.Figure 1. The observed route from vault receipt tokens to two Base-side bridge initiations. Circular nodes identify roles; equal-width arrows show the token route without encoding quantities or elapsed time. Six vault transfers moved exactly 1,783.067 aBaswstETH; eight forwards moved approximately 1,783.067 aBaswstETH to Address A. At 09:23:13 UTC, a pool withdrawal burned aBaswstETH and released approximately 1,783.067 wstETH to that same address. Address A then made two transfers to Address B, which initiated bridge withdrawals of 1 and 1,000 wstETH. These are successive stages, not amounts to add together. This schematic groups the route by role; Figure 4 shows the interleaved downstream transaction order. ≈ marks rounding to three decimals. Ethereum receipt has not been verified.Address key: Vault 0xd1895f…cfcabc; intermediate contract 0xcdfe91…1f569d; Address A 0x0b5126…edb034; Address B 0xc73448…297f8d. Base burn denotes the token Transfer to the zero address in each bridge initiation, not a transfer to the bridge contract.Source: Basescan transaction receipts linked under Sources and method.The reported incident and the two assetsBlockaid’s October 4 public alert described an exploit of an unnamed vault involving a newly whitelisted contract and estimated about US$2.02 million across approximately four transactions. PeckShield’s alert separately suggested that about 1,783 wstETH, valued at roughly US$6 million, had been drained. These are attributed alert estimates. This review does not assign a revised dollar loss.The distinction between the two assets is central to the trace. aBaswstETH is an Aave receipt token representing supplied assets and accrued yield. wstETH is the underlying asset released in the later pool withdrawal. Aave’s tokenization documentation explains that a withdrawal burns aTokens and releases the underlying asset. Adding the receipt-token transfers, the withdrawal, and the bridge burns would count successive stages of the same position repeatedly.Contract deployment and vault outflowsAddress 0x0b5126…edb034 deployed the intermediate contract, 0xcdfe91…1f569d, at 07:28:57. It later submitted the six transactions that moved aBaswstETH from vault 0xd1895f…cfcabc to that contract.The first outflow, for 1 aBaswstETH, occurred at 08:55:01, 86 minutes and four seconds after deployment. Five more transfers followed: 100, 500, 500, 500, and 182.067 aBaswstETH. The last outflow occurred at 09:12:37. Together, the six transfers moved exactly 1,783.067 aBaswstETH over 17 minutes and 36 seconds.Figure 2. Six vault-to-contract outflows of aBaswstETH on October 4, 2026, in UTC transaction order. The exact amounts are 1, 100, 500, 500, 500, and 182.067, totaling 1,783.067 aBaswstETH over 17 minutes and 36 seconds. Bar length starts at zero and encodes token quantity. Rows are equally spaced for comparison, not elapsed time; the 1-token outflow is less than one pixel long at the 720-pixel image width, so its exact value is labeled.Source: the six vault-outflow receipts linked under Sources and method.The route in Figure 1 follows the token Transfer events; Figure 2 compares the six vault outflow amounts. The transaction sender is a separate field: 0x0b5126…edb034 submitted calls to the intermediate contract, while the token Transfer events name the vault as the source of aBaswstETH. That distinction connects the calls to the observed movements without claiming that the vault itself signed a transaction.Receipt-token forwardingEight transactions moved aBaswstETH from the intermediate contract to 0x0b5126…edb034. The first forward, for 1 aBaswstETH, occurred at 08:56:25, 84 seconds after the first vault outflow. The forwarding sequence ended at 09:15:09.Figure 3. Six vault outflows and eight receipt-token forwards through an intermediate contract. The outflows total exactly 1,783.067 aBaswstETH over 17 minutes and 36 seconds. Forwarding overlaps the outflows; ≈ marks its rounded total. Rows are evenly spaced, not an elapsed-time scale. The receiving address deployed the contract at 07:28:57 UTC.Address key: Vault 0xd1895f…cfcabc; Intermediate contract 0xcdfe91…1f569d; Receiving address 0x0b5126…edb034.Source: Basescan transaction receipts linked under Sources and method.The repeated calls have two distinct selectors: 0x9a39f8dd in the transactions containing vault outflows and 0xcb984317 in the forwarding transactions. Their timing supports a description of staged transfer-and-forward execution. A small first movement followed by larger transfers does not, by itself, establish whether the first movement was a deliberate test.The observed forwarding total is approximately 1,783.067 aBaswstETH. At full precision it differs slightly from the vault-outflow total, and the receipts also include small zero-address mint transfers. These are separate recorded totals; their small difference should not be treated as an additional loss.Withdrawal of the underlying wstETHAt 09:23:13, 0x0b5126…edb034 called a contract labeled “Aave: Pool Proxy Base” by Basescan. Its decoded Withdraw event identifies wstETH as the reserve asset and the same address as the recipient.The transaction burned approximately 1,783.067 aBaswstETH and released approximately 1,783.067 wstETH. Those are related sides of one pool withdrawal. The underlying asset moves out of the pool to the recipient, supporting the description of a withdrawal or redemption rather than a debt repayment.Diagram 1. Two accounting legs of one Aave pool withdrawal on Base at 09:23:13 UTC on October 4, 2026. The selected receipt records a Transfer of exactly 1,783.067000109162566728 aBaswstETH to the zero address (a receipt-token burn) and the release of exactly 1,783.067000294435092335 wstETH to the same holder, Address A. The displayed amounts are rounded to three decimals. The upper arrow represents the receipt-token burn within the pool operation; it is not an additional transfer to a new address. The diagram describes the recorded withdrawal and does not establish an exploit mechanism.Address key: Holder / same holder is Address A, 0x0b5126…edb034. Pool operation is a process label; reserve denotes the underlying-wstETH reserve in the selected receipt.Source: Pool-withdrawal receipt and logs.This is the point where the reviewed route changes from receipt-token transfers to movement of the underlying asset. The pool interaction provides no evidence of a vulnerability in Aave’s contracts. The separate question is how the vault’s receipt tokens became available to the transaction-sending address.Two Base bridge initiationsAt 09:24:15, the withdrawing address sent 1 wstETH to 0xc73448…297f8d. At 09:27:29, that second address initiated a withdrawal through 0xac9d11…4287ab. Lido’s official contract list identifies the call target as its Base L2 ERC20 Token Bridge.The bridge receipt records a 1-wstETH Transfer to the zero address and a WithdrawalInitiated event. The call went to the bridge contract; the token movement was a burn on Base.The larger transfer to the second address came at 10:47:23, for approximately 1,782.067 wstETH. Using their full precision, the two selected transfers sum exactly to the wstETH received in the pool withdrawal.At 12:10:59, the second address initiated a further withdrawal of 1,000 wstETH through the same bridge. Both WithdrawalInitiated events specify 0xc73448…297f8d as the intended destination-side recipient.Figure 4. Five downstream transactions in order: pool withdrawal; transfer; bridge-withdrawal burn; transfer; bridge-withdrawal burn. The 1-wstETH bridge initiation precedes the larger transfer between addresses. Both bridge branches end at Base-side burns; Ethereum receipt has not been verified. Rows are evenly spaced, not an elapsed-time scale.Address key: Token contract 0x99cbc4…42ef0d; First address 0x0b5126…edb034 (the upstream receiving address); Second address 0xc73448…297f8d; Base-side burn is the zero address.Source: Basescan transaction receipts linked under Sources and method.The two initiations total exactly 1,001 wstETH. Their order matters: the first bridge initiation happened before the second address received the larger transfer. Grouping both transfers ahead of both burns would misrepresent that sequence.Where the trace stopsThe vault’s permission path remains unresolved. Blockaid reported a newly whitelisted contract, but the reviewed transfers do not independently establish that change or show how it was authorized. The relevant vault implementation, administrative history, and execution traces are needed to test that explanation. The transaction records also do not identify a person or establish common beneficial control of both addresses.The two Base events specify an intended recipient, but this review has not matched either initiation to an Ethereum finalization transaction. A destination-chain continuation needs the corresponding withdrawal message, token amount, receiving address, and confirmed receipt before it can follow any onward movement.Finally, subtracting the two bridge burns from the two selected inflows to 0xc73448…297f8d leaves approximately 782.067 wstETH. This is an arithmetic difference, not a verified current balance. A balance finding needs a query at a specified block or a complete reconciliation through a stated cutoff, including any other transfers.Figure 5. Where the verified trace stops. The selected Base receipts show two bridge-withdrawal initiations of 1 and 1,000 wstETH, totaling exactly 1,001 wstETH. Ethereum receipt has not been verified. Vault permission, destination finalization, and current balance remain to be established from the evidence listed here. A difference between selected transfer amounts is not a verified balance.Source: 1 wstETH initiation; 1,000 wstETH initiation.Sources and methodThis reconstruction uses 20 successful Base transaction records inspected on Basescan on October 5, 2026, including relevant decoded events. It is a selected-record review, not a complete account-history reconciliation or a self-hosted chain replay. The public alert estimates are separately attributed above.Chart 1. Composition of the 20 distinct successful Base transaction records reviewed for this article. Receipt-token movements: 14 (70%), comprising six vault outflows and eight forwards. Underlying-asset records: five (25%), comprising one pool withdrawal, two transfers between addresses, and two Base bridge initiations. Contract deployment: one (5%). Each transaction is assigned once by its role; the withdrawal is counted once with the underlying-asset records despite including both a receipt-token burn and underlying release. The percentages describe the selected evidence, not token quantities, losses, account balances, or coverage of all chain activity.Source: the 20 distinct transaction receipts in the source list below; reviewed October 5, 2026.Contract deployment: 07:28:57Vault outflows: 08:55:01, 09:08:13, 09:09:21, 09:10:19, 09:11:11, 09:12:37Receipt-token forwards: 08:56:25, 09:08:53, 09:09:43, 09:10:45, 09:11:49, 09:13:27, 09:14:15, 09:15:09Pool withdrawal: 09:23:13Transfers between addresses: 09:24:15, 10:47:23Base bridge initiations: 09:27:29, 12:10:59