ERC-1155

ERC-1155 é o padrão multitoken da Ethereum: um único contrato pode registrar diversos tipos de token fungíveis, não fungíveis ou mistos por ID e transferir vários IDs em um só lote.

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

Resposta direta

ERC-1155 é o padrão multitoken da Ethereum. Um único contrato pode manter vários tipos de token, e cada token ID pode representar um saldo fungível, um item não fungível ou outra estrutura de oferta escolhida pela implementação. Portanto, a chave do ativo é contract address + token ID, e não apenas o ID do token.

O padrão define consultas de saldo individuais e em lote, transferências seguras individuais e em lote, aprovação ampla de operador, callbacks do destinatário, eventos de transferência e um comportamento opcional para a URI de metadados. Ele não define quem pode emitir, se a oferta é limitada, se os metadados são permanentes, quais direitos legais um token confere nem quanto vale qualquer token. Essas propriedades precisam ser verificadas no contrato exato, em seus papéis e em suas dependências externas.

Como funciona

Identifique o saldo. balanceOf(account, id) retorna a quantidade que uma conta possui de um ID. balanceOfBatch(accounts, ids) consulta pares correspondentes de conta e ID. Dois contratos podem usar o ID 1 para ativos sem relação entre si; por isso, a identidade completa continua sendo a rede, o endereço do contrato e o ID.
Autorize o chamador. O titular pode transferir seu próprio saldo ou chamar setApprovalForAll(operator, true). Essa aprovação abrange todos os IDs ERC-1155 que o titular possui naquele contrato; isApprovedForAll(owner, operator) informa seu estado. O ERC-1155 não inclui uma aprovação nativa limitada a um ID ou a uma quantidade.
Aplique uma transferência individual ou em lote. safeTransferFrom movimenta um ID e uma quantidade. safeBatchTransferFrom movimenta os arrays paralelos ids e values, cujos tamanhos e ordem devem coincidir. O agrupamento pode reduzir o overhead de transações repetidas, mas não há garantia de que seja mais barato em toda implementação ou carga de trabalho.
Verifique um contrato destinatário. Depois de atualizar os saldos e emitir o evento pertinente, uma transferência compatível para um contrato chama onERC1155Received ou onERC1155BatchReceived. Um callback não suportado, um valor de retorno incorreto ou uma rejeição normalmente reverte a transferência. Essa verificação reduz bloqueios acidentais; ela não prova que o contrato destinatário seja confiável nem que ofereça uma forma de retirada.
Reconstrua o estado a partir dos eventos. Toda emissão, transferência e queima deve aparecer em TransferSingle ou TransferBatch. A emissão usa o endereço zero como from; a queima o usa como to. Indexadores podem derivar desses registros os saldos e a oferta líquida emitida por ID, mas precisam processar corretamente todo o histórico, as reorganizações da rede e as migrações de contrato.
Resolva os metadados. A extensão opcional de URI pode retornar um modelo compartilhado contendo {id}. O cliente o substitui pelo ID hexadecimal do token em letras minúsculas, preenchido com zeros à esquerda até 64 caracteres, sem o prefixo 0x. Ainda assim, os metadados podem ser mutáveis, ficar indisponíveis ou ser enganosos, a menos que a implementação e as garantias de armazenamento indiquem o contrário.

Exemplo prático

Um contrato de jogo atribui o ID 1 a moedas de ouro, o ID 7 a passes de acesso e o ID 42 a uma espada única. Alice possui balanceOf(Alice, 1) = 500, balanceOf(Alice, 7) = 3 e balanceOf(Alice, 42) = 1.

Alice chama safeBatchTransferFrom com ids = [1, 7, 42] e values = [120, 1, 1]. Se a validação for bem-sucedida, seus novos saldos serão 500 - 120 = 380, 3 - 1 = 2 e 1 - 1 = 0; o destinatário recebe as quantidades correspondentes.
O contrato emite TransferBatch. Se o destinatário for um contrato, ele deve aceitar o lote por meio de onERC1155BatchReceived; caso contrário, toda a transação é revertida e nenhuma das três alterações de saldo permanece.
O ID 42 se comporta como não fungível apenas porque sua lógica de emissão e transferência mantém a oferta em 1. O próprio ERC-1155 não impõe essa regra. O mesmo contrato pode emitir mais unidades do ID 1 posteriormente, sujeito ao seu próprio controle de acesso.

Riscos e controles

Autoridade ampla do operador. Um operador mal-intencionado ou comprometido, aprovado por setApprovalForAll, pode movimentar todos os IDs possuídos naquele contrato. Confira o endereço do operador e o contrato, use uma carteira separada quando apropriado e revogue aprovações antigas.
Poderes de emissão, pausa e atualização. São recursos da implementação, não garantias do padrão. Examine os titulares de papéis, os administradores de proxy, os timelocks, as extensões de oferta e se uma atualização pode alterar saldos ou regras de transferência.
Divergência entre metadados e ativo. Uma URI ou um JSON hospedado pode mudar enquanto o ID on-chain permanece igual. Verifique hashes de conteúdo, persistência do armazenamento, compromissos do emissor e os direitos representados fora do contrato do token.
Erros de integração. Carteiras e indexadores podem associar os arrays do lote de forma incorreta, omitir eventos históricos, tratar mal reorganizações ou confundir o mesmo ID entre contratos e redes. Concilie chamadas de contrato, registros e saldos finais.
Risco do destinatário e de reentrância. Callbacks do destinatário executam código externo durante o fluxo da transferência. Implementações e protocolos integrados precisam ordenar o estado adequadamente e adotar proteções contra reentrância; apenas aceitar o callback não equivale a uma auditoria de segurança.
Risco de custo e liquidez. Transferências em lote ainda consomem gas e são revertidas atomicamente se uma condição obrigatória falhar. Liquidez de mercado, preços, royalties, pontes, resgate e execução de direitos off-chain ficam fora do ERC-1155.

Equívocos comuns

“Todo ID é um NFT.” Um ID pode ter qualquer quantidade; a não fungibilidade depende da oferta e da semântica da implementação.
“Um contrato significa uma coleção.” Um contrato pode conter vários tipos de token sem relação entre si, e o mesmo ID numérico em outro contrato identifica um ativo diferente.
“Transferência segura significa que o ativo é seguro.” O callback verifica a compatibilidade do destinatário, não a qualidade do contrato, o preço, os metadados nem a possibilidade de recuperação.
“Agrupar sempre economiza gas.” Muitas vezes, o lote evita overhead repetido, mas o resultado real depende da implementação, do número de IDs, das alterações de armazenamento, dos calldata e do modelo de taxas da rede.