I've started learning ERC-20 from a tutorial in which the totalSupply parameter was used to limit the number of tokens to be created. Now I've started working on the ERC-1400 token (specifically the ConsenSys's implementation). In there the _totalSupply parameter is private and works described as in the OpenZeppelin's Fixed Supply' title here. But from what I understand this doesn't stop the contract owner from minting as many tokens as he/she wants and flooding the market. So,

  1. Should I go in and edit the private _totalSupply parameter to have a fixed amount of tokens in order to create a more secure token?
  2. Am I right? If I apply 1, would that make it more secure?
  3. Is there any other way to limit the maximum number of tokens that can exist at any time (in ERC-20 or ERC-1400)?

1 Answer 1


_totalSupply is internal (see https://github.com/ConsenSys/UniversalToken/blob/master/contracts/ERC1400.sol#L49), so you can access it in a contract that extends the ERC1400 implementation.

The contract has a method isIssuable which return the state of _isIssuable. If that is set to false (either in a custom constructor or by calling renounceIssuance) not more tokens can be created.

What you can do is in the token of your contract that extends ERC1400 you issue the tokens that should available to a wallet that you control and then you disable the possibility to issue more tokens, then your supply is fixed.

Another way is to overwrite the _issue function to perform a check before issuing more tokens. E.g that _totalSupply is below a specific limit, or that this can only be called at specific time frames.

The general question if you should have a fixed supply or not is very opinion based and depends very heavily on your use case. There are also many "in-between" models: maximum supply (so not fixed, but capped) or fixed inflationary supply (so every x days, y tokens can be minted). So I do not think that there is the general "you should have ... supply".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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