Somente para fins educacionais; não constitui aconselhamento de investimento. Investir pode causar perdas.
Resposta direta
Um padrão de token é uma interface publicada que informa a carteiras, exchanges, aplicativos e outros contratos como identificar e usar um token. Ele define funções, eventos e regras esperados, mas não certifica valor, liquidez, qualidade do código ou emissor.
Os padrões mais comuns do Ethereum atendem a modelos de ativos diferentes:
- ERC-20 representa unidades fungíveis: cada unidade pode ser trocada por outra do mesmo token.
- ERC-721 representa tokens não fungíveis identificados individualmente, como um item colecionável ou título único.
- ERC-1155 pode representar vários tipos de tokens fungíveis, não fungíveis ou semifungíveis em um contrato e aceita operações em lote.
A padronização permite que uma integração dependa de uma interface conhecida em vez de uma lógica contratual específica. Portanto, compatibilidade é uma propriedade do sistema, não uma garantia de segurança: uma implementação pode seguir a interface e ainda conter permissões abusivas, metadados enganosos, restrições de transferência ou fragilidades econômicas.
Como funciona
Os padrões especificam funções que podem ser chamadas e eventos emitidos. Uma integração ERC-20 típica verifica balanceOf, totalSupply, transfer, approve, transferFrom e allowance; uma integração ERC-721 verifica propriedade e autorizações por meio de ownerOf, safeTransferFrom, approve, setApprovalForAll e, muitas vezes, tokenURI. ERC-1155 acrescenta balanceOfBatch, safeBatchTransferFrom e uma convenção URI compartilhada para muitos IDs de token.
O ERC-165 permite que um contrato informe as interfaces que suporta por meio de supportsInterface. Aplicativos podem usar esse sinal para escolher um caminho de integração, mas devem tratar chamadas com falha e verificar o endereço do contrato. Padrões descrevem a fronteira entre componentes; a blockchain ainda executa o código específico, controles de acesso, hooks e lógica de metadados que ficam atrás dela.
Exemplo
Suponha que um marketplace aceite um ativo anunciado como NFT. O aplicativo pode verificar rede e endereço do contrato, detectar a interface ERC-721, ler a propriedade e simular uma pequena transferência. Depois deve analisar o escopo das autorizações, restrições de transferência, controles de upgrade e se os metadados são mutáveis ou hospedados fora da cadeia.
Se o mesmo marketplace também aceitar itens de jogo, ERC-1155 pode ser mais adequado, pois um contrato pode conter muitos IDs e transferências em lote podem reduzir o custo das transações. O padrão ajuda a chamar os métodos corretos; não prova que o item seja autêntico, raro, líquido ou juridicamente exigível.
Riscos
- Implementações não conformes ou enganosas: um contrato pode expor nomes conhecidos, mas mudar o comportamento esperado ou adicionar restrições de transferência.
- Risco de autorização: permissões amplas de
approveou operador podem permitir que um gastador comprometido mova ativos; revogue autorizações desnecessárias. - Hooks e reentrância: callbacks de destinatários em transferências NFT e multi-token criam caminhos de execução e interações adicionais.
- Risco de metadados e identidade: dados
tokenURIouURIpodem mudar, desaparecer ou apontar para conteúdo que não corresponde ao ativo anunciado. - Risco administrativo e econômico: chaves de upgrade, pausas ou listas negras, royalties, taxas e pouca liquidez podem dominar o resultado.
Transações de criptoativos são frequentemente irreversíveis. Confirme rede, endereço do contrato, comportamento da interface, permissões e liquidez de saída antes de assinar; auditoria ou padrão, isoladamente, não eliminam esses riscos.
Erros comuns
Um padrão torna um token seguro?
Não. O padrão descreve expectativas de interoperabilidade. A segurança ainda depende da implementação, papéis privilegiados, caminho de upgrade, economia do token, front-end e mercado ao redor.
ERC-20, ERC-721 e ERC-1155 são intercambiáveis?
Não. Saldos ERC-20 são fungíveis, a propriedade ERC-721 é rastreada por ID e ERC-1155 pode rastrear muitos tipos. O aplicativo deve usar o modelo correspondente de transferência, autorização, saldo e evento.
O suporte de uma carteira ou marketplace prova autenticidade?
Não. Geralmente prova apenas que o contrato corresponde a uma interface esperada. Verifique separadamente o endereço canônico, a procedência, o comportamento dos metadados e as alegações do emissor ou da coleção.
Tópicos relacionados
Fontes
- ERC-20: Token Standard - Ethereum Improvement Proposals (accessed: 2026-08-21)
- ERC-721: Non-Fungible Token Standard - Ethereum Improvement Proposals (accessed: 2026-08-21)
- ERC-1155: Multi Token Standard - Ethereum Improvement Proposals (accessed: 2026-08-21)
- ERC-165: Standard Interface Detection - Ethereum Improvement Proposals (accessed: 2026-08-21)
- Token Standards - Ethereum.org (accessed: 2026-08-21)