---
title: "ERC-1155"
description: "ERC-1155 è lo standard multi-token di Ethereum: un contratto può registrare molti tipi di token fungibili, non fungibili o misti per ID e trasferire più ID in un unico lotto."
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

> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

<a id="answer"></a>

## Risposta diretta

ERC-1155 è lo standard multi-token di Ethereum. Un singolo contratto può gestire molti tipi di token e ogni `token ID` può rappresentare un saldo fungibile, un oggetto non fungibile o un’altra struttura dell’offerta scelta dall’implementazione. La chiave dell’asset è quindi `contract address + token ID`, non il solo ID del token.

Lo standard definisce interrogazioni del saldo singole e in batch, trasferimenti sicuri singoli e in batch, approvazione globale dell’operatore, callback del destinatario, eventi di trasferimento e un comportamento opzionale per l’URI dei metadati. Non stabilisce chi possa coniare, se l’offerta abbia un limite, se i metadati siano permanenti, quali diritti legali conferisca un token o quanto valga. Queste proprietà devono essere verificate nel contratto specifico, nei suoi ruoli e nelle sue dipendenze esterne.

<a id="mechanism"></a>

## Come funziona

1. **Identificare il saldo.** `balanceOf(account, id)` restituisce la quantità di un ID detenuta da un account. `balanceOfBatch(accounts, ids)` interroga coppie account-ID. Due contratti possono usare entrambi l’ID `1` per asset non correlati, quindi l’identità completa resta la blockchain, l’indirizzo del contratto e l’ID.
2. **Autorizzare il chiamante.** Un titolare può trasferire il proprio saldo o chiamare `setApprovalForAll(operator, true)`. Questa approvazione copre ogni ID ERC-1155 che il titolare possiede in quel contratto; `isApprovedForAll(owner, operator)` ne indica lo stato. ERC-1155 non include un’approvazione nativa limitata a un singolo ID o importo.
3. **Applicare un trasferimento singolo o in batch.** `safeTransferFrom` sposta un ID e una quantità. `safeBatchTransferFrom` sposta gli array paralleli `ids` e `values`, che devono avere lunghezza e ordine corrispondenti. Il batching può ridurre i costi ripetuti delle transazioni, ma non è garantito che sia più economico per ogni implementazione o carico di lavoro.
4. **Controllare un contratto destinatario.** Dopo aver aggiornato i saldi ed emesso l’evento pertinente, un trasferimento conforme verso un contratto chiama `onERC1155Received` o `onERC1155BatchReceived`. Una callback non supportata, un valore di ritorno errato o un rifiuto normalmente annullano il trasferimento. Questo controllo riduce i blocchi accidentali; non dimostra che il contratto destinatario sia affidabile o offra un percorso di prelievo.
5. **Ricostruire lo stato dagli eventi.** Ogni conio, trasferimento e distruzione deve essere rappresentato da `TransferSingle` o `TransferBatch`. Il conio usa l’indirizzo zero come `from`; la distruzione lo usa come `to`. Gli indicizzatori possono ricavare da questi log i saldi e l’offerta netta coniata per ID, ma devono elaborare correttamente l’intera cronologia, le riorganizzazioni della blockchain e le migrazioni dei contratti.
6. **Risolvere i metadati.** L’estensione URI opzionale può restituire un modello condiviso contenente `{id}`. Un client lo sostituisce con l’ID del token esadecimale in minuscolo, completato con zeri fino a 64 caratteri e senza il prefisso `0x`. I metadati possono comunque essere modificabili, non disponibili o fuorvianti, a meno che l’implementazione e le garanzie di archiviazione non indichino diversamente.

<a id="example"></a>

## Esempio pratico

Un contratto di gioco assegna l’ID `1` alle monete d’oro, l’ID `7` ai pass di accesso e l’ID `42` a una spada unica. Alice detiene `balanceOf(Alice, 1) = 500`, `balanceOf(Alice, 7) = 3` e `balanceOf(Alice, 42) = 1`.

- Alice chiama `safeBatchTransferFrom` con `ids = [1, 7, 42]` e `values = [120, 1, 1]`. Se la convalida riesce, i suoi nuovi saldi sono `500 - 120 = 380`, `3 - 1 = 2` e `1 - 1 = 0`; il destinatario riceve le quantità corrispondenti.
- Il contratto emette `TransferBatch`. Se il destinatario è un contratto, deve accettare il batch tramite `onERC1155BatchReceived`; altrimenti l’intera transazione viene annullata e nessuna delle tre modifiche ai saldi rimane.
- L’ID `42` si comporta come non fungibile solo perché la sua logica di emissione e trasferimento mantiene l’offerta a `1`. ERC-1155 non impone questa regola. Lo stesso contratto può coniare in seguito altre unità dell’ID `1`, nel rispetto del proprio controllo degli accessi.

<a id="risks"></a>

## Rischi e controlli

- **Ampia autorità dell’operatore.** Un operatore malevolo o compromesso approvato tramite `setApprovalForAll` può spostare ogni ID posseduto in quel contratto. Verifica l’indirizzo e il contratto dell’operatore, usa un wallet separato quando opportuno e revoca le approvazioni obsolete.
- **Poteri di conio, sospensione e aggiornamento.** Sono caratteristiche dell’implementazione, non garanzie dello standard. Esamina i titolari dei ruoli, gli amministratori dei proxy, i timelock, le estensioni dell’offerta e se un aggiornamento possa modificare i saldi o le regole di trasferimento.
- **Disallineamento tra metadati e asset.** Un URI o un file JSON ospitato può cambiare mentre l’ID on-chain resta invariato. Verifica gli hash dei contenuti, la persistenza dell’archiviazione, gli impegni dell’emittente e i diritti rappresentati al di fuori del contratto del token.
- **Errori di integrazione.** Wallet e indicizzatori possono abbinare in modo errato gli array di un batch, omettere eventi storici, gestire male le riorganizzazioni o confondere lo stesso ID tra contratti e blockchain. Concilia le chiamate al contratto, i log e i saldi finali.
- **Rischio del destinatario e di rientranza.** Le callback del destinatario eseguono codice esterno durante il flusso di trasferimento. Le implementazioni e i protocolli che le integrano necessitano di un ordine dello stato adeguato e di difese contro la rientranza; il supporto delle callback, da solo, non costituisce una verifica di sicurezza.
- **Rischio di costi e liquidità.** I trasferimenti in batch consumano comunque gas e vengono annullati atomicamente se una condizione necessaria non è soddisfatta. Liquidità di mercato, determinazione dei prezzi, royalty, bridge, riscatto e applicazione off-chain non rientrano in ERC-1155.

<a id="misconceptions"></a>

## Idee sbagliate comuni

- **«Ogni ID è un NFT».** Un ID può avere qualsiasi quantità; la non fungibilità dipende dall’offerta e dalla semantica dell’implementazione.
- **«Un contratto equivale a una collezione».** Un contratto può contenere molti tipi di token non correlati e lo stesso ID numerico in un altro contratto identifica un asset diverso.
- **«Trasferimento sicuro significa che l’asset è sicuro».** La callback verifica la compatibilità del destinatario, non la qualità del contratto, il prezzo, i metadati o la recuperabilità.
- **«Il batching fa sempre risparmiare gas».** Spesso evita costi ripetuti, ma il risultato effettivo dipende dall’implementazione, dal numero di ID, dalle modifiche all’archiviazione, dai calldata e dal modello di commissioni della rete.

<a id="related"></a>

## Argomenti correlati

- [ERC-20](/it/crypto/erc20/)
- [ERC-721](/it/crypto/erc721/)
- [NFT](/it/crypto/nft/)
- [Standard dei token](/it/crypto/token-standard/)

<a id="sources"></a>

## Fonti

- [ERC-1155: standard multi-token](https://eips.ethereum.org/EIPS/eip-1155)
- [API ERC1155](https://docs.openzeppelin.com/contracts/5.x/api/token/erc1155)

Source: https://wiki.fcontext.com/it/crypto/erc1155/index.mdx