Back to Home

TimeLockVault

Wallet
0xed44f3c20814...fab9ed643735
FrontierContract #5,453DecompiledEdit this contract
Deployed December 20, 2015 (10 years ago)Block 719,439

A 20-year time-locked ETH savings vault deployed in December 2015, notable for a critical inverted time-check bug that makes the 50 ETH deposited permanently un

Frontier Era

Historical Significance

TimeLockVault is one of the earliest documented examples of an inverted comparison bug in a deployed Ethereum smart contract. The error demonstrates a class of vulnerability that would later be extensively catalogued in Solidity security literature: logical inversions in access conditions that silently produce the opposite behavior from what was intended. The 50 ETH at stake, worth approximately $110,000 at 2026 prices, remains at permanent risk of being frozen forever. The contract also illustrates the immutability problem: with no upgrade path and no owner override, there is no mechanism to correct the bug once deployed.

Context

In December 2015, Ethereum was five months old and Solidity was at version 0.1.x. Formal auditing practices, security tooling, and established patterns for time-locked contracts did not yet exist. Developers were experimenting directly with on-chain logic without the benefit of later community knowledge around common pitfalls. The concept of a personal time-lock savings vault was a natural early experiment, and several variations appeared in this period. The absence of testnets in common use and the experimental culture of the time meant that contracts with subtle logical errors were regularly deployed to mainnet with real ETH.

Key Facts
Deployment Block
719,439
Deployment Date
Dec 20, 2015, 06:47 AM
Code Size
459.0 B
Gas at Deploy
157,585
Transactions by Year
20151
20171
201810
20232
20252
20267

Description

TimeLockVault is a minimal Solidity contract deployed on December 20, 2015 by address 0x13ae03f074e247b41108b065438b8ee352dba0db. Its stated purpose was to lock ETH deposits for a fixed duration before allowing withdrawal. A single depositor sent 50 ETH into the contract on deployment day, setting a 20-year lock that nominally expires on December 15, 2035.

The contract stores deposits in a mapping of address to a struct containing a balance and an unlock timestamp. Sending ETH to the contract records the deposit and sets the unlock time to the current block timestamp plus a hardcoded duration of 630,720,000 seconds (exactly 20 years). The withdraw function is publicly callable but only sends funds to the caller if that caller has a recorded balance in the mapping.

The contract contains a critical logical error in the withdrawal condition. The check reads unlockTime > block.timestamp, meaning withdrawal is permitted only while the lock is still active, and blocked once the lock expires. The developer almost certainly intended the inverse: block.timestamp > unlockTime, which would allow withdrawal only after the lock period ends. As written, the function behaves in the opposite way intended: depositors can withdraw at any time before 2035, and the funds become permanently frozen after that date.

As of 2026, the 50 ETH remain in the contract. The original depositor has not withdrawn despite the window being open. Numerous third-party addresses attempted withdrawal between 2017 and 2026, all failing because they had no recorded balance in the mapping. The ETH will become permanently unrecoverable after December 2035 when the inverted condition permanently evaluates to false.

Heuristic Analysis

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

Detected Type: Wallet

Bytecode Overview

Opcodes459
Unique Opcodes69
Jump Instructions23
Storage Operations17

External Links