Why ERC20 Tokens can do Everything (using Mutation)

ERC20 tokens have special properties that put them a few steps ahead of traditional cryptocurrency coins and they have Ethereum to thank for that. They have powerful security against double spending. They do not need to inflate to reward network participants. They work with one another and with arbitrary smart contracts on Ethereum, new and old. They have permanent rules that are transparent and unable to be changed. However, most people do not know or take advantage of that fact that ERC20 tokens are also ‘upgradeable’.

All ERC20 tokens are upgradeable. Trustlessly and permissionlessly upgradeable. How is this possible when the solidity code of the token contract can never be changed? Allow me to explain:

Imagine there is a token that implements the ERC20 specification and its name is ‘eToken’. A secondary ERC20 token smart contract can be created (we will call it ‘sToken’) which starts with a supply of 0. This sToken contract follows the ERC20 base standard and has two additional methods, DepositTokens and WithdrawTokens:

function depositTokens(address from, uint amount) public returns (bool) {

require( amount > 0 );

require( ERC20( originaltoken ).transferFrom( from, this, amount) ); balances[from] = balances[from].add(amount);

_totalSupply = _totalSupply.add(amount); return true;

}

function withdrawTokens( uint amount) public returns (bool) {

address from = msg.sender;

require( amount > 0 );

balances[from] = balances[from].sub(amount);

_totalSupply = _totalSupply.sub(amount);

require( ERC20( originaltoken ).transfer( from, amount) ); return true;

}

The deposit method allows a user to lock up X eTokens inside of this sToken contract and then that user will instantly receive X newly-minted sTokens. The withdraw method allows anyone to burn X sTokens and then the sToken contract will instantly send them X eTokens which had been locked up inside of it previously.

The secondary tokens, sTokens, can be traded and used on Ethereum as ERC20 tokens and they are pegged 1:1 to the eTokens because anyone can redeem eTokens by burning the sTokens by using that withdrawTokens method. This is amazing because more solidity code and more methods can be added to the sToken contract in order to imbue sTokens with any arbitrary new properties and rules. I call this ‘Token Mutation”.

The real power of this is evident because a third (or fourth or fifth..) new method could be added to the sToken contract called, for example, transferFromWithSignature() which allows anyone to send the sTokens on behalf of the true owner as long as they have a personalSignature from that owner which allowed the transfer. Or, a method called transferFromUsingZKSnarks() could be added to allow for anonymous or optimistic roll up type transactions. And on and on…

If that were done, then anyone with eTokens could seamlessly and permissionlessly redeem them for sTokens, use them with these new methods, and then they or anyone else can redeem the sTokens back into eTokens. Trustlessly. This means that, effectively, arbitrary code was added to the eToken. Therefore, ERC20 tokens like 0xBTC can be upgraded in this way to absorb all new ERC20 token technologies. Traditional non-ERC20 coins cannot do this because they are not smart-contract based and not within Ethereum!

As new ERC20 technologies are invented in the future which require new solidity methods to use, existing ERC20 tokens can use these technologies by employing this Token Mutation strategy. There is no need to invent brand new tokens with new supplies just to integrate those technologies because 1:1 atomic swap ‘Mutation’ contracts can be deployed like this in order to ‘upgrade’ the capabilities of existing ERC20 tokens.

Here is an example of a 1:1 Mutation Token contract for 0xBTC: