Onchain Atlas

King of the Ether Throne

An early Ethereum 'king of the hill' game whose silent send() payment failure became the canonical unchecked-external-call lesson in smart-contract security.

▶ Run interactive simulation animated mechanism with editable parameters

Statusabandoned
Launched2016-02-06
ChainsEthereum
Mechanismsescalating claim price (king-of-the-hill), push payments via send(), commission to creator (wizard), time-based reset (14-day 'curse'), permissionless kingdom forking (v1.0)
Official sitehttps://www.kingoftheether.com/
Project X@Unknown (unverified)
FoundersKieran Elby

How it works onchain

Diagram of how King of the Ether Throne's mechanism worksOpen full-size diagram
Original diagram derived from this entry’s researched mechanism description.

Summary

King of the Ether Throne (KotET) was one of the earliest playable Ethereum DApps: a "king of the hill" money game written by UK developer Kieran Elby as his first Solidity project and deployed on 6 February 2016 (block 963186). Anyone could pay an escalating "claim price" to be crowned King or Queen of the Ether Throne; most of the payment was forwarded to the previous monarch, so each ruler who was dethroned quickly turned a profit, while the last monarch of a round — never dethroned — received no compensation for their own claim payment. Within a day of launch the contract malfunctioned: compensation payments sent with Solidity's send() silently failed when the recipient was a contract wallet, leaving 98.5 ETH stuck. Elby paused the game, manually refunded affected players, and published a detailed public post-mortem that became foundational reading in Ethereum security. A rewritten v1.0 relaunched on 31 July 2016 with checked payments and permissionless "kingdom" forking. The game itself faded and is no longer maintained, but its failure mode — the unchecked external call and the 2300-gas stipend — is cited in virtually every Solidity security curriculum, and the post-mortem's advice helped establish the "favor pull over push payments" pattern.

Design (Mechanism)

The core loop is a pyramid-flavored succession game:

  • Claiming the throne. A player sends the current claim price to the contract and becomes the named monarch, with their chosen title recorded on-chain. In the documented v1.0 rules, the starting claim price is 0.5 ETH and rises 33% with each successive claim, capped at 100,000 ETH.
  • Compensation. The new claim payment, minus commission, is immediately pushed to the previous monarch. Because the price escalates, any monarch who is dethroned receives more than they paid — the game is profitable for everyone except the final monarch of a round.
  • Commission. A cut goes to the contract creator; in v1.0 it is 2%, split equally between the "top wizard" (Elby, creator of the original throne contract) and the "sub-wizard" (creator of a forked kingdom).
  • The curse. If no one usurps a monarch within 14 days, an "ancient curse" strikes: the reign ends with no compensation and the claim price resets to 0.5 ETH, restarting the game rather than letting it dead-end at unaffordable prices.
  • Kingdoms (v1.0). The relaunched version added a factory so anyone could deploy their own throne ("kingdom") with the same rules — an early example of permissionless forking as a feature; third parties such as Bok Consulting launched "KotET Classic" this way.

The fatal flaw in the original v0.4.0 contract was the payment path: currentMonarch.etherAddress.send(compensation) forwards only a 2300-gas stipend and returns false on failure rather than reverting. When the previous monarch was a contract wallet (e.g., a Mist multi-owner wallet) whose fallback function needed more than 2300 gas, the send failed, the ETH stayed in the KotET contract, and — because the return value was never checked — the game state updated as if payment had succeeded.

Outcome

KotET launched 6 February 2016 and entered its "Turbulent Age" almost immediately: on 7 February Elby noticed an unexpectedly high contract balance, warned players on Reddit, disabled the website's claim button, and by 8 February had confirmed failed compensation payments. Three payments totaling 98.5 ETH had silently failed (42.273 ETH compensation and refunds of 7.77 ETH and 48 ETH, all to contract-wallet addresses). On 19 February Elby manually refunded all three from his own account, and on 20–21 February he published the post-mortem. The rebuilt v1.0 (deployed at 0x2464d1d97f8d0180cfad67bdb19bc30cca69dda0) went live 31 July 2016 with checked sends, a payout-claim fallback, and kingdom forking. The game saw modest continued play and forks but never became a large phenomenon; the project is explicitly no longer maintained, though the contracts remain live. Its real legacy is educational: KotET appears as the archetypal "unchecked external call" case in the Atzei–Bartoletti–Cimoli attack survey, Trail of Bits' not-so-smart-contracts repository, ConsenSys/Solidity best-practice guides, and countless auditor checklists — pre-dating and foreshadowing The DAO's much larger call-handling exploit four months later.

