Title: ERC_6551__Non_fungible_Token_Bound_Accounts
Category: ERCs

Author: sullof
Date: 2023-10-21T21:19:10.267Z

jay:

Since the Registry is a singleton contract whose address will be well-known and included in the proposal, contracts can trivially validate whether a given address matches the canonical Registry address. This address check also guarantees that the IERC6551Registry interface is properly implemented. As such, unlike other ERCs where multiple instances of a contract implementing a certain interface are expected, I don’t think ERC-165 interface detection on the Registry provides much benefit here.


I’d like to point out a few considerations with the Create2 approach. Ensuring the same address across different blockchains involves adhering to a meticulous process which may not always be feasible. Imagine a scenario where a novel blockchain emerges in the future, and the nonce on that blockchain isn’t consistent with the wallet’s previous deployment nonce. Or consider wanting to leverage an optimized proxy size for new blockchains. There could be numerous reasons making it challenging to maintain the same address universally.
Now, let’s examine this from the perspective of a developer working with ERC6551. When coding the smart contract, hardcoding the address isn’t viable, as it would only be operational on the mainnet and not on staging or during development. Hence, the registry address would be input as a deployment parameter. But then arises the challenge: how does one ensure minimalistic yet effective validation of the address to prevent unintended inclusions? Currently, a feasible approach is implementing a try-catch mechanism and verifying the output of the ERC6551Registry.account function. However, in my opinion, a standardized support for the interface would streamline this process and enhance its robustness.

Author: jay
Date: 2023-10-22T21:28:17.161Z

sullof:

Ensuring the same address across different blockchains involves adhering to a meticulous process which may not always be feasible.


I don’t think this is an accurate characterization. The proposal specifies that the registry must be deployed using Nick’s factory in order to ensure the widest possible support across EVM chains. This factory exists on 31 chains according to BlockScan, and can be deployed to any EVM compatible chain using a pre-signed transaction. Additionally, because this factory is widely used, several chains that do not support pre-signed transactions have included it as a pre-deployed contract.



 sullof:

Imagine a scenario where a novel blockchain emerges in the future, and the nonce on that blockchain isn’t consistent with the wallet’s previous deployment nonce.


This proposal is dependent on the create2 opcode, which allows for deployments that are not tied to a given account nonce. Chains that do not support create2 will not be able to support ERC-6551 as a whole (as it requires EVM compatibility), regardless of the method used to deploy the registry contract.



 sullof:

Or consider wanting to leverage an optimized proxy size for new blockchains.


If there are additional optimizations you would like to see included in the proxy bytecode I would love to discuss them and see if there is a way they could be incorporated into this proposal.



 sullof:

When coding the smart contract, hardcoding the address isn’t viable, as it would only be operational on the mainnet and not on staging or during development.


The registry can indeed be deployed to both testnets and local development environments at its canonical address. Instructions for how to do so should be documented, this would be a good addition to the reference implementation repo.



 sullof:

Hence, the registry address would be input as a deployment parameter. But then arises the challenge: how does one ensure minimalistic yet effective validation of the address to prevent unintended inclusions?


If the registry is deployed to staging / testnet environments, this is no longer an issue for developers.



 sullof:

However, in my opinion, a standardized support for the interface would streamline this process and enhance its robustness.


I don’t think ERC-165 would be any more useful than an address equality check for this use case. ERC-165 makes a lot of sense for use cases where many contracts implement a common interface (such as the ERC-6551 accounts), but not as much sense for singleton contracts.

Author: sullof
Date: 2023-10-23T17:50:48.442Z

jay:

I don’t think this is an accurate characterization. The proposal specifies that the registry must be deployed using Nick’s factory in order to ensure the widest possible support across EVM chains. This factory exists on 31 chains according to BlockScan, and can be deployed to any EVM compatible chain using a pre-signed transaction. Additionally, because this factory is widely used, several chains that do not support pre-signed transactions have included it as a pre-deployed contract.


There are blockchains that enforce EIP155-like replay protection for security reasons. If that happens, Nick’s method doesn’t work because the chainId has to be part of the transaction. Did you try to deploy it on CELO or CELO Alfajores?
PS > I use CELO Alfajores as favorite testnet.

Author: jay
Date: 2023-10-23T18:22:29.398Z

sullof:

There are blockchains that enforce EIP155-like replay protection for security reasons. If that happens, Nick’s method doesn’t work because the chainId has to be part of the transaction. Did you try to deploy it on CELO or CELO Alfajores?


Nick’s factory already exists on Alfajores despite Celo’s lack of support for pre-signed transactions. As a result, the registry can be deployed without issue. Any other chains that enforce replay protection can include this factory as a pre-deployed contract as Celo has done.

