Interface ERC-721

O que é a interface ERC-721?

A interface ERC-721 é um conjunto padronizado de funções e eventos de contratos inteligentes usado para representar e transferir tokens não fungíveis em Ethereum e redes blockchain compatíveis.

Um token não fungível, ou NFT, representa um token com identificação exclusiva, em vez de uma quantidade intercambiável de unidades idênticas.

A especificação oficial do ERC-721 define como carteiras, aplicativos, contratos inteligentes e ferramentas de blockchain podem verificar a titularidade de NFTs e realizar transferências padronizadas.

A interface não determina o que um NFT representa, qual é seu valor nem se o conteúdo associado a ele é autêntico.

Ela define uma linguagem técnica comum que diferentes aplicativos cripto podem usar para interagir com contratos de NFT.

O padrão ERC-721 alcançou o status Final no processo de Ethereum Improvement Proposal e continua sendo um dos principais padrões para ativos únicos em blockchain.

O ERC-721 pode ser usado para colecionáveis digitais, itens de jogos, credenciais de associação, terrenos virtuais, ingressos para eventos, ativos semelhantes a domínios, posições financeiras e registros tokenizados.

Por que uma interface é importante?

Uma interface de contrato inteligente descreve as funções externas e os eventos que um software compatível espera encontrar em um contrato.

Sem uma interface compartilhada, cada projeto de NFT poderia usar nomes de funções e regras de transferência diferentes.

Assim, carteiras e aplicativos descentralizados precisariam de código personalizado para cada coleção.

A interface ERC-721 permite que o software chame funções conhecidas, como

, , e .

Ela também padroniza eventos que permitem que sistemas off-chain acompanhem transferências e aprovações de NFTs.

Um contrato pode adicionar funções além do ERC-721 e ainda manter compatibilidade com o padrão principal.

A conformidade com a interface melhora a interoperabilidade, mas não garante que o contrato seja seguro nem que todos os aplicativos ofereçam suporte aos recursos personalizados dele.

O que torna um token ERC-721 não fungível?

Cada token ERC-721 tem um número inteiro sem sinal exclusivo chamado token ID.

O token é totalmente identificado pela combinação da rede blockchain, do endereço do contrato e do token ID.

O token ID 100 em um contrato não tem relação com o token ID 100 em outro contrato.

O padrão não exige que os token IDs comecem em zero, aumentem em sequência nem sigam um padrão previsível.

Os aplicativos devem tratar cada token ID como um identificador opaco, em vez de presumir quais IDs existem.

De acordo com o modelo principal de propriedade do ERC-721, cada token ID válido tem um único proprietário por vez.

Um NFT pode ser transferido como um token completo, enquanto a propriedade fracionada exige um contrato ou uma estrutura de token separada, fora da interface básica.

ID da interface principal ERC-721

A interface principal ERC-721 é identificada pelo valor

por meio do ERC-165.

Um contrato compatível deve retornar

quando for chamado com esse identificador.

O padrão de detecção de interface ERC-165 calcula um identificador de interface aplicando XOR aos seletores de função incluídos nela.

O ERC-165 permite que um aplicativo consulte quais interfaces padronizadas um contrato afirma oferecer antes de tentar interagir com ele.

Uma resposta positiva é útil para verificar compatibilidade, mas não comprova, por si só, que todas as funções foram implementadas corretamente.

Aplicativos que lidam com ativos valiosos também podem precisar de análise de código, testes e simulação de transações.

Principais funções do ERC-721

A interface ERC-721 obrigatória inclui consultas de titularidade, funções de transferência e funções de gerenciamento de aprovações.

As principais funções são

, , , , , , e .

Uma implementação compatível deve seguir o comportamento exigido pelo padrão, incluindo verificações de autorização e condições de falha.

Emissão, queima, royalties, limites de oferta, preços e administração da coleção não são totalmente definidos pela interface principal.

Os projetos geralmente adicionam uma lógica separada para esses recursos.

A função balanceOf

A função

retorna o número de NFTs pertencentes a um endereço dentro de um contrato ERC-721.

Ela não retorna uma quantidade divisível de tokens nem o valor financeiro dos NFTs.

Se um endereço possuir os token IDs 4, 19 e 83 da mesma coleção, seu saldo será três.

O padrão exige que uma consulta ao endereço zero falhe.

A função não revela quais token IDs específicos pertencem ao endereço.

Para encontrar esses IDs, pode ser necessário indexar eventos de transferência ou usar a interface enumerável opcional.

A função ownerOf

A função

retorna o proprietário atual de um token ID específico.

Para um token existente, o proprietário retornado não pode ser o endereço zero.

De acordo com o padrão, uma consulta a um token inválido ou inexistente deve falhar.

A titularidade registrada pelo contrato controla os direitos de transferência principais associados a esse NFT.

Ela não comprova necessariamente a titularidade de direitos autorais, marcas registradas, propriedade física ou outros direitos legais.

Esses direitos dependem do contrato do projeto, da legislação aplicável e de registros externos.

A função transferFrom

A função

transfere um NFT de um endereço para outro após verificar a autorização e a titularidade.

O chamador precisa ser o proprietário, o endereço especificamente aprovado ou um operador aprovado pelo proprietário.

O endereço

deve corresponder ao proprietário atual do NFT.

O destinatário não pode ser o endereço zero.

Essa função não exige que um contrato inteligente destinatário confirme que consegue lidar com NFTs.

Um NFT enviado com

a um contrato incompatível pode ficar permanentemente inacessível.

Em geral, usuários e desenvolvedores devem preferir uma transferência segura ao enviar um NFT para um contrato desconhecido.

As funções safeTransferFrom

O ERC-721 define duas versões sobrecarregadas de

.

Uma versão inclui o remetente, o destinatário e o token ID.

A outra versão acrescenta um campo bytes que pode transportar dados específicos do aplicativo.

As duas funções realizam as verificações normais de titularidade e autorização.

Se o destinatário for um contrato inteligente, o processo de transferência chama

nesse contrato.

O destinatário precisa retornar o seletor esperado, caso contrário toda a transferência é revertida.

Essa verificação do destinatário reduz a possibilidade de enviar um NFT para um contrato que não consiga gerenciá-lo.

Ela não comprova que o contrato destinatário seja confiável ou que o NFT possa ser retirado posteriormente.

O que é IERC721Receiver?

é a interface que um contrato inteligente implementa quando deseja aceitar NFTs por meio de .

Sua função obrigatória é

.

A função recebe o operador, o proprietário anterior, o token ID e dados opcionais.

Um destinatário válido retorna o seletor da função, normalmente representado como

.

Um valor de retorno incorreto ou uma chamada revertida faz a transferência segura falhar.

A documentação atual de implementação do ERC-721 inclui uma interface de destinatário e um utilitário básico de custódia para contratos que precisam aceitar transferências seguras.

Um destinatário deve verificar qual contrato de NFT fez a chamada antes de usar o callback para atualizar uma contabilidade importante.

Risco do callback de destinatário ERC-721

Uma transferência segura para um contrato gera uma chamada externa a esse destinatário.

O destinatário pode executar código adicional antes de a transação original terminar.

Isso cria uma possível via de reentrância quando o aplicativo remetente ainda não concluiu suas atualizações internas de estado.

Um destinatário malicioso pode tentar chamar outra função no contrato original durante o callback.

As orientações de segurança para contratos inteligentes da Solidity recomendam concluir as verificações e os efeitos importantes no estado antes de fazer interações externas, quando o design pretendido permitir.

Os desenvolvedores devem testar transferências seguras de NFTs com contratos destinatários maliciosos, em vez de presumir que o callback é inofensivo.

A função approve

A função

concede a um endereço permissão para transferir um NFT específico.

Normalmente, o proprietário do token ou um operador autorizado pode conceder essa aprovação.

O endereço aprovado não se torna o proprietário.

Ele recebe autorização para transferir o token ID identificado.

Em geral, uma aprovação específica para um token é removida quando o NFT é transferido.

Chamar

com o endereço zero pode remover uma aprovação existente.

Os usuários devem verificar o endereço aprovado, pois um invasor com uma aprovação válida pode transferir o NFT sem outra assinatura do proprietário.

A função getApproved

A função

retorna o endereço atualmente aprovado para um token ID.

Se não houver uma aprovação específica para o token, normalmente ela retorna o endereço zero.

A função se aplica apenas a um NFT válido e existente.

Ela não informa uma aprovação de operador que abranja todo o saldo de uma coleção pertencente a um proprietário.

Ao determinar se outro endereço pode transferir o token, os aplicativos também devem verificar

.

A função setApprovalForAll

A função

autoriza ou remove um operador para todos os tokens ERC-721 que o chamador possui dentro daquele contrato.

Um operador aprovado pode transferir NFTs existentes e NFTs que o proprietário receber posteriormente da mesma coleção.

Essa permissão é mais ampla do que a aprovação de um único token ID.

Ela é usada com frequência quando um aplicativo precisa gerenciar vários NFTs sem solicitar uma aprovação separada para cada um.

Um operador malicioso pode transferir todos os NFTs afetados enquanto a permissão estiver ativa.

As carteiras devem exibir claramente o endereço da coleção e o escopo da aprovação do operador.

A função isApprovedForAll

A função

informa se um operador tem autoridade sobre toda a coleção para determinado proprietário.

Ela retorna um valor booleano, não uma quantidade de tokens.

A autoridade do operador se aplica somente ao contrato ERC-721 que a concedeu.

Uma aprovação em uma coleção de NFT não se aplica automaticamente a outra coleção.

Os usuários devem revisar periodicamente as permissões ativas de operador e revogar aquelas de que não precisam mais.

Eventos ERC-721

A interface principal ERC-721 define os eventos

, e .

Esses logs de eventos permitem que carteiras, indexadores, sistemas de análise e exploradores de blockchain acompanhem atividades padronizadas de NFTs.

Os eventos ajudam o software off-chain a reconstruir o histórico de titularidade e permissões.

Um evento de contrato é uma evidência do que o contrato emitiu durante a execução, mas os aplicativos ainda devem confirmar se a transação foi concluída com sucesso e veio do contrato esperado.

O evento Transfer

O evento

registra o proprietário anterior, o novo proprietário e o token ID.

Transferências normais incluem endereços de remetente e destinatário diferentes de zero.

A emissão costuma ser representada por um evento de transferência do endereço zero para o primeiro proprietário.

A queima costuma ser representada por um evento de transferência do proprietário para o endereço zero.

A interface ERC-721 não define funções públicas de emissão ou queima, embora esses padrões de eventos permitam acompanhar o ciclo de vida dos tokens.

Um evento que indique a emissão de um NFT não comprova que a coleção tenha uma oferta fixa ou autoridade de emissão restrita.

O evento Approval

O evento

registra a aprovação para um token ID.

Ele identifica o proprietário, o endereço aprovado e o token ID.

Os aplicativos podem usá-lo para acompanhar alterações na autoridade de transferência específica de um token.

O evento não deve ser confundido com uma transferência de titularidade, pois o proprietário permanece o mesmo.

O evento ApprovalForAll

O evento

registra se um proprietário ativou ou desativou um operador.

Ele inclui o proprietário, o operador e o status da aprovação.

Monitorar esse evento é importante porque uma aprovação de operador pode afetar todos os NFTs que o proprietário possui naquela coleção.

Um evento de revogação não desfaz transferências realizadas enquanto a autorização estava ativa.

Interface opcional de metadados ERC-721

A extensão de metadados adiciona

, e .

Seu ID de interface ERC-165 é

.

A extensão é opcional de acordo com a especificação oficial, embora muitos contratos de NFT a implementem.

A função

retorna o nome descritivo da coleção.

A função

retorna um identificador curto escolhido pelo desenvolvedor do contrato.

A função

retorna uma URI associada a um token ID específico.

Os nomes e símbolos de coleções não são exclusivos, por isso não devem ser usados como única verificação de autenticidade.

Como funciona tokenURI

A função

normalmente aponta para um documento JSON de metadados.

O documento pode conter campos como nome de exibição, descrição, localização da imagem, animação e atributos específicos do projeto.

A URI pode usar um endereço HTTPS, um identificador de conteúdo descentralizado ou uma data URI on-chain.

O padrão oficial ERC-721 permite que os metadados sejam alteráveis.

Isso significa que o conteúdo exibido para um NFT pode mudar após a emissão, a menos que o contrato ou o projeto ofereça garantias mais fortes de imutabilidade.

O guia atual de desenvolvimento do ERC-721 observa que a parte que controla o local de armazenamento pode alterar os metadados off-chain.

A titularidade do token não garante automaticamente a disponibilidade permanente de uma imagem ou arquivo externo.

Interface enumerável opcional ERC-721

A extensão enumerável permite que aplicativos descubram token IDs por meio de consultas on-chain.

Seu ID de interface ERC-165 é

.

Ela adiciona

, e .

A função

retorna o número de tokens atualmente válidos acompanhados pelo contrato.

As funções de índice permitem que os chamadores recuperem token IDs da oferta total ou dos ativos de um proprietário específico.

A enumeração é opcional porque a manutenção de índices adicionais de titularidade aumenta as gravações de armazenamento e o consumo de gas.

Em vez disso, muitos aplicativos reconstroem as posições de NFTs a partir de eventos

usando indexação off-chain.

Emissão e queima

A interface principal ERC-721 não exige uma função pública de emissão.

Cada projeto decide se a emissão será aberta, restrita, programada, limitada ou permanentemente desativada.

O padrão também não exige uma função pública de queima.

De acordo com a implementação do contrato, a queima remove um token dos registros de titularidade válida.

Os usuários devem analisar quem pode emitir ou queimar NFTs e se um administrador pode afetar tokens mantidos por outras contas.

Uma interface de transferência compatível não comprova que a oferta de tokens seja fixa.

Interface ERC-721 vs. implementação ERC-721

A interface define o comportamento externo necessário para a compatibilidade.

Uma implementação contém a lógica efetiva de armazenamento, autorização, transferência, emissão, metadados e administração.

Dois contratos podem oferecer suporte à mesma interface ERC-721 e ainda usar designs internos muito diferentes.

Uma implementação pode ser imutável, enquanto outra pode funcionar por meio de um proxy atualizável.

Uma pode ter oferta fixa, enquanto outra permite que um administrador emita tokens indefinidamente.

Uma pode armazenar metadados on-chain, enquanto outra aponta para um servidor que pode ser alterado.

Os usuários devem analisar a implementação, em vez de tratar o suporte à interface como uma avaliação completa de segurança.

ERC-721 vs. ERC-20

O ERC-20 representa saldos fungíveis, enquanto o ERC-721 representa tokens identificados individualmente.

Uma conta ERC-20 pode manter uma quantidade divisível, como 250 unidades.

Uma conta ERC-721 possui uma quantidade de token IDs distintos.

A função

do ERC-721 informa quantos NFTs uma conta possui, em vez da quantidade de um token ID específico.

O ERC-721 não exige um campo de decimais, pois cada token normalmente é transferido como uma unidade completa.

As aprovações também são diferentes, pois o ERC-721 oferece aprovação para um token ou controle de operador sobre uma coleção.

ERC-721 vs. ERC-1155

O ERC-721 se concentra em tokens não fungíveis identificados individualmente.

O ERC-1155 permite que um contrato gerencie vários token IDs, incluindo ativos fungíveis, semifungíveis e não fungíveis.

Uma conta ERC-1155 pode manter várias unidades de um mesmo token ID.

Um token ID ERC-721 tem um único proprietário e não mantém um saldo quantitativo para cada conta.

O padrão mais adequado depende do modelo do ativo, dos padrões de transferência, da necessidade de operações em lote e dos requisitos do aplicativo.

Royalties e a interface ERC-721

A interface principal ERC-721 não define royalties para criadores.

Uma interface de royalties separada pode informar o destinatário e o valor sugerido de um pagamento.

As informações de royalties não obrigam automaticamente todos os sistemas de transferência a realizar o pagamento.

Uma coleção que declare oferecer royalties deve explicar como as informações são calculadas e se podem mudar.

Os usuários não devem presumir que um NFT ERC-721 inclui direitos de royalties permanentes ou exigíveis.

Riscos de segurança das aprovações ERC-721

O phishing de aprovações é um dos riscos mais importantes para quem possui NFTs.

Um site malicioso pode solicitar

enquanto descreve a assinatura como uma verificação de conta ou acesso à coleção.

Após a aprovação, o operador pode transferir todos os NFTs afetados sem outra autorização do proprietário.

Uma aprovação específica para um token também pode permitir o roubo do NFT identificado.

Antes de assinar, os usuários devem verificar o endereço do operador, o contrato do NFT, o tipo de permissão e a rede.

Desconectar uma carteira de um site não revoga uma aprovação já registrada on-chain.

Risco de transferência insegura

A função

pode enviar um NFT para um contrato sem mecanismo de recuperação.

A transação pode ser concluída mesmo que ninguém consiga posteriormente fazer o contrato destinatário transferir o NFT de volta.

É por isso que

é preferível para transferências destinadas a contratos.

No entanto, o recebimento seguro apenas comprova que o contrato retornou o valor esperado para o callback.