Why it worked

  • Simple, legible greed loop. "Pay to be king, profit when dethroned" needed no whitepaper; escalating prices plus on-chain immortalization of your royal name made participation fun and self-explanatory in an era with almost no DApps.
  • The curse solved the dead-end problem. The 14-day reset kept the game replayable instead of stalling forever at an unaffordable claim price — an early, elegant use of time-based state resets.
  • Exemplary incident response. Pausing the front-end, refunding users out of pocket, and publishing a frank, technically detailed post-mortem converted a failure into lasting reputational and ecosystem value.

Where the design broke

  • Unchecked push payments. The contract pushed ETH with send() and ignored the return value, assuming recipients were externally owned accounts. Contract wallets broke that assumption and 98.5 ETH silently misrouted — the defining bug.
  • Silent-failure gas model. By the post-mortem's own account, the payment path was built without a full accounting of the EVM's gas-stipend and fallback-function semantics — send()'s 2300-gas limit and non-reverting failure mode were not covered in the design.
  • Untested counterparty class. The payment path was validated against externally-owned-account recipients; contract-wallet recipients — the exact class whose fallback functions needed more than 2300 gas — were not represented in that validation, and the unchecked return value meant the gap surfaced as silent fund loss rather than an error.
  • Zero-sum novelty. Beyond the bug, the game is a greater-fool mechanism; once novelty wore off and prices rose, new claimants dried up and the last monarch of each round ate the loss, limiting durable engagement.

Lessons

  • Check every external call — or don't push at all. send() failures do not revert; unchecked return values corrupt state. The now-standard remedy KotET popularized is the pull-payment (withdrawal) pattern: record balances owed and let recipients claim them.
  • Never assume counterparties are EOAs. Any address can be a contract with arbitrary fallback behavior and gas needs; the 2300-gas stipend makes "obvious" payment code quite likely to fail against contract wallets.
  • Public post-mortems compound ecosystem value. A 98.5 ETH bug, honestly documented, arguably prevented far larger losses across the industry and is still cited a decade later — transparency after failure is a mechanism-design contribution in itself.
  • Design an exit for escalating-price games. The 14-day curse/reset shows how time decay can keep an otherwise dead-ending pyramid game cyclical and playable.

Redesign (EDITORIAL — hypothesis, not fact)

This section is editorial speculation, not historical fact. A modern KotET would make the withdrawal pattern native: dethronement credits the prior monarch's internal balance, claimable at any time via withdraw(), eliminating the entire class of push-payment failures (and, today, using call with full gas plus reentrancy guards, or ERC-4337-aware payouts). The economics could be restructured to convert the greater-fool tail risk into an explicit prize mechanic: divert part of each claim into a pot paid to the monarch who survives the curse, so the final claimant of a round receives a payout instead of none (as FOMO3D later did with timer mechanics). Kingdom forking could carry protocol fees on-chain via a registry with revenue splits, anticipating factory/franchise patterns. Finally, an invariant check — contract balance equals owed balances plus commission — asserted on every claim would have caught the Turbulent Age bug in block one.

Sources

  1. King of the Ether Throne — Post-Mortem Investigation (Feb 2016) — primary (retrospective)
  2. King of the Ether — official throne page (rules, contract address) — primary (docs)
  3. kieranelby/KingOfTheEtherThrone (source code, v0.4.0 and v1.0) — primary (contract)
  4. crytic/not-so-smart-contracts — unchecked external call (KotET source) (analysis)
  5. Atzei, Bartoletti, Cimoli — A survey of attacks on Ethereum smart contracts (IACR eprint 2016/1007) (analysis)
  6. King of the Ether Throne Classic — Bok Consulting (analysis)

Related experiments

Last verified: 2026-07-27 · Spot an error? Suggest a correction