O que é um padrão de token?

Um padrão de token é uma especificação técnica que define quais funções um programa de token deve oferecer, quais entradas ele aceita e como comunica os resultados a carteiras e outras aplicações. Ele permite que tokens criados por pessoas diferentes que desenvolvem sejam reconhecidos e chamados por um mesmo conjunto de regras.

Vale entender um padrão como um acordo de interface: ele define "como se comunicar para fora", mas não decide por nenhum projeto a emissão, o uso, as permissões administrativas ou os direitos fora da cadeia. Dois tokens podem seguir o mesmo padrão e, ainda assim, usar código diferente, ter permissões diferentes e representar coisas completamente distintas.

O que aconteceria sem um padrão comum

Se cada token nomeasse a seu modo as funções de consulta de saldo, transferência e autorização, carteiras e aplicações teriam de escrever uma conexão separada para cada um. Um token novo, mesmo que transfira normalmente, poderia não aparecer nas carteiras existentes nem ser chamado por outros programas on-chain.

Um padrão comum fixa pontos de entrada uniformes para as operações usuais. A carteira sabe como pedir um saldo, a aplicação sabe como solicitar uma transferência, o explorador de blocos sabe quais eventos ler, e outros programas podem chamar vários tokens no mesmo formato. Quem desenvolve não precisa conhecer cada token com antecedência para oferecer suporte básico.

O que um padrão melhora é a compatibilidade do software, não a qualidade do token. Com as interfaces uniformizadas, uma implementação com erro ou mal-intencionada também pode se conectar mais facilmente a aplicações existentes, então quem a usa ainda precisa verificar o código e as permissões concretos.

O que um padrão normalmente define

O alcance de um padrão de token varia conforme a rede e o tipo de token. Os conteúdos comuns se agrupam nas categorias a seguir.

Funções de consulta

Um padrão pode definir como consultar o saldo de um endereço, a emissão total de um token, ou quem controla no momento determinado número próprio. Uma forma uniforme de consulta permite que carteiras e aplicações exibam as informações básicas.

Os resultados de uma consulta só refletem os dados que o programa devolve naquele momento. Um padrão não verifica se um nome de exibição é autêntico, se a emissão tem lastro fora da cadeia, nem garante que o material adicional que descreve um token — seus metadados — continue acessível em seu link no longo prazo.

Funções de transferência

Um padrão pode definir como quem envia transfere tokens a quem recebe, quais parâmetros a chamada exige e como responder em caso de sucesso ou de falha. Para tokens com número próprio, a transferência também precisa indicar o número específico.

Alguns padrões oferecem um método de transferência mais seguro, que checa se o programa destinatário sabe lidar com os tokens recebidos. Isso pode reduzir certos envios equivocados, mas não evita perdas por endereço errado, autorização maliciosa ou falha de programa.

Funções de autorização

Uma autorização permite que quem detém o token deixe outro endereço ou programa agir em seu nome dentro de limites definidos. Quem detém pode, por exemplo, autorizar uma aplicação a transferir certa quantidade de tokens fungíveis, ou habilitar um operador a gerir um conjunto de tokens com número próprio.

Um padrão define como criar, consultar e revogar uma autorização, mas não decide se uma pessoa deveria concedê-la. O tamanho do limite, sua duração e o comportamento do programa autorizado ainda precisam ser avaliados conforme a implementação específica e por quem a usa.

Eventos e formatos de registro

Quando um programa on-chain executa uma transferência, cunhagem ou autorização, ele pode emitir eventos estruturados. Um evento é um aviso de registro de execução para as aplicações lerem, e carteiras, exploradores de blocos e serviços de dados podem usá-lo para atualizar uma interface ou montar um índice.

Um evento não substitui o estado final. A aplicação ainda precisa confirmar se a transação teve sucesso e ler os dados atuais conforme as regras da rede; ver um único evento não confirmado, ou vindo do contrato errado, não basta para provar que um saldo mudou de forma válida.

Funções opcionais e extensões

Um padrão pode listar como opcionais o nome, o código de negociação, os metadados ou uma função que liste todos os números próprios — a enumeração —, e também pode permitir ativar taxas de transferência, congelamento, pausa ou outras extensões. Uma aplicação não pode supor que todas as funções opcionais existem só porque um token declara adotar certo padrão.

As extensões também podem ser incompatíveis entre si, ou exigir que as carteiras se adaptem de propósito. Transferências básicas iguais não significam que uma aplicação antiga consiga entender todas as permissões e campos de dados acrescentados depois.

Padrão, implementação e token não são a mesma coisa

