---
title: "ERC-1155"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# ERC-1155
> 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
1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
## Tópicos relacionados
- [ERC-20](/pt-br/crypto/erc20/)
- [ERC-721](/pt-br/crypto/erc721/)
- [NFT](/pt-br/crypto/nft/)
- [Padrão de token](/pt-br/crypto/token-standard/)
## Fontes
- [ERC-1155: Padrão multitoken](https://eips.ethereum.org/EIPS/eip-1155)
- [API do ERC1155](https://docs.openzeppelin.com/contracts/5.x/api/token/erc1155)
Source: https://wiki.fcontext.com/pt-br/crypto/erc1155/index.mdx