Currency Coin Logo
CurrencyCoin

Technical Evidence & Analysis

Overview

CurrencyCoin, deployed at address 0x8494F777...4FD3, is a pivotal artifact in Ethereum's history. The underlying currency.sol code was authored and published by Vitalik Buterin on September 6, 2015, as part of the Standardized_Contract_APIs initiative—a foundational effort to create a standard interface for tokens. This contract was deployed to the Ethereum mainnet just two days later, on September 8, 2015, by an early developer known as 'rfikki'.

This document provides a comprehensive analysis of its history, a technical comparison of its code, and its significance as a direct precursor and inspiration to the ubiquitous ERC-20 token standard. CurrencyCoin is a true historic blockchain "collectible" based on its early timestamp.

Comparison

A Historic Collectible Digital Artifact

This document compares the currency.sol contract from the Ethereum dapp-bin repository (committed by Vitalik Buterin on September 6, 2015) with the currency contract deployed at 0x8494F777...4FD3 by rfikki on September 8, 2015. It highlights the absence of isApprovedOnceFor in the deployed contract, the presence of disapprove in both, and differences such as visibility modifiers. Both contracts were originally named currency, with CurrencyCoin as the deployed contracts modern wrapper name.

Historical Context: The Blueprint and the Artifact

In the pioneering days of September 2015, the Ethereum blockchain was a new frontier. The concept of a standardized token, which we now take for granted with ERC-20, did not exist. To spur development and discussion, Ethereum co-founder Vitalik Buterin authored currency.sol and committed it to the Ethereum Github public code repository called standardized_contract_apis on September 6, 2015. This was not a deployed contract; it was a proposal—a foundational piece of code, a Github commit by Vitalik Buterin shared with the world to serve as a basis for a common token interface. This specific commit contained the Disapprove function that makes Currency.sol deployment a unique artifact edged by its timestamp in Ethereum blockchain history.

Just two days later, on September 8, 2015, a developer known as Rocky Fikki (rfikki) took that exact blueprint, made a few small but significant changes, and deployed it to the live Ethereum network. This makes the "rfikki" contract the first known on-chain implementation of this specific token code with the Disapprove function and authored by Vitalik Buterin. It represents the immediate, tangible result of Buterin's proposal, transforming a theoretical concept into an immutable, functioning digital asset forever timestamped in Ethereum early blockchain history.

Side-by-Side Code Comparison (Proposal vs. Implementation)

The table below presents the full Solidity code for both contracts, aligned to show corresponding sections.

This comparison shows the evolution from the proposed code to the deployed contract.

LINKS FOR INDEPENDENT VERIFICATION

rfikki Deployed Code:

Vitalik Buterin Committed Code:

Please scroll horizontally to see the rest of the table.

Feature / FunctionVitalik Buterin's Proposal (Sep 06, 2015)Rocky Fikki's Deployed Contract (Sep 08, 2015)
Constructor (currency)function currency() { accounts[msg.sender].balance = 1000000; }function currency() { accounts[msg.sender].balance = 1000000000000; }
sendCoinfunction sendCoin(uint _value, address _to) returns (bool _success) { if (accounts[msg.sender].balance >= _value && _value < 340282366920938463463374607431768211456) { accounts[msg.sender].balance -= _value; accounts[_to].balance += _value; CoinSent(msg.sender, _value, _to); _success = true; } else _success = false; }function sendCoin(uint _value, address _to) returns (bool _success) { if (accounts[msg.sender].balance >= _value && _value < 340282366920938463463374607431768211456) { accounts[msg.sender].balance -= _value; accounts[_to].balance += _value; CoinSent(msg.sender, _value, _to); _success = true; } else _success = false; }
sendCoinFromfunction sendCoinFrom(address _from, uint _value, address _to) returns (bool _success) { uint auth = accounts[_from].withdrawers[msg.sender]; if (accounts[_from].balance >= _value && auth >= _value && _value < 340282366920938463463374607431768211456) { accounts[_from].withdrawers[msg.sender] -= _value; accounts[_from].balance -= _value; accounts[_to].balance += _value; CoinSent(_from, _value, _to); _success = true; } else _success = false; }function sendCoinFrom(address _from, uint _value, address _to) returns (bool _success) { uint auth = accounts[_from].withdrawers[msg.sender]; if (accounts[_from].balance >= _value && auth >= _value && _value < 340282366920938463463374607431768211456) { accounts[_from].withdrawers[msg.sender] -= _value; accounts[_from].balance -= _value; accounts[_to].balance += _value; CoinSent(_from, _value, _to); _success = true; } else _success = false; }
coinBalancefunction coinBalance() constant returns (uint _r) { _r = accounts[msg.sender].balance; }function coinBalance() constant returns (uint _r) { _r = accounts[msg.sender].balance; }
coinBalanceOffunction coinBalanceOf(address _addr) constant returns (uint _r) { _r = accounts[_addr].balance; }function coinBalanceOf(address _addr) constant returns (uint _r) { _r = accounts[_addr].balance; }
approvefunction approve(address _addr) { accounts[msg.sender].withdrawers[_addr] = 340282366920938463463374607431768211456; }function approve(address _addr) { accounts[msg.sender].withdrawers[_addr] = 340282366920938463463374607431768211456; }
isApprovedfunction isApproved(address _proxy) returns (bool _r) { _r = (accounts[msg.sender].withdrawers[_proxy] > 0); }function isApproved(address _proxy) returns (bool _r) { _r = (accounts[msg.sender].withdrawers[_proxy] > 0); }
approveOncefunction approveOnce(address _addr, uint256 _maxValue) { accounts[msg.sender].withdrawers[_addr] += _maxValue; }function approveOnce(address _addr, uint256 _maxValue) { accounts[msg.sender].withdrawers[_addr] += _maxValue; }
isApprovedOnceForfunction isApprovedOnceFor(address _target, address _proxy) returns (uint256 _r) { _r = accounts[_target].withdrawers[_proxy]; }Absent
disapprovefunction disapprove(address _addr) { accounts[msg.sender].withdrawers[_addr] = 0; }function disapprove(address _addr) { accounts[msg.sender].withdrawers[_addr] = 0; }

