ERC-1155

What Is ERC-1155?

ERC-1155 is an Ethereum token standard that allows one smart contract to manage many different token types.

A single ERC-1155 contract can contain fungible tokens, non-fungible tokens, semi-fungible tokens, or a combination of these assets.

The official ERC-1155 specification defines common rules for balances, transfers, batch operations, approvals, receiver callbacks, events, metadata, and interface detection.

ERC-1155 is commonly called the Multi-Token Standard.

Each token type is identified by a token ID and can have its own supply, metadata, purpose, scarcity, and economic characteristics.

This design reduces the need to deploy a separate smart contract for every asset in a large crypto application.

ERC-1155 is especially useful for blockchain games, digital collectibles, memberships, event tickets, reward systems, tokenized inventories, and applications that manage several related assets.

Following the standard improves interoperability, but it does not guarantee that a token is authentic, valuable, scarce, or secure.

Why Was ERC-1155 Created?

Earlier Ethereum token standards generally focused on one fungible asset or one collection of unique assets.

A project containing hundreds of currencies, game items, tickets, and collectibles could therefore require many separate contracts.

Every additional contract creates deployment costs, repeated code, administrative work, and integration complexity.

ERC-1155 allows these token types to share one contract and one common transfer system.

It also supports batch operations that can query or transfer several token IDs in one call.

Batching can reduce repeated transaction overhead and simplify interactions involving many assets.

The standard was designed with large token systems in mind, but it is not limited to blockchain gaming.

How ERC-1155 Works

An ERC-1155 contract records a separate balance for every combination of account address and token ID.

For example, one wallet could own 500 units of token ID 1, three units of token ID 2, and one unit of token ID 3.

Token ID 1 could represent a fungible currency, token ID 2 could represent a limited-edition item, and token ID 3 could represent a unique NFT.

All three balances can exist inside the same smart contract.

When tokens are transferred, the contract reduces the sender’s balance and increases the recipient’s balance for the selected token IDs.

The contract emits standardized events so wallets and blockchain indexers can observe the changes.

When the recipient is a smart contract, ERC-1155 performs a receiver callback to confirm that the contract accepts the tokens.

What Is an ERC-1155 Token ID?

A token ID is an unsigned integer that identifies one token type inside an ERC-1155 contract.

The same token ID can appear in another contract without representing the same crypto asset.

An ERC-1155 asset is therefore identified by its blockchain network, contract address, and token ID together.

Token ID 100 in one contract could represent a game resource, while token ID 100 in another contract could represent an event ticket.

The standard does not require token IDs to begin at zero or increase in a simple order.

Developers can assign IDs according to their application’s design.

Users should verify the complete contract address and token ID rather than relying only on a displayed name or image.

Fungible ERC-1155 Tokens

A token ID can act as a fungible asset when many interchangeable units of that ID exist.

For example, a game could issue one million units of token ID 10 as an in-game currency.

Each holder would have a quantity balance associated with token ID 10.

Units of the same ID normally have the same contract-defined properties.

The core ERC-1155 interface does not define a separate symbol, decimal value, or name for every token ID.

Projects must provide this display information through metadata or custom functions when it is needed.

Non-Fungible ERC-1155 Tokens

A token ID can function as an NFT when its supply is limited to one unit.

The address holding that unit effectively owns the unique asset represented by the ID.

Another ID in the same contract can represent a different unique item.

Unlike ERC-721, ERC-1155 does not automatically require each token ID to have a supply of one.

The contract’s minting logic must enforce uniqueness when a token ID is described as non-fungible.

Users should verify the actual supply controls before trusting a claim that an ERC-1155 item is unique.

Semi-Fungible ERC-1155 Tokens

A semi-fungible token has multiple interchangeable units during one part of its lifecycle but may later gain different meaning or utility.

Event tickets are a common example because several tickets for the same section may be interchangeable before an event.

After the event, each used ticket may become a collectible linked to a specific experience.

Limited-edition game items can also use a semi-fungible model.

ERC-1155 does not formally label a token ID as fungible, non-fungible, or semi-fungible.

