페이지를 넘기고 있습니다.
다음 장을 불러오고 있습니다…
잠깐… 나만의 읽기 환경을 만들어 보세요.
글꼴과 테마는 화면 설정에서 설정하세요. 눈의 편안함도 중요합니다.
다음 장을 불러오고 있습니다…
A multi-token standard that can hold fungible and non-fungible ids in one contract.
브라우저의 읽어주기 지원을 확인하는 중…
이 읽기 자료는 현재 영어로 제공됩니다. 인터페이스에는 선택한 언어가 적용됩니다.
영어 원문 읽기 →ERC-1155 lets one contract track balances for multiple token identifiers. An identifier can represent a fungible item type with many interchangeable units, while another may have a supply of one. This differs from ERC-721's ownership model for individually unique tokens. Applications identify an asset by its network, contract, and ID, then ask how many units an address holds. The shared contract structure can reduce duplication when an application manages a large family of related items.
A game could represent health potions under one ID and admission tickets under another. A single batch transfer can send three potions and two tickets to a recipient by specifying parallel arrays of identifiers and quantities. The receiving contract must implement the appropriate acceptance behavior for safe transfers. The batch facility concerns execution and interoperability; it does not guarantee that a game continues operating, that a ticket remains redeemable, or that every item represented in the contract has equivalent economic rights.
Operator approval can authorize transfers across an owner's token types in the contract, so its scope deserves attention. Metadata may be referenced through a URI and interpreted using the standard's substitution rules. A wallet showing an attractive image is therefore displaying information associated with a token, not independently verifying the item that image claims to represent. Event logs help index balances and token activity, while project documentation is needed for issuance and redemption rules.
Always separate the interface's technical capabilities from the application's promises about the items.