Pluton (PLU), 20 million units at 8 decimals, deployed 26 June 2016.
Historical Significance
Pluton follows the ConsenSys HumanStandardToken layout, which adds name, symbol, decimals and a version string on top of the bare allowance based standard. The deployer minted 2,000,000,000,000,000 base units against 8 decimals for a fixed 20 million PLU, all credited to the creating account. There is no mint and no burn path, so that opening figure is the permanent supply. It also carries approveAndCall for spenders that need to react in the approving transaction.
Context
Deployed in the weeks between the DAO exploit and the hard fork that reversed it.
Token Information
Key Facts
Description
A token from the ethereum.org tutorial. Balances sit in a public balanceOf mapping and transfer(to, value) moves them, throwing rather than returning false when the sender is short and checking the recipient's balance for overflow before adding to it. An allowance mapping lets a holder authorise another address to spend a limited amount through transferFrom. ApproveAndCall sets the allowance and calls receiveApproval on the spender in the same transaction, so a spending contract learns of its allowance at the moment it is granted. There is no owner and no way to create further units: the supply written at deployment is the whole supply. It was deployed as Pluton, with the symbol PLU and an opening supply of 2,000,000,000,000,000 base units at 8 decimal places.
Source Verified
Exact runtime + creation bytecode match. Runtime 1799 bytes, creation 2424 bytes plus 256 bytes of ABI encoded constructor arguments. Compiled with soljson-v0.3.2+commit.81ae2a78, optimizer ON.
Historian Categories
Heuristic Analysis
The following characteristics were detected through bytecode analysis and may not be accurate.
Homestead Era
The first planned hard fork. Removed the canary contract, adjusted gas costs.
Bytecode Overview
Verified Source Available
Source verified through compiler archaeology and exact bytecode matching.
View Verification ProofShow source code (Solidity)
// ---- Token_Contracts/contracts/Token.sol @ Consensys/Tokens@884080acfe ----
contract Token {
/// @return total amount of tokens
function totalSupply() constant returns (uint256 supply) {}
/// @param _owner The address from which the balance will be retrieved
/// @return The balance
function balanceOf(address _owner) constant returns (uint256 balance) {}
/// @notice send `_value` token to `_to` from `msg.sender`
/// @param _to The address of the recipient
/// @param _value The amount of token to be transferred
/// @return Whether the transfer was successful or not
function transfer(address _to, uint256 _value) returns (bool success) {}
/// @notice send `_value` token to `_to` from `_from` on the condition it is approved by `_from`
/// @param _from The address of the sender
/// @param _to The address of the recipient
/// @param _value The amount of token to be transferred
/// @return Whether the transfer was successful or not
function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {}
/// @notice `msg.sender` approves `_addr` to spend `_value` tokens
/// @param _spender The address of the account able to transfer the tokens
/// @param _value The amount of wei to be approved for transfer
/// @return Whether the approval was successful or not
function approve(address _spender, uint256 _value) returns (bool success) {}
/// @param _owner The address of the account owning tokens
/// @param _spender The address of the account able to transfer the tokens
/// @return Amount of remaining tokens allowed to spent
function allowance(address _owner, address _spender) constant returns (uint256 remaining) {}
event Transfer(address indexed _from, address indexed _to, uint256 _value);
event Approval(address indexed _owner, address indexed _spender, uint256 _value);
}
// ---- Token_Contracts/contracts/StandardToken.sol @ Consensys/Tokens@884080acfe ----
/*
This implements ONLY the standard functions and NOTHING else.
For a token like you would want to deploy in something like Mist, see HumanStandardToken.sol.
If you deploy this, you won't have anything useful.
Implements ERC 20 Token standard: https://github.com/ethereum/EIPs/issues/20
.*/
contract StandardToken is Token {
function transfer(address _to, uint256 _value) returns (bool success) {
//Default assumes totalSupply can't be over max (2^256 - 1).
//If your token leaves out totalSupply and can issue more tokens as time goes on, you need to check if it doesn't wrap.
//Replace the if with this one instead.
//if (balances[msg.sender] >= _value && balances[_to] + _value > balances[_to]) {
if (balances[msg.sender] >= _value && _value > 0) {
balances[msg.sender] -= _value;
balances[_to] += _value;
Transfer(msg.sender, _to, _value);
return true;
} else { return false; }
}
function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {
//same as above. Replace this line with the following if you want to protect against wrapping uints.
//if (balances[_from] >= _value && allowed[_from][msg.sender] >= _value && balances[_to] + _value > balances[_to]) {
if (balances[_from] >= _value && allowed[_from][msg.sender] >= _value && _value > 0) {
balances[_to] += _value;
balances[_from] -= _value;
allowed[_from][msg.sender] -= _value;
Transfer(_from, _to, _value);
return true;
} else { return false; }
}
function balanceOf(address _owner) constant returns (uint256 balance) {
return balances[_owner];
}
function approve(address _spender, uint256 _value) returns (bool success) {
allowed[msg.sender][_spender] = _value;
Approval(msg.sender, _spender, _value);
return true;
}
function allowance(address _owner, address _spender) constant returns (uint256 remaining) {
return allowed[_owner][_spender];
}
mapping (address => uint256) balances;
mapping (address => mapping (address => uint256)) allowed;
uint256 public totalSupply;
}
// ---- Token_Contracts/contracts/HumanStandardToken.sol @ Consensys/Tokens@884080acfe ----
/*
This Token Contract implements the standard token functionality (https://github.com/ethereum/EIPs/issues/20) as well as the following OPTIONAL extras intended for use by humans.
In other words. This is intended for deployment in something like a Token Factory or Mist wallet, and then used by humans.
Imagine coins, currencies, shares, voting weight, etc.
Machine-based, rapid creation of many tokens would not necessarily need these extra features or will be minted in other manners.
1) Initial Finite Supply (upon creation one specifies how much is minted).
2) In the absence of a token registry: Optional Decimal, Symbol & Name.
3) Optional approveAndCall() functionality to notify a contract if an approval() has occurred.
.*/
contract HumanStandardToken is StandardToken {
function () {
//if ether is sent to this address, send it back.
throw;
}
/* Public variables of the token */
/*
NOTE:
The following variables are OPTIONAL vanities. One does not have to include them.
They allow one to customise the token contract & in no way influences the core functionality.
Some wallets/interfaces might not even bother to look at this information.
*/
string public name; //fancy name: eg Simon Bucks
uint8 public decimals; //How many decimals to show. ie. There could 1000 base units with 3 decimals. Meaning 0.980 SBX = 980 base units. It's like comparing 1 wei to 1 ether.
string public symbol; //An identifier: eg SBX
string public version = 'H0.1'; //human 0.1 standard. Just an arbitrary versioning scheme.
function HumanStandardToken(
uint256 _initialAmount,
string _tokenName,
uint8 _decimalUnits,
string _tokenSymbol
) {
balances[msg.sender] = _initialAmount; // Give the creator all initial tokens
totalSupply = _initialAmount; // Update total supply
name = _tokenName; // Set the name for display purposes
decimals = _decimalUnits; // Amount of decimals for display purposes
symbol = _tokenSymbol; // Set the symbol for display purposes
}
/* Approves and then calls the receiving contract */
function approveAndCall(address _spender, uint256 _value, bytes _extraData) returns (bool success) {
allowed[msg.sender][_spender] = _value;
Approval(msg.sender, _spender, _value);
//call the receiveApproval function on the contract you want to be notified. This crafts the function signature manually so one doesn't have to include a contract in here just for this.
//receiveApproval(address _from, uint256 _value, address _tokenContract, bytes _extraData)
//it is assumed that when does this that the call *should* succeed, otherwise one would use vanilla approve instead.
if(!_spender.call(bytes4(bytes32(sha3("receiveApproval(address,uint256,address,bytes)"))), msg.sender, _value, this, _extraData)) { throw; }
return true;
}
}External Links
Related contracts
token
Same eraBare Homestead-era token (Mar 14 2016): public balanceOf mapping + a single unchecked transfer firing the standard Transfer event.
0xc77f06...494c69March 14, 2016DinastyCoinToken
Same eraHomestead-era transfer-only token, DinastyCoinToken (DCT), fixed supply 200000000 and 6 decimals.
0x3693fd...c11466March 14, 2016token
Same eraMinimal Homestead-era token shell (Mar 14 2016): just a public balanceOf mapping and its compiler-generated getter, with no other functions.
0x38e1da...41a81aMarch 14, 2016sultancoin
Same eraA fixed-supply token with direct transfers only, deployed March 2016.
0x9a11ff...0b797dMarch 15, 2016666๐
Same eraSix hundred and sixty six units, named and ticketed with a ram emoji.
0x7684aa...d0ed06March 16, 2016CampusCoin
Same eraByte-identical deployment of: Standard ethereum.org tutorial token (Homestead, Mar 2016): name/symbol/decimals metadata, a public balanceOf mapping and an overf
0x00f0b1...e6fcd2March 16, 2016