ERC-20 Mint Module

@perfect-abstractions/compose/token/ERC20/Mint/ERC20MintMod.solCopy

Helper function for creating new ERC-20 tokens

No Authorization Check

mint creates tokens for any account you name, with no permission check of any kind. Whatever facet calls it is responsible for deciding who may mint. Compose ships no general-purpose mint facet precisely so that this decision stays yours.

Key Features

• mint(_account, _value) increases both balanceOf[_account] and totalSupply.
• Emits Transfer from address(0), which is the ERC-20 convention for a mint.
• Arithmetic is checked, so an overflowing mint reverts rather than wrapping.
• Declares a reduced ERC20Storage with no allowance field. See below.

Module Usage

Use helper functions from Compose using your own custom facets. See Facets & Modules for more information.

Storage​

State Variables​

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;
}

Why the struct is shorter here

This is a layout-compatible prefix of the full struct, not a different slot. balanceOf and totalSupply occupy the same positions either way, so this module reads and writes exactly the same storage as the rest of ERC-20. It simply does not declare the field it never touches.

ERC20BurnMod and the two Bridgeable contracts use the same two-field form. Everything that reads or writes an allowance declares all three fields.

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.