ERC-6551: Non-fungible Token Bound Accounts

ERCs
, ,
185

Thank you to everyone who has commented on this proposal so far! We have submitted an update to the proposal which aims to address many points of feedback received so far. Here is a summary of the proposal changes:

  • The owner() method has been removed from the required account interface

    While this method was originally included to ensure compatibility applications that utilize EIP-173, several compelling reasons to remove it have been voiced in this thread:

    • Requiring account implementations to return a single owner address makes it difficult for this proposal to support semi-fungible tokens
    • The return value of owner() is redundant, as ownership of a token can be queried based on the return value of token()
    • The owner() method may cause unwanted bugs since it overlaps with often used Ownable contract implementations
    • Cross-chain account implementations cannot easily query for a token owner if the token exists on another chain

    Many thanks to @dongshu2013, @RobAnon, @0xTraub, @urataps, and @sullof among others for their dialogue on this point.

  • An isValidSigner(address signer, bytes context) method has been added to the account interface

    This method allows external callers to determine whether a given account is authorized to act on behalf of a token bound account, replacing the owner() method as the primary means of querying account authorization. This method gives account implementations greater control of their authorization models, and is better suited to supporting semi-fungible token bound accounts.

  • The nonce() method has been re-named to state()

    This change better reflects the goal of the function (allowing external contracts to introspect account state) and disambiguates it from the common understanding of an account nonce (an incrementing value used for replay protection). It also ensures that this function does not overlap with existing account implementations, enabling account implementations to more easily adopt this proposal.

  • The executeCall(address to, uint256 value, bytes data) method has been removed from the account interface in favor of a variable execution interface to be exposed by account implementations

    Allowing accounts to define their own execution interface allows this proposal to be compatible with both existing execution interfaces (e.g. Safe, EIP-725x, Kernel, etc) and upcoming execution interface standards (e.g. EIP-6900) without requiring account implementations to support multiple execution paths.

  • The recommended execution interface now supports delegatecall, create, and create2 operations

    This change allows account implementations to support any type of state change operation and ensures forward compatibility with future operation types. Thank you @wighawag for recommending this change.

  • The AccountCreated events emitted by the Registry are now indexed by implementation, tokenContract, and tokenId

    This change enables easier indexing and querying of previously created token bound accounts. Thank you @MidnightLightning for the thoughtful reasoning here.

We are also excited to welcome several new co-authors who have contributed significantly to the development of this proposal and the explorations that preceded it:

This proposal has been moved to the Review stage (pending PR approval). We hope to minimize breaking changes to the interfaces defined in this proposal as we move forward toward finalization.

9 Likes