Identity
Chain ID, contract address, proxy and implementation when applicable, verified ABI, decimals, and configuration version.
Contract facts
Register the asset before exposing an endpoint.
Mintability is a property of the deployed implementation and authority configuration, not of the ERC-20 label alone.
Supply
Mint function, cap, pause behavior, burn behavior, emitted events, and any signed-authorization or business constraints.
Authority
Owner, role, multisignature, governance, or contract account permitted to invoke the supply mechanism.
Exact amount contract
Convert display units once.
For a token with six decimals, 250.50 becomes 250500000 base units. Persist that integer in the operation before transaction construction.
- Accept decimal strings, not floating-point numbers.
- Reject more fractional precision than the contract supports.
- Resolve decimals from reviewed asset configuration.
- Return both display and base-unit representations.
{
"asset_id": "loyalty-token-v2",
"network": "ethereum-sepolia",
"standard": "erc20",
"recipient": "0x8ba1f109551bD432803012645Ac136ddd64DBA72",
"amount": "250.50",
"amount_unit": "display",
"external_reference": "campaign_2026_member_1842"
}Reference ERC-20 mint request. Replace example values and apply your own authentication, authorization, and signing policy.
Transaction controls
One logical mint can have several transaction hashes.
Deterministic calldata
Use an allowlisted ABI and function selector. Validate contract, chain, recipient, amount, ETH value, and encoded arguments before signing.
Nonce ownership
Let one transaction manager coordinate the sender nonce. A fee replacement keeps the same nonce and remains linked to the original operation.
Bounded fee policy
Estimate against current state, apply reviewed limits, and keep arbitrary client fee values away from the signer.
Receipt and state evidence
Confirmation is more than RPC acceptance.
Verify the transaction
- Receipt status and expected chain
- Destination contract and function
- Expected mint event and amount
- Block number and block hash
- Replacement hash lineage
Reconcile the token
- Total supply at the selected block context
- Recipient balance or event evidence
- Configured cap and pause state
- Reorganization monitoring policy
- Corrective status when evidence changes
Security boundary
The minter key should never be a generic backend secret.
Use a signer that decodes the transaction and independently checks the contract, method, amount, recipient policy, network, and request identity.
FAQ
ERC-20 minting questions.
Does every ERC-20 contract support minting?
No. ERC-20 defines a common fungible token interface but does not require an externally callable mint function. The deployed contract must implement a supply mechanism and grant the necessary authority.
How should an API represent ERC-20 amounts?
Use decimal strings at the interface and convert with exact decimal arithmetic to integer base units. Store and return the base-unit amount as a string; never use binary floating-point for supply changes.
What proves an ERC-20 mint succeeded?
Verify transaction receipt status, the expected contract and event data, and the resulting supply or recipient balance according to the confirmation and reconciliation policy.
How should EVM nonce conflicts be handled?
Coordinate nonce allocation at the signer or transaction manager. Replacement transactions use the same nonce and remain part of one logical mint operation; a new nonce can represent another issuance.
Build from explicit contracts
Use the reference architecture as a starting point.
Define assets, authorities, idempotency, confirmation, and reconciliation before connecting a production signer.