15 Minutes, 24 Seconds: Following the Movement of 200 ETH

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 NFTs

Why 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 collateral

A 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 money

You 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 ETH

On 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 payments

Follow 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 Etherscan

Original 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 ETH

After 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 order

One 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 address

Original explorer evidence: the newest entries appear first. Compare the Method, To, and Amount columns. Open the wallet history.

The final transfer shows one step further

The 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 payment

Original 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 trace

The 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 losses

We 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 twice

Read 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 checking

Defimon 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 questions

This 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 away

The 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 questions

Labels 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 references

Each 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: 1

Block: 26131503

Amount: 10 ETH

Original transaction: 0xb8ecff9c129d8d9331c85558eaeddff29a38c4c16b71a40986acbf8f6febefeb

Order: 2

Block: 26131507

Amount: 10 ETH

Original transaction: 0x01dd51eff5790bf070ae5abefc4a77f3df2b2476feebbe9aaa6ffa1fd48f8429

Order: 3

Block: 26131509

Amount: 10 ETH

Original transaction: 0x8c5fb4f50aa0f56cc701afdad377e56f53655e48e237f85aef8fe902797a4240

Order: 4

Block: 26131512

Amount: 10 ETH

Original transaction: 0x9a6ef7cce759e09f1d23115f974eb0707460a6834de0d30a55c3761a9c9dce6c

Order: 5

Block: 26131514

Amount: 10 ETH

Original transaction: 0x725cdd6f23f7fc30d6ab43a6cf634aec791e5e2097151a09fc522408786da3ff

Order: 6

Block: 26131516

Amount: 10 ETH

Original transaction: 0xaf1fb061f3d3db6cc6107219ea7bc5e0c6f86ba54c997e10bb062e0a3f7f7eed

Order: 7

Block: 26131519

Amount: 10 ETH

Original transaction: 0xfd60254ab0a74ae6d51706023394190ca20646264d1da322998afa4682ae18b2

Order: 8

Block: 26131521

Amount: 10 ETH

Original transaction: 0xcc14212fc5d51d3d5ea7f0de9895264da8c0b5c779ca2947083f665f50f0bfbe

Order: 9

Block: 26131523

Amount: 10 ETH

Original transaction: 0x31d6c9cb202306536c9f977a486bd2f5d2a16d0db9c7558ac132442fe58440f5

Order: 10

Block: 26131525

Amount: 10 ETH

Original transaction: 0x3ef864598198ff4d23f22a35d540e0437ba0ed3af7a77c3d23ae99f59f1bb96e

Order: 11

Block: 26131527

Amount: 10 ETH

Original transaction: 0x4c10b56e2f5c37706fdcbe2b1c7da35de68661306971b32e8ea5ed95e7a02a7a

Order: 12

Block: 26131529

Amount: 10 ETH

Original transaction: 0xa452e803014458dba087c82bf0a7e9432bf014337b59d34483bbbf232fe39d57

Order: 13

Block: 26131531

Amount: 10 ETH

Original transaction: 0xaddc6ea108b17f39beca57487fee55f878546c8f233bdb8c0736b03658e890d4

Order: 14

Block: 26131533

Amount: 10 ETH

Original transaction: 0x61e349fe5ce11d9b3b8f4d9813c3a1f74e6dd898d43f61c0139673540137b3e6

Order: 15

Block: 26131537

Amount: 10 ETH

Original transaction: 0x7167efdb6740e1c1a38983edd33e3a7446d01abe2fcf63874b80aa8f9f3f7ee6

Order: 16

Block: 26131539

Amount: 10 ETH

Original transaction: 0xe82b2082edd720801389e75cf2a6158f494f9e8b3ad3a7671bfc18f9e7c07538

Order: 17

Block: 26131541

Amount: 10 ETH

Original transaction: 0x48303767bec9e216fa06e79dd21f3f3257524dd613c976f3fe60132bcc38af52

Order: 18

Block: 26131543

Amount: 10 ETH

Original transaction: 0x0ac6195011bfea03360778ce3a05f8ed665a6fe2ce6ac10231c2be3dcbb99210

Order: 19

Block: 26131546

Amount: 10 ETH

Original transaction: 0x2cd7eb09abe21d07e36aedc5a93f6c6f99b5ab796b2b5632aa14c6278192396c

Order: 20

Block: 26131548

Amount: 10 ETH

Original transaction: 0xf1db855a987c2fb5e0ea6184ae8f8ed3271cca98c80e627be4839e4b4ac8dcbf

Appendix B. Full addresses and their roles

These 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 recipient

Full address: 0x01eb957e5c7dcddd60f3c875956ccc6fb9bda5fa

Basis: Withdrawal and subsequent transaction records

Role: Intermediate contract

Full address: 0xec997d2ad033277913d6002277353368e8321dcf

Basis: Transaction target and internal payment

Role: Contract created during the transaction

Full address: 0xf09a13072ed939b79bc25b66aa3a836ea6dcc170

Basis: Creation record and WETH transfers

Role: ETH-A collateral adapter

Full address: 0x2f0b23f53734252bda2277357e97e1517d6b042a

Basis: Explorer label and WETH transfer

Role: WETH contract

Full address: 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2

Basis: Token and withdrawal events

Role: Affected keeper identified in the alert

Full address: 0x9c05a05893ada984fc20d0da0c046de5cc0e8273

Basis: Role attributed by Defimon

Role: Tornado Cash router

Full address: 0xd90e2f925da726b50c4ed8d0fb90ad053324f31b

Basis: Explorer label and subsequent transfers

Role: 10 ETH pool in the final transfer

Full address: 0x910cbd523d972eb0a6f4cae4618ad62622b39dbf

Basis: Internal payment in the final transaction

Appendix C. Source records and review scope

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

1. Withdrawal transaction, timestamp, token transfers, and internal ETH transfers
2. Withdrawal transaction event logs
3. Initiating address and subsequent transaction history
4. Final deposit transaction
5. Defimon Alerts report of the alleged cause
6. Official liquidation-system proposal, MIP45
7. Published Flipper source for the general settlement mechanism
8. Official Auction Keeper project