Currency Coin Logo
CurrencyCoin

Technical Evidence & Analysis

Overview

CurrencyCoin, deployed at address 0x8494F777...4FD3, was built using a modified version of the code that was part of the 2015 Ethereum Github, the Standardized_Contracts_API's directory and its code played a pivotal role in Ethereum's token standardization history. The underlying currency.sol code was committed 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. The rfikki contract was deployed to the Ethereum mainnet just two days later, on September 8, 2015. rfikki was a very active Ethereum community member.

This document provides a comprehensive analysis of the currency.sol code history, a technical comparison of its code, and its historic significance and citation as the "resolution of the ERC-20 Standard". CurrencyCoin is based on code that was proposed for discussion towards the token standard, it is a true historic blockchain "collectible" based on its early timestamp.

Comparison

A Historic Collectible Digital Artifact - based on its use of much of the currency.sol Vitalik code and its early timestamp

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 Vitalik Blueprint and the early deployment timestamp

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 yet. 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_Contracts_API's on September 6, 2015. This was not a deployed contract; it was a foundational piece of early token code, a Github commit by Vitalik Buterin shared with the world, which served as a early repository used for debate as a common token interface. This specific commit contained the Disapprove function as well as other unique attributes 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 rfikki's deployed contract.

LINKS FOR INDEPENDENT VERIFICATION

rfikki's Deployed Code:

Vitalik Buterin's 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 Github commit offered to formalize the future concepts that were 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 known deployment of the currency.sol contract from the original Standardized_Contract_API files with a Disapprove function.
  • Authorship: Currently the only etherscan verified token on Ethereum based on the currency.sol source code committed by Vitalik Buterin on Sep 06, 2015 via Github that was deployed to Ethereum mainnet.
  • Bytecode Uniqueness: Etherscan.io contract search suggests the bytecode is unique. There are zero other contracts according to Etherscan with "EXACT" matching code, establishing it as a singular, non-replicated digital token based on the source code.
  • Influence: As a live implementation of a slightly modified version of the code in dapp-bin, the tokens code served as a proof-of-concept that directly informed the most important token standard in the world, the ERC-20.

Conclusion: the Vitalik currrency.sol code that CurrencyCoin was built on, was the most technically significant inspiration to the ERC-20 standard due to its unparalleled provenance, direct link to Ethereum's core development in 2015, direct link via citation to and from the original ERC-20 proposal, and linkage to Vitalik Buterin at just weeks after 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.

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 a prototype token as part of the Mist browser.

    • Mistcoin is a prototype ERC20 token created via the Mist browser - a model token on an early launchpad, allowing Ethereum users/developers to deploy basic tokens independently in a user friendly interface.
    • Although it was the Standardized_Contracts_API's Currency.sol that was an integral part of the ERC20 token standard discussions - when most early refinements were made - Mistcoin is a large part of Ethereum token history.
    • Mistcoin can be seen as a prototype towards mass adoption in the Ethereum early days. It is a true historic collectible token.
    • Important note: Mistcoin, an Ethereum token prototype deployed before the ERC-20 token standard was proposed, was wrapped as an ERC-20 token, Wrapped MistCoin (WMC), to make it compatible with the current ERC20 final standard.
    • Important note: CurrencyCoin, an Ethereum token prototype deployed before the ERC-20 token standard was proposed, was wrapped as an ERC-20 token, Wrapped CurrencyCoin (CC), to make it compatible with the current ERC20 final standard.

  • 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/com...

  • 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