Author: sullof
Date: 2023-10-23T18:53:48.009Z

Then I don’t have other questions. Thanks

Author: arrans
Date: 2023-10-24T10:14:12.895Z

jay:

However, account state can be deterministic based on operations executed from the account. This would allow commitments to future states that are only reachable if certain conditions are met (e.g. all active approvals have been revoked). Using deterministic state mitigates the shortcomings of the currently suggested fraud prevention schemes. We are currently considering how this should be written into the proposal, and would love your feedback.


Interesting! Paraphrasing to confirm that I understand: we can prove that it was impossible to perform a chain of actions that result in the assets being transferred therefore it is safe to assume that no fraud can be committed.
I think from a technical perspective this is a really elegant solution however I think that buyers still risk being cheated because it’s so much harder to reason about relative to the alternative of declaring transitively owned assets that the buyer expects. That said, I’m keen to see what you write up so please do share it.

Author: wighawag
Date: 2023-11-21T13:04:18.396Z

Just checking in after reviewing the last draft
Really good progress, as I was reading, was skeptical at first of the multi-implementation per NFT but I agree in the end that is it actually a great way to not constraint implementations. Nice!
I got few comments

Feel like the Account standard should be a separate ERC.
on that note, execution standards has been attempted before and I wonder why you chose to use a different spec than ERC725X (ERC-725: General data key/value store and execution) which define 2 functions:

function execute(uint256 operationType, address target, uint256 value, bytes memory data) external payable returns(bytes memory)
function executeBatch(uint256[] memory operationsType, address[] memory targets, uint256[] memory values, bytes[] memory datas) external payable returns(bytes[] memory)
It is really similar than the one specified in 6551 except for

it has STATICCALL
it uses 256 bit to represent operation type
it support batch operation in its interface
have associated events

Author: jay
Date: 2023-11-22T20:04:52.560Z

@wighawag thanks, that means a lot! I definitely agree that there should be a separate smart account execution interface standard, and that this will likely become standardized in the future. Unfortunately there is no strong standard that this proposal can adopt right now, which is why an optional, minimal execution interface has been included in the spec. In my opinion this strikes a balance between having a standard interface across 6551 accounts right now while also allowing future standardization to be adopted without changes to the proposal.
Unfortunately, because ERC-725 has been in draft stage for a long time and does not have a clear path towards finalization, including it as a dependency would mean that ERC-6551 could not become finalized before ERC-725 does.
There are also several developer experience papercuts that exist in ERC-725X that have been adjusted in the recommended ERC-6551 execution interface:

using uint8 to represent operation types allows implementations to represent the value of operation as either a uint8 or an enum in their codebase without affecting the execution function selector
ERC-725X’s representation of arguments to executeBatch as arrays rather than as a single array of structs introduces additional calldata overhead (and causes two of the parameter names to be grammatically incorrect)
ERC-725X’s interpretation of operationType values is different than the equivalent values in most common smart contract accounts (e.g. Safe, Kernel), where an operation value of 1 usually represents DELEGATECALL

If ERC-725 were to be changed to fix these issues and championed towards finalization, or another proposal to standardize the execution interfaces were to gain steam, I would fully support externalizing the account execution interface.
Would love to hear @frozeman’s thoughts on this.

Author: sullof
Date: 2023-12-15T23:28:05.616Z

@jay, I’ve been implementing the Cruna protocol and have used the ERC6551Registry to deploy an NFT’s manager for each tokenID in a Cruna Vault. This experience led me to realize that the applicability of ERC6551 might extend far beyond merely linking wallets to an NFT. In fact, it seems capable of associating any relevant entity with a tokenId.
However, there’s a challenge I’ve encountered: contracts bound using ERC6551 may not feasibly implement the IERC6551Account interface due to the constraints posed by the receive function. Additionally, such contracts might not require signer validation functionality. Their primary need is access to the token’s data.
To address this, I propose an amendment to the protocol. I suggest introducing a new intermediary interface, IERC6551Bond, which could look something like this:
interface IERC6551Bound {
    function token() external view 
    returns (uint256 chainId, address tokenContract, uint256 tokenId);
}

This interface would specifically define a contract as bonded to an NFT and facilitate access to the NFT’s data.
In an ideal scenario, IERC6551Account would be an extension of IERC6551Bond, perhaps as follows:
interface IERC6551Account is IERC6551Bound {

    receive() external payable;

    function state() external view returns (uint256);

    function isValidSigner(address signer, bytes calldata context)
        external
        view
        returns (bytes4 magicValue);
}