The classification depends on the supply, metadata, transfer rules, and application behavior.

Core ERC-1155 Functions

The core ERC-1155 interface contains functions for checking balances, transferring tokens, and managing operator permissions.

Its main functions are

, , , , , and .

ERC-1155 also requires support for ERC-165 interface detection.

The core interface does not define public minting, public burning, royalties, total supply, token decimals, or individual token approvals.

Contracts can add these features through optional extensions or custom logic.

The balanceOf Function

The

function returns the amount of one token ID owned by one account.

It requires both an account address and a token ID.

This differs from ERC-20 because one ERC-20 contract usually represents only one token type.

It also differs from ERC-721 because an ERC-721 balance counts how many unique NFTs an address owns across the collection.

An ERC-1155 balance for one ID can be zero, one, or a larger integer.

The standard requires a balance query for the zero address to fail.

The balanceOfBatch Function

The

function retrieves several balances in one call.

The caller supplies an array of account addresses and an array of token IDs.

Each account is paired with the token ID at the same array position.

The two arrays must have equal lengths.

The function can query several token IDs for one account or one token ID for several accounts.

This reduces the number of separate blockchain calls required by wallets, games, and portfolio applications.

The safeTransferFrom Function

The

function transfers an amount of one token ID from one address to another.

The caller must be the token holder or an operator approved by that holder.

The sender must own enough units of the selected ID.

The recipient cannot be the zero address.

The function also accepts a bytes field that can contain application-specific data.

A successful single transfer emits a

event.

If the recipient is a smart contract, the recipient must pass the required ERC-1155 acceptance check.

The safeBatchTransferFrom Function

The

function transfers several token IDs and amounts in one transaction.

The caller supplies an array of token IDs and a matching array of transfer amounts.

Each amount applies to the ID at the same array position.

The arrays must have equal lengths.

The sender must have enough units of every token included in the batch.

If one required transfer fails, the entire transaction normally reverts.

A successful operation emits one

event.

Benefits of Batch Transfers

Batch transfers can reduce transaction costs when several related assets need to move together.

A player could transfer currency, materials, equipment, and collectibles in one transaction.

A reward contract could distribute several token types to one recipient in one operation.

Batching can also simplify atomic exchanges because either the complete group of assets moves or the transaction fails.

The amount of gas saved depends on the number of IDs, storage changes, receiver logic, and network conditions.

Very large batches can still exceed transaction gas limits or create denial-of-service risks.

Applications should place practical limits on user-controlled batch sizes.

ERC-1155 Operator Approvals

ERC-1155 uses collection-wide operator approvals.

The

function allows a token holder to authorize or revoke an operator.

An approved operator can transfer every ERC-1155 token ID owned by the holder within that contract.

The permission can also cover tokens that the holder receives later from the same contract.

The core standard does not let a user approve only one ID or a limited amount.

This broad permission can improve usability, but it creates significant security risk.

A malicious operator can remove every affected token while approval remains active.

The isApprovedForAll Function

The

function reports whether an operator has authority over an owner’s ERC-1155 balances.

It returns either

or .

The approval applies only within the contract where it was granted.

It does not automatically cover assets in another ERC-1155 contract or tokens that use another standard.

Users should regularly review operator approvals and revoke permissions that are no longer required.

Disconnecting a wallet from a website does not remove an approval stored on the blockchain.

Granular Approval Extensions

The broad operator model may be unsuitable when a holder wants to authorize only one token ID or a limited quantity.

The proposed ERC-5216 allowance extension defines more granular approvals by token ID and amount.

This extension is not part of the core ERC-1155 standard and should not be assumed to exist in every contract.

Wallets should clearly explain whether a transaction grants collection-wide authority or a limited permission.

ERC-1155 Receiver Callbacks

A smart contract receiving ERC-1155 tokens through a standard safe transfer must implement the correct receiver callback.

The single-transfer callback is

.

The batch-transfer callback is

.

The receiver can inspect the operator, previous holder, token IDs, amounts, and attached data.

