Defend Against Cybercrime with the Power of Community

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

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

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