Defend Against Cybercrime with the Power of Community

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