It accepts the tokens by returning the required value.

If it returns the wrong value or reverts, the complete token transfer reverts.

This design reduces accidental transfers to smart contracts that cannot process ERC-1155 assets.

Receiver Interface IDs and Return Values

The ERC-1155 receiver interface ID is

.

The expected return value for

is .

The expected return value for

is .

A receiving contract should verify which ERC-1155 contract triggered the callback.

Accepting callback data without checking the caller can allow a malicious contract to create false deposit records.

Passing a receiver check does not guarantee that the receiving contract has a safe future withdrawal process.

Receiver Callbacks and Reentrancy

ERC-1155 receiver callbacks execute external contract code before the original transaction finishes.

A malicious receiver may call back into another function while the original transfer is still in progress.

This behavior creates a possible reentrancy path.

The ERC-1155 specification requires balance changes and transfer events to occur before the receiver callback.

Applications interacting with the token must still protect their own accounting and authorization logic.

Developers should test both callbacks using hostile receiver contracts that attempt same-function and cross-function reentry.

The current ERC-1155 implementation documentation also warns that transfers to contracts can create reentrancy risk.

ERC-1155 Events

The core standard defines

, , , and events.

These event logs allow wallets, blockchain explorers, and indexers to track token activity.

ERC-1155 is designed so supply and balance history can be reconstructed from properly emitted transfer events.

Every event must be interpreted together with the contract address that emitted it.

A malicious contract can emit familiar event names without representing an authentic project.

The TransferSingle Event

The

event records the operator, sender, recipient, token ID, and amount.

A normal transfer contains nonzero sender and recipient addresses.

Minting uses the zero address as the sender.

Burning uses the zero address as the recipient.

The standard also requires zero-value transfers to emit the appropriate event.

The TransferBatch Event

The

event records several token IDs and amounts transferred in one operation.

The IDs and values are stored in matching array positions.

The event also identifies the operator, sender, and recipient.

Batch minting uses the zero address as the sender.

Batch burning uses the zero address as the recipient.

Indexers must process every element in the event arrays to calculate accurate balances and supplies.

The ApprovalForAll Event

The

event records whether an owner enabled or disabled an operator.

It contains the owner, operator, and approval status.

The event does not transfer any tokens by itself.

It changes whether the operator can initiate future transfers from the owner.

Revoking approval does not reverse transfers completed while the authorization was active.

ERC-165 Interface Detection

ERC-1155 requires ERC-165 interface detection.

The core ERC-1155 interface ID is

.

A compatible contract should return

when is called with that identifier.

The ERC-165 standard gives contracts a common method for publishing supported interfaces.

Interface detection helps applications avoid calling unsupported functions.

A positive result does not independently prove that every function is implemented correctly or securely.

ERC-1155 Metadata

ERC-1155 includes an optional metadata URI extension.

The extension adds a

function that returns a metadata location for a token ID.

Its interface ID is

.

The URI commonly points to a JSON document containing a name, description, image, attributes, and other token information.

The core standard does not require separate on-chain

, , or functions for each token ID.

Projects can add these fields through metadata or custom interfaces.

The {id} Metadata Placeholder

An ERC-1155 metadata URI can contain the placeholder

.

Applications replace this placeholder with the requested token ID in lowercase hexadecimal form.

The formatted value must contain 64 hexadecimal characters, including leading zeros.

It must not include the

prefix.

This method lets one base URI describe metadata locations for many token IDs.

An application that performs the substitution incorrectly may retrieve metadata for the wrong asset.

Metadata Storage Risks

ERC-1155 metadata may be stored on a web server, content-addressed network, or directly on-chain.

Server-hosted metadata can change or disappear.

Content-addressed storage can improve integrity, but the content must remain available.

On-chain metadata reduces external hosting dependence but can cost more to store and update.

A mutable URI can allow an administrator to change names, images, descriptions, and attributes after users acquire tokens.

Users should examine who controls metadata and whether any permanence guarantee can be verified.

Minting ERC-1155 Tokens

Minting creates new units of an ERC-1155 token ID.

