So I’ve been building Financial NFT-based wallets for years now, and I’ll be honest, I’m a bit disappointed that Revest and my team weren’t a part of this EIP’s formulation. We have some stuff we’d love to contribute to it and some EIPs we’d love to branch off of it. Currently in the process of building our V2, were important in getting 6780 put together, and definitely don’t think there should be a standard surrounding the core tech we’ve developed that we aren’t a part of helping out with.
@jay I’d be very interested in getting connected. You can find me on Telegram as “RobAnon” - let’s get something put together, because having chain-wide standards for this sort of thing has been a long-time goal of ours.
Replying to this thread to make sure it’s included. We’re interested in working together with you on this EIP and either including naive support for ERC-1155, or developing an extension of this EIP in parallel to support it. Also want to discuss valuation mechanics, as those are crucial to the success of such a system.
Hey @RobAnon! We would welcome your contributions to this proposal. It is still in draft specifically so that folks interested in this pattern can contribute before it goes to review.
The biggest difference between Revest’s product and this proposal seems to be that this proposal applies to all ERC-721 tokens, while Revest seems to only work with ERC-1155 FNFTs created using the protocol. Please correct me if I’m wrong about this.
The key challenge to supporting ERC-1155 tokens is the lack of a canonical owner for a given token. In the absence of a canonical owner, how would you recommend handling authorization at the account level? How does Revest handle this? If there is a canonical owner for each ERC-1155 token in a collection, these tokens can already be supported within the current structure of this proposal by adding an ownerOf method to the ERC-1155 contract (as ENS NameWrapper does).
For ERC-1155 tokens without a canonical token owner, given the lack of totalSupply support in the ERC-1155 standard, it doesn’t seem like there is a clean way to determine who is allowed to control the account without resorting to 1-of-n execution (anyone whose balance is greater than zero has owner permissions on the account). This makes it challenging to support every ERC-1155 token that exists, which would be ideal if ERC-1155 support is explicitly included in the proposal.
There are a few options to add ERC-1155 support that have been considered:
Remove the concept of a canonical owner address in favor of an isOwner(address) returns (bool) function which determines whether a given wallet is the owner of a token. The implementation would be responsible for determining if an address holds the correct balance of tokens to be considered an owner. This requires a change to the account interface, complicates the security model, and makes it difficult to optimize for the current use case which is ERC-721 tokens (which have a canonical owner).
Parameters under which ERC-1155 token ownership is canonical can be passed in the salt value to a custom account implementation. This could be min/max balance thresholds for example. The implementation could allow “claiming” of an account, causing the caller to become the canonical owner if they meet the balance threshold requirements. This would break the current behavior of automatic transfer of account to the new canonical owner when the underlying token is transferred, which seems less than ideal.
ERC-1155 token bound accounts could be considered unique per holder/token combination. This would mean that every unique holder of an ERC-1155 would have a corresponding token bound account address, with optional balance threshold enforcement at the implementation level. This can be accomplished by passing in the holder address as a part of the account salt. This means that there would not be a single canonical token bound account for a given ERC-1155 token, but rather many accounts, one per holder. Depending on the desired use case, this might be useful.
ERC-1155 tokens could be “wrapped” into an ERC-721, allowing for usage with the existing architecture without any proposal changes.
I’m sure there are other approaches here as well, and would love your thoughts on them drawing on your depth of experience at Revest. We’d love to reconsider ERC-1155 support as a part of this proposal, but understand that the significant differences in functionality between ERC-721 tokens and ERC-1155 tokens may necessitate a separate proposal.
Revest V2 is slated to support both 721 and 1155. It makes sense for us to ensure that positive changes we’ve introduced within it are reflected in the system that you build here. It also makes sense for you that we use this standard in production, as that’d propagate it further and help drive consolidation efforts.
We view this proposal in the context of a series of three proposals that should be published to describe a unified set of Financial NFT standards. I agree with you that 721 might make sense as its own standard, but to be completely honest, I think that even having an NFT type attached to this standard is likely unnecessary. 1155 singletons work well with the 721 system, and while they don’t support ownerOf, they would function just fine on their own. External to this, if you window the functionality to deposit/withdraw functions, 1155s work just fine even with their multiple owners. We use our internal supplyOf(address) and balanceOf(address) to determine what proportion of a given ERC20 an account owns. When you limit these wallets on a per-asset basis, it opens a lot of doors - that’s what we’re interested in discussing w/r/t 3 proposals.
Can you help me understand why you feel it is necessary to have an ownerOf function in the smart wallet?
With respect to supplyOf, EIP-5615 seeks to address this. Revest FNFTs already support this, as it is a necessity for determining subdivideability.
I’m the dev working on Revest V2. A potential implementation for the system is that only the user who owns the entire supply of a given 1155 is able to access the smart wallet. It is functionally the equivalent of having a canonical owner like in 721 but being slightly more strict. It requires some extra work on behalf of the wallet deployer to ensure this but is certainly better than nothing and works in conjunction with EIP-5615
@RobAnon Thanks for providing some extra context! Would love to ensure that Revest V2 can use this proposal.
To clarify: singleton ERC-1155 tokens will work out of the box with the structure of this proposal. All that’s necessary is a custom account implementation that can correctly determine the canonical owner given a token ID. Adding an ownerOf method to the ERC-1155 just means you can use existing account implementations designed for ERC-721 tokens without the need for custom account logic.
Having a single canonical owner is important for a few reasons. First, it allows for (partial) ERC-173 support and (full) ERC-5313 support, making token bound accounts compatible with existing tooling that uses owner() calls to determine smart contract ownership. This seems like a desirable characteristic. Secondly, it enables automatic transfer of account ownership when the underlying asset is transferred. These two traits seem very desirable in the context of ERC-721 tokens, but may be less important in the context of ERC-1155 tokens.
One goal of this proposal is to give every NFT a self-sovereign account, allowing NFTs to execute arbitrary on-chain actions just like any other account. Restricting the actions a wallet can take is the responsibility of the account implementation to enforce, not the registry.
One potential low-hanging-fruit proposal change which would allow ERC-1155 support within this proposal would be to specify that the return value of owner() may be the zero address for tokens that do not have a canonical owner. This would allow the development of ERC-1155 backed token bound accounts without changing the existing account interface. Revest’s custom implementation could use EIP-5615 balance calculation to determine execution permissions, while still allowing the canonical account owner to be queried for ERC-721 token account implementations.
Great to have you here @0xTraub! This is definitely possible with the changes I mentioned in my previous post.
The challenge with using this method within an owner() function is that you need more information than just the token ID to determine the canonical owner of an ERC-1155 token. Specifically, you need to know which account to check the balance of. This data is unavailable within the context of the current owner() function for ERC-1155 tokens, whereas it is queryable using the ownerOf method for ERC-721 tokens.
In this case the owner is whomever owns 100% of the supply of the 1155 ID. It’s not idea especially if that 1155 is traded frequently but its certainly better than nothing and provides some notion of ownership.
@0xTraub this is correct, and works out of the box with this proposal in cases where the user address is known (when authorizing execution of a transaction for example).
However, within the context of an external owner() call the user address is not known (for example, if an external contract/dapp is checking ownership of an unknown account).
The owner() call issue can be solved by either:
Storing the current owner of an account in storage and allowing callers to “claim” control of the contract if they meet certain balance thresholds (option #2 listed above). Importantly, the owner() method does not need to be used to authorize transactions.
Modifying the spec to specifically allow owner() to return zero if there is no canonical order
In either case, this seems to be a relatively low lift and allows for native ERC-1155 support within this proposal. These approaches might not be a perfect fit for Revest v2 if you have strict requirements around minting/burning ERC-1155 tokens, but if Revest uses centrally controlled NFT contracts already it might make sense to bake this logic into the ERC-1155 tokens themselves.
Would love to understand if these changes allowing for ERC-1155 support would make it possible for Revest v2 to adopt this proposal.
ERC-1271 support is required for all accounts already (see the Account Interface section).
I agree that the execution interface is a bit rough at the moment. The intent behind not mentioning delegate_call, create or create2 is to minimize the required interface for accounts. Account implementations that wish to add support for other calls can do so outside the scope of the proposal (e.g. via an executeDelegateCall method).
As smart contract accounts become a more popular pattern, I think there needs to be a separate EIP that proposes a standard execution interface for smart contract accounts. The closest I’ve seen so far is ERC-725X, but it’s been in draft for a very long time. We would support a proposal attempting to standardize this.
In the absence of a standard contract account execution interface, this proposal includes a minimal execution interface to ensure all 6551 accounts can be called in the same way regardless of implementation. Would welcome any feedback on how we could make this interface more flexible or more standardized.
There are also situations where we don’t want to support 1271 (or any real functionality). Consider a wallet holding a bunch of soulbound tokens where I don’t want anyone else adding any other tokens to it.
@wwhchung this is interesting! One thing I’ve been thinking of in this area is the concept of a null account - an account where the implementation address is set to the null address. This would give every NFT an address that can receive assets without allowing future withdrawals or executions. This would essentially provide a mechanic for permanently binding any onchain asset to any NFT. Curious to hear if this would fit your use case.
@jay What would be the benefit of permanently binding a non-executable or withdrawable asset to an existing NFT? Having these emphemeral wallets binded to a revest FNFT makes sense because it allows you to gain at least some kind of utility from it during the length of the locking period.
@0xTraub The use cases I’m thinking of are mostly around unique burn mechanics for NFTs. Imagine an NFT that evolves over time based on the type of tokens / value of tokens that you’ve sent to its null account. Obviously a null account burns every asset which means the assets are lost, but it burns them in such a way that they have provenance which could be valuable in some circumstances.
This seems like a nice little edge case that folks could get creative with, not something that is a primary use case of the proposal.
@jay so it would have value based on the owner of the NFT that burned them? Not sure why that gives the NFT value. Also that would seem to have a potentially negative effect on the seller. If Alice burns an asset through this mechanism and then sells the NFT well they’re no longer able to reap the rewards of having burned the item, and it would be attributed to the person who buys it, which sounds like giving them applause for doing nothing at all. Not sure what the benefit here is for this. I’m not against it but sounds unnecesarry.
@0xTraub This is fairly tightly scoped and would only be useful to NFT projects that would otherwise make use of burn mechanics. Definitely doesn’t apply to all NFTs. I don’t think it’s necessary either, but I do think it has creative applications in a similar way that burn mechanics have creative applications.
I like the idea but I am concerned about addressing potential MEV-related issues.
Imagine a situation where an account holding 1M ETH is linked to an NFT. A malicious owner could collude with miners to sell the NFT on OpenSea. When the NFT is sold, the miner could prioritize a transaction to transfer the 1M ETH elsewhere before the atomic swap occurs.
One possible solution for OpenSea is to verify the wallet balance before performing the atomic swap, using the balance as a parameter, and ensuring it remains unchanged during the swap. However, it seems unlikely that OpenSea would adopt this approach. Moreover, even if implemented, a malicious owner could still add numerous fake assets to the linked account, making it impossible to confirm the full balance without exceeding the gas limit.
@sullof this is an important issue that affects all stateful NFTs, not just NFTs with token bound accounts. Ultimately marketplaces are responsible for ensuring the safety of their users when performing trustless NFT sales. Preventing fraud is beyond the scope of this proposal, as mentioned here.
With that said, we’re collaborating with several marketplace teams to ensure that trustless sales of NFTs with token bound accounts can be performed safely. To take Seaport as an example, this type of fraud can be prevented by passing in the address of a smart contract (called a zone in Seaport lingo) that can execute arbitrary validation logic after an order has been processed in order to determine whether the contents of the token bound account have been maliciously altered in any way. By looking at the nonce of the account, the zone can determine whether any transactions have been executed from it which would invalidate the order, without running into gas limits. Approval-based transfers are an obvious edge case here, but there are several validation/prevention strategies that can be used to address that as well. Marketplaces can also help to prevent fraud at the client level by showing the contents of the token bound account in the UI along with all active approvals.
While fraudulent attacks using stateful NFTs are definitely a concern, there are clear paths forward for marketplaces to prevent them.