Defend Against Cybercrime with the Power of Community

ChainBounty investigation · USDT token shown for context; no endorsement or attribution to the issuer.Key conclusion. One collector initiated 12 delegated USDT calls affecting nine token holders. Separately, two collectors consolidated 51,000 USDT. Neither the method nor the consolidation establishes victim consent, operator identity or total incident loss.Executive summaryPublic allegations about Tronify.rent / tron.store prompted a TRON transaction review. The strongest new finding is not merely where tokens moved: all twelve payment events in the examined subset were initiated by the same collector through the USDT contract’s transferFrom method. Nine different token-holder addresses were debited for a combined 15,864.609801 USDT. This contradicts describing these events as direct USDT transfers initiated by the debited wallets.Two later direct transfers separately show 51,000 USDT converging on one address. That consolidation amount is not a verified loss total and is not added to the payment subset. Approval origin, victim consent, domain attribution and operator identity remain unresolved.MeasureResult / scopeReport version1.1 · editorial revision, 6 October 2026; no extension of the evidence windowNetworkTRON 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────────────────────────────────Finding 1 — one caller, nine debited walletsQuestion: who initiated the token movement? TRONSCAN distinguishes the transaction owner from the From field in the token-transfer event. In all twelve inspected transactions, the owner is C2, while the token-transfer From field identifies a different balance holder. The method is transferFrom, not transfer. All twelve are successful and confirmed; the token contract is TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.This establishes delegated movement of token balances by a common caller. It does not establish how the authorization was obtained, whether it was informed consent, or which website caused it. The sequence merits an approval-history investigation, but an approval-phishing conclusion would require that missing evidence.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.RoleFull addressEvidence boundaryC2 · caller / collectorTV6n8cCLmX5mRCMMNvcE1K1i87Yo9Ys5rvOwner of every payment call; recipient in some eventsC1 · collectorTLv3iSnZxWghEmadLDzuAK2p5GkAwg7tpJRecipient in other payment eventsH · consolidationTDDfKDDttx6rFkq2YWzge83RZqQgerzs9MReceives the two later sweep transfers────────────────────────────────Finding 2 — a concentrated subset, not a complete victim censusQuestion: what does the observed amount measure? It is the sum of twelve transaction-event amounts, counted once per hash. It covers nine distinct token-holder addresses; repeated events for the same address are not additional victims. The largest event is 13,472 USDT, approximately 84.92% of the subset. No conversion to a contemporaneous USD price is applied.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.Unpaired collector inflows, recycled funding and downstream hops are not added. Publicly reported victim counts and losses are a different population. Their gap with this subset remains unexplained, not filled by assumptions.────────────────────────────────Finding 3 — two collectors converge in 81 secondsQuestion: is the consolidation connection real? Yes: on 30 September, C1 sends 36,000 USDT and C2 sends 15,000 USDT to H. Both transactions call transfer and are confirmed in the explorer. Convergence proves these transfers, not common ownership or that every token in them came from the twelve earlier events.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.────────────────────────────────Timeline — transfer observations and public reportingUTC 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────────────────────────────────Normal infrastructure is not an attacker attributionThe 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.────────────────────────────────Evidence classification and alternative interpretationsEvidence 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 attributionDelegated transfers can occur in legitimate workflows as well as deceptive ones. The transaction method alone cannot establish fraud, intent or a stolen private key. A common transaction owner strengthens the operational connection of the examined calls, while actual operator identity remains unknown. Public allegations concerning Gemini recommendations, AI videos or search manipulation are off-chain claims and do not become proven causes through this ledger.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.────────────────────────────────Case-specific response pointsQuestion 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 attributionThese are evidence priorities, not claims that funds have been frozen, recovered or definitively traced to 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.1 improves evidence indexing, appendix structure, figure captions, visual spacing and the smaller-event chart. The verified transaction set, aggregate 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