Type: Blockchain forensics case study (portfolio project)
Chain: Ethereum mainnet
Primary vault under analysis: 0xad0360Fa11fCFc85210F5743E7B49727C1f97Ce8
Data source: Public on-chain data via Etherscan
Status: All findings below are descriptive observations of public blockchain data. No claims of illegal activity are made or implied — the patterns described are consistent with automated DEX arbitrage / MEV infrastructure, which is legal and common on Ethereum.
This project traces a cluster of Ethereum wallets that, based on funding relationships and transaction patterns, appear to operate as a single coordinated automated trading system rather than independent, unrelated addresses. The cluster includes:
- A central holding wallet (referred to here as the vault) accumulating ERC-20 token balances
- Two active bot wallets executing frequent swaps through DEX aggregators (1inch, KyberSwap)
- A smart contract deployed by one of the wallets, used for on-chain execution
- A dedicated "treasury" wallet that periodically re-supplies the bots with ETH for gas and trading capital
- A consistent, repeated withdrawal pattern to a single centralized exchange (CEX) deposit address
The goal of this project was to practice and demonstrate the core methodology of address-cluster attribution: verifying funding relationships, confirming contract-deployment claims against primary on-chain records rather than assuming them, and building a defensible, source-linked narrative from raw transaction data.
AltCoinTrader (CEX) Gate.io Hot Wallet Pool MEXC (CEX)
│ │ │
│ 0.3 ETH │ gas funding │ ETH funding
▼ ▼ ▼
Bridge Wallet (0x6f7D...) Launcher (0xddce...) Treasury Hub (0x400c...)
│ ┌──────┴──────┐ │
│ ▼ ▼ │
│ Bot 1 (0x73fB...) Bot 2 (0x337F...) ◄──────┘
│ │ │
│ └──────┬──────┘
│ ▼
│ 1inch / KyberSwap execution
│ │
│ ▼
└──────────────► VAULT (0xad0360Fa...7Ce8)
│
│ repeated USDT transfers
▼
Gate.io deposit address (0xB01ECC...34b19E)
A controller wallet, 0x2fE33378...9776, deployed a smart contract (0x9b9c...6dd) used as part of the execution layer, and independently swept capital toward the vault.
| Address | Role | Verified Relationship |
|---|---|---|
0xad0360Fa...7Ce8 |
Central vault | Recipient of swept profits from bot wallets and the MEV contract |
0xB01ECC...34b19E |
Gate.io deposit address | Recipient of repeated USDT transfers from the vault |
0x400cb6AA...1E19 |
Treasury / refill hub | Funded by MEXC; supplies ETH to 0x337F... |
0x337Fe706...aAc67 |
Bot node (1inch) | Funded by Gate.io hot wallet; recycles ETH through 1inch Router |
0x73fB1d96...D11f |
Bot node (MEV/DEX) | Funded by Gate.io hot wallet; sweeps proceeds to vault |
0x2fE33378...9776 |
Controller (EOA) | Funded by 0xddce...; deployed 0x9b9c... |
0x9b9c...6dd |
Smart contract | Deployed by 0x2fE3...; used for execution/capital sweeps |
0xddce4fd9...81e6 |
Disposable launcher | Funded by Gate.io hot wallet; funded 0x2fE3... |
0x0D0707...b492Fe |
Gate.io hot wallet | Source of gas funding for multiple cluster wallets |
0x6f7D2446...d590 |
Historical bridge wallet | Pass-through from AltCoinTrader to Gate.io (single low-value transfer) |
The goal throughout was to treat every relationship as a claim requiring verification, not an assumption. The general process for each edge in the network graph:
- Identify the claimed relationship (e.g., "Wallet A deployed Contract B," "Wallet A was funded by Wallet C").
- Locate primary evidence for it directly — for funding claims, this means checking the "Funded By" field on the address overview page and following the linked transaction. For deployment claims, this means checking the "Contract Creator" field on the contract's own address page (not inferring it from the deployer's transaction history, which does not reliably surface deployment events under the "Method" column).
- Cross-check timestamps and transaction hashes between both sides of a claimed relationship. A genuine link should show the same transaction hash appearing on both the sender's and receiver's transaction history.
- Distinguish confirmed relationships from working assumptions. Where a claim could not be independently verified (see Limitations, below), it is marked as such rather than presented as fact.
Worked example — verifying a contract-deployment claim:
An earlier draft of this analysis asserted that 0x2fE3... deployed 0x9b9c.... Rather than accept this, the deployment was checked from the contract's own page:
0x9b9c...'s address overview listsContractCreator: 0x2fe3337863d428ad38903c461b825be6b5a79776, linked to transaction0x2b4aa46a....- That same transaction hash appears on
0x2fE3...'s own transaction history as its first-ever transaction, immediately following its initial funding from0xddce....
This double confirmation — same hash, both sides, and consistent with the wallet's very first action after being funded — is what elevates this from "claimed" to "verified" in the directory above. A single-sided claim (e.g., only checking the deployer's history, which doesn't clearly label deployment transactions) would not have met this bar.
Worked example — establishing an activity timeline:
To assess whether the cluster was still active, three independent data sources were checked for the 0x9b9c... contract: the Transactions tab, Internal Transactions tab, and ERC-20 Token Transfers tab. All three showed the same most-recent activity date, which is a stronger basis for concluding the contract went dormant on that date than relying on any single tab alone (some activity types, like internal calls or token movements, do not always appear under the main Transactions view).
Risk-segmented architecture. The vault holds a large ERC-20 balance but a minimal native ETH balance (well under $1). This is a common operational pattern: keeping a vault "gas-poor" means that even if its private key were compromised, an attacker could not move ERC-20 tokens out without a separate ETH top-up, adding friction to unauthorized withdrawal.
Consistent funding origin across bot wallets. The disposable launcher, and both bot nodes, were each initially funded from the same Gate.io hot wallet. Shared funding origin across otherwise-unconnected wallets is one of the more reliable heuristics for clustering addresses under common control, though it is not conclusive on its own (a shared exchange hot wallet reflects many unrelated users' withdrawals, so this observation is meaningfully strengthened only when combined with the other relationships mapped here — shared destination, shared deployer, matching timestamps).
Concentrated off-ramp. All observed profit-taking transactions from the vault route to a single Gate.io deposit address, rather than being distributed across multiple exchanges or addresses. Concentration to a single off-ramp is a pattern often associated with a single operator managing withdrawals manually or via one automated routine, though again this is descriptive rather than conclusive.
Coordinated dormancy. The 0x9b9c... contract's last recorded activity across transactions, internal transactions, and token transfers occurred on the same date, and this coincides with the last recorded activity of its controller wallet, 0x2fE3.... This suggests a deliberate pause or wind-down of at least this part of the cluster, rather than a gradual decline — though whether the broader cluster (bot nodes, treasury hub, vault) paused simultaneously was not fully confirmed in this pass (see Limitations).
This analysis is based entirely on public on-chain data and does not include, and does not claim to include:
- Any off-chain identity verification (KYC, IP logs, account ownership) for the CEX-linked addresses referenced. Statements about exchange deposit addresses describe observed on-chain destination patterns only — they are not claims about who owns or controls any exchange account.
- Full confirmation that all cluster wallets (bot nodes, treasury hub, vault) went dormant simultaneously. Only the deployed contract and its controller wallet were confirmed to share a common last-activity date at the time of writing; extending this to the rest of the cluster would require repeating the same three-tab cross-check on each remaining address.
- Attribution of intent. Terms like "operator" are used descriptively to refer to whoever controls this set of wallets, without asserting who that is or what their purpose was.
- A complete contract-creation history for the controller wallet. Only one deployed contract was identified within the scope of this pass; a full picture would require paginating through the wallet's entire transaction history rather than relying on the default (most-recent) view.
The candidate wallet list that this investigation started from (including the vault analyzed above) was surfaced using a SQL query against on-chain trade and transfer data, rather than manual browsing. The full query is in queries/wallet_discovery.sql.
Approach: filter Ethereum wallets first seen between 2021 and 2024 with high cumulative Uniswap trade volume and a trading-hour pattern concentrated in the 14:00–21:00 UTC window, then exclude any wallet that shows CEX-linked stablecoin transfers or CEX-originated funding traces — surfacing wallets that trade at high volume while remaining, on the surface, un-hosted (avoiding direct CEX interaction).
Known limitations in this query, identified during review:
- The volume metric is mislabeled. The query sums the USD value of every trade a wallet makes. This is gross trade volume, not net profit or loss — a wallet that traded $10M in and $10M back out with no net gain would rank identically to one with $10M in real gains. The query and this write-up now label it
gross_trade_volume_usdrather than "profit" to reflect what it actually measures. A true profit ranking would require reconstructing realized PnL per wallet (matching buys/sells, tracking cost basis), which this query does not attempt. - The "genesis" funding check isn't strictly first-transaction-only. It flags any CEX-originated trace within a wallet's birth-year window, not necessarily its very first inbound transaction. A wallet funded first by a non-CEX source, but touched by an unrelated CEX-linked trace later in the same window, would still be excluded — potentially removing wallets that should have passed the filter.
These are flagged here deliberately: a query like this is meant to generate candidates for manual review, not a final verdict, and being explicit about what it does and doesn't verify is part of using it responsibly.
The methodology in Section 4 was applied manually to keep the verification steps explicit and auditable. Three natural next iterations of this project, in order of expected value:
- Automate the graph walk. Wrap the manual process from Section 4 — check "Funded By," check "Contract Creator," follow the resulting edges — into a script (e.g., Python against the Etherscan API) that takes a seed address and expands the funding/deployment graph automatically. This would turn the case study's methodology into a reusable tool rather than a one-off write-up.
- Confirm cluster-wide dormancy. Section 5 establishes that the deployed contract and its controller wallet share a common last-activity date. Repeating the same three-source cross-check (transactions, internal transactions, token transfers) on the remaining bot and treasury wallets would confirm whether the pause was cluster-wide or limited to this one contract/controller pair.
- Bytecode fingerprinting. Comparing
0x9b9c...'s verified source against public open-source arbitrage/flashloan bot templates could establish whether it is a fork of an existing project, which would add another independent attribution signal beyond funding and deployment relationships.