Minting creates new tokens out of thin air and assigns them to an address, increasing totalSupply. Burning destroys tokens from an address, decreasing totalSupply. These are not part of the core ERC-20 standard (EIP-20 does not define mint or burn functions), but they are extremely common in practice. The Proof of Effort token you are earning right now uses minting — when you complete a task, new EFFORT tokens are minted to your address.
1// Minting: create new tokens2function _mint(address to, uint256 amount) internal {3require(to != address(0), "Mint to zero address");45_totalSupply += amount; // Increase total supply6_balances[to] += amount; // Credit the recipient78emit Transfer(address(0), to, amount); // from = 0x0 signals a mint9}1011// Burning: destroy existing tokens12function _burn(address from, uint256 amount) internal {13require(from != address(0), "Burn from zero address");1415uint256 accountBalance = _balances[from];16require(accountBalance >= amount, "Burn exceeds balance");1718_balances[from] = accountBalance - amount;19_totalSupply -= amount;2021emit Transfer(from, address(0), amount); // to = 0x0 signals a burn22}
Notice that both _mint and _burn emit a Transfer event with the zero address. This is the ERC-20 convention: Transfer(address(0), to, amount) means newly minted tokens, and Transfer(from, address(0), amount) means burned tokens. Block explorers and indexers use this pattern to track circulating supply changes.
Security critical: _mint and _burn are 'internal' functions — they cannot be called directly from outside the contract. The contract must expose public functions with proper access control. Common patterns include onlyOwner (centralized), role-based access (OpenZeppelin AccessControl), or algorithmic minting (like this dApp's task completion system).
1// Different minting access control patterns:23// Pattern 1: Only owner can mint (centralized)4function mint(address to, uint256 amount) external onlyOwner {5_mint(to, amount);6}78// Pattern 2: Role-based (multiple authorized minters)9function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {10_mint(to, amount);11}1213// Pattern 3: Proof-based (this dApp's pattern!)14function completeTask(uint256 taskId, bytes32 nonce, bytes signature) external {15require(verifySignature(msg.sender, taskId, nonce, signature));16require(!isTaskCompletedBy[msg.sender][taskId], "Already completed");17isTaskCompletedBy[msg.sender][taskId] = true;18effortToken.mint(msg.sender, tasks[taskId].rewardAmount);19}2021// Pattern 4: Burn is often permissionless22function burn(uint256 amount) external {23_burn(msg.sender, amount);24}
Fixed-supply tokens (like most meme tokens) mint all tokens in the constructor and never mint again. Inflationary tokens mint on a schedule or in response to actions. Deflationary tokens incorporate burning (some tax a percentage of every transfer and burn it). Understanding mint and burn mechanics is essential for evaluating any token's economic model — if anyone can mint unlimited tokens, the token has no value.
Connect your wallet to mark this lesson as complete
Earn 15 EFFORT tokens