The core standard does not define a public mint function or decide who may create tokens.

An implementation can restrict minting to an administrator, smart contract, governance process, or another authorized role.

A single mint emits

from the zero address.

A batch mint emits

from the zero address.

Minting to a smart contract normally triggers the appropriate receiver callback.

Users should inspect minting authority before relying on supply or scarcity claims.

Burning ERC-1155 Tokens

Burning removes token units from circulation according to the contract’s rules.

The core standard does not require a public burn function.

A contract may allow holders, approved operators, administrators, or protocol logic to burn tokens.

A burn emits a transfer event with the zero address as the recipient.

Burning every current unit of one ID does not necessarily prevent that ID from being minted again.

The result depends on the implementation’s minting and supply controls.

Total Supply and Enumeration

The core ERC-1155 interface does not include a

function.

Supply can be reconstructed from mint and burn events when the contract follows the event requirements correctly.

An implementation can add an optional supply-tracking extension that reports total supply for each ID.

The current ERC-1155 contract library includes extensions for supply tracking, burning, pausing, and URI storage.

ERC-1155 also does not define a core function that lists every existing token ID or holder.

Applications commonly use off-chain event indexing to build these lists.

ERC-1155 Royalties

Creator royalties are not part of the core ERC-1155 standard.

The optional ERC-2981 royalty standard allows a contract to report a royalty recipient and suggested amount.

The royalty amount is calculated using a supplied sale price.

ERC-2981 communicates royalty information but does not automatically enforce payment during every transfer.

A transfer can occur without a sale, which is one reason the token contract cannot treat every movement as a royalty event.

Users should determine whether royalty settings can be changed by an administrator.

Standardized ERC-1155 Errors

The original ERC-1155 specification does not define modern Solidity custom errors.

The Final ERC-6093 error standard defines common error names for ERC-1155 contracts.

These errors cover insufficient balances, invalid senders, invalid receivers, missing operator approval, invalid operators, and mismatched array lengths.

Standardized errors can help wallets and developers explain failed transactions more consistently.

Existing ERC-1155 contracts are not required to adopt these errors.

ERC-1155 vs. ERC-20

ERC-20 normally represents one fungible token type per contract.

ERC-1155 can represent many token types in one contract.

ERC-20 uses numeric spender allowances, while core ERC-1155 uses collection-wide operator approval.

ERC-1155 includes batch transfers and mandatory receiver callbacks for smart contract recipients.

The core ERC-20 standard does not include these features.

ERC-20 can remain simpler when a project needs only one fungible crypto asset.

ERC-1155 vs. ERC-721

ERC-721 is designed for individually owned non-fungible token IDs.

One valid ERC-721 token ID has one owner.

ERC-1155 stores a quantity balance for every account and token ID combination.

This allows one ID to have many interchangeable units while another ID in the same contract has a supply of one.

ERC-1155 also supports standardized batch transfers, while ERC-721 normally transfers one NFT at a time.

ERC-721 may provide a simpler model when every asset is unique.

Common ERC-1155 Use Cases

Blockchain games can manage currencies, materials, weapons, characters, and land through one ERC-1155 contract.

Event systems can issue different ticket categories and quantities under separate token IDs.

Membership projects can create several access levels or benefit packages.

Digital artists can issue limited editions containing multiple interchangeable copies of each work.

Financial applications can use token IDs to identify maturity dates, claims, position categories, or risk groups.

Reward systems can distribute several point types or achievement items through one batch transaction.

The standard does not independently verify that a token represents a legally enforceable right or real-world asset.

ERC-1155 Approval Risks

Operator approval phishing is a major risk for ERC-1155 holders.

A malicious website may request

while describing the transaction as verification, account connection, or reward access.

After approval, the operator may transfer every ERC-1155 token the user holds in that contract.

The authority can remain active until the owner revokes it.

Users should verify the network, token contract, operator address, and permission type before signing.

A wallet recovery phrase or private key is never required to cancel an operator approval.

Batch Operation Risks

Batch operations use arrays whose positions must remain correctly aligned.

