Ethereum Etheria v1.1

Information

Created: 29 October 2015
Creator: Cyrus Adkisson
Blockchain: Ethereum

Description

The Smart Move and the Dumb One

A better way to change hands

On October 29, 2015, Cyrus Adkisson published a short blog post announcing Etheria 1.1. It was a developer's update rather than a grand unveiling: a list of changes, practical improvements and an attempt to make the system easier to use.

The central change was simple. Adkisson removed the internal offer-and-accept marketplace and replaced it with a function called setOwner. A tile's owner could now transfer it directly to another address.

That might sound like a minor programming detail. It was a useful change in the way Etheria was designed.

The original contracts had tried to manage both the world and the market. The world knew about offers, payments, sellers and buyers. This made the code more complicated and created opportunities for problems such as the stuck-ETH bug. With v1.1, Adkisson separated those responsibilities. Etheria would keep track of its land and its owners; other contracts could handle buying and selling.

The distinction is familiar today. A digital asset does not need to know the details of every marketplace where it might be traded. One piece of software can manage the asset while another handles the transaction. In 2015, however, the infrastructure for this arrangement was still being invented.

The rest of Adkisson's update reads like the notes of someone steadily improving a workshop. He added a way to return stray payments, a method for withdrawing funds sent to the contract by mistake, and clearer text for debugging. He also made it possible to change a block's colour without moving it, which had previously required two transactions.

The building materials were revised as well. The number of block types fell from 32 to 18, their orientations were aligned with the edges of the hexagonal tiles, and farming allowed players to choose a type rather than receiving random blocks. Each farming session yielded ten blocks of the selected type.

The building system remained expensive to calculate, though, and Adkisson admitted that he had not solved its underlying inefficiencies. That would have to wait.

One promise in the update was more consequential than any of these improvements. Whenever he deployed a new overlapping version of Etheria, existing ownership would carry over without dilution. If a future version contained four times as much land, existing holders would receive a proportionate increase in their holdings. He did not intend to create additional unowned land in a way that would undermine the scarcity of what people already possessed.

It was a commitment to continuity. A new version would not simply erase the old one or make its owners start again.

Unfortunately, the attempt to improve Etheria also left a problem in the code that would persist for years.

The difference between two callers

The error concerned two pieces of Solidity terminology: tx.origin and msg.sender.

Both refer to addresses involved in a transaction, but they are not interchangeable. tx.origin identifies the original wallet that initiated the transaction. msg.sender identifies the immediate caller of the current function. When a transaction passes through a smart contract, these can be different addresses.

Imagine a marketplace selling a piece of Etheria land. A buyer sends a transaction to the marketplace, which then calls Etheria's contract to transfer the tile. The buyer's wallet initiated the transaction, but the marketplace contract is the immediate caller.

A contract that checks the wrong address can therefore behave in ways its author did not intend.

While attempting to address v1.0's stuck-ETH problem, Adkisson used tx.origin to verify tile ownership in v1.1. The change introduced a limitation that was not immediately obvious: tiles could be owned by ordinary wallets, but not safely managed through the smart contracts that modern Ethereum applications rely on.

This was not an academic distinction. A marketplace might need to hold an asset in escrow before transferring it to a buyer. A multisignature wallet might use a contract to require approval from several people before moving funds. An NFT wrapper also needs to hold the original asset in its own contract.

The v1.1 ownership check obstructed these uses. Send an unwrapped tile to an incompatible contract address, and the tile could become permanently inaccessible. The blockchain would still record it, but the rules of the contract would prevent its owner from using it as intended.

The irony is that Adkisson had just made a good architectural decision by separating ownership from the marketplace. He had made the world easier to build around, then inadvertently restricted which kinds of software could hold its land.

His own later FAQ describes the choice bluntly: setOwner was smart; using tx.origin was dumb.

There is no need to pretend this was an easy mistake to avoid. In 2015, Ethereum was young, Solidity was at version 0.1.6, and developers were learning how smart contracts behaved in practice. The conventions familiar to modern developers had not yet settled into place. The error only became especially troublesome as the ecosystem grew around the contract.

A world with its own rules

The mistake explains why Etheria is not one simple collection of interchangeable plots. Each version is a separate contract, preserving its own history and limitations.

In v0.9 and v1.0, the internal offer system was cumbersome, but their tiles could be held by smart contracts. Those versions could eventually be wrapped into ERC-721 tokens. In v1.1, the simpler transfer mechanism came with a compatibility problem that made wrapping impractical.

The result is a split in the modern Etheria ecosystem. The first two versions can be traded through OpenSea after wrapping. The later versions require Etheria's own exchange, built to work with their original contracts. The v1.1 tiles are not simply waiting for someone to write a clever marketplace. The limitation sits deeper, in the way ownership is checked.

As of Etheria's September 2026 FAQ, Adkisson was looking to EIP-8141, associated with the planned Hegota hard fork, as a possible way to resolve the long-standing compatibility problem. This remains a prospective solution rather than a completed fix.

For now, v1.1 remains an object lesson in the difference between a design that looks elegant on paper and one that continues to work as its surroundings change.

Its setOwner function anticipated a useful separation of responsibilities. Its ownership check, meanwhile, tied the contract to assumptions about Ethereum that would become increasingly inconvenient.

The island remained. Its land remained scarce. But the ways in which its owners could manage that land were shaped by a few lines of code written when the future of smart contracts was still uncertain.