ERC-20 Mint Module

ERC20Storage​

This module declares only the two fields it uses. The allowance mapping that other ERC-20 contracts declare is absent.

/** @custom:storage-location erc8042:erc20 */
struct ERC20Storage {
  mapping(address owner => uint256 balance) balanceOf;
  uint256 totalSupply;
}

Functions​

getStorage​

Returns a pointer to the ERC20Storage struct.

Because this module's struct has no allowance field, the returned pointer cannot reach allowances. If your facet needs to inspect one, import a module that declares the full struct, such as ERC20TransferMod or ERC20ApproveMod.

function getStorage() pure returns (ERC20Storage storage s);

Returns:

mint​

Creates _value new tokens, credits them to _account, and increases the total supply by the same amount.

No permission is checked. Gate this behind your own authorization. Minting 0 is allowed and still emits Transfer.

function mint(address _account, uint256 _value);

Parameters:

Reverts:

Events​

Transfer

event Transfer(address indexed _from, address indexed _to, uint256 _value);

Errors​

ERC20InvalidReceiver

Thrown when _account is the zero address. Without this guard the mint would emit Transfer(address(0), address(0), _value), indistinguishable from a burn to any indexer that keys off _to == address(0), and would credit a balance nobody can ever spend.

Signature:

error ERC20InvalidReceiver(address _receiver);

Best Practices​

• Wrap mint in an external function that checks permission first, for example an owner guard or a role check. Without one, any caller reaching your facet can inflate the supply.
• Decide on a supply policy before deploying. Nothing here enforces a cap, so if you need one, check it in your facet before calling.
• Mint during initialization if you want a fixed supply. Call mint from your diamond constructor and never expose an external mint path at all.
• Keep balanceOf and totalSupply in step. If you ever write balances directly, adjust the supply to match, or the unchecked subtractions in ERC20BurnMod can underflow later.
• Keep the same STORAGE_POSITION and field order as the other ERC-20 contracts. Do not introduce a second balance mapping.

Integration Notes​

Import the module under a namespace and call it from your facet:

import "src/token/ERC20/Mint/ERC20MintMod.sol" as ERC20MintMod;
import "src/access/Owner/Data/OwnerDataMod.sol" as OwnerDataMod;

contract MyFacet {
  function mintTo(address _account, uint256 _value) external {
      OwnerDataMod.requireOwner();
      ERC20MintMod.mint(_account, _value);
  }
}

ERC20Storage lives at keccak256("erc20") inside the diamond, the same slot ERC20DataFacet reads, so a mint is immediately visible through balanceOf() and totalSupply().

This module is not the only way supply grows. crosschainMint on ERC20BridgeableFacet also increases totalSupply, gated to holders of the trusted-bridge role. The two differ in one important way: this module uses checked arithmetic, so an overflowing mint reverts, while the bridge performs its additions inside an unchecked block.

Last updated:September 16, 2026

Newsletter

Get notified about releases, feature announcements, and technical deep-dives on building smart contracts with Compose.

Subscribe

No spam. Unsubscribe anytime.