1

I believe that the openzeppelin project have updated their StandardToken smart contract which is now called ERC20.sol.

One issue that I have is that the new smart contract has some missing functionalities that we previously had. In the past, when you imported StandardToken into your smart contract, you would be able to initialize your Token like that:

pragma solidity ^0.4.19;  

import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC20/ERC20.sol";
import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/ownership/Ownable.sol";

/**  
 * @title ExampleToken is a basic ERC20 
 */  
contract ExampleToken is ERC20, Ownable {  
    uint256 public totalSupply;  
    string public name;  
    string public symbol;  
    uint32 public decimals;  

    /**  
     * @dev assign totalSupply to owner of contract
     */  
    constructor() public {  
        symbol = "EXM";  
        name = "ExampleCoin";  
        decimals = 4;  
        totalSupply = 10000000000;  

        owner = msg.sender;  
        balances[msg.sender] = totalSupply;  

        emit Transfer(0x0, msg.sender, totalSupply);  
    }
}

Because I am using the new smart contract, I can't do this anymore:

balances[msg.sender] = totalSupply;  

because I am getting the error since openzeppelin has not implemented it:

DeclarationError: Undeclared identifier. Did you mean "balanceOf"?

balanceOf is obviously not suitable since this is a function returning the balance at a given address.

What's the most suitable way to initialize the balance?

Is it better to send it to owner's address or just leave it in the smart contract? Is there a risk for leaving the balance inside the smart contract and is this procedure widely used?

If I shouldn't leave it in the smart contract, then what's the best way to give the total supply to the contract creator?

Alternatively, is it possible to import previous openzeppelin smart contracts when StandardToken existed?

1

If I'm not mistaken, you would use the ERC20Capped.sol and mint() tokens as a second step in the migration/deployment process.

This seems sensible to me as a mintable token can do everything a non-mintable token could do. The "capped" variant puts a limit on minted supply and seems like the replacement for the old style that initialized the supply and minter balance in the constructor.

https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC20/ERC20Capped.sol

Hope it helps.

  • Your answer has determined the basics that enabled me to implement it! I used ERC20Detailed rather than ERC20Capped and it's doing its job very well. If you have anything to add or objectify to my implementation, your feedback is always well received. – Cristian Jan 11 at 20:05
0

As Rob has recommended, I should be using mint for the initial supply. I used ERC20Detailedtoken rather than ER20Capped.

First, import ERC20Detailedtoken which I recommend to check. From the previous code, my implementation becomes as following:

pragma solidity ^0.4.19;  

import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC20/ERC20.sol";
import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/ownership/Ownable.sol";
import "http://github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC20/ERC20Detailed.sol";

  /**  
  * @title ExampleToken is basic ERC20 Token  
  */  
contract ExampleToken is ERC20, ERC20Detailed, Ownable{  

  uint256 public initialSupply  = 100000000000; 
  string public name;  
  string public symbol;  
  uint32 public decimals;  

  /**  
  * @dev assign totalSupply to account creating this contract 
  */  
  constructor() public ERC20Detailed("ExampleCoin", "EXM", 4) {  

   _mint(msg.sender, initialSupply);

 }}

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.