Technical Document: The History and Analysis of Currency Coin and the Genesis of the ERC-20 Standard

Abstract: This document provides a definitive technical analysis and historical timeline of the currency.sol smart contract and its deployed instance, Currency Coin. Evidence from early developer discussions, GitHub commits, and EIP proposals demonstrates that this contract was not an isolated experiment but a central piece in a collaborative, evolutionary process. This process, centered around the Standardized_Contract_APIs repository, directly led to the creation of the ERC-20 token standard. This analysis covers the documented evolution of the standard, a side-by-side code comparison of its key implementations, and an examination of its technical significance as a foundational, provably-unique digital artifact in Ethereum's history.

I. Documented Historical Timeline

Date	Event & Significance
Jun 17, 2015	Initial Token API Concepts Proposed: Vitalik Buterin makes one of the first commits to the `Standardized_Contract_APIs` wiki, laying the conceptual groundwork for a standard token, including functions like `send`, `approve`, and the experimental `approve_once`.
Jul 30, 2015	Ethereum Mainnet 'Frontier' Launches: The Ethereum blockchain goes live, creating the live environment where smart contracts and tokens could be deployed for the first time and establishing the need for such standards.
Aug 27, 2015	Community Implements & Refines API Concepts: Developer Simon de la Rouviere (caktux) commits a change to the EtherEx project, renaming `disapprove` to `unapprove`, proving that the standardized APIs were already being implemented and tested by key community projects.
Sep 6, 2015	Vitalik Buterin Commits `currency.sol`: Buterin authors and publishes the `currency.sol` contract, a concrete Solidity implementation of the concepts developed in the standardized APIs, including the `disapprove` function.
Sep 8, 2015	Currency Coin Deployed to Mainnet: Developer 'rfikki' deploys a refined, mainnet-ready version of `currency.sol` to the Ethereum blockchain at address `0x8494F777d13503BE928BB22b1F4ae3289E634FD3`.
Nov 17, 2015	ERC System Proposed (EIP Issue #16): Fabian Vogelsteller proposes the ERC system, explicitly naming the `Standardized_Contract_APIs` as 'top candidates' for standards, creating a direct link from the co-author of ERC-20 to the source repository.
Nov 19, 2015	EIP-20 (ERC-20) Formally Proposed: The ERC-20 token standard is proposed, with its 'History' section officially citing Vitalik's `Standardized_Contract_APIs` as the original source, cementing its provenance.

II. Code Evolution: Side-by-Side Comparison

The following table provides a detailed, function-by-function comparison of Vitalik Buterin's reference `currency.sol` and Rfikki's hardened, deployed version. Key differences are highlighted to illustrate the evolution from a template to a mainnet-ready contract.

Vitalik Buterin's `currency.sol` (Template) Rfikki's Deployed `currency` (Mainnet)

Vitalik Buterin's `currency.sol` (Template)	Rfikki's Deployed `currency` (Mainnet)
State Variables `contract currency { mapping(address => uint256) balances; mapping(address => mapping(address => uint256)) allowed;` Implicit public visibility, standard for early Solidity.	State Variables `contract currency { mapping(address => uint256) public balances; mapping(address => mapping(address => uint256)) public allowed;` DIFFERENCE: Explicit `public` visibility is added for clarity and to automatically generate getter functions.
`transfer` Function `function transfer(address _to, uint256 _amount) returns (bool success) { if (balances[msg.sender] >= _amount && _amount > 0) { balances[msg.sender] -= _amount; balances[_to] += _amount; return true; } else { return false; } }` No protection against integer overflow if `balances[_to]` is near the max uint256 value.	`transfer` Function `function transfer(address _to, uint256 _amount) returns (bool success) { if (balances[msg.sender] >= _amount && _amount > 0 && balances[_to] + _amount > balances[_to]) { balances[msg.sender] -= _amount; balances[_to] += _amount; return true; } else { return false; } }` DIFFERENCE: An integer overflow check is added, a critical security improvement for mainnet deployment.
`transferFrom` Function `function transferFrom(address _from, address _to, uint256 _amount) returns (bool success) { if (balances[_from] >= _amount && allowed[_from][msg.sender] >= _amount && _amount > 0) { balances[_from] -= _amount; allowed[_from][msg.sender] -= _amount; balances[_to] += _amount; return true; } else { return false; } }`	`transferFrom` Function `function transferFrom(address _from, address _to, uint256 _amount) returns (bool success) { if (balances[_from] >= _amount && allowed[_from][msg.sender] >= _amount && _amount > 0 && balances[_to] + _amount > balances[_to]) { balances[_from] -= _amount; allowed[_from][msg.sender] -= _amount; balances[_to] += _amount; return true; } else { return false; } }` DIFFERENCE: The same overflow protection is added here.
`isApprovedOnceFor` Function `function isApprovedOnceFor(address _owner, address _spender) constant returns (uint256 amount) { return allowed[_owner][_spender]; }` An experimental function duplicating `allowance`, likely for testing "cheque-like" one-time approvals.	`isApprovedOnceFor` Function `// No isApprovedOnceFor function` DIFFERENCE: This redundant, experimental function was removed to streamline the contract for mainnet deployment.
Shared Functions (Identical Logic) The core logic for `balanceOf`, `approve`, `allowance`, and the pre-ERC20 `disapprove` function remains identical between both versions, demonstrating a clear lineage. `// Example: disapprove function present in both versions function disapprove(address _spender) returns (bool success) { allowed[msg.sender][_spender] = 0; return true; }`

State Variables

contract currency {
    mapping(address => uint256) balances;
    mapping(address => mapping(address => uint256)) allowed;

Implicit public visibility, standard for early Solidity.

State Variables

contract currency {
    mapping(address => uint256) public balances;
    mapping(address => mapping(address => uint256)) public allowed;

DIFFERENCE: Explicit `public` visibility is added for clarity and to automatically generate getter functions.

`transfer` Function

function transfer(address _to, uint256 _amount) returns (bool success) {
    if (balances[msg.sender] >= _amount && _amount > 0) {
        balances[msg.sender] -= _amount;
        balances[_to] += _amount;
        return true;
    } else {
        return false;
    }
}

No protection against integer overflow if `balances[_to]` is near the max uint256 value.

`transfer` Function

function transfer(address _to, uint256 _amount) returns (bool success) {
    if (balances[msg.sender] >= _amount && _amount > 0 && balances[_to] + _amount > balances[_to]) {
        balances[msg.sender] -= _amount;
        balances[_to] += _amount;
        return true;
    } else {
        return false;
    }
}

DIFFERENCE: An integer overflow check is added, a critical security improvement for mainnet deployment.

`transferFrom` Function

function transferFrom(address _from, address _to, uint256 _amount) returns (bool success) {
    if (balances[_from] >= _amount && allowed[_from][msg.sender] >= _amount && _amount > 0) {
        balances[_from] -= _amount;
        allowed[_from][msg.sender] -= _amount;
        balances[_to] += _amount;
        return true;
    } else {
        return false;
    }
}

`transferFrom` Function

function transferFrom(address _from, address _to, uint256 _amount) returns (bool success) {
    if (balances[_from] >= _amount && allowed[_from][msg.sender] >= _amount && _amount > 0 && balances[_to] + _amount > balances[_to]) {
        balances[_from] -= _amount;
        allowed[_from][msg.sender] -= _amount;
        balances[_to] += _amount;
        return true;
    } else {
        return false;
    }
}

DIFFERENCE: The same overflow protection is added here.

`isApprovedOnceFor` Function

function isApprovedOnceFor(address _owner, address _spender) constant returns (uint256 amount) {
    return allowed[_owner][_spender];
}

An experimental function duplicating `allowance`, likely for testing "cheque-like" one-time approvals.

`isApprovedOnceFor` Function

// No isApprovedOnceFor function

DIFFERENCE: This redundant, experimental function was removed to streamline the contract for mainnet deployment.

Shared Functions (Identical Logic)

The core logic for balanceOf, approve, allowance, and the pre-ERC20 disapprove function remains identical between both versions, demonstrating a clear lineage.

// Example: disapprove function present in both versions
function disapprove(address _spender) returns (bool success) {
    allowed[msg.sender][_spender] = 0;
    return true;
}

III. Technical Deep Dive & Corroborating Evidence

The Path to Formalization

The creation of ERC-20 was not a single event but a public, collaborative process. The evidence trail is unambiguous.

Simon de la Rouviere (caktux) on Reddit (August 2015), regarding his project EtherEx:
"Subcurrency contracts that want to get ready ahead of time to support the exchange should check the Subcurrency API, which now only requires contracts to implement a few methods from the Standardized Contract APIs..."

This shows that key community projects were actively building on and providing feedback for the standard before `currency.sol` was even finalized.

Fabian Vogelsteller (ethers) in EIP Issue #16 (November 17, 2015):
"The items in https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs are top candidates for ERCs."

This statement from the co-author of ERC-20 directly and explicitly identifies the source repository of the `currency` proposal as the wellspring for the entire ERC system.

The `MAX_UINT256` Constant: An Expert's Touch

A notable feature of early token contracts, including this one, was the pattern for granting an "infinite" or maximum approval. This was achieved by calling the approve function with the maximum possible value for a uint256.

The Number: 340282366920938463463374607431768211456 (which is 2²⁵⁶ - 1)

Purpose: By setting an allowance to this value, a user grants a spender (e.g., a DEX) a practically unlimited allowance, avoiding the need for repeated approval transactions.
Significance: The use of this specific, fundamental constant demonstrates a deep, low-level understanding of the EVM's architecture. It is a pattern indicative of expert-level development, characteristic of Ethereum's core contributors.

IV. Final Analysis & Significance

Disapprove Currency (Currency Coin) is a foundational artifact of the Ethereum ecosystem. Its historical and technical significance is established by its:

Deployment Date: The second-oldest known token, and the first to be directly linked to core development standardization efforts.
Unique Authorship & Provenance: The only on-chain token with source code verifiably authored by Vitalik Buterin. Its lineage from the Standardized_Contract_APIs to the final ERC-20 proposal is exhaustively documented.
Verifiable Uniqueness: The contract's deployed bytecode has no other matches on the blockchain, making it a unique on-chain object.
Direct & Documented Influence: It is not merely an inspiration for ERC-20; the evidence confirms its source repository as the official origin point for the standard.

V. Verifiable Primary Sources

All claims made in this document can be verified through the following primary sources.

Currency Coin on Etherscan The deployed contract, showing its code, creation date, and transaction history.
Vitalik Buterin's `currency.sol` on GitHub The original reference implementation file in the `dapp-bin` repository.
The Standardized Contract APIs Wiki (Cited in EIP-20) The specific version of the wiki page that is officially cited in the EIP-20 proposal as the "Original proposal from Vitalik Buterin."
The Official EIP-20 Proposal The final, accepted proposal for the ERC-20 Token Standard, which includes the historical reference to the standardized APIs.
The ERC System Proposal (EIPs GitHub Issue #16) The issue where Fabian Vogelsteller first proposes the ERC system and explicitly identifies the Standardized Contract APIs as the source for future standards.