How the token standard was written

The Frontier Guide is the official Ethereum user documentation for the first live network. It is a GitBook, and it holds almost no prose of its own: chapters are one-line transclusions of pages in the go-ethereum wiki. contract_coin.md in full, as created:

# Coin contract

One hundred and eighteen seconds later Gerring created the wiki page it would point at, and rewrote the chapter to pull it in:

{% include "git+https://github.com/ethereum/go-ethereum.wiki.git/Coin-Contract-Tutorial.md" %}

That transclusion is why the guide's own repository contains no token vocabulary at any point in its history: 216 commits between 2015-04-30 and 2015-07-28, and a search of every revision for sendCoin, balanceOf, coinBalance or the word “token” returns nothing. The content lives in the wiki.

The contract the official guide shipped

contract token { 
    mapping (address => uint) balances;

    // Initializes contract with 10 000 tokens to the creator of the contract
    function token() {
        balances[msg.sender] = 10000;
    }
    // Very simple trade function
    function sendToken(address receiver, uint amount) returns(bool sufficient) {
        if (balances[msg.sender] < amount) return false;
        balances[msg.sender] -= amount;
        balances[receiver] += amount;
        return true;
    }

    // Check balances of any account
    function getBalance(address account) returns(uint balance){
        return balances[account];
    }
}

This is a third vocabulary, and it belongs to neither of the others. Not the wiki's sendCoin and coinBalanceOf, which do not exist yet. Not the standard's transfer and balanceOf, which are five months away. The official guide for the first live Ethereum network taught sendToken and getBalance, and it did so before there was any standardization effort to disagree with.

There is no event of any kind. Nothing a client could watch.

The selectors, and where they can be seen

sendToken(address,uint256)   0x412664ae
getBalance(address)          0xf8b2cb4f

Both appear in the compiled bytecode the tutorial pastes underneath the source, in its dispatcher: …90048063412664ae1461003a578063f8b2cb4f1461005257005b…. The published bytecode and the published source agree.

Sources

• Guide chapterfrontier-guide a465ac5 · Create contract_coin.md
• Transclusionfrontier-guide 8c91460 · Update contract_coin.md
• Tutorial pagego-ethereum wiki cc23634 · Created Coin Contract Tutorial
• Wiki clonegit clone https://github.com/ethereum/go-ethereum.wiki.git · cc236342996894a61a884303a3e9869bed2fb7a7
• Repo created2015-04-30T21:04:22Z, Taylor Gerring

The framing sentence of the page states the whole design intent, and it is worth reading before anything else in this trail:

Although Ethereum allows developers to create absolutely any kind of application without restriction to specific feature types, and prides itself on its "lack of features", there is nevertheless a need to standardize certain very common use cases in order to allow users and applications to more easily interact with each other.Standardized_Contract_APIs, revision 1, verbatim

The currency API as created

balance(address addr) returns (uint256 bal)
send(address to, uint256 value) returns (bool success)
send(address to, uint256 value, address from) returns (bool success)

approve(address addr, bool status)
approved(address addr) returns (bool status)
approve_once(address addr, bool status, uint256 maxval)

Two structures already present here survive all the way to the finished standard. The first is the pull model: a third-party spender is authorised in advance, then moves funds on the owner's behalf. The second is the paragraph justifying it, which travels almost unedited into the issue five months later:

The third command is used for a "direct debit" workflow, allowing contracts to charge fees in sub-currencies; the second send command should fail unless the from account has deliberately authorized the sender of the message via some mechanism; we propose these standardized APIs for approvalStandardized_Contract_APIs, revision 1, verbatim

What is not here: no events at all, no totalSupply, no read of another account's balance, and an approval that is a boolean switch rather than an amount.

Sources

• Wiki revision748c9b0a7f459ed5754420b6368bdd536bc4bdc4
• MessageCreated Standardized_Contract_APIs (markdown)
• Raw artifactraw/wiki-revisions/01-2015-06-17_18-06-56-748c9b0.md

This is the page reached at ethereum.org/token, and it is the third piece of official documentation in this trail, alongside the Frontier Guide and the wallet's own ABI. It is the one Van de Sande points the issue thread to eight months later, when he writes that “the latest proposed standard is kept updated at ethereum.org/token”.

contract token { 
    mapping (address => uint) public coinBalanceOf;
    event CoinTransfer(address sender, address receiver, uint amount);

    /* Initializes contract with initial supply tokens to the creator of the contract */
    function token(uint supply) {
        coinBalanceOf[msg.sender] = (supply || 10000);
    }

    /* Very simple trade function */
    function sendCoin(address receiver, uint amount) returns(bool sufficient) {
        if (coinBalanceOf[msg.sender] < amount) return false;
        coinBalanceOf[msg.sender] -= amount;
        coinBalanceOf[receiver] += amount;
        CoinTransfer(msg.sender, receiver, amount);
        return true;
    }
}

What the page said the standard was

[Meta coin standard](https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs) is a proposed standardization of function names for coin and token contracts, to allow them to be automatically added to other ethereum contract that utilizes trading, like exchanges or escrow.ethereum.org/token, Learn More section, verbatim including its markdown link syntax

A pointer to the wiki, under the name “Meta coin standard”. It stays on the page for five months and is removed on 23 December 2015.

Sources

• Commitethereum-org 33b1217 · Updating the release to the latest frontier page
• Author date2015-07-15 12:38:24 -0300
• Fileviews/content/token.md, first of 117 revisions
• Referenced byissue #20, comment 196816918, 2016-03-15

After this edit the page contains coinBalanceOf 35 times, sendCoin 14 times, and sendToken zero. The token contract is now this, and the source does not change again until a one-operator compile fix four weeks later:

contract token { 
    mapping (address => uint) public coinBalanceOf;
    event CoinTransfer(address sender, address receiver, uint amount);
  
  /* Initializes contract with initial supply tokens to the creator of the contract */
  function token(uint supply) {
        coinBalanceOf[msg.sender] = (supply || 10000);
    }
  
  /* Very simple trade function */
    function sendCoin(address receiver, uint amount) returns(bool sufficient) {
        if (coinBalanceOf[msg.sender] < amount) return false;
        coinBalanceOf[msg.sender] -= amount;
        coinBalanceOf[receiver] += amount;
        CoinTransfer(msg.sender, receiver, amount);
        return true;
    }
}

guide  sendCoin(address,uint256)              0x90b98a11
wiki   sendCoin(uint256,address)              0xc86a90fe

both   coinBalanceOf(address)                 0xbbd39ac0
guide  CoinTransfer(address,address,uint256)  0x16cdf170…6146

The coinBalanceOf getter matches. The transfer function does not. A contract written from the guide and a contract written from the specification could read each other's balances and could not move each other's tokens.

Note also what the event is not. The wiki had specified indexed parameters since June; this one indexes nothing, so a client cannot filter its logs by sender or recipient. And it is named CoinTransfer, which the wiki had already renamed from CoinSent on 5 July and would rename to Transfer on 4 October. The guide never follows.

The guide follows, ninety-three minutes later

{% sections "the-coin", "" %}
{% endsections %}

{% include "git+https://github.com/ethereum/go-ethereum.wiki.git/Contract-Tutorial.md" %}

The commit message is “fix section anchors for Alex tutorial updates”. The guide had been pulling the section anchored "coin"; the rewrite renamed the heading, so the anchor became "the-coin". That one-word edit is the entire mechanism by which the official Frontier documentation adopted this contract.

Sources

• Tutorial rewritego-ethereum wiki 8eaddd0 · updated tutorial
• Guide anchor fixfrontier-guide 7366342 · fix section anchors for Alex tutorial updates
• Author dates2015-07-24 11:51:33 -0300 · 2015-07-24 17:24:55 +0100
• Last guide commit2015-07-28T09:05:36Z, Fabian Vogelsteller, “Update SUMMARY.md”. The repository stops here, two days before Frontier.

Measured across every contract created on mainnet from Frontier launch on 2015-07-30 to 2015-12-31: 6,187 create traces, 5,724 with runtime bytecode, 628 carrying token vocabulary.

The first six

None of the 264 has name, symbol or decimals, and none has any of the final six. They cluster tightly by bytecode: 91 in one family, 54 in a second, 46 in a third, and runtime sizes of 495 bytes (99 contracts), 278 (66) and 238 (46). By month: 65 in August, 51 in September, 102 in October, 12 in November, 34 in December.

What is established is the co-occurrence and its size. The attribution to the guide is an inference, though a tight one: the pairing of a public coinBalanceOf mapping with an unindexed CoinTransfer event, no optional metadata, and no specification sendCoin, is exactly the shape of the contract printed in the official tutorial and of nothing else in the vocabulary. It has not been re-verified by re-scanning, because the archived corpus stores decoded member lists rather than bytecode. Re-running the walk with 0x90b98a11 added would settle it.

Sources

• Corpusraw/onchain/y2015-token-vocabulary-hits.json (628 records), window-token-vocabulary-hits.json (320 records)
• Scan vocabularyraw/onchain/scan-selectors.py, LEGACY map
• Missing selectorsendCoin(address,uint256) = 0x90b98a11

This is the earliest public appearance of balanceOf and of the Transfer event anywhere in the sources examined. The same edit shortens Van de Sande's coinBaseUnit to baseUnit and drops the coin prefix from the other two optional members.

The full interface after this edit

sendCoin(uint _value, address _to)
sendCoinFrom(address _from, uint _value, address _to)
balanceOf(address _addr)
approve(address _addr)
unapprove(address _addr)
isApprovedFor(address _target, address _proxy)
approveOnce(address _addr, uint256 _maxValue)
isApprovedOnceFor(address _target, address _proxy)

event Transfer(address indexed from, address indexed to, uint256 value)
event AddressApproval(address indexed address, address indexed proxy, bool result)
event AddressApprovalOnce(address indexed address, address indexed proxy, uint256 value)

Note what has and has not happened. balanceOf and Transfer are final. The two transfer methods are still sendCoin and sendCoinFrom, and still take value before recipient. There is no totalSupply, no allowance, and approve takes no amount.

A second, cosmetic revision follows nineteen seconds later at 15:07:25Z.

Sources

• Wiki revision607b6ac9c090c45c10e05a00c172793811d02621
• Follow-up352eade · 2015-10-04T15:07:25Z
• Raw artifactraw/wiki-revisions/28-2015-10-04_17-07-06-607b6ac.md

The function is named in a wiki edit that also misspells its sibling. The correction commit message is “Typo fix”.

After the typo fix, revision 31

transfer(uint _value, address _to)
transferFrom(address _from, uint _value, address _to)
balanceOf(address _addr)
approve(address _addr)
unapprove(address _addr)
isApprovedFor(address _target, address _proxy)
approveOnce(address _address, uint256 _maxValue)
isApprovedOnceFor(address _target, address _proxy)

event Transfer(address indexed from, address indexed to, uint256 value)
event AddressApproval(address indexed address, address indexed proxy, bool result)
event AddressApprovalOnce(address indexed address, address indexed proxy, uint256 value)

The names are now final but the signatures are not. transfer still takes value first and recipient second, which is the reverse of the standard. That is corrected on 28 October 2015 by Fabian Vogelsteller, and only then do these two members reach the form the ABI selectors are computed from.

Sources

• Renamebfc39cb · Function names were still "coin" related.
• Typo fix9721a6b · Typo fix
• Raw artifactsraw/wiki-revisions/30-…-bfc39cb.md, 31-…-9721a6b.md