What do you think?
PS > If you like the idea, I can raise a PR in the erc6551/reference implementation and in the ERC itself.
PS2 > I think that IERC6551Account’s interfaceId should remain the same since the selectors ar XOR-ed and the interface contains the same selectors.
PS3 > I just realized that it would be also better if in the case of a simple bond, the registry emits a different event — it looks unlikely to pass. Maybe I have to make a new proposal…

Author: jay
Date: 2023-12-16T02:41:41.587Z

sullof:

However, there’s a challenge I’ve encountered: contracts bound using ERC6551 may not feasibly implement the IERC6551Account interface due to the constraints posed by the receive function. Additionally, such contracts might not require signer validation functionality.


Could you expand on the constraints you’re referring to here? Implementing an empty receive function or one that always reverts is fine. Similarly isValidSignature and isValidSigner can always return invalid. It seems like this should cover most use cases.

Author: sullof
Date: 2023-12-16T02:44:57.310Z

jay:

Could you expand on the constraints you’re referring to here?


Right now, the registry emits an event telling the world that an account has been created.
The way for a third party to know if that is actually a TBA is to verify if it supports the IERC6551Account and IERC6551Executable interfaces. In our use of it, since we do not support it, the user knows that, despite the emitted event, that is not an account.
It would be better, IMO, if the standard supports a recognizable interface that tells the world what that specific contract is.

Author: sullof
Date: 2024-01-06T20:00:58.820Z

In our discussions with various projects regarding the Cruna protocol and its capability to produce secure NFTs linked to TBAs, a predominant concern has emerged. Many projects are apprehensive about the current limitation in trading assets contained within a TBA on standard marketplaces. This concern primarily revolves around the technical challenge of recognizing the actual owner of an asset that is, in essence, held by a TBA, and subsequently authorizing that asset for sale.
I am aware that there are ongoing dialogues with marketplace operators to address this issue and establish a system for accurately identifying the rightful owner of such assets for transactional purposes. However, I am keen to understand the current progress in these discussions. As it stands, this hurdle appears to be the main obstacle preventing the widespread adoption of the ERC6551 standard. Any updates or insights on the status of these negotiations would be greatly beneficial.

Author: 0xknon
Date: 2024-04-29T06:28:26.514Z

The standard has the function:
function token()
        external
        view
        returns (uint256 chainId, address tokenContract, uint256 tokenId);

So, I assume marketplaces should be able to identify the rightful owner by checking owner of the corresponding NFT.
Then, what is the technical challenge of recognising the actual owner of an asset that is held by a TBA ?

Author: sullof
Date: 2024-12-12T13:27:16.395Z

0xknon:

Then, what is the technical challenge of recognising the actual owner of an asset that is held by a TBA ?


Yes, it is quite easy, but exchanges have to do that check. Instead, usually, they get the owner of an asset from the events that are emitted by the contract.

Author: MidnightLightning
Date: 2025-02-03T02:56:07.979Z

This ERC has been in “Review” status for a year and a half now. What is the next step for this? It seems like a very long time to have no response either way?

Author: jay
Date: 2025-02-03T17:54:52.400Z

We haven’t moved this proposal towards finalization yet as there are still a couple of open questions surfaced during review which may require changes to the proposal:

How can marketplaces efficiently prevent bait-and-switch scams involving TBAs? There have been a few potential solutions proposed so far (see discussions about using state for this above), but they still have edge cases and have not been fully proven.
Can this proposal be made compatible with EOF? Currently it requires extcodecopy, which will only be usable by legacy contracts once EOF is live.

Once these questions have been adequately answered and the solutions have been implemented we can proceed towards finalization. If you’re interested in helping with these improvements your contributions would be welcomed!

Author: sullof
Date: 2025-02-24T08:49:02.366Z

I would be happy to help with that.
Where can I have more info about the current solutions, all the edge cases that you are trying to solve, etc.?

Author: Shymaa-Arafat
Date: 2025-05-05T11:53:47.061Z

Sorry if I’m new to the discussion, and haven’t read much about the implantation details and/or previous comments, but I think an advantage of this token is that it can solve all NFT Royalty problems mentioned here


a16z crypto – 26 Jun 24



How NFT royalties work: Designs, challenges, and new ideas
Pros and cons of existing NFT royalty designs, plus two new approaches to royalties that leverage incentive mechanisms.

Est. reading time: 20







(since it naturally keeps all the NFT trading history, irrelevant from the market place as I got from what I’ve read)
Still, I wonder how to prevent what could resemble double spending or maybe  (a fast glance at the first comment, what if someone minted 2 tokens ERC-721 and this one) or if a new buyer swept the old history by transferring it to ERC-721 (for example to get the whole sell price with no Royalties)
.
Ps.
The token is listed in Nicosia University NFT and/or web3 MOOCs as one of the Ethereum NFT tokens.