Um padrão é um acordo de funcionalidades, que indica como um programa compatível deve responder para fora. Uma implementação é o código concreto que alguém escreve e implanta seguindo esse acordo. Um token é o registro on-chain e as unidades geridos por uma implementação específica.

Um padrão pode ter muitas implementações de código; uma mesma implementação também pode servir para criar vários tokens diferentes. Uma implementação pode ainda acrescentar taxas, congelamento, listas, atualizações ou outra lógica além do que o padrão exige.

Por isso "adotar um padrão" só indica a intenção de suportar um conjunto de interfaces. Não prova que o código esteja livre de falhas, nem mostra que todas as interfaces foram implementadas corretamente. Ao integrar, a aplicação precisa conferir o endereço implantado, os resultados realmente devolvidos, as permissões adicionais e os comportamentos excepcionais.

Como um padrão se forma e é adotado

Um padrão de token normalmente aparece primeiro como proposta técnica, documento de especificação ou programa compartilhado. Quem escreve expõe o problema a resolver, os requisitos de interface e as razões do desenho; depois da discussão pela comunidade e por quem desenvolve, a proposta pode alcançar um estado relativamente estável, continuar mudando ou parar de avançar.

O estado do documento e a adoção pelo mercado são duas coisas distintas. Uma proposta pode estar redigida por completo e ser pouco usada; outro padrão pode ter muitas implementações antes de ser finalizado. O suporte de carteiras e aplicações depende das implantações reais, das necessidades de uso e das escolhas de quem desenvolve, não do número em si.

A atualização de um padrão também não muda necessariamente os tokens já implantados. Um contrato antigo pode continuar funcionando com a interface anterior, enquanto as funções novas chegam por um contrato novo, uma versão nova ou uma extensão opcional. Ao ler um padrão é preciso confirmar ao mesmo tempo a rede, a versão, o estado e a implementação específica.

A interface comum dos tokens fungíveis

Tokens fungíveis são registrados por quantidade, e unidades iguais normalmente podem ser trocadas entre si. Esse tipo de padrão costuma definir consulta de saldo, emissão total, transferência e uma função de autorização que permite a outro endereço transferir em nome de quem detém, até um limite definido.

No Ethereum, por exemplo, as propostas de padrão da camada de aplicação são chamadas de Ethereum Request for Comments (ERC). O ERC-20 é o padrão ERC que define as interfaces básicas dos tokens fungíveis, permitindo que carteiras e aplicações on-chain consultem saldos, peçam transferências e tratem autorizações de forma comum.

O ERC-20 não exige que um token tenha emissão fixa nem proíbe que quem desenvolve acrescente lógica adicional como pausa, taxas de transferência ou listas. Informações de exibição como nome, código de negociação e casas decimais também não substituem o endereço do contrato para identificar um token de forma única.

A interface comum dos tokens com número próprio

Tokens não fungíveis (non-fungible token, NFT) exigem acompanhar cada número separadamente. Os padrões correspondentes normalmente definem como consultar quem detém um número, transferir um número determinado e autorizar outro endereço a operar um token ou um conjunto deles.

Essas interfaces são implementadas de formas diferentes em cada rede. No Ethereum, por exemplo, o ERC-721 define operações básicas de posse, transferência e autorização de tokens com número próprio, enquanto metadados e a lista completa de números são extensões opcionais. Adotar esse padrão não significa que uma imagem ou outro conteúdo esteja necessariamente armazenado on-chain, e não prova que o objeto fora da cadeia que o token representa exista de fato.

Alguns padrões também permitem que um mesmo programa gerencie ao mesmo tempo unidades fungíveis, unidades com número próprio ou várias cópias sob um mesmo número. Eles atendem a necessidades de registro diferentes; isso não significa que um padrão seja em geral superior a outro.

Como redes diferentes padronizam

Um padrão de token não precisa significar "implantar um contrato por token, cada um implementando a mesma interface". Blockchains diferentes podem obter compatibilidade por regras de protocolo, um programa compartilhado ou extensões opcionais.

Por exemplo, o programa de tokens da Solana oferece em um só lugar instruções de cunhagem, registro de contas, transferência e autorização. Cada mint registra a emissão e as permissões de determinado token, enquanto carteiras e aplicações lidam com muitos mints pelo mesmo programa de tokens.

A Solana também oferece Token Extensions, um programa de tokens ao qual é possível acrescentar funções adicionais. Ao criar um token, quem desenvolve pode escolher extensões conforme a necessidade; algumas não podem ser acrescentadas após a inicialização, e algumas podem ser incompatíveis entre si. Isso mostra que "usar o mesmo programa de tokens" ainda não basta para concluir que dois tokens se comportam de forma idêntica.

