Back to Home

HackerGold(HKG)

Token
0x14f37b574242...289a5035c506
Spurious DragonContract #28KSource VerifiedEdit this contract
Deployed January 9, 2017 (9 years ago)Block 2,963,564

Hacker Gold (HKG), the token of ether.camp's 2017 virtual accelerator, redeployed with every balance restored after a one character bug in its predecessor.

Spurious Dragon EraVerified Source

Historical Significance

This is one of the earliest well documented token bugs on Ethereum, and it became a standard teaching example. The lesson it taught was not about clever attacks: the code was readable, the logic was correct as written, and the flaw was a typographical error that compiles silently and does not look wrong. It is a large part of why later token work leaned on audited base implementations rather than hand written balance arithmetic.

The response is as instructive as the bug. The supply was recomputed off chain, hardcoded into a new constructor, and the token continued at a new address with holders made whole. There was no proxy to upgrade and no admin switch to flip, so a redeployment carrying a snapshot in its constructor was the only repair available. That constraint shaped how the whole ecosystem thought about upgradeability afterwards.

Context

Deployed on 9 January 2017 at block 2,963,564, during a run of HackerGold deployments that week as the problem was found and worked through. An almost identical contract had gone out the day before at 0xa62bdee2f277c2e2c0f46cba96879b263796ee1c, already carrying the same recovery balance.

The one difference between the two is visible on chain and is the reason this address is the one that stuck. The earlier contract kept its supply in a plain state variable with no ERC-20 getter, so calling totalSupply() on it reverts with an invalid jump to this day, and only its own getTotalSupply() answers. This version renames the variable and adds the standard totalSupply() function, which is what exchanges and wallets expect to find. Byte for byte identical code was deployed once more on 18 January.

A separate contract carrying the original uncorrected source was deployed by an unrelated address on 9 January and survives at 0xd7ac7486f7e756df65422752b76060ae0808f6a2, where the flawed transferFrom can still be read.

Token Information
Token Name
HackerGold
Symbol
HKG
Decimals
3
Key Facts
Deployment Block
2,963,564
Deployment Date
Jan 9, 2017, 03:02 PM
Code Size
2.3 KB
Gas at Deploy
1,091,296
Transactions by Year
20174,221
201897
201916
20202
20211

Description

HKG funded ether.camp's virtual accelerator, a hackathon where holders backed teams with tokens rather than votes. It sold at three tiers, 200 then 150 then 100 HKG per ether, and carries three decimals rather than the usual eighteen.

What makes this particular deployment worth reading is its constructor. It does not start empty. It assigns a supply of 16,110,893,000 units and credits the whole of it to a single recovery address, alongside a recorded total of 85,362 ether raised. The comment in the source calls it exactly that, a recovery balance. This contract was not selling anything new: it existed to carry the state of a broken predecessor across to working code.

Read on chain today, totalSupply() still returns 16,110,893,000, unchanged from the constant compiled into the constructor, and getPrice() returns zero because the sale is long closed. The recovery address has since paid out almost all of its holding and retains 43,813,419 units.

The defect being recovered from was a single character. In the predecessor's transferFrom the recipient's balance was updated with '=+' rather than '+=', which Solidity reads as assignment of a positive number rather than addition. The recipient's balance was therefore overwritten with the transferred amount instead of increased by it, so anyone could approve themselves a token and use transferFrom to reset another account's balance to a number of their choosing. No ether was ever at risk, because the token contract held none.

Heuristic Analysis

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

Detected Type: Token
Has ERC-20-like patterns

Bytecode Overview

Opcodes2,361
Unique Opcodes186
Jump Instructions152
Storage Operations71

External Links

Related contracts