Back to Home

Devcon2Token

Token
Part of The Piper Merriam Collection
0x0a43edfe106d...b5598af9474c
DAO ForkContract #23KSource VerifiedEdit this contract
Deployed September 19, 2016 (9 years ago)Block 2,286,854

A non-fungible attendee token minted at Devcon2 in September 2016, one per named identity, a year before ERC-721 existed.

DAO Fork EraVerified Source

Historical Significance

This is a working non-fungible token from September 2016. ERC-721 was not proposed until a year later, so there was no standard to follow and no word for what this was. The design arrives at the same conclusions anyway: unique ids, an ownerOf lookup, metadata bound to the id, and a supply that counts things rather than measuring an amount.

It is also an early example of a token whose whole purpose is proof of presence. The 231 holders are people who were in a room in Shanghai on a particular week, and the token says so permanently without a central register to consult. That idea now has a name and a category, and this is a clean instance of it predating both.

Context

Deployed on 19 September 2016, the opening day of Devcon2 in Shanghai, and set to stop minting at midnight UTC as the conference closed on the 22nd. The three day window in the code is the conference itself.

The author is Piper Merriam, whose Ethereum Alarm Clock contracts from 2015 and 2016 are documented elsewhere in this archive and who went on to write py-evm. The same habit shows here as in that work: a library, TokenLib, holds the token struct and the event emitters, and the main contract is kept thin.

Key Facts
Deployer
Piper Merriam(0xd3cda9...293601)
Deployment Block
2,286,854
Deployment Date
Sep 19, 2016, 12:49 PM
Code Size
3.6 KB
Gas at Deploy
1,069,790
Transactions by Year
2016249
20222
20231

Description

Devcon2Token issues one token per person rather than a balance per address. A token is a struct holding an identity string and an owner, and its id is sha3 of that identity string, so the name is the key and the same name cannot be minted twice. Minting takes an address and an identity string together, and the contract exposes ownerOf and identityOf, which are the questions you ask of a collectible and not of a currency.

The ERC-20 shape is present but bent to fit. transfer, transferFrom and approve are each declared twice, once taking a uint256 and once a bytes32, because a holder owns exactly one token and the thing being moved is an identity rather than an amount. balanceOf returns the id of the token an address owns rather than a quantity. The result is a non-fungible token wearing the only token interface that existed at the time.

Two values read directly from the deployed contract fix what this was for. Storage slot 1 holds numTokens, and it reads 231, so 231 of these were issued and no more have been since. The contract also carries a hardcoded constant _END_MINTING of 1474502400, which is 22 September 2016 at 00:00 UTC. Minting was shut off by the clock at the close of the conference, which is why the number has not moved in ten years.

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

Opcodes3,719
Unique Opcodes206
Jump Instructions187
Storage Operations78

External Links

Related contracts