Quando o mesmo nome de padrão ou uma interface parecida aparece em redes diferentes, também não convém supor que endereços, permissões e formatos de transação sejam diretamente transferíveis. O alcance de um padrão está sempre ligado à rede e ao ambiente de execução concretos.

Compatível não quer dizer comportamento idêntico

Quando uma carteira ou aplicação diz "suportar um padrão", normalmente significa que consegue tratar as interfaces básicas que o padrão exige. A compatibilidade real ainda pode ser afetada pelas situações a seguir:

• o token não implementa por completo as funções exigidas, ou devolve resultados diferentes do esperado;
• o token acrescenta taxas de transferência, pausa, congelamento ou regras de listas;
• a aplicação não suporta certas extensões opcionais;
• o programa destinatário não consegue tratar um método de transferência específico;
• uma estrutura de atualização por proxy, que troca o código executado por trás de um ponto de entrada fixo, alterou a lógica real;
• tokens de mesmo nome estão implantados em redes ou endereços diferentes.

Por isso os testes de compatibilidade de interface precisam se dirigir ao código concreto e aos resultados concretos de uma chamada. Um rótulo de "em conformidade com o padrão" não é, por si só, uma auditoria de segurança, nem uma garantia de que o comportamento futuro não mudará.

O que um padrão não define

Um padrão de token normalmente não substitui as seguintes informações:

• quem pode continuar cunhando, congelando, pausando ou atualizando o token;
• como a quantidade total é distribuída e se isso vai mudar;
• qual uso prático ou demanda de mercado o token tem;
• se nome, ícone e metadados são mantidos por uma fonte confiável;
• se existem as reservas, os bens físicos ou os serviços a que o token diz corresponder;
• se quem detém tem direitos de resgate, de governança ou outros direitos fora da cadeia.

Essas perguntas exigem examinar a implementação, as permissões e os arranjos fora da cadeia concretos. Um padrão técnico resolve apenas parte dos problemas de interação do software; não pode carregar a prova de autenticidade, valor ou efeito jurídico.

Perguntas frequentes

Um token precisa seguir um padrão?

Não necessariamente. Quem desenvolve pode criar uma interface própria, mas então carteiras e aplicações precisam de adaptação extra. Adotar um padrão amplamente suportado normalmente facilita obter compatibilidade básica.

Um número de padrão mais novo é melhor?

Não se pode julgar assim. Um padrão novo pode acrescentar funções, mas também pode ter menos suporte, continuar mudando ou não servir para certo uso. É preciso ver o estado da proposta, a adoção real e a necessidade concreta.

Um mesmo token pode adotar vários padrões?

É possível. Uma implementação pode suportar várias interfaces ao mesmo tempo, ou acrescentar extensões sobre um padrão base. Se essas interfaces funcionam bem juntas, isso ainda precisa ser checado no código concreto.

Seguir um padrão garante exibição em todas as carteiras?

Não há garantia. A carteira também precisa suportar a rede correspondente, a versão do padrão e as funções opcionais, e reconhecer o contrato ou mint correto. Metadados como nome e ícone podem ainda exigir uma fonte adicional.

Um padrão garante que um token é seguro?

Não. Um padrão só define interfaces comuns ou requisitos de comportamento. Falhas de código, permissões administrativas, dados externos, autorizações das pessoas e a rede subjacente ainda podem gerar risco.

Conceitos relacionados

Continue com token de criptomoeda, contrato inteligente, blockchain e carteira de criptomoedas, ou volte ao glossário de criptomoedas.

Fontes

• NISTIR 8301: Blockchain Networks: Token Design and Management Overview — modelos de dados de token, operações de protocolo e de conta, e o alcance diferente dos padrões.
• Ethereum.org: padrões de token — o papel das interfaces de token na compatibilidade entre carteiras, aplicações e programas on-chain.
• Processo de padrões da camada de aplicação do Ethereum — a categoria ERC, os estados das propostas de padrão e o alcance da interoperabilidade entre aplicações.
• Padrão de tokens fungíveis do Ethereum ERC-20 — interfaces básicas de saldos, transferências, autorizações e eventos.
• Padrão de tokens não fungíveis do Ethereum ERC-721 — posse, transferência, autorização e extensões opcionais de tokens com número próprio.
• Solana Docs: tokens e extensões — programa de tokens compartilhado, mints, contas de token e extensões opcionais.