Defend Against Cybercrime with the Power of Community

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. 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.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.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

Investigation FindingsExecutive SummaryOn 1 October 2026, a third-party FlashLoopAdapter enabled execution from two Safe accounts. The exploit transaction delivered 114.096151469674448809 ETH to the initiating EOA. The evidence points to delegated module authority, not an exploit of Aave V3 core. SlowMist primary analysis and clarification.The strongest downstream finding is an exact fee split: 114.030726169100264326 ETH was wrapped, 113.745649353677513666 WETH entered the RAILGUN privacy-system proxy, and 0.285076815422750660 WETH went to the protocol treasury. The visible route ends at that privacy boundary; it does not identify a hidden recipient or prove an exchange cash-out.Measure / scopeVerified resultExploit proceeds received114.096151469674448809 ETH; counted oncePrivate-pool transfer113.745649353677513666 WETHTreasury fee0.285076815422750660 WETHScopeEthereum; focused funding and outbound routeInvestigation cutoff4 October 2026, 23:32:47 UTC; block 26122303Evidence basisSentinelTX call traces and receipts, independently checked Etherscan anchors, SlowMist primary analysisCore findingWhat establishes itDelegated authorityVictim-emitted module success logs 1023 and 1030Exact extraction accountingReceipt logs separate collateral, repaid debt, returned loan and ETH proceedsPrivacy boundaryShield receipt separates private-pool transfer and protocol feeFinding 1 — How Did the Safe Accounts Execute Without Owner Signatures?The question is not whether a wallet signed the initiating transaction—it did—but whether the victims’ owners signed the Safe executions that removed assets. The traced exploit used module executions. No owner-signed Safe execution was observed in the inspected call tree.Observed call relationshipEvidence / interpretationAdapter → victim Safe 1Module execution targeting weETH transferAdapter → victim Safe 2Module execution targeting lending-pool withdrawalAdapter → execution helperAdditional module execution frames naming the helper as the SafeCoverage boundary259 frames reported; 134 returned by the trace tool—not a complete replaySlowMist reports that open()/close() checked ISafe(msg.sender).isModuleEnabled(address(this)), allowing a fake caller to answer its own authentication check. It then describes attacker-controlled router.call data targeting genuine victim Safes through execTransactionFromModule. This source-level explanation is attributed research; our call-trace evidence supports the module-execution route, but we did not independently compile or replay the adapter. SlowMist primary analysis and clarification. 0x75328f916b1a0878724d364da5eb12b255160b894cb36c63ed5d718efc616fc4.Receipt corroboration — two victim-emitted success eventsBoth victim Safe contracts emitted ExecutionFromModuleSuccess naming the same adapter. Log 1023 follows the first victim’s weETH Transfer; log 1030 follows the second victim’s Aave withdrawal. These events independently corroborate the module route beyond the partial call trace. They establish successful execution by the named module, but do not by themselves reconstruct the caller’s authorization check or the owners’ earlier decision to enable it. Exploit receipt: decoded event logs.The implication is a separate authorization boundary: enabling a module grants executable authority beyond the ordinary owner-signature path. SlowMist explicitly clarified that Aave V3 core was unaffected. The current enabled-module lists and the complete set of exposed Safes were not enumerated; two observed victims are not a total exposure count.Finding 2 — Which Amount Is the Loss, and Which Is Reused Liquidity?The exploit receipt and internal movements show WETH unwrapped into the execution helper and then paid to the attack EOA. Those two legs describe the same 114.096151469674448809 ETH and must be counted once. 0x75328f916b1a0878724d364da5eb12b255160b894cb36c63ed5d718efc616fc4.QuantityClassificationEvidence boundary114.096151469674448809 ETHExploit proceeds receivedExact internal transfer11,537.239738536922710940 WETHMorpho loan and matching returnExact logs 1014–1015 and 1059; returned liquidity1,335.255802777509633370 WETHDebt repaymentExact Repay event for victim Safe 2, log 10211,449.351954247184082179 WETHSwap outputExact WETH transfer to helper, log 1058The large flash loan provides temporary liquidity for repayment and collateral release. It was returned, so counting it as stolen funds would inflate the incident by two orders of magnitude. Proceeds received are also not necessarily each victim’s gross collateral loss: debt repayment changes the net economic calculation. The receipt now establishes each victim’s exact token movements. A single ETH-denominated loss for each victim still requires an explicit weETH valuation basis and account-state reconciliation.Subtracting only exploit-transaction gas gives 114.092231045147641069 ETH. That is an arithmetic subtotal, not an all-in profit claim: deployment costs, forwarding costs and other activity are not completely reconciled.Victim Safe 1 — direct token removalThe first victim transferred 6.426087021311600894 weETH directly to the execution helper in log 1022. Its own module-success event follows in log 1023. This is an exact token outflow; it must not be relabeled as 6.426087 ETH or added to a WETH figure without a conversion basis. Exploit receipt: decoded event logs.Receipt itemExact resultVictimSafe 1; full account address in evidence appendixweETH outflow6.426087021311600894 weETHTransfer evidenceLog 1022; victim → execution helperModule executionLog 1023; adapter named by victimVictim Safe 2 — collateral removal after debt repaymentThe helper paid 1,335.255802777509633370 WETH against Safe 2’s debt. The Pool Repay event identifies both that victim and the helper as repayer. The Pool then records withdrawal of 1,306.482324969756972729 weETH for Safe 2 to the same helper; the token Transfer corroborates it. Gross collateral removed and debt extinguished are economically different legs. Exploit receipt: decoded event logs.Receipt itemExact resultDebt repaid for Safe 21,335.255802777509633370 WETH; logs 1020–1021Collateral delivered to helper1,306.482324969756972729 weETH; logs 1027 and 1029aToken burn value1,306.482262583889567736; log 1026Accrued balance increase0.000062385867404993; log 1026Module executionLog 1030; adapter named by victimThe aToken burn value plus its logged balanceIncrease equals the underlying weETH withdrawal exactly. Counting the burn, Transfer and Withdraw as three losses would triple-count the same collateral leg. The debt-token Burn likewise separates 1,329.536830578102452349 from 5.718972199407181021 of balance increase; together they equal the 1,335.255802777509633370 WETH repayment. These are receipt reconciliations, not independent cash movements.Helper accounting — why the flash loan cancels outHelper WETH legExact amount / receiptMorpho loan in11,537.239738536922710940 WETH; logs 1014–1015WETH debt repayment out1,335.255802777509633370 WETH; logs 1020–1021WETH swap output in1,449.351954247184082179 WETH; log 1058Morpho loan returned11,537.239738536922710940 WETH; log 1059WETH unwrapped114.096151469674448809 WETH; log 1060The matching loan-in and loan-return cancel. Swap output minus debt repayment equals 114.096151469674448809 WETH exactly, matching the withdrawal event and subsequent ETH receipt. This explains the observed extraction without treating temporary liquidity as incident loss. The helper also retained approximately 0.008411991 weETH in the explorer’s rounded token overview; it is excluded from the exact ETH subtotal because that overview is not an exact balance proof. Exploit receipt: decoded event logs.Finding 3 — What Actually Entered the Private Pool?The forwarding transfer is larger than the exploit receipt because the EOA had pre-existing funding. It cannot be treated as an exclusively stolen-funds figure. The next transaction converts the gross ETH input to WETH and divides it between the privacy-system proxy and treasury. 0x3a5663d9a3d32bdea3c3012fd9dbaf490195ed413204c4db8f1097e1e7f753f9. 0xa20636bf3792f705ae51a48afdec336fb0518cd43365a8fc3e596dea23266dc9.Shield receipt legExact WETHLogWrapped input114.030726169100264326262Transfer to privacy-system proxy113.745649353677513666266Transfer to treasury0.285076815422750660267Shield eventSupports the amount / fee split268The allocation chart below uses a shared linear WETH scale. The fee bar is intentionally tiny: enlarging it without a separate scale would misrepresent the 0.25% allocation. Chart labels are rounded to six decimals; the native table above preserves the full values and receipt indices.The two transfers sum exactly to the wrapped input. The treasury fee is 0.25% rounded down at token precision; transaction gas of 0.001793902352363730 ETH is separate. The treasury leg is a protocol fee—not evidence of cash-out, common ownership, or a recovery target. We independently checked these visible Etherscan logs against the SentinelTX follow-up result.Timeline — Funding, Execution and DispositionAll times below are UTC on 1 October 2026. These are selected transaction anchors, not a claim that every intervening transaction has been accounted for.UTC / blockEventAmount14:15:23 / 26098000RAILGUN withdrawal funds attack EOA0.049875 ETH net received15:08:47 / 26098264Exploit helper pays attack EOA114.096151469674448809 ETH16:45:59 / 26098748Attack EOA forwards to intermediate EOA114.130726169100264326 ETH16:46:59 / 26098753Intermediate EOA sends Relay Adapt input114.030726169100264326 ETHFunding to exploitation took 53 minutes 24 seconds. The creation transaction preceded exploitation by six minutes; forwarding followed exploitation by 1 hour 37 minutes 12 seconds, and shielding followed forwarding by 60 seconds. These measured intervals are consistent with a prepared execution sequence, but do not identify a person or prove coordination with any service operator.Helper creation — a direct infrastructure anchorThe creation transaction at block 26098235, 1 October 2026 15:02:47 UTC, was signed by the same initiating EOA and sent to a separate contract; the explorer identifies the helper as created within that transaction. This establishes a transaction-level infrastructure link. It does not justify calling the EOA the direct CREATE caller without inspecting the creation call frame. 0x0c2bbaf2b5ebf1102e0df4acb1bcc2c7bc920896c45da6f85b4e9442506a3884.Creation anchorObserved resultTransaction signer0x42c2633438609881c8fBAb82414eb9A0c45F9353Transaction target0x4a418c7132d452705a2123e95B5b9bFdF3b1f84aCreated helper0xf09168963ac7b31917a02aa82fa9cd667f4b67ffUTC / block2026-10-01 15:02:47 / 26098235Creation transaction0x0c2bbaf2b5ebf1102e0df4acb1bcc2c7bc920896c45da6f85b4e9442506a3884Connection Evidence — Direct Transfers Are Not Identity EvidenceA same-transaction call chain directly connects the initiating EOA, helper, adapter and victim executions. Two later transaction hashes directly connect the initiating EOA to the forwarding EOA and Relay Adapt. These are transaction relationships, not human attribution.Proposed connectionEvidence levelConclusionAttack EOA → helper → adapter → victimsDirect inspected call traceExecution relationship establishedAttack EOA → forwarding EOA → RAILGUNDirect value transfersVisible disposition route establishedFunding withdrawal and shield use same public serviceShared service patternDoes not establish hidden owner continuitySimilar-looking addressesPotential poisoningDo not merge into attacker clusterPost-shield withdrawal of similar sizeHeuristic onlyAmount / timing alone cannot attribute fundsLimits and Alternative InterpretationsThe traced scope is Ethereum. Two reported Optimism activities were not inspected. The exact exploit receipt and helper creation transaction were checked in this revision. Adapter source code, a complete replay, incident-block module lists, the precise CREATE caller and each victim’s pre/post account valuation remain unestablished. Historical owner/setup claims from the first automated result were withdrawn in the follow-up and are not used here.The RAILGUN funding-transaction signer may be an independent relayer. Shared public infrastructure does not identify an operator. No exchange endpoint was identified in the inspected routes; that is narrower than proving no exchange cash-out occurred. The private-pool transfer cannot be followed to a particular hidden withdrawal using these public records alone.Visible noncustodial EOA balances are not automatically freezeable. We also do not describe the helper’s deployment as the only remaining lead: unexamined histories, module exposure and alternate infrastructure remain separate questions.Incident-Specific Response PointsQuestionPractical investigation actionWhich Safes retain this authority?Enumerate adapter-enabled Safes and incident-block module lists; validate current exposure before remediationHow much did each victim lose net of debt?Use the exact receipt legs established here; reconcile pre/post positions and a documented weETH valuation basisWas infrastructure reused?Inspect the creation call frame and transaction target history; the signing EOA is now directly linked to helper creationCan downstream funds be attributed?Treat pool exit matches as leads; require independent evidence before attribution or exchange requestsFor affected account operators, the relevant control is the specific module’s execution authority. A verified vulnerable-module exposure warrants targeted module revocation and preservation of account state and receipts. This is distinct from a blanket assertion that Safe or Aave core is compromised.Evidence Appendix — Ethereum Account AnchorsRoleFull addressAttack EOA0x42c2633438609881c8fBAb82414eb9A0c45F9353Execution helper0xf09168963ac7b31917a02aa82fa9cd667f4b67ffThird-party adapter0x16bb8b912da187870c23ec6756bb3fad061283d8Victim Safe 10xe3b23e47df7cd85876ac6cb05bdb9d7cd5b28520Victim Safe 20xcfedf95a3653a128dfc2e4288758a1a1850d169fForwarding EOA0x951ad21b85c1ce165f15d548a7c7d42520a32f1aRAILGUN Relay Adapt0xac9f360ae85469b27aeddeafc579ef2d052ad405RAILGUN privacy-system proxy0xfa7093cdd9ee6932b4eb2c9e1cde7ce00b1fa4b9RAILGUN Treasury0xe8a8b458bcd1ececc6b6b58f80929b29ccecff40Evidence Appendix — Contract and Asset AnchorsRoleEthereum addressweETH token0xcd5fe23c85820f7b72d0926fc9b05b43e359b7eeWETH token0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2Aave Pool V30x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2aEthweETH token0xbdfa7b7893081b35fb54027489e2bc7a38275129Variable debt WETH token0xea51d7853eefb32b6ee06b1c12e6dcca88be0ffeMorpho flash lender0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcbHelper creation transaction target0x4a418c7132d452705a2123e95B5b9bFdF3b1f84aEvidence Appendix — Transaction AnchorsRoleFull transaction hashHelper creation0x0c2bbaf2b5ebf1102e0df4acb1bcc2c7bc920896c45da6f85b4e9442506a3884Funding withdrawal0xc5dc2606e42ebfad29fce601056248b9b3f3571318c9a0de2910ac7c0363852bExploit0x75328f916b1a0878724d364da5eb12b255160b894cb36c63ed5d718efc616fc4Forwarding0x3a5663d9a3d32bdea3c3012fd9dbaf490195ed413204c4db8f1097e1e7f753f9Shield / fee split0xa20636bf3792f705ae51a48afdec336fb0518cd43365a8fc3e596dea23266dc9Source and Method NotesPrimary mechanism and scope clarification: SlowMist primary analysis and clarification. Incident index: SlowMist Hacked. Transaction references above are Etherscan records. SentinelTX was used for the original call-trace and downstream receipt analysis. This revision directly checked the exploit receipt’s decoded events and the helper creation transaction in Etherscan; the shield accounting and exploit anchor were cross-checked against visible explorer records. The report separates directly observed transfers, attributed source-code findings and analytical inference.The central result is a module-authority route yielding a precisely observed ETH receipt, followed by a fee-reconciled privacy-pool entry. A large flash loan is not the loss figure, a protocol fee is not cash-out, and a privacy endpoint is not an identified attacker.Revision note — 5 October 2026: added exact victim-level receipt accounting, helper creation evidence, a measured UTC timeline, a proportional shield-allocation chart and clearer directional diagrams. The original investigation window ends at block 26122303 (4 October 2026 23:32:47 UTC); this revision does not claim a complete scan of later activity.