Sixteen days before issue #20 was filed, and two months before the specification stopped moving, the token that is most often called the first ERC-20 was put on mainnet. This is the day, minute by minute. Gist times come from the GitHub gist history API, release times from the GitHub releases API, and the deployment time from the block timestamp of its create trace.

The seventeen-second ordering is not a paradox. Recompilation shows the deployed bytecode carries revision 5's constructor argument order, not revision 4's: the source was edited locally, compiled, deployed, and saved back to the gist afterwards.

The source, gist revision 7bcfaef3, contract body

contract MyToken {
    /* Public variables of the token */
    string public name;
    string public symbol;
    uint8 public decimals;

    /* This creates an array with all balances */
    mapping (address => uint256) public balanceOf;

    /* This generates a public event on the blockchain that will notify clients */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /* Initializes contract with initial supply tokens to the creator of the contract */
    function MyToken(uint256 _supply, string _name, string _symbol, uint8 _decimals) {
        /* if supply not given then generate 1 million of the smallest unit of the token */
        if (_supply == 0) _supply = 1000000;

        /* Unless you add other functions these variables will never change */
        balanceOf[msg.sender] = _supply;
        name = _name;
        symbol = _symbol;

        /* If you want a divisible token then add the amount of decimals the base unit has  */
        decimals = _decimals;
    }

    /* Send coins */
    function transfer(address _to, uint256 _value) {
        /* if the sender doenst have enough balance then stop */
        if (balanceOf[msg.sender] < _value) throw;
        if (balanceOf[_to] + _value < balanceOf[_to]) throw;

        /* Add and subtract new balances */
        balanceOf[msg.sender] -= _value;
        balanceOf[_to] += _value;

        /* Notifiy anyone listening that this transfer took place */
        Transfer(msg.sender, _to, _value);
    }
}

That is the entire contract. One method, one event, three public variables. The transfer here declares no return value at all, which is why the deployed function returns nothing where EIP-20 specifies returns (bool success).

Issue #20 did not exist on this day, and would not for another sixteen. See the MistCoin section for what the deployed bytecode contains and where the contract sits in the record.

What the release notes said

This release fixes a lot of bugs and adds a new custom Token system, as well as a simple way to deploy contracts right from the wallet!Ethereum Wallet 0.3.5 release notes, verbatim

The notes never use the words “standard”, “ERC” or “EIP”. They describe tokens purely as a wallet feature, and they are explicit that names and symbols are not trustworthy identifiers:

Tokens can have any names or symbols (including "US dollar" or "BTC" and other token names) but each one will have a single unique icon, this is your guarantee of sending and receiving the token you want.Ethereum Wallet 0.3.5 release notes, verbatim

The release links its example token to the anonymous gist of 30 October, not to frozeman's own gist of that morning.

Sources

• Gistfrozeman/20c8b5658349b003b08d
• First revisionbce55cca788d90df01447f74eb227e3ed953ec4c
• Releasegithub.com/ethereum/mist/releases/tag/0.3.5
• Announcementr/ethereum, the wallet release thread
• Fabian on MistCoinr/ethereum, his own account of the deployment
• Wallet ABI0022e37
• Raw artifactsraw/gists/mytoken-rev5-7bcfaef3…sol, raw/onchain/mist-release-0.3.5.json, raw/onchain/mistcoin-0xf4eced2f-runtime.hex

The gist is written in the same shape the issue will use: a method list with a prose paragraph for each. It is the document ethers cites two days later when updating the wiki, and it is the direct source of the issue body.

Revision 1, complete method list

transfer(address _to, uint256 _value) returns (bool success)
transferFrom(address _from, address _to, uint256 _value) returns (bool success)
balanceOf(address _address) constant returns (uint256 balance)

approve(address _address) returns (bool _success)
unapprove(address _address) returns (bool _success)
isApprovedFor(address _target, address _proxy) constant returns (bool _r)
approveOnce(address _address, uint256 _maxValue) returns (bool _success)
isApprovedOnceFor(address _target, address _proxy) returns (uint256 _maxValue)

Transfer(address indexed from, address indexed to, uint256 value)
AddressApproval(address indexed address, address indexed proxy, bool result)
AddressApprovalOnce(address indexed address, address indexed proxy, uint256 value)

Five of the eight methods are the approval system: a full-custody approve, its unapprove, a query, a one-time variant and that variant's query. Of the five, exactly one survives, and only after being redefined. There is no totalSupply and no allowance.

The paragraph introducing the approval members is the one Buterin wrote on the wiki seventeen months earlier, carried across almost unedited:

The transferFrom method is used for a "direct debit" workflow, allowing contracts to send coins on your behalf, for example to "deposit" to a contract address and/or to charge fees in sub-currencies; the command should fail unless the _from account has deliberately authorized the sender of the message via some mechanism; we propose these standardized APIs for approval:Token proposal gist, revision 1, verbatim

All six revisions

Revisions 5 and 6, thirteen months later, add only a banner: “This is outdated: The ERC-20 is here”. The gist never gains allowance or Approval. Those two members are born on the issue, not here.

Sources

• Gistfrozeman/090ae32041bcfe120824
• Revision 1d3c1475afd436dbf1b04158bebf552851ffb6cb8
• Raw artifactsraw/gists/tokenproposal-*.txt

Every other member of the final eight can be traced to an ancestor with a different name. balanceOf was coinBalanceOf, transfer was sendCoin, allowance was isApprovedFor, Transfer was CoinTransfer and before that CoinSent. totalSupply has no ancestor.

It reaches implementation code the same day, 4 hours 7 minutes later, in ConsenSys/Tokens.

Sources

• Gist revisione7abcdde39e2ba576a170b07e06c5f84017dc267
• Into codeConsenSys/Tokens 45c5488 · 2015-11-18T13:07:05Z
• Into the wikie5e56c0 · 2015-11-19T01:29:04Z

Members as posted