Summary of Similarities

Similarities:

The deployed contract is a near-perfect reflection of the proposed blueprint. It faithfully implements all the core logic for account structure, direct transfers (sendCoin), delegated transfers (sendCoinFrom), and the entire approval/disapproval mechanism that formed the basis for what would become the ERC-20 standard.

Summary of Differences

Differences:

The developer, Rocky Fikki, made two deliberate changes when bringing the theoretical code to life:

1. Modified the Supply

The initial supply was increased from the proposal's 1 million to 1 trillion tokens, a decision that drastically changed the economic scale of the asset, and a fitting supply for a token contract named currency.sol.

2. Removed a Function

The isApprovedOnceFor function was omitted. This removed a piece of the proposed transparency, preventing third parties from easily checking the specific allowance amounts between accounts. This may have been done for gas optimization, simplification, or other unknown reasons.

Historical Context

In September 2015, Ethereum's mainnet was six weeks old, and standardized token interfaces were critical. Vitalik's currency.sol proposed a template with experimental features like disapprove and isApprovedOnceFor. rfikki's deployed currency contract, two days later, adapted this template for mainnet use, streamlining the code for gas optimization and omitting isApprovedOnceFor. The deployed contract's modifications align it closer to the ERC-20 proposed standard (November 19, 2015), which adopted core functions but excluded disapprove and isApprovedOnceFor. The CurrencyCoin solidity code highlights this history.

Conclusion

The deployed currency contract at 0x8494F777...4FD3 closely mimics Vitalik's currency.sol, sharing core functions and logic, but omits isApprovedOnceFor.The relationship between these two pieces of Solidity code is a perfect illustration of the open-source, permissionless spirit of early Ethereum development collaboration. One provided the foundational idea, a gift to the nascent community. The other represents the community's immediate response: to build, to experiment, and to launch. Vitalik Buterin's currency.sol is the conceptual genesis of ERC20, while Rocky Fikki's deployed contract is its on-chain birth. Together, they tell a complete story: from a revolutionary idea proposed by a visionary founder to its immediate adoption and implementation by an early pioneer. These changes reflect a refined, mainnet-ready version, influencing the ERC-20 standard and Ethereum's token ecosystem from the early days. In short, we have a true historic blockchain collectible!!!

Significance

Historical Significance & Ranking

Context in the Pre-ERC20 Era

Deployed on September 8, 2015, Currency.sol emerged in an era of experimentation, just 40 days after Ethereum's launch. Before the formal ERC-20 standard, every token was a custom implementation. This contract is significant because it wasn't an isolated experiment; it was a public test of the concepts being developed in the official Standardized_Contract_APIs repository, directly influencing the future of all tokens on Ethereum.

Uniqueness and Historic Collectability

  • Deployment Rank: 1,066th known contract deployed to Ethereum. 75th known coin contract deployed to Ethereum. First coin contract derived from the original Standardized_Contract_API files for standard currency with a Disapprove function.
  • Authorship: The only known token on Ethereum with source code verifiably authored by Vitalik Buterin via Github that was deployed to Ethereum mainnet in 2015.
  • Bytecode Uniqueness: A cryptographic diff of the blockchain confirms its deployed bytecode is unique. There are zero other contracts according to Etherscan with exact matching code, establishing it as a singular, non-replicated digital artifact.
  • Influence: As a live implementation of the code in dapp-bin, it served as a proof-of-concept that directly informed the most important token standard in the world, the ERC20.