Isso não garante que o destinatário tenha um mecanismo legítimo de saque.

Riscos de metadados e autenticidade

Qualquer pessoa pode implantar um contrato ERC-721 usando o nome ou símbolo conhecido de uma coleção.

O endereço do contrato é o identificador técnico mais importante de uma coleção.

Os metadados também podem conter nomes enganosos, obras de arte copiadas, links externos inseguros ou arquivos indisponíveis.

Uma URI de token controlada por um administrador do projeto pode posteriormente apontar para outro conteúdo.

A titularidade on-chain não verifica, por si só, a identidade do criador nem os direitos de propriedade intelectual.

Os usuários devem confirmar o endereço da coleção e as informações do projeto por meio de fontes confiáveis.

Risco de contratos atualizáveis

Uma implementação ERC-721 pode funcionar por trás de um proxy atualizável.

Um administrador autorizado pode conseguir alterar as regras de transferência, a lógica dos metadados, os direitos de emissão ou outros comportamentos depois que os usuários adquirirem NFTs.

As atualizações podem corrigir bugs, mas também criam riscos relacionados à governança e ao comprometimento de chaves.

Os usuários devem analisar as permissões de atualização, os atrasos de execução, os controles de multisig e as funções administrativas.

O suporte à interface ERC-721 não revela todas as funções privilegiadas da implementação.

Como os desenvolvedores devem implementar o ERC-721

Os desenvolvedores devem começar com uma implementação revisada e mantida ativamente, em vez de reescrever a lógica sensível de titularidade sem um motivo sólido.

A API atual de ERC-721 do OpenZeppelin oferece componentes principais, de metadados, enumeráveis, pausáveis, passíveis de queima, de royalties, de votação e relacionados a destinatários.

O acesso à emissão deve ser restrito de acordo com a política de oferta documentada da coleção.

Deve-se considerar a emissão segura quando NFTs puderem ser emitidos diretamente para contratos inteligentes.

Os callbacks de destinatário devem ser tratados como chamadas externas com possível comportamento de reentrância.

Os testes devem abranger titularidade, aprovações, permissões de operador, destinatários seguros, destinatários maliciosos, queimas, token IDs inválidos e transferências não autorizadas.

Os desenvolvedores também devem testar se a detecção de interface retorna os valores corretos para cada extensão implementada.

Como os aplicativos podem detectar suporte ao ERC-721

Um aplicativo pode chamar

com o ID da interface principal ERC-721.

Um valor de retorno

indica que o contrato afirma implementar a interface.

O aplicativo pode verificar separadamente os IDs das interfaces de metadados ou enumerável.

A detecção de interface é mais confiável do que tentar adivinhar apenas pelos nomes das funções.

No entanto, contratos mal escritos ou enganosos podem retornar informações imprecisas.

Os aplicativos devem tratar chamadas com falha e comportamentos inesperados com segurança, em vez de presumir que todo contrato está em conformidade.

Exemplo de transferência ERC-721

Suponha que Alice seja proprietária do token ID 42 em um contrato ERC-721.

A função

do contrato retorna o endereço de Alice para o token ID 42.

Alice decide enviar o NFT a um contrato inteligente.

A carteira dela chama

com o endereço de Alice, o contrato destinatário e o token ID 42.

O contrato NFT verifica se Alice é proprietária do token e está autorizada a transferi-lo.

Ele atualiza a titularidade e chama

no destinatário.

O destinatário verifica o contrato do NFT, o operador, o proprietário anterior e o token ID.

Se o destinatário retornar o seletor correto, a transferência é concluída e um evento

é emitido.

Se o destinatário rejeitar o callback, toda a transação é revertida e Alice continua sendo a proprietária.

Erros comuns relacionados à interface ERC-721

Um erro comum é presumir que o nome de uma coleção identifica exclusivamente um contrato NFT.

Outro erro é tratar

como a quantidade de um token ID.

Um terceiro erro é usar

ao enviar para um contrato inteligente desconhecido.

Um quarto erro é conceder aprovação de operador para toda a coleção sem verificar o endereço do operador.

Um quinto erro é presumir que desconectar uma carteira revoga aprovações on-chain.

Um sexto erro é tratar os metadados como permanentemente armazenados on-chain sem verificar a URI do token.

Um sétimo erro é presumir que o ERC-721 inclui royalties obrigatórios.

Um oitavo erro é presumir que todo contrato ERC-721 oferece suporte à enumeração.

