Padrão Multi-Token ERC-1155

O que é o padrão Multi-Token ERC-1155?

ERC-1155 é um padrão de tokens da Ethereum que permite que um único contrato inteligente gerencie vários tipos de tokens ao mesmo tempo.

Um único contrato ERC-1155 pode representar tokens fungíveis, tokens não fungíveis, tokens semifungíveis ou uma combinação desses tipos de ativos.

A especificação ERC-1155 oficial define consultas de saldo padronizadas, transferências individuais e em lote, aprovações de operadores, callbacks de destinatários, eventos e metadados opcionais.

O ERC-1155 é classificado como um padrão Final de Ethereum Request for Comments.

Ele é comumente chamado de Multi-Token Standard porque cada token ID em um contrato pode representar um ativo cripto diferente.

Cada token ID pode ter sua própria oferta, saldos, metadados, raridade, finalidade e características econômicas.

O ERC-1155 foi criado para reduzir o custo e a complexidade de implantar e interagir com grandes coleções de ativos em blockchain.

Por que o ERC-1155 foi criado?

Os modelos de tokens anteriores geralmente exigiam contratos separados para diferentes ativos fungíveis ou coleções de NFTs.

Assim, um jogo em blockchain com centenas de moedas, recursos, armas, personagens e itens de eventos poderia exigir muitos contratos.

A implantação repetida de contratos aumenta o bytecode, o trabalho administrativo e de integração e os custos de transação.

O ERC-1155 reúne vários tipos de tokens em um único contrato e aplica a eles um sistema compartilhado de transferências e aprovações.

O padrão também oferece suporte a operações em lote padronizadas, que podem transferir vários token IDs em uma única transação.

Isso torna o padrão útil para jogos, colecionáveis digitais, sistemas de associação, inventários tokenizados, posições financeiras, programas de recompensas e outros aplicativos cripto com diversas categorias de ativos.

O padrão não se limita a jogos e pode ser usado sempre que um contrato precisar gerenciar vários tipos de tokens com eficiência.

Como o ERC-1155 funciona

Um contrato ERC-1155 mantém um saldo separado para cada combinação de endereço de conta e token ID.

Um endereço pode ter dez unidades do token ID 1, uma unidade do token ID 2 e nenhuma unidade do token ID 3 no mesmo contrato.

Cada token ID pode funcionar como um ativo fungível, um NFT único ou um ativo com uma oferta limitada de unidades intercambiáveis.

Quando os tokens são transferidos, o contrato reduz o saldo do remetente para cada ID relevante e aumenta o saldo correspondente do destinatário.

O contrato emite eventos padronizados para que carteiras e indexadores possam reconstruir a criação, as transferências e a destruição de tokens.

Se o destinatário for um contrato inteligente, o contrato ERC-1155 chama uma função de destinatário para confirmar que ele aceita os ativos.

Os nós da Ethereum executam essas regras e verificam as alterações de saldo resultantes de acordo com o código do contrato implantado.

O que é um token ID no ERC-1155?

Um token ID é um número inteiro sem sinal que identifica um tipo de token dentro de um contrato ERC-1155.

O mesmo token ID pode existir em outro contrato sem representar o mesmo ativo.

Portanto, um ativo ERC-1155 é identificado em conjunto pela rede blockchain, pelo endereço do contrato e pelo token ID.

O token ID 25 pode representar um recurso fungível de jogo em um contrato e um colecionável único em outro.

O padrão não exige que os IDs comecem em zero, sigam uma sequência crescente ou codifiquem um significado específico.

Os desenvolvedores podem atribuir IDs de acordo com a arquitetura do aplicativo.

Os aplicativos devem consultar dados confiáveis do contrato, em vez de tentar adivinhar quais token IDs existem.

Tokens fungíveis no ERC-1155

Um token ID ERC-1155 pode representar um ativo fungível quando existem várias unidades intercambiáveis desse ID.

Por exemplo, o token ID 1 pode representar uma moeda de jogo com um milhão de unidades idênticas.

Cada detentor tem um saldo quantitativo associado ao token ID 1.

As unidades do mesmo ID normalmente têm propriedades idênticas definidas pelo contrato.

Ao contrário do ERC-20, o ERC-1155 não define, em sua interface principal, funções separadas de oferta total, símbolo, nome ou casas decimais para cada token ID.

Os projetos devem fornecer as informações necessárias de oferta ou exibição por meio de extensões, metadados ou funções personalizadas.

Tokens não fungíveis no ERC-1155

Um token ID ERC-1155 pode representar um ativo não fungível se a oferta desse ID for limitada a uma unidade.

O endereço que detém essa única unidade funciona como proprietário do token.

Outro token ID no mesmo contrato pode representar um item único diferente.

Por exemplo, o token ID 1001 pode representar uma espada, enquanto o token ID 1002 representa um terreno virtual.

O padrão principal não obriga que a oferta de um token ID seja limitada a uma unidade.

A lógica de emissão do contrato deve garantir a exclusividade quando um ID se destina a funcionar como NFT.

Tokens semifungíveis

Um token semifungível começa com unidades intercambiáveis, mas pode posteriormente adquirir um significado distinto ou uma utilidade limitada.

Ingressos para eventos são um exemplo comum: vários ingressos para a mesma seção podem ser intercambiáveis antes do evento.

Depois de usados, cada ingresso pode se tornar um registro colecionável associado a uma experiência específica.

Itens de jogos com edições limitadas ou estados que mudam também podem usar um modelo semifungível.

O ERC-1155 não classifica formalmente os IDs como fungíveis, não fungíveis ou semifungíveis.

A classificação depende da oferta do token, dos metadados, das regras de transferência e do design do aplicativo.

Funções principais do ERC-1155

A interface principal inclui funções para consultar saldos, transferir tokens e gerenciar aprovações de operadores.

As funções obrigatórias são

, , , , e .

O ERC-1155 também exige a detecção de interfaces ERC-165.

A interface principal não exige emissão pública, queima, oferta total, royalties, nomes de tokens, símbolos ou casas decimais.

Esses recursos podem ser adicionados por meio de extensões ou de lógica de implementação personalizada.

A função balanceOf

A função

retorna a quantidade de um token ID pertencente a um endereço.

Ela recebe como entradas um endereço de conta e um token ID.

Isso difere do ERC-20, no qual um contrato geralmente representa apenas um tipo de token e a função precisa receber somente o endereço da conta.

Também difere do ERC-721, no qual

informa quantos NFTs distintos de uma coleção pertencem a um endereço.

Um saldo ERC-1155 pode ser zero, um ou qualquer número inteiro maior permitido pelo contrato.

O padrão exige que uma consulta de saldo para o endereço zero falhe.

A função balanceOfBatch

A função

consulta, em uma única chamada, vários saldos de contas e token IDs.

O chamador fornece um array de endereços de contas e um array correspondente de token IDs.

Cada valor retornado corresponde à conta e ao ID na mesma posição dos arrays.

Os dois arrays de entrada devem ter o mesmo tamanho.

Essa função pode consultar vários ativos de uma conta ou um ativo em várias contas.

As consultas de saldo em lote reduzem o número de chamadas separadas necessárias para carteiras, jogos e aplicativos de análise.

A função safeTransferFrom

A função

transfere uma quantidade de um token ID de um endereço para outro.

O chamador deve ser o detentor do token ou um operador aprovado por esse detentor.

O remetente deve ter saldo suficiente do token ID selecionado.

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

A função também aceita um campo bytes que pode conter informações específicas do aplicativo.

Se o destinatário for um contrato inteligente, ele deverá aceitar a transferência por meio do callback de destinatário ERC-1155 exigido.

Uma transferência bem-sucedida emite um evento

.

A função safeBatchTransferFrom

A função

transfere vários token IDs e quantidades em uma única transação.

O chamador fornece arrays correspondentes de token IDs e valores.

O token ID em cada posição do array é transferido na quantidade indicada pela posição correspondente do array de valores.

Os arrays devem ter o mesmo tamanho.

O chamador deve ser o detentor ou um operador aprovado, e o detentor precisa ter saldo suficiente de cada item do lote.

Se uma transferência necessária falhar, normalmente a transação inteira é revertida.

Uma transferência em lote bem-sucedida emite um evento

, em vez de um evento de transferência separado para cada token ID.

Por que as transferências em lote são importantes

As transferências em lote permitem movimentar vários tipos de ativos em uma única transação na blockchain.

Um usuário de jogo poderia transferir moeda, materiais, armadura e itens colecionáveis juntos.

Um aplicativo também poderia distribuir vários tipos de recompensas a um destinatário em uma operação.

O processamento em lote pode reduzir custos recorrentes de transação e o custo total em comparação com o envio de muitas transações separadas.

A economia exata depende da quantidade de IDs, da implementação do contrato, das alterações de armazenamento, das condições da rede e da lógica do destinatário.

Lotes muito grandes ainda podem consumir gas demais e falhar devido ao limite de gas do bloco.

Os aplicativos devem estabelecer limites razoáveis para o tamanho de lotes controlados pelo usuário.

Aprovações de operadores ERC-1155

O ERC-1155 utiliza um modelo de aprovação de operador para toda a coleção.

A função

permite que um detentor autorize ou revogue um operador.

Um operador aprovado pode gerenciar todos os token IDs ERC-1155 pertencentes ao detentor dentro do contrato.

A aprovação abrange os saldos existentes e os tokens que o detentor receber posteriormente do mesmo contrato.

O padrão não oferece uma função principal para aprovar apenas um token ID ou uma quantidade limitada.

Essa permissão ampla facilita o uso dos aplicativos, mas cria um risco significativo de segurança.

Os usuários devem verificar o endereço do operador e o contrato antes de aprová-lo.

A função isApprovedForAll

A função

informa se um endereço tem autoridade de operador sobre os tokens de outro endereço.

Ela retorna

ou .

A aprovação se aplica somente ao contrato ERC-1155 em que foi registrada.

Ela não concede automaticamente autoridade sobre tokens ERC-20, NFTs ERC-721 ou ativos de outro contrato ERC-1155.

Os usuários devem revisar periodicamente as aprovações ativas de operadores e revogar as permissões que não forem mais necessárias.

Desconectar uma carteira de um site não remove uma aprovação de operador armazenada on-chain.

Extensões de aprovação granular

O modelo amplo de aprovação do ERC-1155 pode não ser adequado quando o usuário deseja autorizar apenas determinados token IDs ou quantidades.

Padrões adicionais ou contratos personalizados podem oferecer permissões mais limitadas.

A extensão de autorização ERC-5216 define quantidades de aprovação para token IDs ERC-1155 específicos.

O suporte a essas extensões é opcional e não deve ser presumido.

Uma carteira deve diferenciar claramente uma autorização limitada a um token ID de uma aprovação padrão para toda a coleção.

Interface de destinatário ERC-1155

Um contrato inteligente que recebe tokens ERC-1155 por meio de uma transferência segura padrão deve implementar a função de destinatário adequada.

A interface de destinatário inclui

para uma transferência individual e para uma transferência em lote.

O identificador ERC-165 da interface de destinatário é

.

O contrato destinatário analisa o operador, o detentor anterior, os token IDs, as quantidades e os dados anexados.

Ele deve retornar o valor de aceitação esperado; caso contrário, a transferência é revertida.

Esse sistema reduz transferências acidentais para contratos incapazes de processar ativos ERC-1155.

Callback de destinatário para transferência individual

A função

é chamada depois que o saldo do destinatário é atualizado em uma transferência individual.

O valor de aceitação esperado é

.

O destinatário pode validar o contrato do token, o operador, o remetente, o token ID, a quantidade e os dados anexados.

Ele pode aceitar a transferência retornando o valor exigido.

Ele pode rejeitá-la revertendo a transação ou retornando outro valor.

Um contrato destinatário nunca deve creditar um depósito com base apenas nos dados do callback, sem verificar o contrato do token que fez a chamada.

Callback de destinatário para transferência em lote

A função

processa o recebimento de vários token IDs em uma transferência.

O valor de aceitação esperado é

.

Os arrays de IDs e quantidades devem ser interpretados na ordem correspondente.

O destinatário deve validar o tamanho dos arrays e confirmar que cada token ID compatível segue as regras do aplicativo.

Retornar um valor incorreto ou reverter a transação faz com que toda a transferência em lote falhe.

Um destinatário de lote deve ser projetado com cuidado, pois uma transação pode entregar muitos tipos diferentes de ativos.

Callbacks de destinatário e reentrância

Os callbacks de destinatário ERC-1155 executam código de contratos externos antes que a transação de transferência original seja concluída.

O contrato destinatário pode chamar o contrato do token ou outro aplicativo durante o callback.

Isso cria uma possível via de reentrância.

A especificação ERC-1155 exige que os saldos e os eventos de transferência sejam atualizados antes da chamada ao hook do destinatário.

Os contratos de aplicativos ainda precisam proteger sua própria lógica de contabilização e autorização.

As orientações de segurança do Solidity recomendam concluir as verificações e as alterações importantes de estado antes das interações externas, quando a lógica pretendida permitir.

Os desenvolvedores devem testar ambas as funções de destinatário com contratos maliciosos que tentem reentrância na mesma função e entre funções diferentes.

Eventos ERC-1155

O padrão principal define os eventos

, , e .

Esses registros permitem que carteiras, exploradores, indexadores e sistemas de análise acompanhem a atividade dos tokens.

O padrão foi projetado para que os saldos dos tokens e as alterações de oferta possam ser reconstruídos a partir dos eventos de transferência.

As implementações devem emitir os eventos corretos sempre que tokens forem criados, transferidos ou destruídos.

Um evento deve sempre ser interpretado em conjunto com o endereço do contrato que o emitiu.

O evento TransferSingle

O evento

registra o operador, o remetente, o destinatário, o token ID e a quantidade de um tipo de token.

Uma transferência normal inclui endereços diferentes de zero para remetente e destinatário.

Na emissão, o endereço zero é usado como remetente.

Na queima, o endereço zero é usado como destinatário.

Transferências de valor zero também devem gerar o evento apropriado.

Os observadores podem usar esses registros para atualizar seus saldos indexados.

O evento TransferBatch

O evento

registra vários token IDs e quantidades transferidos em uma operação.

Os IDs e as quantidades aparecem em posições correspondentes nos arrays.

O evento também registra o operador, o remetente e o destinatário.

Na emissão em lote, o endereço zero é usado como remetente; na queima em lote, é usado como destinatário.

Os indexadores devem processar cada elemento dos arrays para calcular corretamente os saldos e as ofertas.

O evento ApprovalForAll

O evento

registra se um proprietário habilitou ou desabilitou um operador.

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

O evento não transfere tokens por si só.

Ele altera a possibilidade de o operador iniciar transferências futuras a partir do proprietário.

Revogar um operador não reverte as transações concluídas enquanto a permissão estava ativa.

Detecção de interfaces ERC-1155

O ERC-1155 exige suporte ao padrão de detecção de interfaces ERC-165.

O ID da interface principal ERC-1155 é

.

Um contrato compatível deve retornar

quando for chamada com esse valor.

O padrão ERC-165 define como contratos inteligentes publicam e detectam interfaces compatíveis.

A detecção de interfaces ajuda os aplicativos a evitar chamadas não compatíveis.

Um contrato pode declarar falsamente que oferece suporte ou implementar funções incorretamente; portanto, uma resposta positiva não é uma garantia completa de segurança.

Metadados ERC-1155

O ERC-1155 inclui uma extensão opcional de URI de metadados.

A extensão adiciona uma função

que retorna a localização dos metadados de um token ID.

O ID da interface é

.

Normalmente, a localização retornada aponta para um documento JSON com informações como nome, descrição, imagem, atributos e recursos externos.

Ao contrário das interfaces de metadados ERC-20 e ERC-721, o design principal ERC-1155 não exige funções on-chain

ou .

Os projetos ainda podem adicionar essas funções por meio de extensões personalizadas.

Substituição do metadado {id}

Uma URI de metadados ERC-1155 pode conter o marcador

.

Os aplicativos substituem esse marcador pelo token ID solicitado, escrito como um valor hexadecimal em letras minúsculas.

O valor deve conter 64 caracteres, incluindo zeros à esquerda, e não deve incluir o prefixo

.

Essa estrutura permite que uma URI base descreva os locais de metadados de muitos token IDs.

Os aplicativos devem fazer a substituição corretamente, ou poderão solicitar o arquivo de metadados errado.

O evento URI

O evento

anuncia uma URI de metadados associada a um token ID.

Quando uma URI não programática muda, uma implementação que utiliza a extensão de metadados deve emitir o evento quando a alteração puder ser representada por ele.

Se um evento tiver sido emitido, a função

deve retornar o mesmo valor do evento URI mais recente para aquele ID.

A existência de uma URI válida não prova que um token ID foi emitido.

Os aplicativos devem usar saldos e eventos de transferência, e não a disponibilidade de metadados, para determinar a existência de tokens.

Riscos de armazenamento de metadados

Os metadados ERC-1155 podem ser armazenados em um servidor tradicional, em uma rede endereçada por conteúdo ou diretamente on-chain.

O conteúdo hospedado em servidores pode ser alterado ou desaparecer.

O armazenamento endereçado por conteúdo melhora a integridade quando o identificador corresponde ao arquivo, mas ainda depende da disponibilidade contínua.

Os metadados on-chain reduzem a dependência de hospedagem externa, mas aumentam os custos de armazenamento e implantação.

Uma URI de contrato mutável pode alterar nomes, imagens, atributos ou descrições depois que os usuários adquirirem tokens.

Os usuários devem verificar quem pode alterar os metadados e se o conteúdo referenciado deve permanecer disponível.

Emissão de tokens ERC-1155

A emissão cria unidades de tokens e as atribui a um endereço.

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

Cada implementação decide quem pode emitir, quais IDs podem ser criados e se há limites de oferta.

Uma emissão deve gerar

ou com o endereço zero como remetente.

Se os tokens forem emitidos para um contrato inteligente, normalmente será aplicado o callback de destinatário adequado.

Os usuários devem verificar as permissões de emissão, em vez de presumir que um ID semelhante a NFT tem uma oferta permanentemente limitada.

Queima de tokens ERC-1155

A queima remove permanentemente unidades de tokens dos saldos, de acordo com a implementação do contrato.

A interface principal não exige uma função pública de queima.

Um projeto pode permitir que detentores, operadores aprovados, administradores ou outra lógica do protocolo queimem ativos.

Uma queima deve emitir o evento de transferência apropriado, com o endereço zero como destinatário.

Queimar todas as unidades existentes de um ID não impede necessariamente que o contrato volte a emitir esse ID.

O resultado depende das regras de oferta e controle de acesso do contrato.

Oferta total ERC-1155

O padrão principal ERC-1155 não define uma função

.

A oferta de cada token ID pode ser calculada a partir dos eventos de emissão e queima quando a implementação segue as regras de emissão de eventos exigidas.

Um contrato pode adicionar uma extensão de acompanhamento de oferta para facilitar consultas on-chain.

A atual API de implementação ERC-1155 inclui uma extensão opcional que acompanha a oferta total por token ID.

Os aplicativos não devem presumir que todos os contratos ERC-1155 expõem as mesmas funções de oferta.

Enumeração ERC-1155

O ERC-1155 não define uma função principal que liste todos os token IDs ou todos os detentores.

O padrão espera que sistemas off-chain reconstruam a atividade dos tokens a partir dos eventos

, e .

Normalmente, um indexador começa no bloco de implantação do contrato e processa os eventos até o bloco mais recente.

A perda de um evento pode produzir registros incorretos de saldos ou ofertas.

Os contratos podem adicionar funções personalizadas de enumeração, mas elas não estão disponíveis universalmente.

Royalties ERC-1155

O padrão principal ERC-1155 não define royalties para criadores.

O padrão opcional de royalties ERC-2981 pode fornecer um destinatário e um valor de pagamento sugerido para a venda de um token.

O ERC-2981 é compatível com o ERC-1155 e pode definir informações de royalties padrão ou específicas por token.

O padrão de royalties comunica informações de pagamento, mas não obriga todos os aplicativos a pagá-los.

As configurações de royalties também podem ser alteradas quando a implementação concede essa autoridade a um administrador.

Erros padronizados ERC-1155

O padrão ERC-1155 original não define erros personalizados modernos do Solidity.

O padrão Final ERC-6093 define erros comuns para implementações ERC-1155.

Entre eles estão erros de saldo insuficiente, remetentes inválidos, destinatários inválidos, ausência de aprovação do operador, operadores inválidos e tamanhos incompatíveis de arrays.

Erros padronizados podem ajudar carteiras e desenvolvedores a explicar falhas de transação de forma consistente.

Os contratos ERC-1155 existentes não são obrigados a adotá-los.

ERC-1155 vs. ERC-20

Normalmente, o ERC-20 representa um tipo de token fungível por contrato.

O ERC-1155 pode representar muitos token IDs fungíveis e não fungíveis em um único contrato.

O ERC-20 usa permissões numéricas para gastos por terceiros, enquanto o ERC-1155 principal usa aprovação de operador para toda a coleção.

O ERC-1155 oferece transferências em lote padronizadas e callbacks de destinatário.

O padrão principal ERC-20 não oferece nenhum desses recursos.

O ERC-20 pode continuar sendo mais simples quando um projeto precisa de apenas um ativo cripto fungível.

ERC-1155 vs. ERC-721

O ERC-721 representa token IDs não fungíveis de propriedade individual.

Um token ID ERC-721 válido tem um proprietário, em vez de um saldo quantitativo para cada conta.

O ERC-1155 armazena uma quantidade para cada combinação de conta e token ID.

Isso permite que um ID tenha muitas unidades intercambiáveis enquanto outro ID no mesmo contrato tenha oferta de uma unidade.

O ERC-1155 também oferece transferências em lote padronizadas, enquanto o ERC-721 normalmente transfere um NFT por vez.

O ERC-721 pode oferecer um modelo de propriedade mais simples quando cada token é único.

Casos de uso do ERC-1155

Jogos em blockchain podem usar um único contrato ERC-1155 para moedas, materiais, personagens, armas, terrenos e itens de edição limitada.

Sistemas de eventos podem emitir várias categorias e quantidades de ingressos a partir de um único contrato.

Projetos de associação podem gerenciar diferentes níveis de acesso, grupos de expiração ou pacotes de benefícios por meio de token IDs separados.

Projetos de colecionáveis digitais podem criar edições com várias cópias intercambiáveis de cada obra.

Aplicativos financeiros podem usar IDs para representar datas de vencimento, riscos, direitos ou categorias de posições.

Sistemas de recompensas podem distribuir vários tipos de pontos ou itens de conquistas em um único lote.

O padrão não verifica se um token representa um direito legal válido ou um ativo do mundo real.

Riscos de phishing de aprovação

Um aplicativo malicioso pode pedir ao usuário que chame

, descrevendo a solicitação como uma verificação ou conexão da carteira.

Após a aprovação, o operador pode transferir todos os token IDs que o usuário possui naquele contrato ERC-1155.

A aprovação também pode se aplicar a tokens que o usuário receber posteriormente.

Os usuários devem verificar a rede, o contrato do token, o endereço do operador e o tipo de permissão antes de assinar.

Revogar o acesso de um site na interface da carteira não revoga automaticamente a aprovação na blockchain.

Uma frase de recuperação ou chave privada nunca é necessária para cancelar uma permissão de operador ERC-1155.

Riscos do processamento em lote

As operações em lote processam arrays cujos elementos devem permanecer corretamente alinhados.

Uma incompatibilidade entre IDs e quantidades deve fazer a transação falhar.

Uma indexação incorreta pode transferir a quantidade errada de um ativo.

Lotes grandes podem ultrapassar os limites de gas da transação ou criar condições de negação de serviço.

Um destinatário pode aceitar economicamente alguns token IDs, mas não outros; por isso, deve validar o lote inteiro antes de confirmar o recebimento.

Os aplicativos devem limitar o tamanho dos lotes e testar token IDs repetidos ou não ordenados de acordo com as regras de implementação.

Riscos de destinatário e reentrância

Transferências seguras chamam o código externo do destinatário depois das atualizações de saldo.

Um destinatário malicioso pode tentar reentrar em funções de emissão, transferência, venda, staking, empréstimo ou saque.

Um contrato pode continuar vulnerável mesmo quando uma função tem proteção contra reentrância, se outra função expuser um estado relacionado.

Os desenvolvedores devem usar uma lógica consistente de transição de estado nas operações individuais e em lote.

Os callbacks de destinatário devem verificar o contrato do token que fez a chamada e não devem confiar automaticamente em dados fornecidos pelo usuário.

Os testes de segurança devem incluir transferências aninhadas, destinatários que encaminham tokens, callbacks revertidos e interações entre contratos.

Riscos de oferta e autenticidade

Um token ID ERC-1155 pode parecer único porque existe apenas uma unidade no momento.

Mesmo assim, um emissor autorizado ainda pode criar unidades adicionais posteriormente.

O nome, a imagem ou o token ID de uma coleção também podem ser copiados em outro contrato.

O endereço do contrato e a rede são partes essenciais da identidade do ativo.

Antes de confiar em alegações de escassez, os usuários devem analisar a autoridade de emissão, as extensões de oferta, as permissões de administrador e os controles de atualização.

A conformidade com o ERC-1155 não comprova autenticidade, lastro, raridade ou valor financeiro.

Riscos de contratos atualizáveis

Um contrato ERC-1155 pode operar por meio de um proxy atualizável.

Um administrador autorizado pode conseguir alterar a emissão, as transferências, as aprovações, os metadados, as taxas ou o comportamento do destinatário.

Atualizações podem corrigir falhas, mas também introduzir código malicioso ou inseguro.

Uma chave de atualização comprometida pode colocar em risco todos os token IDs do contrato.

Os usuários devem examinar a autoridade de atualização, os atrasos temporais, os requisitos de assinatura múltipla e os controles de emergência.

Um contrato pode oferecer suporte à interface correta e ainda manter permissões centralizadas poderosas.

Como os desenvolvedores devem implementar o ERC-1155

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

O atual guia de desenvolvimento ERC-1155 fornece contratos principais e explica saldos multi-token e operações em lote.

As funções de emissão e administração devem usar controles de acesso explícitos.

As restrições de oferta devem ser aplicadas na lógica do contrato, e não apenas descritas na documentação do projeto.

Os desenvolvedores devem emitir todos os eventos exigidos e retornar valores corretos de interface ERC-165.

Os testes devem abranger transferências individuais e em lote, aprovações, queimas, emissões, incompatibilidades entre arrays, destinatários inválidos, callbacks maliciosos e alterações de metadados.

Como os usuários podem avaliar um token ERC-1155

O primeiro passo é verificar a rede blockchain, o endereço do contrato e o token ID.

O segundo é identificar se o ID deve ser fungível, não fungível ou semifungível.

O terceiro é analisar a oferta atual, a autoridade de emissão e os limites de oferta.

O quarto é revisar as aprovações de operadores associadas à carteira.

O quinto é examinar o armazenamento de metadados e determinar se eles podem ser alterados.

O sexto é identificar os poderes de administrador, pausa, congelamento e atualização.

O sétimo é entender se callbacks de destinatário ou contratos externos introduzem riscos adicionais.

O oitavo é analisar auditorias e código-fonte verificado sem tratá-los como garantias.

O nono é confirmar quais direitos ou utilidades o token realmente oferece.

O décimo é testar um contrato desconhecido com uma quantidade limitada antes de transferir ativos valiosos.

Exemplo de transferência em lote ERC-1155

Suponha que Alice tenha 100 unidades do token ID 1, cinco unidades do token ID 2 e uma unidade do token ID 3.

Ela quer enviar a Bob dez unidades do ID 1, duas unidades do ID 2 e uma unidade do ID 3.

A carteira dela chama

com arrays contendo os três IDs e as quantidades correspondentes.

O contrato verifica os saldos de Alice e a autoridade do chamador.

Ele reduz os saldos de Alice e aumenta os saldos de Bob para cada ID listado.

O contrato emite um evento

que descreve toda a movimentação.

Se Bob for um contrato inteligente, o contrato do token chama

.

Se o destinatário retornar o valor de aceitação correto, a transação será concluída.

Se qualquer verificação de saldo ou requisito do destinatário falhar, toda a transferência em lote será revertida.

Erros comuns no ERC-1155

Um erro comum é presumir que todo token ID ERC-1155 é um NFT.

Outro é presumir que uma unidade é a oferta máxima de um token ID.

Um terceiro erro é conceder aprovação de operador sem entender que ela abrange todos os IDs do contrato.

Um quarto é acreditar que desconectar uma carteira remove uma aprovação on-chain.

Um quinto é usar a disponibilidade de metadados como prova de que um token existe.

Um sexto é presumir que o ERC-1155 define uma função de oferta total para cada ID.

Um sétimo é processar arrays em lote sem verificar se seus tamanhos e posições correspondem.

Um oitavo é ignorar callbacks externos de destinatário e os riscos de reentrância.

Um nono é tratar royalties como automaticamente obrigatórios.

Um décimo é tratar a conformidade com a interface como prova de autenticidade, escassez ou segurança.

Perguntas frequentes

O que significa ERC-1155?

ERC-1155 é o Multi-Token Standard da Ethereum para gerenciar vários tipos de tokens fungíveis, não fungíveis e semifungíveis em um único contrato.

ERC-1155 é uma criptomoeda?

ERC-1155 é um padrão técnico; os contratos que o implementam podem criar muitos tipos de ativos cripto.

Qual é o ID da interface ERC-1155?

O ID da interface principal ERC-1155 é

.

Qual é o ID da interface de destinatário ERC-1155?

O ID da interface de destinatário é

.

O ERC-1155 pode criar tokens fungíveis?

Sim. Um token ID pode ter muitas unidades intercambiáveis distribuídas entre várias contas.

O ERC-1155 pode criar NFTs?

Sim. Um token ID pode funcionar como NFT quando a oferta definida pelo contrato é limitada a uma unidade.

