Skip to content

eip-draft_ownerof_multitoken_nft.md

Latest commit

 

History

History
90 lines (60 loc) · 6.51 KB

eip-draft_ownerof_multitoken_nft.md

File metadata and controls

90 lines (60 loc) · 6.51 KB
Raw
eip XXXX
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 TBD
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 and ERC-6909 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. 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 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

/// @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 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.