Back to Home

UserWallet

Wallet
0x1fb8ba299039...c1fff9610fa3
ByzantiumSource VerifiedEdit this contract
Deployed June 12, 2018 (8 years ago)Block 5,775,088

Per-user deposit wallet from June 2018 whose sweep(token, to, amount) can move ether or any token to a caller-chosen address, if the controller lists the caller as a sweeper.

Byzantium EraVerified Source

Historical Significance

Shows how the Bittrex deposit wallet design spread and mutated during 2018. The shape survives intact, with a thin per-user wallet, a central controller and sweep plus tokenFallback as the interface, but the operator moved the choice of destination from the controller to each sweep call. That makes every approved sweeper key able to send any customer deposit anywhere, which is a real change in who has to be trusted, made with only a few lines of code.

Key Facts
Deployment Block
5,775,088
Deployment Date
Jun 12, 2018, 09:01 AM
Code Size
713.0 B
Gas at Deploy
269,520
Transactions by Year
20184

Description

A deposit wallet in the style of the NewAlchemy UserWallet used by Bittrex, rewritten around a different trust model. The wallet stores only the address of a controller. The controller keeps a list of approved sweepers, managed through addSweeper, and the wallet asks it isSweeper(msg.sender) before doing anything.

sweep(address token, address to, uint256 amount) is the only real function. If the token address is zero it checks that the wallet holds at least the requested amount of ether and sends it to the given address; otherwise it checks the token balance with balanceOf and calls transfer. A short balance returns false instead of reverting, and so does a call from anyone who is not a sweeper. Unlike the NewAlchemy design, the destination is an argument chosen by the sweeper for each call rather than a single address held by the controller. The wallet also accepts ether through a payable fallback and implements an empty tokenFallback so ERC223 token transfers do not bounce.

The first copy was deployed in June 2018 as a test, and the operator later ran production deployments through a factory account. The source was compiled with solc 0.4.21 with the optimizer on at 200 runs. The runtime code matches the deployed bytecode; only the trailing swarm metadata hash differs, because the EthereumHistory attribution comment changes the source text. Sourcify records this as a partial match and Etherscan shows it as verified.

Source Verified

Solidityeh_crack_source_verified
Compiler: v0.4.21

Historian Categories

Wallet
Heuristic Analysis

The following characteristics were detected through bytecode analysis and may not be accurate.

Detected Type: Wallet

Bytecode Overview

Opcodes713
Unique Opcodes117
Jump Instructions39
Storage Operations4

External Links

Related contracts