A mismatch between token IDs and amounts must cause the transaction to fail.

Incorrect indexing can transfer the wrong quantity of an asset.

Very large user-controlled arrays can consume excessive gas or make a function unusable.

A receiving contract should validate every ID and amount before accepting a batch.

Developers should test empty arrays, repeated IDs, mismatched lengths, large batches, and unsupported asset IDs.

Supply and Authenticity Risks

A token ID may appear unique because only one unit currently exists.

An authorized account may still be able to mint additional units later.

Another contract can copy the same token name, ID, image, or metadata.

The contract address and network are essential parts of an ERC-1155 token’s identity.

Users should examine minting roles, supply caps, upgrade permissions, and metadata controls.

ERC-1155 compatibility does not prove authenticity, scarcity, collateral backing, or investment value.

Upgradeable Contract Risks

An ERC-1155 contract may operate through an upgradeable proxy.

An authorized administrator may be able to change minting, transfers, approvals, metadata, fees, or other behavior.

Upgrades can repair vulnerabilities but can also introduce harmful logic.

A compromised upgrade key can place every token ID managed by the contract at risk.

Users should review upgrade authority, time delays, multisignature controls, and emergency permissions.

Supporting the correct interface does not prove that a contract is decentralized or immutable.

How Developers Should Implement ERC-1155

Developers should begin with an actively maintained and reviewed implementation unless custom balance logic is necessary.

The current ERC-1155 development guide explains multi-token balances, batch operations, receiver checks, and common extensions.

Minting and administration functions should use clear access control.

Supply restrictions should be enforced in contract code rather than only described in project documentation.

Implementations must emit all required transfer and approval events.

Tests should cover single transfers, batch transfers, mints, burns, operator permissions, invalid receivers, array mismatches, and malicious callbacks.

Developers should also verify the correct ERC-165 interface identifiers for every supported extension.

How Users Can Evaluate an ERC-1155 Token

The first step is to verify the blockchain network, contract address, and token ID.

The second step is to identify whether the token is intended to be fungible, non-fungible, or semi-fungible.

The third step is to inspect current supply, minting authority, and any supply cap.

The fourth step is to review active operator approvals associated with the wallet.

The fifth step is to determine how metadata is stored and whether it can change.

The sixth step is to identify administrator, pause, freeze, royalty, and upgrade powers.

The seventh step is to examine source code, audits, and incident history without treating them as guarantees.

The eighth step is to understand what utility, redemption right, or legal claim the token actually provides.

The ninth step is to check whether receiving contracts provide a reliable withdrawal process.

The tenth step is to test an unfamiliar contract with a small amount before transferring valuable assets.

Example of an ERC-1155 Batch Transfer

Suppose Alice owns 100 units of token ID 1, five units of token ID 2, and one unit of token ID 3.

She wants to send Bob ten units of ID 1, two units of ID 2, and one unit of ID 3.

Her wallet calls

with arrays containing the three IDs and matching amounts.

The contract verifies Alice’s balances and confirms that the caller is authorized.

It decreases Alice’s balances and increases Bob’s balances for each ID.

The contract emits one

event describing the movement.

If Bob is a smart contract, the token contract calls

.

If the recipient returns the correct value, the transaction completes.

If any balance, authorization, array, or receiver check fails, the complete transaction reverts.

Common ERC-1155 Mistakes

One common mistake is assuming that every ERC-1155 token ID represents an NFT.

Another mistake is assuming that an ID with one current unit has a permanent maximum supply of one.

A third mistake is granting operator approval without understanding that it covers every token ID in the contract.

A fourth mistake is believing that disconnecting a wallet removes on-chain approval.

A fifth mistake is using metadata availability as proof that a token has been minted.

A sixth mistake is assuming that every contract provides a total supply function.

A seventh mistake is processing batch arrays without checking their lengths and positions.

An eighth mistake is ignoring receiver callbacks and reentrancy risk.

A ninth mistake is assuming that reported royalties are automatically enforced.

