ERC: 1067
Title: Token standard
Author: Techracers
Status: Draft
Type: ERC
Created: 5-08.2018
Recommended implementation: https://github.com/techracers-blockchain/ERC-1067
Abstract
Token contract usually have a monolithic design that is not friendly to upgrades. The following proposal describes a more distributed token contract architecture that has a simple upgrade-ability protocol and allows to bring in new functions after being deployed.
Motivation
There have been countless number of tokens where due to the inability to upgrade and fix bugs, contract holders have lost millions of dollars. A simple bug that might take days, months, or years to solve, can be solved simply and quickly using the ERC-1067 standard.
There exist approaches that includes an upgrade agent, which has its own limitations and restrictions and sometimes might not lead to a successful upgrade implementation. It has to include all token holders, and might cost a lot.
If there is a simple bug that was left out during the deployment of a token contract, it might result in the loss of millions of dollars. There have been a number of token contracts owners, who have come to us after the token sale with bugs that have no workaround but to cost a lot of time and money. If instead, we had an upgrade-ability protocol that allows rapid fast upgrades at low cost, such accidents can be rectified.
This will allow contracts to pause and handle bugs and allow them to fix bugs or upgrade the ERC standard to a newer one.
This standard has the ability to be cross compatible with any other monolithic ERC interface like the ERC20, ERC223, ERC721, ERC827 etc.
Specification
The following Upgradeable Token approach requires
- a DataCentre contract that has a few sets of getter setter methods that allows us to keep the data at a separate location
- that the token contract interacts with, reads and writes all the data into the DataCentre.
Methods
All of the ERC20 functions remain the same in essence. We interact with the DataCentre and write all the data into our DataCentre.
All the calls fetch data from the DataCentre, the supporting DataCentre function is written below each call-
totalSupply
Token-
function totalSupply() public constant returns (uint256) {
return DataCentre(dataCentreAddr).getValue("STK", "totalSupply");
}
DataCentre-
function getValue(bytes32 _container, bytes32 _key) public {
containers[_container].values[_key] = _value;
}
balanceOf(address)
Get the account balance of another account with address _owner
Token-
function balanceOf(address _owner) public constant returns (uint256) {
return DataCentre(dataCentreAddr).getBalanace("STK", _owner);
}
DataCentre-
function getBalance(bytes32 _container, address _key) public constant returns(uint256) {
return containers[_container].balances[_key];
}
transfer(address, uint)
Token-
function transfer(address to, uint value) public returns (bool) {
require(_to != address(this));
require(_to != address(0));
require(_amount > 0);
_setBalanceOf(_from, balanceOf(_from).sub(_amount));
_setBalanceOf(_to, balanceOf(_to).add(_amount));
Transfer(_from, _to, _amount);
return true;
}
Internal Function-
function _setBalanceOf(address _owner, uint256 _newValue) internal {
DataCentre(dataCentreAddr).setBalanace("STK", _owner, _newValue);
}
DataCentre-
function setBalance(bytes32 _container, address _key, uint256 _value) public onlyOwner {
containers[_container].balances[_key] = _value;
}
The owner of the DataCentre contract is always the Token contract.
Upgradeability Protocol
The token contract has some simple measures through which an upgrade can be made in just 2 transactions-
- Deploy new token contract
- Kill the old token contract.
The kill function looks like below-
function kill(address _newTokenContract) public onlyOwner {
if (dataCentreAddr != address(0)) {
Ownable(dataCentreAddr).transferOwnership(_newTokenContract);
}
selfdestruct(_newTokenContract);
}
Recommended implementation
This is highly recommended implementation of ERC-1067 token:
https://github.com/techracers-blockchain/ERC-1067
Abstract
Token contract usually have a monolithic design that is not friendly to upgrades. The following proposal describes a more distributed token contract architecture that has a simple upgrade-ability protocol and allows to bring in new functions after being deployed.
Motivation
There have been countless number of tokens where due to the inability to upgrade and fix bugs, contract holders have lost millions of dollars. A simple bug that might take days, months, or years to solve, can be solved simply and quickly using the ERC-1067 standard.
There exist approaches that includes an upgrade agent, which has its own limitations and restrictions and sometimes might not lead to a successful upgrade implementation. It has to include all token holders, and might cost a lot.
If there is a simple bug that was left out during the deployment of a token contract, it might result in the loss of millions of dollars. There have been a number of token contracts owners, who have come to us after the token sale with bugs that have no workaround but to cost a lot of time and money. If instead, we had an upgrade-ability protocol that allows rapid fast upgrades at low cost, such accidents can be rectified.
This will allow contracts to pause and handle bugs and allow them to fix bugs or upgrade the ERC standard to a newer one.
This standard has the ability to be cross compatible with any other monolithic ERC interface like the ERC20, ERC223, ERC721, ERC827 etc.
Specification
The following Upgradeable Token approach requires
Methods
All of the ERC20 functions remain the same in essence. We interact with the DataCentre and write all the data into our DataCentre.
All the calls fetch data from the DataCentre, the supporting DataCentre function is written below each call-
totalSupply
Token-
DataCentre-
balanceOf(address)
Get the account balance of another account with address _owner
Token-
DataCentre-
transfer(address, uint)
Token-
Internal Function-
DataCentre-
The owner of the DataCentre contract is always the Token contract.
Upgradeability Protocol
The token contract has some simple measures through which an upgrade can be made in just 2 transactions-
The kill function looks like below-
Recommended implementation
This is highly recommended implementation of ERC-1067 token:
https://github.com/techracers-blockchain/ERC-1067