--- eip: 8276 title: Non-Fungible Multi-Token ownerOf description: A canonical ownerOf interface for non-fungible ERC-1155 and ERC-6909 token IDs. author: Prem Makeig (@nxt3d) discussions-to: https://ethereum-magicians.org/t/erc-8276-non-fungible-multi-token-ownerof-erc-1155f-erc-6909f/28646 status: Draft type: Standards Track category: ERC created: 2026-05-23 requires: 165, 721, 1155, 5409, 5615, 6909 --- ## Abstract This ERC defines a minimal `ownerOf(uint256 id)` interface for non-fungible [ERC-1155](./eip-1155.md) and [ERC-6909](./eip-6909.md) multi-token contracts. Each token ID has a supply of either zero or one unit, and its current holder can be read with the same function selector used by [ERC-721](./eip-721.md). The interface lets wallets, marketplaces, delegation registries, indexers, token-bound integrations, and agent-binding integrations consume non-fungible multi-token IDs through a single-owner accessor without requiring the contract to implement ERC-721. Implementations of this profile are informally referred to as ERC-1155F and ERC-6909F, where the `F` denotes the non-fungible profile of the respective base standard. ## Motivation ERC-1155 and ERC-6909 can both represent fungible and non-fungible token IDs within one contract. Their base interfaces expose balances by `(owner, id)`, but they do not expose a canonical single-owner read for IDs whose supply is fixed to one. Integrators that understand ERC-721 ownership through `ownerOf(uint256)` therefore need bespoke adapters, offchain indexing, or contract-specific logic for non-fungible multi-token IDs. This gap already appears in production: the ENS NameWrapper represents wrapped names as single-unit ERC-1155 token IDs and exposes `ownerOf(uint256)` for direct owner lookup. Standardizing that profile makes the pattern reusable by tools that need to resolve a single controlling account for a token ID. This ERC generalizes the Stagnant [ERC-5409](./eip-5409.md) proposal for ERC-1155 by retaining the same `ownerOf(uint256)` selector and ERC-165 interface identifier while adding ERC-6909 support and specifying the relationship between `ownerOf`, supply, and balances. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. ### Interface ```solidity /// @title Non-fungible multi-token owner lookup /// @dev The ERC-165 interface identifier is 0x6352211e. interface IERC_NFMultiTokenOwnerOf { /// @notice Returns the owner of a non-fungible multi-token id. /// @dev Returns address(0) if the id has no current owner. /// @param id The token id to query. /// @return owner The current owner of id, or address(0) if unowned. function ownerOf(uint256 id) external view returns (address owner); } ``` The ERC-165 interface identifier for `IERC_NFMultiTokenOwnerOf` is `0x6352211e`, calculated as `bytes4(keccak256("ownerOf(uint256)"))`. This is the same function selector used by ERC-721 `ownerOf(uint256)`. Support for this interface applies to the contract as a whole: every token ID in an implementing contract is in the non-fungible profile. An ERC-1155 or ERC-6909 contract that implements this ERC: - MUST implement ERC-165 and return `true` for interface identifier `0x6352211e`. - MUST implement either ERC-1155 or ERC-6909. - MUST ensure every token ID has total supply of either `0` or `1` at all times. - MUST NOT allow a token ID to be owned by more than one address at the same time. - MUST return the current owner from `ownerOf(id)` when `id` is minted and has supply one. The returned owner MUST hold a balance of exactly one for that id: whenever `ownerOf(id) != address(0)`, `balanceOf(ownerOf(id), id)` MUST equal `1`. - MUST return `address(0)` from `ownerOf(id)` when `id` has supply zero, including before minting and after burning. - MUST ensure that `ownerOf(id) == owner` if and only if `balanceOf(owner, id) == 1` for a token ID with supply one. - MUST ensure that `balanceOf(account, id)` is either `0` or `1` for every account and every token ID. - MUST emit the transfer events required by the underlying ERC-1155 or ERC-6909 standard when minting, transferring, or burning a token ID. If an implementation exposes a total supply function for a token ID, such as [ERC-5615](./eip-5615.md) `totalSupply(uint256)`, the returned supply for that ID MUST be either `0` or `1`. Implementations SHOULD NOT revert solely because a token ID is currently unminted or burned. ## Rationale The interface is deliberately one function. ERC-721 `ownerOf(uint256)` is already the common single-owner read used by NFT tooling, so reusing the same selector avoids another adapter shape for multi-token standards. It also lets contracts such as ENS NameWrapper keep their existing owner lookup while making the behavior discoverable through ERC-165. Returning `address(0)` for unminted or burned token IDs follows ERC-5409 and avoids requiring callers to use revert handling to distinguish absent ownership. This differs from ERC-721, where `ownerOf` reverts for invalid token IDs, but it is better aligned with multi-token balance queries where absence is represented by a zero balance. ERC-1155 and ERC-6909 are included in one ERC because the ownership accessor, selector, ERC-165 identifier, balance invariant, and integration use cases are identical. Splitting them would duplicate the same interface and increase the risk that tooling supports one multi-token standard but not the other. ## Backwards Compatibility This ERC is backward compatible with ERC-1155 and ERC-6909 because it only adds an optional read interface and does not change either base standard. Existing ERC-5409-style ERC-1155 contracts can be compatible if they satisfy this ERC's invariants and support `0x6352211e` through ERC-165. ERC-721 integrations can reuse the `ownerOf(uint256)` selector, but MUST NOT assume full ERC-721 compatibility unless the contract also supports ERC-721. ## Security Considerations Implementations MUST keep `ownerOf(id)` synchronized with balances and transfer events. A stale owner value can cause integrations to grant authority to the wrong account. Implementations MUST enforce the `0` or `1` supply invariant across minting, transfers, burns, and administrative flows. Consumers MUST treat `ownerOf(id) == address(0)` as no current owner, not as proof that the ID can never exist. Contracts that use owner lookup for authorization SHOULD read ownership at the point of use and account for transfer ordering and reentrancy. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).