Guia completo do padrão ERC-20: o que você precisa saber

O padrão ERC-20 consolidou-se como a espinha dorsal da tokenização no ecossistema Ethereum. Desde o lançamento do primeiro token CryptoKitties até os bilhões em capitalização de mercado das DeFi, compreender a especificação técnica, as boas práticas de desenvolvimento e os aspectos regulatórios no Brasil é essencial para quem deseja atuar no mercado de criptoativos.

Introdução

Se você está começando a explorar o universo das criptomoedas ou já possui alguma experiência prática, o padrão ERC-20 será um dos primeiros conceitos que você encontrará ao criar ou interagir com tokens. Neste artigo, vamos abordar:

• Definição e histórico do ERC-20;
• Funções e eventos obrigatórios;
• Como desenvolver seu próprio token passo a passo;
• Diferenças entre ERC-20, ERC-721 e ERC-1155;
• Aspectos de segurança, custos de gas e regulamentação brasileira.

Principais Pontos

• ERC-20 define um conjunto de 10 funções e 3 eventos que garantem interoperabilidade entre contratos.
• O padrão foi proposto em novembro de 2015 por Fabian Vogelsteller e Vitalik Buterin.
• Tokens ERC-20 são fungíveis: cada unidade tem o mesmo valor e características.
• Implementações mal‑escritas podem gerar vulnerabilidades como overflow, reentrancy e perda de fundos.
• No Brasil, a Instrução CVM 588 e o Banco Central tratam tokens como ativos financeiros, exigindo compliance.

O que é o padrão ERC-20?

ERC significa Ethereum Request for Comments. O número 20 identifica a proposta que descreve um conjunto mínimo de regras que um contrato inteligente deve implementar para ser reconhecido como um token fungível na rede Ethereum. O objetivo principal é garantir que carteiras, exchanges e DApps possam interagir de forma padronizada, sem a necessidade de customizações específicas para cada contrato.

História e evolução

A proposta original, EIP‑20, foi submetida em 2015. Desde então, surgiram extensões como ERC‑223 (para prevenir perdas ao enviar tokens para contratos que não suportam), ERC‑777 (para melhorar segurança e capacidade de extensibilidade) e ERC‑4626 (para tokens de rendimento). Contudo, a maioria dos projetos ainda utiliza a especificação básica por causa da ampla compatibilidade.

Especificação técnica

A seguir, apresentamos as funções e eventos que compõem o contrato ERC‑20. Cada item inclui a assinatura Solidity, uma breve explicação e aspectos de implementação recomendada.

Funções obrigatórias

1. function totalSupply() public view returns (uint256) – Retorna o total de tokens em circulação.
2. function balanceOf(address account) public view returns (uint256) – Consulta o saldo de um endereço.
3. function transfer(address recipient, uint256 amount) public returns (bool) – Transfere amount tokens do remetente para recipient. Deve lançar o evento Transfer e retornar true em caso de sucesso.
4. function allowance(address owner, address spender) public view returns (uint256) – Quantidade que spender ainda pode gastar em nome de owner.
5. function approve(address spender, uint256 amount) public returns (bool) – Autoriza spender a gastar até amount tokens. Emite o evento Approval.
6. function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) – Permite que spender mova tokens de sender para recipient, dentro do limite definido por allowance.

Eventos obrigatórios

• event Transfer(address indexed from, address indexed to, uint256 value) – Disparado em transfer e transferFrom.
• event Approval(address indexed owner, address indexed spender, uint256 value) – Disparado em approve.

Funções opcionais (convenções)

Embora não sejam exigidas pela especificação, muitas implementações adicionam funções como name(), symbol() e decimals() para melhorar a experiência do usuário em carteiras.

Como criar seu próprio token ERC-20

A seguir, um tutorial passo‑a‑passo usando Hardhat e a biblioteca OpenZeppelin Contracts, que já inclui implementações seguras e auditadas.

Pré‑requisitos

• Node.js (versão 18 ou superior);
• NPM ou Yarn;
• Uma carteira Ethereum (ex.: MetaMask) com saldo suficiente para pagar gas na testnet Goerli;
• Conta no Infura ou Alchemy para acesso à rede.

Passo 1 – Inicializar o projeto

mkdir meu-token-erc20
cd meu-token-erc20
npm init -y
npm install --save-dev hardhat @nomiclabs/hardhat-ethers ethers
npx hardhat
# Selecione "Create a basic sample project"

Passo 2 – Instalar OpenZeppelin

npm install @openzeppelin/contracts

Passo 3 – Escrever o contrato

Crie o arquivo contracts/MeuToken.sol com o código abaixo:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

/**
 * @title MeuToken
 * @dev Implementação simples de ERC-20 usando OpenZeppelin.
 */
contract MeuToken is ERC20, Ownable {
    constructor(uint256 initialSupply) ERC20("Meu Token", "MTK") {
        _mint(msg.sender, initialSupply);
    }

    /**
     * @dev Função para criar tokens adicionais. Apenas o proprietário pode chamar.
     */
    function mint(address to, uint256 amount) external onlyOwner {
        _mint(to, amount);
    }
}

Passo 4 – Configurar a rede de teste

Edite hardhat.config.js adicionando a rede Goerli:

