Community Investigation

Following 200 WETH from a Keeper Withdrawal to 20 ETH Transfers

October 06, 2026

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 show

At 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 moved

Observed value: 200 WETH

What it means: The amount moving through the withdrawal transaction.

Measure: Subsequent transfers

Observed value: 20 × 10 ETH

What it means: A total of 200 ETH sent to the router, excluding gas fees.

Measure: Elapsed time

Observed value: 15 minutes 24 seconds

What 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 auction

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

Figure 1. Six stages from collateral deposit to external withdrawal

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

According 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 movements

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

Figure 2. Verified WETH and ETH movements within the withdrawal transaction

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

Evidence 1. Etherscan withdrawal transaction with WETH and internal ETH transfers

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

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

Figure 3. Twenty transfers of 10 ETH each, with their block numbers

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

Evidence 2. Etherscan transaction list showing repeated 10 ETH deposits

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

Evidence 3. Final deposit and the internal payment to the 10 ETH pool

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

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

6. The money trail and the cause are different questions

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

Figure 4. Directly verified records, externally reported cause, 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.

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 records

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