O que é um token ERC-1155 semifungível?

É um token cujas unidades são intercambiáveis em determinado contexto, mas que depois pode adquirir significado, estado ou utilidade distintos.

Um contrato ERC-1155 pode conter vários tipos de ativos?

Sim. Um contrato pode gerenciar muitos IDs com diferentes ofertas, metadados e finalidades.

O que balanceOf retorna?

Retorna a quantidade de um token ID ERC-1155 específico pertencente a uma conta.

O que balanceOfBatch faz?

Retorna, em uma chamada, os saldos de vários pares de contas e token IDs.

O que é safeBatchTransferFrom?

É uma função que transfere vários token IDs e quantidades em uma transação e verifica o destinatário quando ele é um contrato.

O que setApprovalForAll faz?

Autoriza um operador a gerenciar todos os token IDs pertencentes ao chamador em um contrato ERC-1155.

Um usuário pode aprovar apenas um token ID?

Não pela função de aprovação principal, embora extensões opcionais ou contratos personalizados possam oferecer permissões mais limitadas.

Uma aprovação de operador ERC-1155 expira?

Não. A aprovação padrão permanece ativa até ser revogada ou até que uma lógica personalizada do contrato altere seu efeito.

O ERC-1155 exige verificações de destinatário seguro?

Sim. As transferências padrão para contratos inteligentes devem seguir as regras adequadas de callback de destinatário individual ou em lote.

Um destinatário ERC-1155 pode rejeitar tokens?

Sim. O destinatário pode reverter a transação ou retornar um valor de aceitação incorreto, fazendo a transferência falhar.

O ERC-1155 oferece suporte a metadados?

Sim. Ele define uma extensão opcional de URI de metadados com o ID de interface

.

Todo token ERC-1155 tem nome e símbolo?

Não. O padrão principal não exige funções on-chain de nome ou símbolo.

O ERC-1155 define casas decimais?

Não. Quando necessário, os aplicativos devem obter informações de denominação dos metadados ou da lógica específica do projeto.

O ERC-1155 inclui totalSupply?

Não. Para consultar a oferta total, é necessário indexar eventos ou usar uma extensão opcional de oferta.

Os metadados ERC-1155 podem mudar?

Sim. Os metadados podem mudar quando o contrato ou o sistema de armazenamento externo permite atualizações.

O ERC-1155 impõe royalties?

Não. As informações de royalties exigem um padrão separado, e o contrato principal do token não impõe automaticamente os royalties informados.

Transferências em lote ERC-1155 podem economizar gas?

Sim. Transferir vários token IDs em uma única transação pode reduzir os custos recorrentes de transação.

Callbacks ERC-1155 podem causar reentrância?

Sim. Os callbacks de destinatário executam código externo e podem chamar outras funções do contrato antes que a transação original seja concluída.

A conformidade com o ERC-1155 prova que um token é seguro?

Não. Um contrato compatível ainda pode ter código inseguro, permissões excessivas, metadados mutáveis, controles de oferta fracos ou alegações fraudulentas.

Conclusão

ERC-1155 é o padrão da Ethereum para gerenciar vários tipos de tokens em um único contrato inteligente.

Cada token ID pode representar um ativo fungível, um NFT único, um item semifungível ou outro ativo cripto baseado em saldo.

O padrão define consultas de saldo individuais e em lote, transferências seguras, aprovações de operador para toda a coleção, callbacks de destinatário, eventos e detecção de interfaces.

As operações em lote podem reduzir os custos de transação quando vários token IDs precisam ser consultados ou transferidos juntos.

Os callbacks obrigatórios de destinatário reduzem transferências acidentais para contratos incompatíveis, mas introduzem riscos de chamadas externas e reentrância.

O padrão principal não define emissão pública, queima, oferta total, casas decimais, royalties ou metadados permanentes.

Essas propriedades dependem de extensões opcionais e da implementação de cada contrato.

Os usuários devem verificar a rede, o endereço do contrato, o token ID, os controles de oferta, as aprovações de operadores, o sistema de metadados e as permissões de administrador.

Os desenvolvedores devem usar implementações mantidas, emitir todos os eventos exigidos, proteger callbacks de destinatário, limitar a complexidade dos lotes e testar cada caminho de autorização.

O ERC-1155 oferece uma infraestrutura multi-token flexível e eficiente, mas a compatibilidade técnica não garante autenticidade, escassez, valor financeiro ou segurança do contrato inteligente.