function decimals()
function totalSupply()
function balanceOf(address _address)
function transfer(address _to, uint256 _value)
function transferFrom(address _from, address _to, uint256 _value)
function approve(address _address)
function unapprove(address _address)
function isApprovedFor(address _target, address _proxy)
function approveOnce(address _address, uint256 _maxValue)
function isApprovedOnceFor(address _target, address _proxy)

event Transfer(address indexed _from, address indexed _to, uint256 _value)
event AddressApproval(address indexed _address, address indexed _proxy, bool _result)
event AddressApprovalOnce(address indexed _address, address indexed _proxy, uint256 _value)

Ten methods, of which four match the final standard by name and signature. Three events, of which one survives. Five members here do not exist in ERC-20 today: decimals, unapprove, isApprovedFor, approveOnce, isApprovedOnceFor.

The body as posted, verbatim

The following describes standard functions a token contract can implement. Those will allow dapps and wallets to handle tokens across multiple interfaces/dapps.

The most important here are, `transfer`, `balanceOf`, `decimals` and the `Transfer` event.

```js
## Token

### Methods

#### decimals

```js
function decimals() constant returns (uint256 decimals)
```
Returns the number of decimal points this token requires, e.g. `2`


#### totalSupply

```js
function totalSupply() constant returns (uint256 supply)
```
Get the total coin supply

#### balanceOf

```js
function balanceOf(address _address) constant returns (uint256 balance)
```
Get the account balance of another account with address `_address`

#### transfer

```js
function transfer(address _to, uint256 _value) returns (bool _success)
```
Send `_value` amount of coins to address `_to`

#### transferFrom

```js
function transferFrom(address _from, address _to, uint256 _value) returns (bool success)
```
Send `_value` amount of coins from address `_from` to address `_to`

The `transferFrom` method is used for a "direct debit" workflow, allowing contracts to send coins on your behalf, for example to "deposit" to a contract address and/or to charge fees in sub-currencies; the command should fail unless the `_from` account has deliberately authorized the sender of the message via some mechanism; we propose these standardized APIs for approval:

#### approve

```js
function approve(address _address) returns (bool success)
```
Allow `_address ` to direct debit from your account with full custody. Only implement if absolutely required and use carefully. See `approveOnce` below for a more limited method.

#### unapprove

```js
function unapprove(address _address) returns (bool success)
```
Unapprove address `_address ` to direct debit from your account if it was previously approved. Must reset both one-time and full custody approvals.

#### isApprovedFor

```js
function isApprovedFor(address _target, address _proxy) constant returns (bool success)
```
Returns 1 if `_proxy` is allowed to direct debit from `_target`

#### approveOnce

```js
function approveOnce(address _address, uint256 _maxValue) returns (bool success)
```
Makes a one-time approval for `_address ` to send a maximum amount of currency equal to `_maxValue`

#### isApprovedOnceFor

```js
function isApprovedOnceFor(address _target, address _proxy) returns (uint256 maxValue)
```
Returns `_maxValue` if `_proxy` is allowed to direct debit the returned `maxValue` from address `_target` only once. The approval must be reset on any transfer by `_proxy` of `_maxValue` or less.

### Events
#### Transfer

```js
event Transfer(address indexed _from, address indexed _to, uint256 _value)
```
Triggered when tokens are transferred.

#### AddressApproval

```js
event AddressApproval(address indexed _address, address indexed _proxy, bool _result)
```
Triggered when an `_address` approves `_proxy` to direct debit from their account.

#### AddressApprovalOnce

```js
event AddressApprovalOnce(address indexed _address, address indexed _proxy, uint256 _value)
```
Triggered when an `_address` approves `_proxy` to direct debit from their account only once for a maximum of `_value`

```

Two sentences in that text are worth marking. The first line of the Motivation is the standard's actual purpose, and it does not mention exchanges, allowances or contract-to-contract accounting at all. The second is the ranking: “The most important here are, transfer, balanceOf, decimals and the Transfer event.” That sentence names decimals, which is removed from the standard seven days later, and it survives into the final text unedited, still naming decimals, long after the member itself is gone.

Sources

• Issueethereum/EIPs issue #20
• GH Archive filedata.gharchive.org/2015-11-19-9.json.gz
• OriginIssuesEvent / opened
• Raw artifactraw/issue20-bodies/r01-20151119T095256Z.md

The two members that make ERC-20 what it is, and that exchanges and later DeFi protocols are built on, are the last two to arrive. Both arrive as renames, in an edit between two comments three minutes and forty-four seconds apart.

function decimals()
function totalSupply()
function balanceOf(address _address)
function transfer(address _to, uint256 _value)
function transferFrom(address _from, address _to, uint256 _value)
function approve(address _spender, uint256 _value)
function unapprove(address _spender)
function allowance(address _address, address _spender)

event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _address, address indexed _spender, uin256 _value)

The uin256 in the Approval declaration is a typo in the original. It persists through revisions 7 to 13 and is not corrected until revision 14 on 2 December 2015.

Two members that are not in the final standard are still here: decimals and unapprove. The parameter names are still _address rather than _owner. Revision 8, two minutes and twenty-four seconds later, is a thirteen-byte change.

Sources

• Snapshot carried bycomment 158439737, frozeman
• GH Archive filedata.gharchive.org/2015-11-20-15.json.gz
• Edit windowafter 2015-11-20T15:49:58Z, at or before 15:53:42Z
• Raw artifactraw/issue20-bodies/r07-20151120T155342Z.md

Revision 10, sixty-nine minutes earlier, had already done the other cleanup: _address becomes _owner throughout, giving balanceOf(address _owner) and allowance(address _owner, address _spender) their final parameter names.

function totalSupply()
function balanceOf(address _owner)
function transfer(address _to, uint256 _value)
function transferFrom(address _from, address _to, uint256 _value)
function approve(address _spender, uint256 _value)
function unapprove(address _spender)
function allowance(address _owner, address _spender)

