ERC-6551: Non-fungible Token Bound Accounts

Tokens
,
166

I see. This use case is pretty far outside the scope of this proposal, but should be easy to accomplish without any proposal changes by separating the account and ERC20 contracts. You can create an ERC20 contract and set an existing token bound account address as the owner. That way the ownership of the ERC20 contract is permanently bound to the NFT’s account, but neither the token bound account or the ERC20 contract need to be aware of each other. This also removes the need to append additional data to the token bound account bytecode within the proposal.

This could also be easily accomplished with an external auction contract that uses immutable storage. There is no need to include ERC20 or auction logic inside of a token bound account.

salt is required as a parameter in order for the registry to have the ability to create multiple accounts per instance/NFT combination.

1 Like
167

I see, then that is a reasonable cause to include it in the bytecode.

You’re right, I failed to see the bigger picture here. Essentially, we can introduce token bound functionality to any smart contract by making certain interactions to be performed via a token bound account.

Still, I wonder if any other folks can find use-cases where the extraData would make sense.

1 Like
168

Hi @Jay,
Thankyou for this wonderful new ERC and all your replies.

I’m considering implementing this ERC in a project I’m starting, but I’m worried that the interface could change. Is there some expected finalization date? Forgive my lack of experience with the process. Thankyou.

169

I came here intending to write this same comment.
A project I’m working on could really benefit from TBAs and I’m eager to use 6551, but I’m not familiar enough with the ERC process to know where this proposal stands.
What’s it waiting for? Is it “safe” to implement it today?

170

The current version of this EIP is in “Draft” status. As the tooltip on the “draft” status on that page indicates, EIPs in draft form might still have significant changes made before finalizing, so it’s not recommended to rely on its current form just yet. The EIP process itself is laid out in EIP-1, which indicates the next step for this EIP is the original author flagging it as ready for peer review, which moves it to the “Review” stage.

1 Like
171

My options!

172

Just posting a link to a competing EIP idea isn’t all that helpful in furthering discussion. If you think the proposal in this thread can be improved in specific ways, can you call out what those specifically are? The EIP idea you’re promoting is for very different use-cases (cross-chain interactions) and therefore I don’t really see how it adds “options” to this proposal?

173

There is a discussion going on about the name of the function to get the owner of the bound account. That must be solved before move from Draft to another state. That, of course, is a problem for everyone is implementing this EIP.

@jay I am assuming that you are going with isValidSigner. Any news about it? I haven’t seen any PR on the repo.

174

I am mainly concerned about usage scenarios. For example, whether this standard can collect assets in multiple chains. As I said in the article, I have an nft on eth. Can I use this to hold other nfts on polygan? ? And can this nft be held by multiple parties and jointly promoted?

175

The goal of ERC-6551 is to give each ERC-721 token a token-bound account with full Ether account functionality, which makes NFTs no longer just static assets, but with more utility and functionality, opening up a world of new possibilities. The realization of this concept may lead to a variety of new applications and innovations that will allow NFT to play an even greater role in the digital asset and blockchain space.

176

ERC-6551 does not cover those two scenarios. However it does serve as a base logic layer that both those ideas could be built on top of as separate EIPs/applications.

177

ERC6551 specifies a way to associate smart-contract wallets to any NFT. That works only on the chain where the account is deployed. To manage assets on different chains you should use a bridge like Wormhole, but that is out of the scope of this proposal. If you like to explore that, you can consider using GitHub - ndujaLabs/wormhole-tunnel

About the second question, you can do that letting a multi-signature wallet hold the NFT that holds the bound-account.

178

The ERC-6551 DRAFT looks really complicated and does not clearly demonstrate why such a complicated use case is required.

For just one example: the first use case is trustless counterfactual sending of NFTs. But then later it talks about upgradable contracts, which is the opposite of trustless.

The many levels of complexity that are added by this contract are not sufficiently motivated by motivation section text in the draft.

179