Conclusion: CurrencyCoin was verifiable used as the most technical significant inspiration to the ERC20 standard due to its unparalleled provenance, direct link to Ethereum's core development, direct link via citation to and from the original ERC20 proposal, and unique authorship by Vitalik Buterin at the inception of the Ethereum platform.

Background: Serpent

Vitalik Buterin created the Serpent programming language and its compiler for usage in writing smart contracts on Ethereum many months before the Frontier launch on July 30th, 2015. There were several iterations and updates to the Serpent language.

Serpent is a programming language inspired by Python. Like Python, it has a simple, minimal syntax, dynamic typing, and support for object-oriented programming.

While Serpent was one of the early programming languages available for writing Ethereum smart contracts, it was eventually superseded by Solidity, which was designed by Gavin Wood and developed by a team at the Ethereum project.

Solidity is an object-oriented, high-level language for implementing smart contracts. Smart contracts are programs that govern the behavior of accounts within the Ethereum state. Solidity is a curly-bracket language designed to target the Ethereum Virtual Machine (EVM). It is influenced by C++, Python, and JavaScript.

There are several challenges. First of all, existing c++ and other compilers tend to output code that is really not optimized for compact code size; eg. even the simplest program outputs a file that is longer than 4kb. This is ok for computers, where storage is cheap, but terrible for blockchains, where storage is expensive. So specialized compilers are required. Second, EVM smart contract languages need to be designed with a particularly strong focus on security, which is not something that most existing languages care about to the same extent.

Informational links:

Serpent is an assembly language that compiles to EVM code that is extended with various high-level features. It can be useful for writing code that requires low-level opcode manipulation as well as access to high-level primitives like the ABI.

  • http://mc2-umd.github.io/ethereumlab/doc...
  • Being a low-level language, Serpent is NOT RECOMMENDED for building applications unless you really really know what you're doing. The creator recommends Solidity as a default choice, LLL if you want close-to-the-metal optimizations, or Viper if you like its features though it is still experimental.
  • Important note: Gavin Wood was the initial creator of Solidity.
  • On Jun 17, 2015, Standardized_Contract_APIs are created by Vitalik Buterin as a sub-directory of the Ethereum Github Dapp-bin.
  • Here is a saved fork of the WIKI, it was archived by Ethereum but here is a saved fork by: https://github.com/rfikki/wiki-1/commit/748c9b0a7f459ed5754420b6368bdd536bc4bdc4

Ethereum Wiki changes

(kind of like a readme history of changes: relative to currency, unapprove, disapprove:

The Actual Standardized Contracts APIs code:

July 30th, 2015, Ethereum mainnet was launched (The Frontier).

  • Sep 06, 2015 The Actual Standardized Contracts API official directory, thus not the wiki, Vitalik moves the Serpent/Solidity code he proposes for discussion into the Ethereum Standardized_Contract_APIs directory this change includes the code for currency.sol, and includes the disapprove function again. Not the unapprove function.

  • Sep 08, 2015 our currency contract is deployed by rfikki.

  • Between Sep 06, 2015 up to when ERC20 was finalized several years later there were many discussions as to how to improve/set the standard.

  • Nov 03, 2015 - Mistcoin is deployed as an enhancement/part of the Mist browser.

    • Important note Mistcoin was not referenced in proposed or finalized ERC20, Mistcoin was not an integral part of the ERC20 standard discussions as can be seen in the various links provided in this document.
    • Mistcoin is an important later prototype as an intermediate step towards the ERC20 standard and was solely created within the Mist browser as a test token on an early style token launchpad so that Ethereum users/developers could deploy basic tokens independently in a user friendly interface. It is a large part of the Ethereum token history, but it is not what the ERC20 token Standard was based on.
    • Mistcoin did not exist during the early ERC20 token standard discussions Jun 2015 - Oct 2015. Which is when most of the early refinements were made.

  • Nov 19, 2015 The ERC20 standard was proposed.

  • Sep 2017 - The ERC20 standard was finalized.

  • As late as Nov 07, 2016 Vitalik still used the word Disapprove in his other code files see the bottom of this Standardized Contract API’s crowdfund file: https://github.com/ethereum/dapp-bin/commit/183f820e18fad173d92142e63c80bd7747225058

  • An important note, is in the various differing Standardized_Contract_APIs code such as, order, exchange, crowdfund, namereg. Vitalik Buterin continually used the word currency in his code.

The EIP 20 Ethereum Improvement Proposal discussion references and states that ERC20 is a resolution of the Standardized_Contract_APIs code this is very important, see https://github.com/ethereum/EIPs/issues/20

Also see this historical reference as part of ERC20 - https://eips.ethereum.org/EIPS/eip-20#history

Sources

Verifiable Primary Sources

Explore the Complete Story

Now that you've seen the technical evidence, explore the complete chronological timeline of events.

View Historical Timeline