event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uin256 _value)

One member stands between this and the finished standard: unapprove. It takes another six weeks to remove.

Sources

• Snapshot carried bycomment 159872082, simondlr
• GH Archive filedata.gharchive.org/2015-11-26-10.json.gz
• Edit windowafter 2015-11-26T09:25:09Z, at or before 10:34:22Z
• Raw artifactraw/issue20-bodies/r11-20151126T103422Z.md

function totalSupply()
function balanceOf(address _owner)
function transfer(address _to, uint256 _value)
function transferFrom(address _from, address _to, uint256 _value)
function approve(address _spender, uint256 _value)
function unapprove(address _spender)
function allowance(address _owner, address _spender)

event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approval(address indexed _owner, address indexed _spender, uint256 _value)

This is finding 2. Note that the typo in the specification, uin256, does not appear here: the implementation writes uint256, because it has to compile. The specification is corrected two days later.

Sources

• Commit4ba2396 · Refactored to current standards.
• Raw artifactraw/code-snapshots/ConsenSysTokens-4ba2396-Token.sol

The rename is consistent with the design at that moment: if unapprove is a real method, it needs its own event, and a pair called Approved and Unapproved is more symmetrical than Approval and Unapproved. The whole branch is abandoned five weeks later when approve is redefined as absolute and unapprove stops being needed.

function totalSupply()
function balanceOf(address _owner)
function transfer(address _to, uint256 _value)
function transferFrom(address _from, address _to, uint256 _value)
function approve(address _spender, uint256 _value)
function unapprove(address _spender)
function allowance(address _owner, address _spender)

event Transfer(address indexed _from, address indexed _to, uint256 _value)
event Approved(address indexed _owner, address indexed _spender, uin256 _value)
event Unapproved(address indexed _owner, address indexed _spender)

Revision 14, fifty-three minutes later, is a one-byte change: the uin256 typo introduced on 20 November is finally corrected to uint256.

The regression propagates. ConsenSys/Tokens follows it on the same day at 13:24:54Z with “Added unapprove”, and the wiki follows it on 16 December with “update to latest Token standard draft”. For five weeks the specification, the reference implementation and the wiki all agree on an interface that no longer exists.

Sources

• Snapshot carried bycomment 161234094, frozeman
• GH Archive filedata.gharchive.org/2015-12-02-9.json.gz
• Into codeConsenSys/Tokens f3c0fc1 · Added unapprove
• Into the wiki551fce2 · 2015-12-16T02:00:37Z
• Raw artifactsraw/issue20-bodies/r13-…md, r14-…md

Full title: “Ethereum in practice part 1: how to build your own cryptocurrency without touching a line of code”. Published two weeks after issue #20 was filed.

The post contains no inline Solidity. It instructs the reader to load the contract into the browser-based compiler from a gist: chriseth.github.io/browser-solidity/?gist=21935dc37c5bfbe92e5a. Its only description of what the token implements is:

Since all tokens implement some basic features in a standard way, this also means that your token will be instantly compatible with the ethereum wallet and any other client or contract that uses the same standards.Verbatim

It also concedes the wallet's discovery limitation directly: “the wallet only tracks tokens it knows about, and you have to add these manually.”

What the linked gist contains

contract MyToken {
    event Transfer(address indexed from, address indexed to, uint256 value);
    function MyToken(uint256 _supply, string _name, string _symbol, uint8 _decimals)
    function transfer(address _to, uint256 _value)
}

One method and one event. As of December 2015 the Ethereum Foundation's own public tutorial for creating a token neither named the standard nor implemented it.

The post left a measurable trace onchain

The tutorial tells the reader to enter “10,000 as the supply, any name you want, "%" for a symbol and 2 decimal places.” That instruction is visible in the constructor arguments of contracts deployed afterwards.

Weekly MyToken-shaped deployments

week of 2015-11-02:  17   (Wallet 0.3.5 ships)
week of 2015-11-09:  10
week of 2015-11-16:   2
week of 2015-11-23:   2
week of 2015-11-30:  36   (blog post, 2015-12-03)
week of 2015-12-07:  33
week of 2015-12-14:  17
week of 2015-12-21:  10
week of 2015-12-28:   8
week of 2016-01-04:   5

Two spikes, both attributable: eight deployments on 3 November, the day Wallet 0.3.5 shipped, and fifteen each on 4 and 5 December, the two days after the blog post. From the week of 23 November to the week of 30 November is an eighteenfold jump.

Two circulating argument layouts

Of the 118 window deployments whose constructor arguments decode cleanly, 94 carry the rev5 layout and 24 the rev≤4 layout. The two published sources are distinguishable in the deployed bytes, in roughly a four-to-one ratio favouring the one the blog post carried.

Sources

• Postblog.ethereum.org/2015/12/03/how-to-build-your-own-cryptocurrency
• Gist21935dc37c5bfbe92e5a
• Gist revisione055b2f271def0a188cc2da13c75a190cc770dfa, single revision, created 2015-12-01T18:37:25Z
• Raw artifactsraw/gists/mytoken-blogpost-21935dc37c5bfbe92e5a-20151201.sol, raw/onchain/window-token-census.tsv, raw/onchain/decode-constructor-args.py

“Absolute approval” is the decision that removes unapprove: once approve overwrites the allowance rather than adding to it, setting it to zero is unapproving, and a separate method is redundant. That is the design argument the specification adopts on 6 January. The code makes it first.

Token.sol at c3a3426, complete

contract Token {

    function totalSupply() constant returns (uint256 supply) {}
    function balanceOf(address _owner) constant returns (uint256 balance) {}
    function transfer(address _to, uint256 _value) returns (bool success) {}
    function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {}
    function approve(address _spender, uint256 _value) returns (bool success) {}
    function allowance(address _owner, address _spender) constant returns (uint256 remaining) {}

    event Transfer(address indexed _from, address indexed _to, uint256 _value);
    event Approval(address indexed _owner, address indexed _spender, uint256 _value);
}

