Defend Against Cybercrime with the Power of Community

On October 6, 2026, a transaction moved 200 WETH out of a collateral contract, converted it to ETH, and paid the ETH to the address that initiated the transaction.That address then sent 20 transfers of 10 ETH each to a Tornado Cash router. A security alert attributed the withdrawal to a permission problem in an old auction keeper. The transfer records establish the money trail; the alert's explanation of the cause requires separate verification.This walkthrough explains what the auction was for, how the funds moved, and where the available evidence stops.Incident date: October 6, 2026.Evidence reviewed: October 6, 2026, 21:55 UTC (October 7, 06:55 KST).Scope: one withdrawal transaction, 20 subsequent transfers, and the internal ETH payment in the final transfer.1. What the transaction records showAt 06:13:11 UTC on October 6, 200 WETH moved through a sequence of contracts. Within the same transaction, the WETH was unwrapped into 200 ETH, which reached the transaction's initiating address. View the withdrawal transaction.The receiving address subsequently made 20 transfers to the same Tornado Cash router, each for 10 ETH. The last transfer was recorded at 06:28:35 UTC, 15 minutes and 24 seconds after the withdrawal. View the address transaction list.Measure: WETH movedObserved value: 200 WETHWhat it means: The amount moving through the withdrawal transaction.Measure: Subsequent transfersObserved value: 20 × 10 ETHWhat it means: A total of 200 ETH sent to the router, excluding gas fees.Measure: Elapsed timeObserved value: 15 minutes 24 secondsWhat it means: From the withdrawal to the final transfer, not the duration of the whole incident.Defimon Alerts described the incident as a withdrawal-permission problem affecting an old MakerDAO liquidation-auction keeper. A keeper is software that automates tasks such as participating in auctions. To understand the allegation, it helps to start with what those auctions sell. Read the October 6 alert.2. An auction of loan collateral, not an NFT auctionMakerDAO allows users to deposit assets such as ETH as collateral and borrow DAI, a token designed to track the value of one US dollar. The collateral must remain sufficient under the system's rules.Think of borrowing money against an item you own. If that item's value falls too far, it may need to be sold to settle the debt. In this setting, selling the crypto collateral through an auction is called a liquidation auction.This is a simplified analogy. The actual system has collateral-specific thresholds, fees, and settlement rules. Read the official liquidation-system proposal.The borrower and the auction buyer are different participants. A keeper can automate bidding for an auction participant; the word does not mean the person who borrowed against the collateral. See the official Auction Keeper project.Figure 1. From borrowing to withdrawing collateralRead from top to bottom. This is a conceptual diagram of the historical Flipper process, not an execution trace of this incident. It omits detailed bidding rules and does not describe the entire current liquidation system.Winning an auction does not automatically place the collateral in an external wallet. In the historical auction contract, a completed auction is settled through a function called deal. Withdrawing the internally credited collateral as an external token is a separate step.The published Flipper code allocates the collateral to the recorded winning bidder. Calling the settlement function does not, by itself, make the caller the owner of that collateral. See the Flipper implementation.The linked source explains the general mechanism. Its comments note differences from the production version, so it should not be assumed to match the exact contract deployed at the time of this incident.3. The alert concerns a separate withdrawal permissionAccording to Defimon, a keeper had won four auctions in 2020—numbers 1457 through 1460, each for 50 WETH—but had not settled them. The alert says this left collateral equivalent to 200 WETH available for settlement.Defimon reported that an external caller used an unprotected keeper function to carry out the settlement and withdrawal sequence. These historical and causal details are the alert's account, not independently established conclusions from the transfer records alone. Read the source alert.A publicly callable auction-settlement function is not automatically a vulnerability.The alleged problem is that someone else could invoke functionality that sent the keeper's collateral to a specified external address. Confirming the missing permission, the implementation, and the configuration requires historical code and state analysis.For that reason, these records should not be described as proof of a system-wide MakerDAO compromise. They show a specific asset movement, alongside an externally reported explanation involving a keeper.4. One transaction contains several asset movementsA blockchain transaction can contain more than one transfer. A contract can call another contract, which can then move tokens or pay ETH. The address that starts a transaction is therefore not necessarily the first address sending the asset.Here, 0x01EB…A5FA initiated the transaction. The first WETH sender in the token-transfer records was the collateral adapter labeled Sky: MCD Join ETH A by the explorer. That is an explorer label for the component, not evidence that the entire Sky or historical MakerDAO system was compromised. View the transaction details.Figure 2. Separating WETH transfers from ETH paymentsBlue represents WETH; purple represents ETH. The numbered stages explain one transaction, not five separate transactions. The gray panel identifies the initial call rather than an asset transfer. Sources: token logs 174, 176, and 177, plus internal ETH transfers.WETH is a token representation of ETH. In this transaction, withdrawing 200 WETH caused the WETH contract to release 200 ETH. This is a change in the asset's form, not evidence of a profit or price gain.Do not add every appearance of “200” and conclude that 800 ETH was lost. The records show the same-sized amount passing through intermediate contracts and changing form.Similarly, the subsequent 200 ETH sent by the receiving address must not be counted as an additional, separate 200 ETH loss.Evidence 1. The withdrawal transaction on EtherscanCompare the transaction identifier and timestamp with the two WETH transfers and two internal ETH transfers. Dollar values shown in the screenshot reflect the explorer display at capture time; they are not used to calculate the incident-time loss. Open the original transaction.5. The receiving address made twenty transfers of 10 ETHThe transaction list for 0x01EB…A5FA shows 20 subsequent calls labeled Deposit, directed to the same Tornado Cash router. Each sent 10 ETH.The total is 200 ETH in transferred value, excluding gas fees. View the address history.A router is an intermediate contract that forwards a request to another contract. For the final transfer, the internal transaction record also shows the router paying 10 ETH to the pool labeled Tornado.Cash: 10 ETH.That detailed check establishes the router-to-pool payment for the final transaction. It should not be confused with a complete internal-trace review of all 20 transfers. View the final transfer.Figure 3. All twenty transfers in block orderEach tile represents one transfer of 10 ETH. Read left to right, then top to bottom. Tile spacing does not represent elapsed time. This is a static image; individual transaction links appear in the table below.The withdrawal occurred at 06:13:11 UTC; the final transfer occurred at 06:28:35 UTC. The interval is 15 minutes and 24 seconds.This is the interval between those two transactions. It is neither the time spent on the entire operation nor the duration of the 20 transfers alone.Evidence 2. Repeated 10 ETH transfers from the same addressEtherscan lists the newest transactions first, the reverse of the chronological diagram. Compare the Method, To, and Amount columns. Open the original address history.Evidence 3. The final 10 ETH paymentThe successful transaction is timestamped 06:28:35 UTC. From identifies the initiating address, To identifies the router, and Internal Transactions shows the router paying the 10 ETH pool. Open the original transaction.Tornado Cash is a mixer designed to make the direct link between a deposit and a later withdrawal difficult to establish. These deposit records alone do not identify a later exchange destination, prove a cash-out, or identify the person controlling the address.The money-flow diagram stops where the evidence stops.Transaction references for all twenty transfersOrder: 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: 0xf1db855a987c2fb5e0ea6184ae8f8ed3271cca98c80e627be4839e4b4ac8dcbf6. The money trail and the cause are different questionsThe records describe where the assets moved. They do not, on their own, prove the precise vulnerability or identify the operator. Keep the observed transfers, the external explanation, and the unresolved questions separate.Figure 4. 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.Open question: Which permission was missing?Evidence needed: The keeper's historical implementation, storage state, and execution trace.What it would establish: Whether the cause was a code defect, initialization issue, configuration problem, or another mechanism.Open question: Had the auctions remained unsettled since 2020?Evidence needed: Creation, bidding, and settlement records for auctions 1457–1460.What it would establish: Whether the alert's account of the collateral history is correct.Open question: Did all 20 transfers reach the same pool?Evidence needed: Internal transfers and events for each Deposit transaction.What it would establish: The pool's total receipts, separately from the amount sent to the router.Open question: Where did the funds go after mixing?Evidence needed: Independent evidence supporting a deposit-to-withdrawal link.What it would establish: Whether any later destination can be attributed reliably.The supported conclusion is a withdrawal of 200 WETH, its conversion to ETH, and 20 subsequent transfers totaling 200 ETH from the receiving address.The reported permission failure and the old auction history remain follow-up verification tasks. If the account of long-unsettled collateral is confirmed, the case illustrates why winning an auction, settling it, and securing the eventual withdrawal must be treated as distinct steps.7. Addresses and source recordsThe roles below describe transaction behavior or an attributed source claim. They do not identify a person or establish that a contract operator knowingly participated 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 transactionSource linksWithdrawal transaction, timestamp, token transfers, and internal ETH transfersWithdrawal transaction event logsInitiating address and subsequent transaction historyFinal Deposit transactionDefimon Alerts report of the alleged causeOfficial liquidation-system proposal, MIP45Published Flipper source for the general settlement mechanismOfficial Auction Keeper project

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

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