@fulldecent appreciate the comments! Can you expand on your complexity concerns?

This proposal specifies a canonical registry from which to deploy smart contract accounts owned by NFTs. Each account is an ERC-1167 proxy to a contract which implements an interface defined in the proposal. Given the stated motivation of giving every NFT an account, how would you recommend simplifying the proposal to achieve this goal?

The proposal does not mention or rely on upgradable contracts (although there has been some discussion about them in this thread). Can you provide some more details about your concerns here?

1 Like
180

Has the team considered, looked at or spoke to the Charged Particles team? CP has been doing this for a couple years and has lots of trial and error and I think there is a lot to be learned from them as well as possible collab.

181

Can you give some examples of what these applications are?

182

Is this extract from the ERC spec not contradictory?

    /// By default, token bound accounts MUST allow the owner of the ERC-721 token
    /// which owns the account to execute arbitrary calls using `executeCall`.
    ///
    /// Token bound accounts MAY implement additional authorization mechanisms
    /// which limit the ability of the ERC-721 token holder to execute calls.

If the ERC specifies that TBAs must allow execution of arbitrary calls by NFT owner but may limit these calls, then arbitrary calls are not allowed, no?

In addition…

Suggestion: change of verbiage.

Having the TBA return as owner the account that owns the NFT goes against the spirit of “the NFT owns the TBA”.

To mitigate this, I suggest changing the function name to tokenOwner.

    /// @dev Returns the owner of the ERC-721 token which controls the account
    /// if the token exists.
    ///
    /// This is value is obtained by calling `ownerOf` on the ERC-721 contract.
    ///
    /// @return Address of the owner of the ERC-721 token which owns the account
    function owner() external view returns (address);

In addition, is this factually correct?

The specification proposed above allows ERC-721 tokens to have multiple token bound accounts, one per implementation address.

If you change the salt, given the same implementation you get a different TBA, no?

Lastly, regarding this mentioned asset rug mitigation:

Here are a few mitigations strategies to be considered:

* Attach the current token bound account nonce to the marketplace order. If the nonce of the account has changed since the order was placed, consider the offer void. This functionality would need to be supported at the marketplace level.

What is there to stop a third party approved operator from moving the assets thus avoiding increment of the nonce?

3 Likes
183

I made the same proposal a while ago and you can read a long discussion starting from ERC-6551: Non-fungible Token Bound Accounts - #125 by sullof
A lot of comments after you can see @jay saying that they are working on renaming the function.
However, it would be very helpful if the name of function is defined as soon as possible.

1 Like
184

We were pleasantly surprised to see A3S being mentioned in the discussion. We’ve been diligently working on A3S Protocol since 2022 and our product V1.0 has successfully achieved the NFT-gated contract address feature. This empowers the bulk transfer of on-chain assets and off-chain interaction records, enhancing the liquidity of addresses.

We’re thrilled that ERC6551 has become a trending topic. It has always been our mission to make the concepts and innovations of account abstraction more widely known and understood by the community.

Regarding @jay’s analysis, we find some of the points agreeable and would like to share our perspective as well:
Firstly, the functionalities of A3S and ERC6551 align closely, both are trying to let an NFT have ability to control assets, the slightly differences is that ERC6551 focuses on NFT’s ID can own accounts/wallets while A3S focuses on NFT itself being accounts/wallets. However, technically speaking, we can achieve same outcomes with minor code modifications.

Secondly, concerning “centrally owned and upgradable”, our initial version of product is actually a monetised application, so evidently we need it to be upgradeable to meet the demands of the market and users, it’s a common practice for projects rapidly evolving and iterating like us. We will renounce ownership and achieve full decentralisation at any time when we achieve our desired goals.

We have taken the first step by integrating crypto assets into NFTs and our long-term goal is to improve user-friendly interactions across diverse scenarios in crypto world. Hope we could engage in meaningful discussions with your team and join forces on EIP promotion and adoption.

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