Extending StandaloneERC20 contract

Archive SDK
1

Hey friends, I’m having trouble extending the StandaloneErc20 contract. Probably some dumb semantic thing I’m missing

contract HelbizToken is StandaloneERC20 {
  function initialize(address[] memory _minters, address[] memory _pausers) public initializer {
    //StandaloneERC20.initialize("Helbiz Token", "HBZ", uint8(18), _minters, _pausers);
    string memory sig = "initialize(string,string,uint8,address[],address[])";
    address(this).delegatecall(abi.encodeWithSignature(sig, "Helbiz Token", "HBZ", uint8(18), _minters, _pausers));
  }
}

Is delegatecall the appropriate thing to use, given the proxy contract? Because doing StandaloneERC20.initialize raises an error due to the overloaded function…
@spalladino :slight_smile:

2

Hey @imthatcarlos! You should not need to run any manual delegatecalls if you are extending the contract. You should just call into the parent’s initialize function regularly, as in the line you have commented out:

StandaloneERC20.initialize("Helbiz Token", "HBZ", uint8(18), _minters, _pausers);

Keep in mind though that if you extend StandaloneERC20 you will no longer be able to use the version pre-deployed in openzeppelin-eth, but you will need to deploy your own logic contract. There are no issues with this of course, except for the additional gas cost for the deployment.

3

Got it! But the contract won’t compile cause of the overloaded function… am I missing something?

/Users/carlos/Desktop/helbiz/babylon/contracts/HelbizToken.sol:14:5: TypeError: Wrong argument count for function call: 5 arguments given but expected 7.
    StandaloneERC20.initialize("Helbiz Token", "HBZ", uint8(18), _minters, _pausers);
    ^------------------------------------------------------------------------------^
4

Apparently, you have just stumbled upon a bug in Solidity: https://github.com/ethereum/solidity/issues/6497.

My suggestion would be to try and use the version with 7 args instead:

StandaloneERC20.initialize("Helbiz Token", "HBZ", uint8(18), 0, address(1), _minters, _pausers);

(Edit: Using address(1) instead of address(0). See the comments below.)

5

Oh wow! Glad to know I wasn’t being dumb :sweat_smile:

One issue with doing that is the StandaloneERC20 contract attempts to mint here even though there’s a guard against address(0) in _mint() in the base contract.

Honestly for my purposes, I’ll just comment the version with 7 args. Just wanted to be sure I was doing things properly! Thanks for looking into it

6

True. It's ugly but you can use address(1) in place of it. As long as intialSupply is 0 it probably doesn't matter.

1 Like
7

Btw, what was the reason to give it the name “StandaloneERC20”?

1 Like
8

I had a look through the Pull request:

Whilst it shows some of the earlier names, I didn’t see how they ended up as Standalone*. @nventuro can you advise?

9

The reasoning behind the name is that it's a full fledged token, already deployed, that you can just link against and create new instances of. It combines ERC20Detailed, Mintable and Pausable, though you can easily opt-out of minting and pausing by passing an empty array.

Without standalone, you have to develop your token yourself (i.e. inherit from ERC20 and whichever extensions you need), push it, and only then create instances. If all you need is a regular token, Standalone does the job.

2 Likes