This is finding 3. Every declaration matches the final standard, and there is nothing else in the file. The word ERC does not appear in it, in the commit message, or anywhere in the repository at this date.

Sources

• Commitc3a3426bb1c8ac8aac627d246cc4e011273dd6c4
• BlobToken_Contracts/contracts/Token.sol
• Raw artifactraw/code-snapshots/ConsenSysTokens-c3a3426-Token.sol

Two days after ConsenSys reached the exact interface, and fourteen days before the specification froze, the Foundation's own token page moves off the Frontier vocabulary. It does not move to the specification. It moves to the contract from the December blog post, which is the contract deployed as MistCoin.

contract MyToken { 
    /* Public variables of the token */
    string public name;
    string public symbol;
    uint8 public decimals;

    /* This creates an array with all balances */
    mapping (address => uint256) public balanceOf;

    /* This generates a public event on the blockchain that will notify clients */
    event Transfer(address indexed from, address indexed to, uint256 value);

    /* Initializes contract with initial supply tokens to the creator of the contract */
    function myToken(uint256 initialSupply, string tokenName, uint8 decimalUnits, string tokenSymbol) {

Two of the six required methods, one of the two required events, three of three optional members: the same score as MistCoin, and the same shape the wallet rendered. The Transfer event is indexed here, which the Frontier Guide's CoinTransfer never was.

The same commit removes the “Meta coin standard” link to Standardized_Contract_APIs that had been on the page since July. From this date ethereum.org's token page points at no standard at all.

Sources

• Commitethereum-org b0abb37 · add the DAO page
• Author date2015-12-23 17:36:12 -0200
• Link removal“Meta coin standard” added 33b1217 (2015-07-15), removed b0abb37 (2015-12-23). No other commit touches the string.

It follows the cutting edge standards (which is de facto finalised by the community here: https://github.com/ethereum/EIPs/issues/20)ConsenSys/Tokens README at bbbff96, verbatim

The claim is true of the code and premature about the document. ConsenSys/Tokens had held the exact interface since 21 December. The issue body still said unapprove, Approved and Unapproved, and would for another five days.

Sources

• Commitbbbff96 · Udpated README for public.

This is finding 4, and it is a bound rather than a timestamp. The issue thread was silent between 2015-12-02T10:22:08Z and 2016-01-06T10:12:13Z, so no snapshot exists inside that window. What the evidence supports exactly: the final interface was not present at 10:12:13Z and was present at 10:28:48Z, sixteen minutes and thirty-five seconds later.

The body, verbatim, complete

```
ERC: 20
Title: Token standard
Status: Draft
Type: Informational
Created: 19-11.2015
Resolution: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs
```
# Abstract

The following describes standard functions a token contract can implement.

# Motivation

Those will allow dapps and wallets to handle tokens across multiple interfaces/dapps.

The most important here are, `transfer`, `balanceOf`, `decimals` and the `Transfer` event.

# Specification

## Token

### Methods


#### totalSupply

```js
function totalSupply() constant returns (uint256 supply)
```
Get the total token supply

#### balanceOf

```js
function balanceOf(address _owner) constant returns (uint256 balance)
```
Get the account balance of another account with address `_owner`

#### transfer

```js
function transfer(address _to, uint256 _value) returns (bool success)
```
Send `_value` amount of tokens to address `_to`

#### transferFrom

```js
function transferFrom(address _from, address _to, uint256 _value) returns (bool success)
```
Send `_value` amount of tokens from address `_from` to address `_to`

The `transferFrom` method is used for a withdraw workflow, allowing contracts to send tokens on your behalf, for example to "deposit" to a contract address and/or to charge fees in sub-currencies; the command should fail unless the `_from` account has deliberately authorized the sender of the message via some mechanism; we propose these standardized APIs for approval:

#### approve

```js
function approve(address _spender, uint256 _value) returns (bool success)
```
Allow _spender to withdraw from your account, multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.

#### allowance

```js
function allowance(address _owner, address _spender) constant returns (uint256 remaining)
```
Returns the amount which `_spender ` is still allowed to withdraw from `_owner`


### Events
#### Transfer

```js
event Transfer(address indexed _from, address indexed _to, uint256 _value)
```
Triggered when tokens are transferred.

#### Approval

```js
event Approval(address indexed _owner, address indexed _spender, uint256 _value)
```
Triggered whenever `approve(address _spender, uint256 _value)` is called.

Three details are worth noting in that text. The Motivation still recommends decimals, which was removed six weeks earlier and is not defined anywhere below. The word “coins” from the original has been replaced by “tokens” throughout. And the sentence defining approve as overwriting rather than accumulating, “If this function is called again it overwrites the current allowance with _value”, is the sentence that makes unapprove unnecessary and is the direct descendant of ConsenSys's “Absolute approval” commit sixteen days earlier.

What happened next, the same morning

• 10:48:26Z, twenty minutes later, caktux mirrors it on the wiki: “update to latest draft - approve() now absolute, remove unapprove() and Unapproved(), Approved() renamed to Approval()”.
• 20:55:55Z, revision 16, a twelve-byte change. The body then does not change again across 111 consecutive comment snapshots, until 28 October 2016. That is genuine stability, not a gap in coverage.

Sources

• Snapshot carried bycomment 169288676, frozeman
• GH Archive filedata.gharchive.org/2016-01-06-10.json.gz
• Wiki mirror02c64c1 · 2016-01-06T10:48:26Z
• Raw artifactraw/issue20-bodies/r15-20160106T102848Z.md

Address

0x99146Bab2bB34D9Ca49EC4f0c82De3E5789ae22e

Deployed

2016-01-10T00:21:08Z, block 824,235

Deployer

0x4f53269e422711d4725F7381444c7F66F7D05788

Runtime size

6,701 bytes

Contents

All six methods. Both the Transfer and Approval topics. Plus owner() and 45 further unrecognised selectors.

Supply

totalSupply() returns zero at the block after deployment, five thousand blocks later, forty thousand blocks later, and at block 913,198. It has never emitted a Transfer.

Carrying the interface and being a token are different claims, and this contract separates them. It is the Digix gold ledger, and this deployment and the one that follows it eleven hours later, 0xB2dd0dc22c7D103928650AbD260935Ef9EF40CFc, are staging runs: the same 6,701 bytes, no supply, no transfer, ever. The ledger that went into service is the third, on 14 January.

The gap this closes is the central empirical result of the reconstruction. Between 3 November 2015 and 6 January 2016, across 2,941 contracts with runtime bytecode, nothing implements more than three of the six, and nothing at all implements approve or allowance. The allowance model, the half of ERC-20 that makes exchanges possible and the half that consumed almost all of the argument on the issue, has zero deployed instances during the period in which it was being specified.

See the onchain section for the full census and the adoption curve.

Sources

• Raw artifactraw/onchain/y2016-final-six-4plus.json
• DetectionOpcode walk over the runtime blob, cross-checked by substring match. See Method.

Address

0x55b9a11c2e8351b4Ffc7b11561148bfaC9977855

Deployed

2016-01-14T15:22:33Z, block 847,527

Deployer

0x4f53269e422711d4725F7381444c7F66F7D05788

Runtime size

6,770 bytes

Supply

1,400,331,016,000

First Transfer

block 937,821

Four tests separate a token from a contract that merely exposes the interface, and this is the first deployment to pass all four. It carries the six selectors, among 38 other functions. It has a real supply: totalSupply() returns 1,400,331,016,000 at block 847,528, the block after deployment, and the same value at every block sampled between there and block 937,821, so it was never an empty ledger waiting to be filled. It was meant as a token, being the address Digix names in its own gold-tokens-interface repository and the one MyEtherWallet's token list carries as DGX 1.0. And it emits Transfer when tokens move, from block 937,821 onward.

The two Digix ledgers deployed four days earlier hold the identical interface and fail every test but the first. Their supply reads zero at deployment, five thousand blocks later, forty thousand blocks later, and at block 913,198, and neither has emitted a Transfer in its life. They are staging deployments of the contract this one became.

What it is not is fully compliant with EIP-20. Run on a mainnet fork it breaks two mandatory requirements, both visible in what it emits:

• Event shapeTransfer is declared with _value indexed. Every one it has emitted carries four topics and an empty data field. EIP-20 requires three topics with the value in data, so a reader following the standard finds no amount at all.
• Wrong sendertransferFrom names the spender as _from, not the owner whose balance moved. One call emits three Transfer events, one of them a fee leg, and the movement leg attributes the debit to the wrong account.

Both are properties of the deployed runtime, unchanged since 2016 and reproducible at any block. The first contract that satisfies every EIP-20 requirement arrives on 20 March 2016, sixty-six days later.

The first ERC-20 token cannot be verified on Etherscan. It belongs to a Digix system compiled by solc v0.1.7 commit c806b9bc, a build that exists in the Solidity history and was never published to solc-bin, so no released compiler reproduces its bytecode.

Sources

• InterfaceDigixGlobal/gold-tokens-interface
• DetectionSelector walk over the runtime, then totalSupply() at historical blocks and a log scan on the Transfer topic.

diff --git a/Token_Contracts/contracts/Standard_Token.sol b/Token_Contracts/contracts/Standard_Token.sol
index ab28fea..28f1ceb 100644
--- a/Token_Contracts/contracts/Standard_Token.sol
+++ b/Token_Contracts/contracts/Standard_Token.sol
@@ -1,7 +1,7 @@
 /*Most, basic default, standardised Token contract.
 Allows the creation of a token with a finite issued amount to the creator.
 
-Based on standardised APIs: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs
+Implements ERC 20 Token standard: https://github.com/ethereum/EIPs/issues/20
 .*/
 
 import "Token";

Two months after the issue was filed and five weeks after the code was already correct, someone writes the standard's name down in a repository for the first time. The name lags the thing by a wide margin at every stage of this trail.

The naming sequence

“First” here means first across the sources enumerated in Method. Commit-message evidence outside those repositories was sampled through GH Archive rather than exhaustively searched.

Sources

• Commit85610c3ed1a614453fe32834a2694dd9ec000de9
• Authorethers <ethereum@outlook.com>
• Author date2016-01-24 16:39:07 -0800

Address

0xa04bf47F0E9D1745D254b9B89f304c7d7ad121Aa

Deployed

2016-01-27T14:47:57Z, block 912,760

First Transfer

2016-01-27T16:54:44Z, block 913,198

From

0x48175Da4c20313bcb6B62d74937d3fF985885701

To

0x96CB25A6445648A56352677D6C80600F769F2642

Value

1,000,000

Not a mint. The sender is the deployer's own account, not the zero address, so this is one holder paying another rather than a supply being created. The contract answers name() with a bytes32 that decodes to elcoin, and answers neither symbol() nor decimals(), both of which were optional and arrived later.

Thirteen days separate the first token from the first transfer, and in that window no contract carrying the interface moved a single token. Digix Gold, deployed first, did not emit its own first Transfer until block 937,821.

The event is real, the interface behind it is not. elcoin holds all six selectors, but its own ERC-20 entry points do nothing. Called on a fork, transfer, approve and transferFrom each return false, move no balance and emit no event, from a funded holder as readily as from an empty account. The contract asks a security registry at 0xa95b9127e7102dCFa3869c47ee12a0Ec85C261C5 whether the caller is permitted, receives zero, and returns. The behaviour is identical at block 950,000 and at the head of the chain, so this is not a later configuration change.

Every transfer elcoin recorded, all 1,450 of them, was driven through a platform controller rather than through transfer. The chain also records the other half of that: every direct call to transfer(address,uint256) in elcoin's history failed. It is an asset on a permissioned platform that exposes the ERC-20 shape, not a contract that behaves as ERC-20 requires.

Sources

• DetectionLog scan on topic ddf252ad… from each candidate's deployment block, earliest first.

In order to work on the Ethereum Wallet all your token need is to implement correctly balanceOf and transfer and their corresponding events. We are waiting for all others but the latest proposed standard is kept updated at ethereum.org/tokenVerbatim

This is the single most useful sentence in the whole issue for dating what “compliance” meant. It is stated by the person who built the client that defined the requirement, on the standard's own thread, and it corroborates the wallet ABI evidence from the other direction. See Compliance.

His other interventions on the thread

Sources

• Raw artifactraw/gharchive-events/issue20-events.jsonl

Address

0xacFD9D15fA769EaBb68410c4c675Ff2030f26416

Deployed

2016-03-20T11:09:16Z, block 1,184,107

Deployer

0x3a77633f26ddD2cf58D1fea2C889098565cA5C8C

Runtime size

2,356 bytes

Contents

The six required methods, both event topics, plus deposit() and withdraw(uint256). No name, symbol or decimals.

Use

One transaction in its life, its own creation. Zero logs.

It is an ether wrapper, the pattern later made familiar by WETH. deposit() credits the caller with the ether sent, withdraw(uint256) returns it, and totalSupply() reports the contract's own ether balance rather than a stored figure, so supply and backing cannot drift apart. It emits the same Deposit and Withdrawal topics that canonical WETH9 would later use.

Compliance here is a claim about behaviour, so it was tested by behaviour. The contract was run on a mainnet fork, funded through its own deposit() rather than by writing storage, and every obligation checked against real transactions: receipts read for the events actually emitted, eth_call used to measure the width of each return value. It passes all ten, and passes them twice, once at the head of the chain and once on a fork pinned 93 blocks after its deployment under the hardfork rules of the day.

Reaching this point took a single opcode. The contract deployed on 25 February, 0xb345180D0a2c791d4943a239f8eBb50eFA01C81a, is the same code for its first 2,342 bytes and differs only in the tail bounds helper, which compares with ADD GT where this one compares with ADD LT ISZERO. Strict against inclusive. Under the strict form an amount of zero fails the check and the call throws, which is why the February contract rejects zero-value transfers and this one accepts them. That one comparison is the whole twenty-three day gap.

Everything deployed before it fails. All 34 contracts carrying the six selectors that predate this block were executed the same way and every one breaks at least one requirement: thirteen return no boolean from transfer, four return no data at all from totalSupply() and balanceOf(), three index _value in Transfer, one has ERC-20 entry points that do nothing, and the remaining thirteen reject transfers of zero, some of them emitting the wrong events besides.

Sources

• CorpusEvery create trace of 2015 and 2016, 6,187 and 230,818 respectively, internal creates included. 2015 yields no contract with all six selectors; 2016 yields 1,014.
• DetectionPUSH-aware disassembly for selector presence, then execution on an anvil mainnet fork for behaviour. Balances obtained through each contract's own mint path where one exists, otherwise by impersonating a live holder.

Cloned and read from the initial commit. README.md in full: “dapple package for ERC20 token type interface”. dappfile declares name: erc20.

contracts/erc20.sol at that commit, complete

contract ERC20 {
    function totalSupply() constant returns (uint);
    function balanceOf(address who) constant returns (uint);
    function allowance(address owner, address spender) constant returns (uint);

    function transfer(address to, uint value) returns (bool ok);
    function transferFrom(address from, address to, uint value) returns (bool ok);
    function approve(address spender, uint value) returns (bool ok);

    event Transfer(address indexed from, address indexed to, uint value);
    event Approval(address indexed owner, address indexed spender, uint value);
}

Six methods, two events, nothing else. Scored by literal declaration text against the final signatures this reads as three of six, because uint and uint256 are different strings. They are the same ABI type. Scored by canonical selector, which is what interoperability actually depends on, it is six of six and both events match:

totalSupply()                          0x18160ddd
balanceOf(address)                     0x70a08231
allowance(address,address)             0xdd62ed3e
transfer(address,uint256)              0xa9059cbb
transferFrom(address,address,uint256)  0x23b872dd
approve(address,uint256)               0x095ea7b3
Transfer(address,address,uint256)      0xddf252ad…b3ef
Approval(address,address,uint256)      0x8c5be1e5…b925

The base implementation arrives sixteen minutes later in c0b1dfc, “copy base implementation and tests from dappsys”. The repository keeps its purpose: fc53f48 of 2017-02-02 reduces it back to the interface, and the file survives through solc 0.5.0 and 0.6.6.

No repository created in 2015 has ERC20 in its name or description

A search for “token standard” restricted to Solidity over the same two years returns zero results.

Sources

• Commite9707811d80ab36fecc67deb3a75a41adda3a954
• Blobcontracts/erc20.sol
• Author date2016-04-24 15:55:53 -0400
• Raw artifactraw/code-snapshots/dapphub-erc20-e970781-erc20-INITIAL.sol

Searching the whole repository across all 1,210 commits from 2015-03-07 to 2019-04-17:

And in views/content/token.md itself, the page a reader actually saw, the substring ERC never appears in any of its 117 revisions, through the last commit in the repository.

That closes the loop with the Frontier Guide. Neither of the Foundation's two documentation properties adopted the name while the standard was being written, and only one of them ever adopted the interface.

Sources

• Commitethereum-org 298cb09 · Separate solidity files (#693)
• Author date2017-09-29 18:22:55 -0300
• Methodgit log --all -S"<string>" over the full clone; and a scan of all 117 revisions of views/content/token.md for the substring ERC