A tenth mistake is treating interface compliance as proof of authenticity, scarcity, or security.

FAQ

What does ERC-1155 mean?

ERC-1155 is Ethereum’s Multi-Token Standard for managing many fungible, non-fungible, and semi-fungible token types in one contract.

Is ERC-1155 a cryptocurrency?

ERC-1155 is a technical standard, while contracts implementing it can create different types of crypto assets.

What is the ERC-1155 interface ID?

The core ERC-1155 interface ID is

.

What is the ERC-1155 receiver interface ID?

The receiver interface ID is

.

Can ERC-1155 create fungible tokens?

Yes, one token ID can represent many interchangeable units distributed among several accounts.

Can ERC-1155 create NFTs?

Yes, a token ID can function as an NFT when the contract limits its supply to one.

What is a semi-fungible token?

It is a token whose units are interchangeable in one context but later gain different meaning, status, or utility.

Can one ERC-1155 contract contain many assets?

Yes, one contract can manage many token IDs with different supplies, metadata, and purposes.

What does balanceOf return?

It returns an account’s quantity of one specified token ID.

What does balanceOfBatch do?

It returns balances for several account and token ID pairs in one call.

What is safeBatchTransferFrom?

It transfers several token IDs and amounts in one transaction and performs a receiver check when the recipient is a smart contract.

What does setApprovalForAll do?

It authorizes an operator to manage every token ID owned by the caller within one ERC-1155 contract.

Can users approve only one token ID?

Not through the core ERC-1155 approval function, although optional extensions can provide more limited permissions.

Does ERC-1155 approval expire automatically?

No, a standard operator approval remains active until the owner revokes it or custom logic changes its effect.

Does ERC-1155 require receiver checks?

Yes, standard safe transfers to smart contracts must follow the appropriate single or batch receiver callback rules.

Can a receiving contract reject ERC-1155 tokens?

Yes, it can revert or return the wrong acceptance value, causing the transfer to fail.

Does ERC-1155 support metadata?

Yes, it includes an optional metadata URI extension with interface ID

.

Does every ERC-1155 token have a name and symbol?

No, the core standard does not require separate on-chain name or symbol functions for every token ID.

Does ERC-1155 define decimals?

No, denomination information must come from metadata or project-specific logic when needed.

Does ERC-1155 include totalSupply?

No, total supply requires event indexing or an optional supply-tracking extension.

Can ERC-1155 metadata change?

Yes, metadata can change when the contract or external storage system permits updates.

Does ERC-1155 enforce royalties?

No, royalty information requires a separate standard and is not automatically enforced by the core transfer functions.

Can ERC-1155 batch transfers save gas?

Yes, combining several token movements into one transaction can reduce repeated transaction overhead.

Can ERC-1155 callbacks cause reentrancy?

Yes, receiver callbacks execute external code and can call other contract functions before the original transaction finishes.

Does ERC-1155 compliance make a token safe?

No, a compatible contract can still contain unsafe code, excessive permissions, mutable metadata, weak supply controls, or fraudulent claims.

Conclusion

ERC-1155 is Ethereum’s standard for managing many token types through one smart contract.

Each token ID can represent a fungible asset, unique NFT, semi-fungible item, or another quantity-based crypto asset.

The standard defines balance queries, single and batch transfers, collection-wide operator approvals, receiver callbacks, events, metadata rules, and interface detection.

Batch operations can reduce transaction overhead when several assets must be queried or transferred together.

Mandatory receiver callbacks reduce accidental transfers to incompatible contracts but introduce external-call and reentrancy risks.

The core standard does not define public minting, burning, total supply, decimals, royalties, permanent metadata, or individual token allowances.

These properties depend on optional extensions and the specific contract implementation.

Users should verify the network, contract address, token ID, supply controls, operator approvals, metadata system, and administrator permissions.

Developers should use maintained implementations, emit all required events, protect receiver callbacks, limit batch complexity, and test every authorization path.

ERC-1155 provides flexible multi-token infrastructure, but technical compatibility does not guarantee authenticity, scarcity, financial value, or smart contract safety.