How to Check if a Token Has a Mint Function That Can Create More Supply

06 October 2026

A mint function on a token allows its owner or a designated address to create new tokens out of thin air, increasing the total supply after launch. If a token has an active, unrestricted mint function - especially one you cannot verify or one controlled by an anonymous developer - the token's value can be diluted at any time. You can check for this function by reading the token's source code on a block explorer or using a dedicated scanning tool. The steps below walk through both methods, with emphasis on understanding what you find rather than relying on a single number or score.

Why a mint function matters

When a creator can mint more tokens, they can dump newly created supply onto the market, crashing the price for everyone else. Even a supposedly "locked" or "renounced" contract can still have a mint function that was never disabled. Some tokens include a mint function but restrict it (for example, only callable by a multisig or a timelock contract). Others keep it open to anyone who calls the function. The difference matters, and you must verify which case applies.

Step 1: Find the Verified Contract Source Code

Before you can read the code, you need the token contract address. Verify it on a block explorer (such as Etherscan, BscScan, or Polygonscan) using the standard process: confirm the address matches the official source, and check that the contract source code has been verified. Unverified contracts are much harder to inspect and generally riskier.

Once on the token's contract page, look for the Contract tab, then select Read Contract. This shows all readable functions and variables of the token.

Step 2: Look for a mint Function

In the list of functions shown on the Read Contract page, search for any function named mint, mintTo, mintWithLimit, or similar. Common naming patterns include: - mint(address to, uint256 amount) - mint(uint256 amount) - mintFor(address to, uint256 amount)

If you see such a function, the contract includes a mint function. That alone does not mean it is dangerous - you need to check who can call it.

Step 3: Check the Function's Access Control

The Read Contract page will show you the function's inputs and outputs, but not who can call it. To see access control, switch to the Read as Proxy or Read Contract section (depending on the explorer) and look for:

• An owner variable: If the contract uses OpenZeppelin's Ownable, then owner() returns the current owner's address. If that address is a dead wallet (0x000000000000000000000000000000000000dEaD or similar) or renounced to a burn address, the mint function may still be callable only by the owner. But if the owner is renounced, no one can call owner-only functions - including mint.
• A mintingAllowed boolean: Some contracts have an onlyOwner modifier on mint plus a separate toggle that must be true.
• Role-based access (e.g., OpenZeppelin's AccessControl): Look for MINTER_ROLE or hasRole(bytes32 role, address account). A role means a specific address can mint, not the contract owner.

If you cannot understand the access control from reading the contract alone, use the next step.

Step 4: Test with a Simulation or External Tool

Many block explorers offer a Write Contract or Read Contract simulation feature. You can simulate calling the mint function with a small amount (like 0 tokens and your own address as the recipient). If the explorer shows the transaction will revert with an error like "Ownable: caller is not the owner" or "AccessControl: account does not have minter role," then the function is restricted. If it succeeds on simulation, anyone could mint tokens.

Alternatively, use a dedicated token scanner that flags mint functions. Look for a field like "Can Mint" or "Mintable" that returns "Yes" or "No." Does not blindly trust a green check - some scanners only detect the presence of a mint function, not its access control. Read the linked contract evidence yourself.

Step 5: Check for Hard-Coded Supply Caps

A token with a mint function is safer if the contract also has a MAX_SUPPLY or cap variable that limits how many tokens can ever exist. On the Read Contract page, look for: - cap() or maxSupply() - totalSupply() (to see current supply) - If cap equals totalSupply, no more can be minted even if the function is present.

If there is no cap, or if the cap is extremely high (like 2^256), the mint function can be called indefinitely.

Step 6: Assess the Token's Age and Activity

A mint function does not guarantee abuse, but check the contract's transaction history. Has the owner or minter role ever called the mint function? If so, how much was minted? If minting happened after the initial liquidity was added, that is a red flag. If minting was only used once during the token creation (called in the constructor), it is not necessarily suspicious.

Also check if the contract's ownership has been renounced. On the Read Contract page, look for renounceOwnership() in the transaction list. If ownership was renounced and no minter role was assigned, the mint function is effectively dead - even though it still appears in the code.

Important Caveats

• A proxy contract can have a mint function in its implementation that is not visible until you read the logic contract separately. For proxy tokens, always read the underlying implementation address. The site's guide on checking proxy contracts covers this.
• Some tokens use "hidden" mint mechanisms not named mint - for example, a swapAndLiquify function that also mints. These require deeper code reading beyond simple checks.
• A mint function that only the deployer could call before renouncing ownership is not a threat. But if the deployer still controls it, the risk is real.

Summary

The clear danger sign is a token with an unrestricted mint function - one that anyone can call, or one controlled by an anonymous or active owner - and no hard cap on total supply. By reading the contract's readable functions and simulating the mint call, you can determine whether such a risk exists. If you cannot confidently rule out an exploitable mint function, treat the token as unsafe and move on.

Back to token safety