Um nono erro é ignorar a reentrância durante o callback do destinatário.

Um décimo erro é tratar o suporte ao ERC-165 como prova de que a implementação é segura ou autêntica.

Perguntas frequentes

O que é a interface ERC-721?

A interface ERC-721 é um conjunto padronizado de funções e eventos para acompanhar a titularidade, as aprovações e as transferências de tokens não fungíveis.

Qual é o ID da interface ERC-721?

O ID da interface principal ERC-721 é

.

O que balanceOf retorna em um contrato ERC-721?

Ela retorna o número de NFTs distintos daquele contrato pertencentes a um endereço.

O que ownerOf faz?

Ela retorna o proprietário atual de um token ID válido.

Qual é a diferença entre transferFrom e safeTransferFrom?

verifica se um contrato destinatário oferece suporte ao callback de destinatário ERC-721; não faz essa verificação.

O que é onERC721Received?

É o callback que um contrato inteligente implementa para confirmar que pode receber um NFT por meio de uma transferência segura.

Uma transferência segura de NFT pode falhar?

Sim. Ela falha quando as verificações de autorização falham ou quando um contrato destinatário não retorna o seletor de callback esperado.

O que approve faz?

Autoriza um endereço a transferir um NFT específico.

O que setApprovalForAll faz?

Concede a um operador autoridade sobre todos os NFTs que o chamador possui naquele contrato ERC-721.

Uma aprovação de operador expira automaticamente?

Não. Uma aprovação padrão para toda a coleção continua ativa até que o proprietário a revogue ou que o contrato aplique regras personalizadas adicionais.

A transferência de um NFT remove sua aprovação específica?

Sim. Uma implementação ERC-721 normal remove a aprovação associada ao token durante a transferência.

Os metadados são obrigatórios no ERC-721?

Não. A interface de metadados é opcional, embora a maioria das coleções de NFT a implemente.

Qual é o ID da interface de metadados ERC-721?

A extensão de metadados usa o ID de interface

.

Qual é o ID da interface enumerável ERC-721?

A extensão enumerável usa o ID de interface

.

Todo contrato ERC-721 oferece suporte a totalSupply?

Não.

pertence à extensão enumerável opcional.

O ERC-721 exige uma função de emissão?

Não. A interface principal não define como usuários ou administradores emitem NFTs.

O ERC-721 exige uma função de queima?

Não. A queima é um recurso da implementação, não uma função principal obrigatória.

O ERC-721 impõe royalties?

Não. Royalties estão fora da interface principal ERC-721 e exigem lógica ou padrões separados.

Os metadados ERC-721 podem mudar?

Sim. O padrão permite que a URI do token seja alterável, a menos que a implementação ofereça garantias mais fortes de imutabilidade.

A conformidade com o ERC-721 comprova que um NFT é autêntico?

Não. Qualquer pessoa pode implantar um contrato compatível; portanto, os usuários precisam verificar o endereço do contrato e o emissor de forma independente.

Conclusão

A interface ERC-721 fornece regras comuns de titularidade, aprovação, transferência e eventos usadas por tokens não fungíveis em aplicativos compatíveis com Ethereum.

Seu ID de interface principal é

, que os contratos publicam por meio da detecção de interface ERC-165.

As funções obrigatórias permitem que os aplicativos consultem saldos e proprietários, aprovem autoridade de transferência e movimentem token IDs únicos.

As funções de transferência segura reduzem transferências acidentais para contratos incompatíveis ao exigir um callback de destinatário ERC-721.

Esse callback também cria um risco de chamada externa e reentrância que os desenvolvedores precisam tratar com cuidado.

Metadados e enumeração são interfaces opcionais com identificadores próprios e considerações adicionais de gas ou confiança.

O padrão não define permissões de emissão, direitos de queima, royalties, limites de oferta, permanência dos metadados, titularidade legal nem autenticidade da coleção.

Antes de interagir com um NFT, os usuários devem verificar os endereços dos contratos, revisar aprovações de operadores, inspecionar o armazenamento de metadados e entender as permissões de atualização.

Os desenvolvedores devem usar implementações mantidas, testar todos os fluxos de autorização e tratar callbacks de destinatário de NFT como código potencialmente hostil.

Entender a interface ERC-721 ajuda os usuários de cripto a distinguir a compatibilidade padronizada com NFTs das propriedades econômicas, legais e de segurança mais amplas de uma coleção específica.