3 Key Facts
On August 9, 2015, Day 3 of Ethereum mainnet, someone deployed what appears to be the first lottery smart contract in blockchain history. Contract address: 0x7af6af3d4491a161670837d0737bada43ffbb992. The developer’s first attempt self-destructed 42 minutes before this one was deployed. No source code was ever published. The only surviving artifact is 1,475 bytes of runtime bytecode.
Researchers at Ethereum History reverse-engineered the bytecode and decoded 13 functions. The contract ran on an 88-block cycle (~22 minutes) with three phases: BUY (blocks 0-39), REVEAL (blocks 49-67), and PAYOUT (blocks 68+). Randomness was generated by XOR-ing all revealed player secrets together, clever for 2015, but fundamentally exploitable by miners.
The contract had a fatal state machine bug: tickets were allocated during the REVEAL phase rather than the BUY phase. This meant the lottery pool could accumulate ETH indefinitely, but if any player failed to reveal their secret, the payout mechanism could never select a winner. 27 real transactions confirm people actually played it. It is unknown whether anyone ever won.
Three days after Ethereum mainnet launched in August 2015, someone sat down at a command line, there was no graphical interface yet, no MetaMask, no Remix IDE, and deployed what may be the first lottery contract in the history of blockchain. Their first attempt self-destructed 42 minutes later. They tried again. The second contract survived.
No source code was ever published. The developer, whoever they were, left only bytecode: 1,475 bytes of compiled EVM instructions sitting at an address on Ethereum mainnet, where they will remain as long as the chain exists. For nearly a decade the contract sat unanalysed, one of thousands of forgotten Frontier-era experiments.
Then researchers at Ethereum History, a project dedicated to preserving and decoding early Ethereum smart contracts, reverse-engineered the bytecode. What they found is a remarkably sophisticated piece of engineering for Day 3 of a brand-new blockchain, complete with a commit-reveal randomness scheme, an 88-block game cycle, weighted ticket allocation, and a state machine bug that almost certainly prevented anyone from ever being paid.
This article is a technical and historical breakdown of what they found, why it matters for smart contract developers today, and what it tells us about the extraordinary ambition, and peril, of the Ethereum Frontier era.
| Day 3 Ethereum Mainnet | 1,475 Bytes of Bytecode | 27 Real Transactions | 0 Known Winners |
The Ethereum Frontier: What Day 3 Actually Looked Like
To understand what it meant to deploy a smart contract on Day 3 of Ethereum, you need to understand what the Frontier release actually was. The Ethereum Foundation was explicit about it: Frontier was Ethereum “in its barest form.” There was no graphical user interface. All developer actions happened via command line. The gas limit per block had been hardcoded at 5,000 for the first few days, a deliberate throttle to give miners time to set up operations before the network could process meaningful transactions. That throttle had only just lifted.
The Ethereum Foundation’s own pre-launch materials included a warning from Vinay Gupta, published just before the Frontier launch: “Like their counterparts during the American Frontier, these settlers will be presented with vast opportunities, but will also face many dangers.” The canary contracts, emergency kill switches built into the early chain, were a heavily centralised protection mechanism that the core team could trigger if something went badly wrong. This was not a polished platform. It was a live experiment.
Block 56,646 was mined on August 9, 2015. Ethereum itself had launched on July 30, 2015. The person who deployed the lottery contract was writing Solidity, a language that had existed for less than a year, against a runtime that had been live for ten days, on a network with no tooling, no auditors, no documentation beyond research papers and forum posts. And they built something genuinely sophisticated.
How the Contract Worked: The 88-Block Cycle Decoded
The bytecode decoding by Ethereum History revealed a three-phase game cycle built around 88 Ethereum blocks, roughly 22 minutes at the ~15-second block times of 2015. The architecture is a commit-reveal scheme, a cryptographic pattern first described by Michael Blum in 1981 for coin-flipping over telephone lines, applied here to on-chain lottery randomness.
| Phase | Blocks | What Happened |
|---|---|---|
| BUY | Blocks 0-39 | Players sent 0.1 ETH plus a secret hash (their committed random value). More ETH meant more tickets and higher win probability. The contract accepted entries and held the ETH. No ticket allocation happened yet. |
| BUFFER | Blocks 40-48 | A 9-block buffer period. No new entries accepted. Players prepared to reveal their secrets. |
| REVEAL | Blocks 49-67 | Players revealed their original secret values. The contract verified each reveal matched the hash committed in the BUY phase. Ticket allocation happened here, not in the BUY phase. The XOR sum of all revealed secrets accumulated as the randomness seed. |
| PAYOUT | Blocks 68+ | The final XOR sum of all revealed secrets selected the winner. The ETH pool was transferred to the winning address. But this phase could only execute if there were players in the revealed ticket pool. If nobody revealed, no payout was possible. |
How the Day 3 Ethereum lottery worked
An 88-block cycle (~22 minutes). Hover over the phases to explore.
27 real transactions confirmed. No known winner. ETH may be permanently locked.
The commit-reveal architecture is genuinely clever. The idea is that each player commits to a secret value by submitting its hash, then reveals the actual value later. By XOR-ing all revealed secrets together, the final random number is a function of every player’s input, no single participant could control it without knowing everyone else’s secret in advance. This is the same conceptual framework that underpins RANDAO, Ethereum’s post-merge randomness beacon, more than seven years later.
The Bug: A State Machine Error That Bricked the Payout
Here is where the tragedy lies. The contract had a logic error in the order of operations, a state machine bug, that almost certainly prevented it from ever paying out a winner. The error is subtle, the kind that slips through without unit tests or a second pair of eyes, and it sits at the intersection of commit-reveal design and ticket accounting.
| Intended Logic | Actual Logic (the bug) |
|---|---|
| buy() sends ETH + hash allocate_tickets() runs during BUY reveal() proves the secret pick_winner() selects from ticket pool | buy() sends ETH + hash reveal() proves the secret allocate_tickets() runs during REVEAL pick_winner() can only run if ticket pool exists |
The consequence: a player who sent 0.1 ETH in the BUY phase but failed to call reveal() in the REVEAL phase never received a ticket. Their ETH stayed in the contract pool. But from the contract’s perspective, they were not a participant in the current round’s draw. If all players failed to reveal, or if the gas cost of revealing was too high, or if players simply forgot, the ticket pool for that round would be empty. An empty ticket pool meant pick_winner() had nothing to select from. The payout function was effectively bricked.
This specific failure mode, ETH locked because a multi-phase commit-reveal scheme breaks when participants drop out at the reveal step, is well-documented in modern smart contract security literature. OWASP’s Smart Contract Top 10 lists it as a category. It affects auction contracts, governance systems, and any application where reveal is a precondition for payout. The 2015 lottery contract may be the earliest known on-chain example of it.
The XOR Randomness: Clever in 2015, Exploitable in Practice
The randomness mechanism itself, XOR-ing all revealed secrets to generate the winning number, was a reasonable approach for 2015 and reflects genuine cryptographic thinking. The commit-reveal structure means no single player can see other players’ secrets before committing their own. Once committed, they cannot change their value. The XOR of all inputs produces a number that none of them could have predetermined.
But the approach has two known weaknesses that were understood even in 2015, and both apply here.
The first is the last-revealer problem. The final player to reveal can compute the XOR of all other revealed secrets before submitting their own. This lets them calculate what the winning number will be for any value they reveal. If they do not like the outcome, they can simply not reveal, sacrificing their entry but denying the payout to everyone else. The academic literature on this dates to Michael Blum’s 1981 work on coin-flipping; it is a structural property of XOR-based multi-party randomness.
The second is miner manipulation. In 2015, Ethereum ran on proof-of-work. Miners could, within limits, choose which transactions to include and in what order. If a mining pool’s expected profit from a lottery exceeded the block reward (5 ETH on Frontier), the miner had a financial incentive to manipulate which reveals landed in which block, or to withhold a block entirely if the XOR result was unfavourable to a wallet they controlled. As the Ethereum randomness literature notes, any gamble with a prize exceeding approximately twice the block reward creates a meaningful miner incentive to cheat.
With 27 transactions on a 0.1 ETH entry fee, the prize pool in this contract was never large enough to create a serious miner incentive. But the architecture would have become exploitable the moment the pool grew.
The randomness problem: 2015 vs today
Why XOR of player secrets is exploitable, and how Chainlink VRF fixes it.
How We Would Build This in 2026: The Modern Solution
The same lottery the 2015 developer was attempting to build can be built correctly today. The intervening decade of smart contract security research, failed experiments, and tool development has produced well-understood solutions to each of the problems this contract encountered.
| 2015 Problem | 2015 Approach | 2026 Solution |
|---|---|---|
| Ticket allocation timing | Tickets allocated in REVEAL phase, meant unrevealed players could lock up ETH with no recourse. | Allocate tickets at BUY time. Use a separate mapping to track which tickets are “valid” (i.e., backed by a successful reveal). Implement a refund mechanism for players who bought but failed to reveal. |
| XOR randomness | XOR of revealed player secrets, exploitable by last revealer and miners. | Chainlink VRF (Verifiable Random Function): cryptographically provable off-chain randomness, impossible for miners or players to manipulate. First became available in 2020. Standard for all production lottery contracts today. |
| No-reveal griefing | Last player could abort payout by not revealing, at cost of forfeiting their own entry. | Chainlink VRF eliminates the need for player-sourced randomness entirely. Alternatively: penalise non-revealers by forfeiting their ETH to the pool, creating a financial incentive to reveal regardless of outcome. |
| Locked ETH with no exit | No withdrawal mechanism for failed rounds. ETH could be locked indefinitely. | Implement a round-failure state with explicit refund paths. Use OpenZeppelin’s PullPayment pattern to allow individual withdrawals rather than push-based payouts. |
| No source code | Bytecode only, no way for users to verify what they were interacting with. | Verify source code on Etherscan. Use a formal audit before mainnet deployment. Publish the audit report alongside the contract. Consider formal verification for high-value lottery logic. |
Why This Discovery Matters Beyond Historical Curiosity
The same vulnerabilities present in this 2015 lottery contract have collectively cost the DeFi ecosystem hundreds of millions of dollars in the decade since. The state machine error, where a multi-phase protocol breaks if participants drop out mid-sequence, appears in a slightly different form in every commit-reveal governance system, every staged auction, and every multi-round game contract. The 2022 Akutars NFT contract locked 34 ETH permanently because of a related pattern. The commit-reveal griefing vector has been used in governance attacks.
The XOR randomness approach, meanwhile, is still being used incorrectly. OWASP’s Smart Contract Top 10 lists insecure randomness as a recurring critical vulnerability. In Q1 2024, smart contract exploits including randomness manipulation accounted for nearly $45 million in losses across 16 incidents, per Hacken’s security analysis. Chainlink VRF has been available since 2020 and is the standard solution, yet developers continue to use block hashes, timestamps, and player-sourced entropy as substitutes.
The 2015 lottery contract is, in a sense, the origin document of this entire vulnerability class. The developer was working in good faith, with the best tools available, against a problem that cryptographers had been writing about since 1981. They got 80% of the design right. The 20% that was wrong happened to be fatal. That ratio, sophisticated architecture undone by a single logic ordering error, is the defining characteristic of smart contract security failures to this day.
For readers interested in how DeFi security failures play out in practice with real money at stake, see our coverage of the $50M AAVE swap loss in March 2026 and the broader analysis in our cyber insurance guide for crypto firms. The lessons from 2015 are not historical footnotes. They are current events in a different costume.
Frequently Asked Questions
📰 Related Coverage on CryptoNewsBytes
Sources and Further Reading
Ethereum History, Frontier Era Smart Contract Archive · Ethereum Foundation, Frontier Launch Announcement (July 30, 2015) · ConsenSys, A Short History of Ethereum · OWASP Smart Contract Top 10, Insecure Randomness · Solidity Developer, Randomness and the Blockchain · Gitcoin, Commit Reveal Scheme on Ethereum · Hacken, Top 10 Smart Contract Vulnerabilities 2025 · Chainlink, How to Build a Blockchain Lottery with VRF
Disclaimer: This article is based on bytecode analysis and historical chain data published by Ethereum History (ethereumhistory.com). Technical details of the contract’s architecture are derived from their reverse-engineering work on contract 0x7af6af3d4491a161670837d0737bada43ffbb992. Source code for this contract has never been published. Claims marked as decoded or inferred are based on bytecode analysis and are clearly labeled as such. This article is for educational and historical purposes only.
