Best practices to store ERC-20 token | Contract vs. Account

General
1

What are the general best practices around storing newly minted ERC-20 tokens?

Do you store them in the Token Contract or Treasure Account?

Using oz SDK and one of the Initialize functions w/in

Here is a code snippet from a flattened verified contract.

/**
 * @title Standard ERC20 token, with minting and pause functionality.
 *
 */
contract StandaloneERC20 is Initializable, ERC20Detailed, ERC20Mintable, ERC20Pausable {
    function initialize(
        string memory name, string memory symbol, uint8 decimals, uint256 initialSupply, address initialHolder,
        address[] memory minters, address[] memory pausers
    ) public initializer {
        ERC20Detailed.initialize(name, symbol, decimals);

        // Mint the initial supply
        _mint(initialHolder, initialSupply);

        // Initialize the minter and pauser roles, and renounce them
        ERC20Mintable.initialize(address(this));
        _removeMinter(address(this));

        ERC20Pausable.initialize(address(this));
        _removePauser(address(this));

        // Add the requested minters and pausers (this can be done after renouncing since
        // these are the internal calls)
        for (uint256 i = 0; i < minters.length; ++i) {
            _addMinter(minters[i]);
        }

        for (uint256 i = 0; i < pausers.length; ++i) {
            _addPauser(pausers[i]);
        }
    }
1 Like
2

Hi @pkr,

I assume it depends on what the tokens are being used for and the amount of tokens.

  • If they are being issued to a user and they potentially have value, then some form of hardware wallet or a multi-signature wallet.
  • If the tokens are being locked for a user for a period of time, then TokenTimelock or TokenVesting
  • If the tokens are being sold, then transfer to the Crowdsale contract (see Crowdsales documentation).

Also interested to see thoughts from the community.
Tagging @itinance in case they would like to share their thoughts.

With an upgradeable contract, also need to consider the upgrades governance, see Upgrades governance documentation for an example using a multi-sig wallet.

3

Hi @pkr,

Did the above answer your question? Feel free to ask more questions.

1 Like
4

Hi @abcoathup

Thanks for these links…am going through them today.

These are currently planned to be security tokens issued every time a physical asset is digitised/tokenised.

Yes they do have to adhere to appropriate jurisdiction guidance and will be time-locked for a duration.

Most likely we will use a 3rd party custodial services for the token holders, until such time the investors want to do something with their holdings.

Keen to find out if anyone else going through similar requirements, and if so, how are you using oz SDK |or| building everything custom?

1 Like