require("@nomiclabs/hardhat-ethers");
module.exports = {
  solidity: "0.8.24",
  networks: {
    goerli: {
      url: "https://goerli.infura.io/v3/SEU-PROJETO-ID",
      accounts: ["0xCHAVE-PRIVADA-DA-CARTEIRA"]
    }
  }
};

Passo 5 – Deploy do contrato

Crie o script scripts/deploy.js:

async function main() {
  const [deployer] = await ethers.getSigners();
  console.log("Deploying contracts with the account:", deployer.address);
  console.log("Account balance:", (await deployer.getBalance()).toString());

  const initialSupply = ethers.utils.parseUnits("1000000", 18); // 1 milhão de MTK
  const MeuToken = await ethers.getContractFactory("MeuToken");
  const token = await MeuToken.deploy(initialSupply);

  await token.deployed();
  console.log("MeuToken deployed at:", token.address);
}

main()
  .then(() => process.exit(0))
  .catch(error => {
    console.error(error);
    process.exit(1);
  });

Execute:

npx hardhat run scripts/deploy.js --network goerli

Passo 6 – Verificar e interagir

Use Etherscan para confirmar o contrato. Em seguida, conecte a carteira ao DApp de exemplo e teste as funções transfer, approve e mint.

Comparação com outros padrões de token

Embora o ERC‑20 seja o mais usado, existem casos onde outros padrões são mais adequados:

• ERC‑721: Tokens não‑fungíveis (NFTs) – cada token possui identidade única.
• ERC‑1155: Multi‑token – permite combinar tokens fungíveis e não‑fungíveis em um único contrato, economizando gas.
• ERC‑223 / ERC‑777: Melhorias de segurança e funcionalidade para transferências.

Escolher o padrão correto depende do caso de uso: se você precisa de itens colecionáveis, opte por ERC‑721 ou ERC‑1155; se o foco é liquidez e integração com exchanges, ERC‑20 continua a melhor escolha.

Custos de gas e otimizações

Na rede principal (mainnet), cada operação tem um custo de gas que varia conforme a complexidade. Um transfer padrão costuma consumir entre 21 000 e 65 000 gas, o que, com o preço médio de R$ 0,02 por gas (valor hipotético), representa aproximadamente R$ 1,30 a R$ 4,00 por transação. Estratégias para reduzir custos incluem:

• Utilizar batchTransfer (via ERC‑1155) para enviar múltiplos pagamentos em uma única chamada.
• Implementar unchecked somente onde há garantias de overflow.
• Usar soluções Layer 2 como Optimism ou Arbitrum, que reduzem drasticamente o custo.

Segurança: vulnerabilidades comuns

Mesmo seguindo o padrão, desenvolvedores podem cometer erros críticos:

1. Overflow/Underflow: Antes do Solidity 0.8, era preciso usar bibliotecas SafeMath. Agora o compilador lança exceção automática.
2. Reentrancy: Se um contrato chama outro que, por sua vez, chama de volta funções críticas, pode ocorrer roubo de tokens. Use o padrão checks‑effects‑interactions ou o modificador nonReentrant da OpenZeppelin.
3. Approve race‑condition: Quando o usuário altera o valor de allowance de um spender, pode haver risco de gasto duplo. A prática recomendada é primeiro definir a allowance para 0 e depois para o novo valor.

Regulamentação no Brasil

A Comissão de Valores Mobiliários (CVM) publicou a Instrução CVM 588 que trata de ofertas de criptoativos. Tokens que representem direitos econômicos, dividendos ou participação em projetos podem ser classificados como valores mobiliários, exigindo registro ou dispensa. Além disso, o Banco Central, via Regulação de Ativos Virtuais, exige que exchanges e corretoras mantenham relatórios de transações (KYC/AML).

Para desenvolvedores, isso significa:

• Incluir cláusulas de “não‑oferta de valores mobiliários” no whitepaper;
• Manter auditorias de código independentes;
• Implementar mecanismos de bloqueio (freeze) caso autoridades solicitem.

Consultoria jurídica especializada é altamente recomendada antes de lançar um token ao público brasileiro.

Casos de uso reais no Brasil

Várias startups brasileiras adotaram ERC‑20 para:

• Programas de fidelidade (ex.: RewardCoin);
• Financiamento coletivo de projetos de energia renovável;
• Stablecoins lastreadas em Real (ex.: BRL‑Stable), que utilizam contratos de reserva e oráculos.

Esses projetos demonstram a flexibilidade do padrão e a importância de combinar tecnologia blockchain com conformidade regulatória.

Perguntas Frequentes (FAQ)

Conclusão

O padrão ERC‑20 permanece como a espinha dorsal da tokenização no ecossistema Ethereum. Seu design simples, aliado à vasta adoção por exchanges, DApps e projetos DeFi, garante alta liquidez e interoperabilidade. Contudo, desenvolvedores e empreendedores precisam estar atentos a boas práticas de segurança, otimizações de gas e, sobretudo, ao cenário regulatório brasileiro, que evolui rapidamente.

Ao seguir as recomendações apresentadas – desde a implementação com OpenZeppelin até a auditoria jurídica – você estará preparado para lançar tokens confiáveis, escaláveis e alinhados às exigências do mercado. Continue acompanhando nosso blog para novidades sobre upgrades de padrões, Layer 2 e estratégias avançadas de tokenomics.