Executive SummaryPublic research describes an Aquifer Solana venue exploit on 31 August 2026. This investigation separates the reported exploit mechanism from the later transaction-anchored proceeds trail. Ethereum records confirm a transfer of 1,000.795547188808275967 ETH on 1 September to a relay address. Eleven subsequent Arbitrum USDC transfers to a contract labeled Hyperliquid: Deposit Bridge 2 total 2,470,625.249359 USDC.The deposit total does not establish a current Hyperliquid balance, the identity of the operator, or an ability to freeze assets. The Solana provenance of the largest Ethereum arrival remains unresolved. Reported counts of 212 calls and 18 vaults were not independently re-enumerated.Incident AnchorsRoleAddress / networkEvidence boundaryReported exploit wallet7fTe9pvrwXJRBHq9MaSyVPR4PgEuhqLiA93Dxf4gRk7JSolanaPublic incident anchor; selected transfers tracedEthereum arrival0x2Dfe9e969796e2797278b02761dd9Ad6aE922746Forwarded 1,000.795547188808275967 ETHRelay / depositor0x200e52350fbc579c96bad87b6ef782c1f962dffdArbitrum; same address also used on EthereumSender of all 11 verified depositsDeposit destination0x2df1c51e09aecf9cacb7bc98cb1742757f163df7ArbitrumExplorer label: Hyperliquid: Deposit Bridge 2; onward balances not establishedThe Ethereum HandoffA successful Ethereum transfer on 1 September at 20:37:23 UTC forwarded 1,000.795547188808275967 ETH from the explorer-labeled Aquifer Exploiter 1 address to the relay. This is a verified transaction anchor, not proof that every upstream Solana transfer has been matched.FieldVerified valueTransaction0x728294f756bf1f2f35fb32d9c5a18b5f65f9e78cdc2fae72544a64ffb8004800Block / status25,884,871 / SuccessETH transferred1,000.795547188808275967ETH transaction fee0.000022413007617The dashed Solana segment marks unresolved provenance; the deposit endpoint does not imply current holdings.Verified Arbitrum Deposit LedgerAll eleven transactions below were checked against visible Arbiscan records: successful status, the same sender and destination, and native Arbitrum USDC. Times are UTC in 2026. The total is gross deposited USDC, not a current account balance or independently proven total stolen proceeds.UTC / sequenceUSDCTransaction1 · 09-04 20:16:472,453.9642340x5ca132222846c1e54b7ff42cd57869cb9734b23e34c1309ba7920e88c4ccea002 · 09-04 20:24:12243,041.1311030x2841ebcd439b5a22d1874d16a34c35e1aabada620bc54e2e93c2b796b421f4323 · 09-05 00:28:49245,361.5044680xfebdb16f6dd1ece48e0321da5acf80adc6a110a62ae8bd070936de4808d136734 · 09-05 02:41:46244,958.4719630x2e87862888319a4c1adcdab04d80f45a06172bd2e150156c80f26d0013ca4b275 · 09-05 04:47:32244,776.9320260xd37f8c85728d2539dca14f5c4ec54084c0270fe871f891f76910137569130a446 · 09-05 17:15:46247,930.4844880x44b89b44235aa3990a8c6fe12ce948a5e301b6bf9ba3dc1c48d3e87d718290c47 · 09-05 20:11:06247,586.8793160x4fa683c1804963b151fbbf36cd33420f0b0b24900d8837db9472069cbf9a742d8 · 09-05 22:15:04248,624.1728560x1af9d9423bb06d4002616c928ffbbc6637a36a6f4e6f817873750366bc4e78339 · 09-05 23:18:24247,966.9649290xdd1b18847b4dc17419fc0af0b30df967773f852eb934d7d6b972da963938ea8610 · 09-06 00:16:16248,132.1646680x0832c6bd5077ee6230bbbe1f4882d37d8fe03676b6c48d050bc8b4e9681f8b4311 · 09-06 02:40:26249,792.5793080x3933bb6d2e80de8365e92ec226df853a19f408206ead21589e96fb4b7e43fcf8Total · 11 deposits2,470,625.249359Nonces 0–10What the Deposit Endpoint Does Not ProveThe destination is explorer-labeled Hyperliquid: Deposit Bridge 2. These transactions establish deposits to that contract. They do not establish the subsequent trading-account balance, withdrawals, beneficial ownership, or the availability of a freeze mechanism. Those conclusions require separate evidence.CCTP: One Supported Pair, Not Eleven Proven PairsSentinelTX saved evidence supports one Ethereum burn and Arbitrum mint pair using decoded message fields and matching amounts. The other ten routes remain amount-and-time correlations. A message hash and attestation were not established in the retained evidence, so this report does not claim complete cryptographic proof for all routes.StageUSDCEvidenceEthereum burn249,820.128254Decoded source amountExecuted fee27.548946Decoded feeArbitrum mint249,792.579308Burn minus feeFinal deposit249,792.579308Independently checked Arbiscan transferRecordTransactionEthereum burn0xe169519295399ed8d548480c77b1c01d97538bf2de99d3371adfbd2646d67f5aArbitrum mint0xb02754f975a86c91f3ebdfab98723c9e8e431047293beab7dd304a0afdcb7497The fee-adjusted mint equals the last verified deposit. This figure illustrates one supported pair, not a universal proof of every route.The Separate Privacy BranchA separate relay-funded branch received 1 ETH and interacted with wrapping and shielding infrastructure. Its amounts must not be confused with the much larger Arbitrum deposit route or with total activity in a shared helper contract. The following values come from the saved SentinelTX investigation, not a fresh independent replay of every internal call.StageAsset / amountMeaningRelay funding1 ETHBranch seedWrap-helper input0.999709712414154961 ETHSaved internal-call evidenceShield amount0.9959140645635465 WETHCase-specific branchFee output0.002496025224470041 WETHSaved fee transferUnreconciled difference0.00129962262613842 WETHDo not assign a destination without evidenceThe lower branch is separate from the main Arbitrum deposit route. Its unreconciled remainder is explicitly retained rather than assigned by inference.RoleEthereum address / transactionBranch wallet0xbc8d344b12c728707eb005b123786f3cd22e905cFunding transaction0xd2b4fee82f7322128fe1ffebb9697f6af3ee829ab6d2951419c1c3d0bea73485Shield transaction0x699cb2d44ec16685e6a7ae4f17a08798300beb4378ca66c0a8957a643b931d20The shared helper’s aggregate volume is not Aquifer proceeds. The earlier 54.53 WETH preview is not attributed to this case. A later call from the branch wallet remains unverified; the privacy boundary prevents a supported claim about its final owner or destination.Evidence Boundaries and Next Verification PointsQuestionCurrent evidenceRequired next checkLargest Solana-to-Ethereum arrivalProvenance unresolvedMatch source bridge recordAll CCTP routes paired?One supported; ten correlatedCompare message identifiers and attestationsFunds still on Hyperliquid?Deposits onlyEstablish account-level onward activityWho operated the wallet?No human attributionIndependent attribution evidenceGross deposits equal stolen funds?Not fully establishedReconcile every inbound source and dustConclusionThe strongest result is a transaction-anchored EVM trail: one large ETH handoff and eleven independently verified Arbitrum USDC deposits. The key analytical distinction is between seeing a deposit endpoint and proving where the money is now. Upstream provenance, complete cross-chain message matching, and onward account activity remain separate questions. Neither a service label nor a matching amount establishes an operator’s identity.Source NotesThe report combines the saved SentinelTX investigation with visible Etherscan and Arbiscan transaction checks. Public incident context: Bitquery Aquifer investigation. Reported exploit counts and mechanism are public research, not an independent re-execution performed for this report. The full transaction links above identify the directly checked transfer evidence.