- Stablecoins: ERC-20 tokens serve as the foundation for stablecoins like USDC, backed by US dollars. To learn more about the USDC contract, see 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 on Etherscan.
- Loyalty points: ERC-20 tokens can represent on-chain loyalty points to incentivize and reward users for their activities within a platform or ecosystem.
- Governance: ERC-20 tokens can represent governance rights, allowing holders to participate in protocol decisions. Notable examples include tokens utilized by platforms like Uniswap.
- Ownership: ERC-20 tokens can also represent fractional ownership in real-world assets, such as houses, ounces of gold, or company shares.
Deployment parameters
The Token template creates a customized, fully compliant ERC-20 smart contract. To create a contract using this template, provide the following parameter values when deploying a smart contract template using thePOST: /templates/{id}/deploy
API.
Template ID: a1b74add-23e0-4712-88d1-6b3009e85a86
Template deployment parameters
Here is an example of the
templateParameters JSON object within the request
body to
deploy a contract from a template
for the ERC-20 Token template.
In this example, the
defaultAdmin and primarySaleRecipient parameters are
the same address but can be set distinctly based on your use case.JSON
Common functions
This section lists the most commonly used functions on the Token template, their respective parameters and potential failure scenarios. These functions include:- approve [write]
- transfer [write]
- mintTo [write]
- burn [write]
- grantRole [write]
- revokeRole [write]
- balanceOf [read]
- allowance [read]
At this time, not all failure scenarios or error messages received from the
blockchain are passed through Circle’s APIs. Instead, you will receive a
generic
ESTIMATION_ERROR
error. If available, the errorDetails field will have more information on
the cause of failure.approve [write]
Theapprove function lets token owners specify a limit on the number of tokens
another account address can spend on their behalf.
Parameters
Failure scenarios
- The approve function fails if the
spenderis the zero address.
”ERC20: approve to the zero address”
Notes
-
If
amountis the maximum uint256 value the allowance is not updated when thetransferFromfunction is called. This is semantically equivalent to an infinite approval. -
There is no balance check on the
approvefunction so token owners may approve allowances greater than their current balance.
Solidity
transfer [write]
Allows the token owner to transfer a specified number of tokens to another account address.Parameters
Failure scenarios
- The
toaddress parameter is checked to ensure it is not the zero addressaddress(0).
”ERC20: transfer to the zero address” - The
beforeTokenTransferhook is called, which checksTOKEN_TRANSFERpermissions.
”restricted to TRANSFER_ROLE holders” - The token owner doesn’t have a sufficient balance to transfer the specified
token amount.
”ERC20: transfer amount exceeds balance”
Solidity
mintTo [write]
A designated minter can create a specified number of tokens and assign them to a specified account address.Parameters
Failure scenarios
- The function checks if the caller has the
MINTER_ROLE. The function will fail if the caller does not have the minter role. Expect to see the following error:
“not minter.” - The function ensures that the account address is not the zero address
address(0), as this is an invalid address to mint tokens to.
”ERC20: mint to the zero address” - The
beforeTokenTransferhook is called, which checksTOKEN_TRANSFERpermissions.
”restricted to TRANSFERROLE _holders”
Solidity
burn [write]
Allows a token holder to burn (destroy) a specified number of the token total supply.Parameters
Failure scenarios
- The
_beforeTokenTransferhook is called, which checksTOKEN_TRANSFERpermissions.
”restricted to TRANSFER_ROLE holders” - The token owner has no sufficient balance to burn the specified token
amount.
”ERC20: burn amount exceeds balance”
Solidity
Permissions and roles
Roles are referred to by theirbytes32 identifier. For example:
Solidity
hasRole:
Solidity
grantRole and
revokeRole functions. Each role has an associated admin role, and only
accounts that have a role’s admin role can call grantRole and revokeRole. By
default, the admin role for all roles is DEFAULT_ADMIN_ROLE. Only accounts
with the DEFAULT_ADMIN_ROLE can grant or revoke other roles. You can use the
_setRoleAdmin function to create more complex role relationships.
grantRole [write]
Grants a specified role to an account. Only an account address that has the admin role assigned can call this function.Parameters
Failure scenarios
- The
onlyRole(getRoleAdmin(role))modifier ensures that the function caller has the admin role for the specified role. Only addresses with the admin role can grant roles to other accounts.
”AccessControl: account ”, StringsUpgradeable.toHexString(account), ” is missing role ”, StringsUpgradeable.toHexString(uint256(role), 32) - The function checks if the account already has the specified role using the
hasRolefunction. If the account does not have the role, the function continues. There is no error message.
Solidity
revokeRole [write]
Revoke the specified role from an account address. Only account addresses with the admin role assigned can call this function.Parameters
Failure scenarios
- The
onlyRole(getRoleAdmin(role))modifier ensures that the function caller has the admin role for the specified role. Only addresses with the admin role can revoke roles from other accounts.
”AccessControl: account ”, StringsUpgradeable.toHexString(account), ” is missing role ”, StringsUpgradeable.toHexString(uint256(role), 32)
Solidity
balanceOf [read]
Retrieves the balance of tokens owned by a specific account address.Parameters
Solidity
allowance [read]
Returns the maximum amount the spender is approved to withdraw from the owner’s account. This function retrieves the allowance granted by the owner account address to the spender account address.Parameters
Solidity