Bytecode verified via sibling
This contract shares identical runtime bytecode with UserWallet (0x5aa66081...) which has been verified through compiler archaeology.
Exchange deposit wallet with ETH and ERC20 sweep functions. One of the most widely deployed bytecodes on Ethereum.
Historical Significance
With 709,039 sibling contracts sharing identical runtime bytecode, this is the single most-deployed bytecode pattern in Ethereum history. Deployed at the peak of the 2017-2018 ICO bull run, this fleet of deposit wallets represents the exchange infrastructure that enabled millions of crypto trades. The deployer's nonce of 121,422 confirms the scale of operations — over 120,000 prior transactions from a single hot wallet account. Every major centralized exchange of the era used patterns like this to generate unique deposit addresses for each user at scale.
Context
Exchange deposit wallet contracts solved a specific UX problem: giving each user a unique Ethereum address for deposits while keeping the exchange's treasury in a separate hot/cold wallet system. This contract's approach — deploying a fresh contract per user, with the exchange hot wallet as owner — was a common 2017-2018 pattern. The fallback function accepted deposits; the sweep functions (collect for ETH, collectToken for ERC20s) drained them to the exchange treasury. The destroy function allowed reclaiming gas by selfdestructing wallets from inactive users. The deployer address 0x17bc58b788808dab201a9a90817ff3c168bf3d61 remains unidentified publicly but its 709,039 deployments place it among the most prolific contract deployers in Ethereum history.
Key Facts
Description
UserWallet is a minimal 4-function exchange deposit wallet deployed at peak ICO mania in January 2018. The deployer — an exchange hot wallet with nonce 121,422 — spawned 709,039 identical contracts, one per user. Each contract's owner variable is set to msg.sender at deploy time (the exchange hot wallet), enabling the exchange to sweep both ETH and ERC20 token balances on demand.
The four functions: (1) fallback accepts incoming ETH deposits; (2) collect() sweeps the ETH balance to owner; (3) collectToken(address) queries an ERC20 token's balance for this contract, then transfers it to owner; (4) destroy() calls selfdestruct, sending remaining ETH to owner.
Source reconstruction required identifying: a Solidity modifier pattern (not inline require) for access control; old-style if/throw instead of require(); and Token t = Token(token) local variable caching in collectToken, which causes the compiler to maintain an extra storage slot on the EVM stack. These subtle source-level details produce the specific DUP2/SWAP1/POP opcode sequences that distinguish this bytecode from superficially similar reconstructions.
Source Verified
Near-exact match: 669/670 runtime bytes identical. Compiler: soljson v0.4.12+commit.194ff033 optimizer ON. Source reconstructed from bytecode: 4 functions (collectToken, destroy, owner, collect) + payable fallback. All 61 v0.4.11-v0.4.12 nightlies tested. 1-byte gap from unknown source detail.
Heuristic Analysis
The following characteristics were detected through bytecode analysis and may not be accurate.
Byzantium Era
First Metropolis hard fork. Added zk-SNARK precompiles, REVERT opcode, and staticcall.
Bytecode Overview
Verified Source Available
Source verified through compiler archaeology (near-exact bytecode match).
View Verification ProofShow source code (Solidity)
pragma solidity ^0.4.11;
contract ERC20 {
function balanceOf(address _owner) constant returns (uint256);
function transfer(address _to, uint256 _value) returns (bool);
}
contract Wallet {
address public owner;
modifier onlyOwner {
require(msg.sender == owner);
_;
}
function Wallet() {
owner = msg.sender;
}
function() payable {}
function collectToken(address _token) onlyOwner {
uint256 bal = ERC20(_token).balanceOf(this);
ERC20(_token).transfer(owner, bal);
}
function destroy() onlyOwner {
selfdestruct(owner);
}
function collect() onlyOwner {
owner.transfer(this.balance);
}
}