contract UnixERC20 is StandardToken {
    function() {

    string public name;
    uint8 public decimals;
    string public symbol;
    string public version = 'H1.0';

    function UnixERC20() {
        balances[msg.sender] = 5500000000;
        totalSupply = 5500000000;
        name = "UNIWORTH COIN";
        decimals = 0;
        symbol = "UNIX";

    function approveAndCall(address _spender, uint256 _value, bytes _extraData) returns (bool success) {
        allowed[msg.sender][_spender] = _value;
        Approval(msg.sender, _spender, _value);

        if (!_spender.call(bytes4(bytes32(sha3("receiveApproval(address,uint256,address,bytes)"))), msg.sender, _value, this, _extraData)) { 
        return true;

Why is the totalSupply initialised to 5500000000, and is there any reason to predefine this value? How is the UNIX token different or unique from other tokens?


The value of totalSupply is simply chosen by the deployer on the basis of general consideration about scarcity (in theory if there they exist few tokens they are more precious), distribution (in theory more token involve more buyer and this create a market), market forecast (in theory if you can foresee the market, you can understand what is the right number), illusion (in theory if you think your token shall appreciate up to one dollar or whatever, if you have more tokens you have more market cap, I.e. value) and so on.

The token you are asking for is a simple erc20 token derived from a tutorial and deployed, absolutely not reccomandable because affected by a reentrancy attack possibility at least in the transferFrom method:

if (balances[_from] >= _value && allowed[_from][msg.sender] >= _value && _value > 0) {

        balances[_to] += _value; <—- // attack!!!

        balances[_from] -= _value;
        allowed[_from][msg.sender] -= _value;
        Transfer(_from, _to, _value);

As you may notice, they increment the _to balance before decrement the _ from balance, so if you attack the code here using repeated call in reentrancy, you can create tokens because the double spending shields is broken (in practice you obtain to repeatedly sum tokens in the _to balance without taking them out from the _from balance).

So it is to be considered a simple exercise made by someone, to be abandoned as soon as possible.

  • You are welcome – Rick Park Jan 1 at 9:29
  • Thank you... @Rick Park for well understandable answer. It will help me more if you give some detail about how to fix this reentrancy attack by making modification in above given code. I've previously referred some audit reports of ERC20 tokens, there they've mentioned Reentrancy attack, but still I have difficulty to understand that how do I fix Reentrancy. – Rudrika Jan 1 at 9:34
  • 1
    Simply move “balances[_from] -= _value;” BEFORE “balances[_to] += _value;” and this kind of attack is impossible. Any repeated execution of the code repeatedly decreases the _from balance, even when “interrupted” by the reentrancy, before to increase the _to balance. So nobody can increase repeatedly without decrease. – Rick Park Jan 1 at 9:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.