ERC-20 | Financial Context Wiki

ERC-20 é a interface padrão do Ethereum para tokens fungíveis. Saiba como funcionam saldos, transferências, limites de gasto e aprovações, e o que o padrão não garante.

Somente para fins educacionais; não constitui aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

ERC-20 é uma interface padrão para contratos de tokens fungíveis no Ethereum. Ela permite que carteiras, exchanges e aplicativos descentralizados usem as mesmas chamadas para consultar uma oferta ou um saldo, transferir tokens e autorizar outro endereço a gastar um valor limitado. Fungível significa que unidades equivalentes do mesmo token são concebidas para ser intercambiáveis.

A interface principal inclui:

totalSupply e balanceOf para consultar a oferta e os saldos das contas;
transfer para enviar os tokens de quem faz a chamada;
approve e allowance para definir e consultar o limite de um gastador;
transferFrom para gastar do saldo de um proprietário dentro desse limite; e
os eventos Transfer e Approval para registrar transferências e aprovações.

O padrão define interoperabilidade, não a qualidade do ativo. A conformidade com o ERC-20 não garante uma oferta fixa, um valor justo de mercado, conversibilidade, liquidez, uma administração segura nem sequer um comportamento idêntico entre implementações.

Como funciona

Um saldo ERC-20 é um registro no estado do contrato do token, associado a um endereço. A carteira exibe esse estado; ela não guarda um arquivo de token separado. Quando transfer(to, amount) é executada com sucesso, o contrato reduz o saldo de quem fez a chamada, aumenta o saldo do destinatário e emite um evento Transfer. Normalmente, o usuário paga o gás da rede em ETH. Se a execução for revertida, as mudanças no estado do token serão desfeitas, mas o gás já consumido não será reembolsado integralmente.

O gasto delegado usa um limite de gasto. A chamada approve(spender, amount) define quanto esse gastador pode usar do saldo de quem faz a chamada. Em seguida, o gastador pode chamar transferFrom(owner, to, amount), e allowance(owner, spender) informa o limite restante. Uma aprovação pertence a um único par proprietário-gastador, em um único contrato de token e em uma única rede; ela não concede permissão sobre todos os ativos da carteira.

Chamar approve novamente substitui o limite anterior. A especificação EIP-20 orienta as interfaces de usuário a definir um limite existente como 0 antes de estabelecer outro valor diferente de zero, pois, caso contrário, a ordem das transações pode permitir que um gastador use tanto o limite antigo quanto o novo. Definir um limite como 0 pode impedir futuras chamadas a transferFrom para essa combinação de proprietário, gastador e token, mas não permite recuperar tokens já transferidos.

name, symbol e decimals são métodos opcionais de metadados no EIP-20. decimals afeta as unidades exibidas, não a contabilidade de números inteiros do contrato. O padrão também não determina como os tokens são emitidos ou queimados, se as transferências podem ser pausadas ou taxadas, se os endereços podem ser bloqueados ou se a lógica de um proxy pode ser atualizada. Esses comportamentos devem ser verificados no código implantado, na implementação atual e nas permissões administrativas.

Exemplo

Suponha que uma carteira tenha 1,000 unidades de um token ERC-20 e que um usuário queira trocar 100 delas por meio do roteador de uma exchange descentralizada. Primeiro, o usuário envia approve(router, 100). Se a operação for bem-sucedida, o roteador poderá chamar transferFrom(user, pool, 100); depois de gastar todo o valor, o limite restante normal será 0. A transação de aprovação e a transação de troca são ações separadas na rede, então cada uma pode exigir gás e falhar independentemente.

Aprovar o maior valor possível pode evitar aprovações repetidas, mas deixa um valor maior exposto por mais tempo caso o roteador, sua autoridade de atualização ou a interface usada para obter a aprovação sejam comprometidos. Um limite de gasto reduzido diminui essa exposição, embora não elimine os riscos de contratos inteligentes, preço do token, liquidez ou transação.

Riscos

Contrato ou rede incorretos: nomes, símbolos e ícones podem ser copiados; confira o endereço do contrato na rede pretendida.
Limite excessivo: um gastador mal-intencionado ou comprometido pode usar um limite não gasto até o valor aprovado.
Comportamento fora do padrão: alguns tokens amplamente utilizados não retornam valores exatamente como esperado, enquanto outros cobram taxas de transferência, reajustam saldos, bloqueiam endereços ou pausam transferências.
Controle administrativo: emissão, bloqueio, atualizações ou outras ações privilegiadas podem mudar o risco do token depois que o usuário o adquire.
Transferência irrecuperável: enviar tokens para o endereço errado ou para um contrato que não consiga processá-los pode impossibilitar a recuperação.

A padronização ERC-20 reduz o atrito de integração; ela não elimina riscos relacionados ao contrato, ao emissor, à custódia, ao mercado ou às operações. Antes de assinar, confira a rede, o contrato do token, o endereço do gastador, o valor aprovado e a chamada da transação.

Equívocos comuns

Mito 1: O rótulo ERC-20 prova que um token é legítimo

Qualquer pessoa pode implantar um contrato com um nome ou símbolo conhecido. O rótulo descreve apenas uma alegação de conformidade com uma interface. Confira o endereço do contrato e, depois, avalie separadamente o código, as permissões, o emissor, a liquidez e o mercado.

Mito 2: Uma aprovação transfere imediatamente os tokens aprovados

Normalmente, approve altera um limite de gasto; a chamada em si não transfere tokens para o gastador. A chamada posterior a transferFrom é que os movimenta. Ainda assim, um limite em aberto é uma permissão real que pode continuar utilizável até ser gasto, substituído ou definido como 0.

Mito 3: Todos os tokens ERC-20 se comportam de forma idêntica

O padrão especifica uma interface comum mínima. Ele não exige uma política de oferta específica nem proíbe taxas, pausas, listas de bloqueio, reajustes de saldo ou capacidade de atualização. As integrações devem considerar a implementação real, em vez de depender apenas do rótulo ERC-20.

Tópicos relacionados

Fontes

ERC-20: Token Standard - Ethereum Improvement Proposals (acessado em: 2026-08-20)
ERC-20 Token Standard - Ethereum.org (acessado em: 2026-08-20)