I’m not sure that we are talking about the same thing… Why would you waste gas on a view function being called directly? View functions are free… 
Thank you, but the discussion here is focused on 6454 and 6059 is finalized anyway. The point is, that 6059 is a great example of this implementation being useful.
I’m not sure that we are talking about the same thing… Why would you waste gas on a view function being called directly? View functions are free…
If they’re doing the check on contract, then it wastes gas. View functions used within a contract write are not free.
If they’re only using it for the frontend, it’s not necessary at all because you can do the same without that method. And in fact, you’d probably just end up using the function I pseudo-coded above for maximum compatability.
True, but it is used for both, and if you have conditional mechanics attached to it, you need to be able to call this within a contract.
Let’s say you have a game token that gets a buff if they have a non-transferable token equipped into it (like ERC-6220 allows). You have to be able to validate non-transferability from within the smart contract.
You might get special conditions when selling a token that has a non-transferable token nested. This also requires the function to validate non-transferability when calculating a discount or special fee…
As I was explaining, you don’t. You are simply wasting gas by attempting to do on contract validation, as simply doing the transfer would fail, and your frontend should be simulating the tx before even submitting.
I’ve provided a few code examples above which would be functionally equivalent on both the UX and smart contract side without doing the additional check for the case you’re describing. In fact, that’s how most smart contracts try to save on gas efficiency, by removing unnecessary checks that would cause reversions anyways. This would fall under this category.
Do you have a sample piece of smart contract code that illustrates where the standard transferFrom revert wouldn’t work and this new view method is absolutely needed?
example of exactly what I mean:
smart contract pseudocode
function buyNFT(address owner, address contractAddress, uint256 tokenId) {
require(!ERC6454(contractAddress).isNonTransferable(tokenId), "Cannot be transferred");
ERC721(contractAddress).transferFrom(owner, msg.sender, tokenId);
}
vs:
function buyNFT(address owner, address contractAddress, uint256 tokenId) {
ERC721(contractAddress).transferFrom(owner, msg.sender, tokenId);
}
Would both cause a revert if it’s not transferrable, except the second one uses less gas. There’s no reason to call the view method beforehand, because, even if you implemented it, you would use the same underlying check within transferFrom (see:
)
I have yet to see an example where ERC6454 helps. This example shows why it’s unecessary at the smart contract level (both cases will revert anyways), and the post right before shows how you can accomplish the same check already, without ERC6454, on a frontend UX.
Btw, if we’re talking about ‘conditional’ checking to change behavior, I get that case. But I would also say that, in that case, you want a general ‘attribute’ EIP for NFT’s, not something specific to ‘soulbound’, since you’re going to end up with a billion EIP’s for all these features and properties.
I think you missed the point of the last reply. You do. Because tokens being non-transferrable could influence a game or a fee.
Some pseudo-code to illustrate it:
function calculateGemDamageBuff(address gemCollectionSmartContract, uint256 gemTokenId) returns (uint256) {
uint256 baseDamage = gemCollectionSmartContract.baseDamage(gemTokenId);
uint256 damageMultiplier;
gemCollectionSmartContract.isNonTransferable(gemTokenId) ? damageMultiplier = 2 : damageMultiplier = 1;
return baseDamage * damageMultiplier;
}
If you want to run a game on-chain, you need ifNonTransferable if you don’t you can ignore the proposal and implement the game mechanic the web2 way.
There is more benefit to be gained by this proposal than just simple blocking of transfers (which is an integral part of it, just to be clear).
Just saw this reply after sending the previous one…
You could, but this is minimal in order to reliably serve as many use cases as it can.
Soulbound or non-transferable is quite universal and useful for many use cases. It is quite beneficial to have it standardized.
Not everyone has to agree with an EIP, if it is useful for enough use cases, it benefits from becoming a standard. You are not forced to use it.
Also, these same arguments can be applied to disqualify the usefulness of ERC165, which is obviously useful at this point.
Ya, just responded to this as well. There’s many on-chain attribute props that can trigger different behavior/computation.
I would say that an EIP that allows for storage of a prop is more effective than one specifically around transferability. Where do you draw the line between what is/isn’t generalizable enough to be a completely separate method and EIP?
This doesn’t seem like one of them.
Btw, I can see this use case, but the ones from before around it being useful for marketplaces/etc. aren’t really for the reasons I mentioned.
The use case that this EIP specifically enables is dynamic non-revert behavior changes based on transferability. Just want to be clear as to what this actually enables.
Looking at alternative solution you proposed.
The front end part: Yes sure the pre-check would work, but it is important to take FE developer’s UX in mind, and not just end-user’s UX. As a client-side developer, I would rather have a ready made method on the contract that tells me if token is transferable with a simple function call that is descriptive and clear, and I am fine that this comes at a slightly increased gas cost for the sake of clearer integration (both for me and other people who come across this ERC) VS doing this check with gasEstimate, which is very un-intuitive.
From the contract-to-contract checks:
Just the revert is not enough for so many possible use cases, I agree that the immediate and most obvious benefits here VS just expecting a revert, is relevant on custom implementations and combining this EIP with other EIPs and gaming/trading or marketplace contracts
Using on-chain attributes as you suggested can solve some cases where a new behaviour/computation should be triggered. But we can’t deny that there are plethora of such ideas and use-cases out there specifically that require non-transferability and conditional logic based on transferability, so having people implement their own solutions for both instead of providing them with a clear method to do it is exactly why the ERC is a good idea. At the end of the day if this was just blocking transferability then this would be pointless, this EIP is specifically for those who want to prevent transferability and react to it from other contracts (games, reputation systems, achievement registries etc) while having a clear way to check transferability status from a UI.
Right now the most easy to imagine use cases are very well paired with Nestable tokens (ERC-6059) and other custom contracts (gaming, reputation), but the bonus that the same standard works with just simple ERC-721 and thus will automatically just work on existing dapps, and these more advanced ERCs and custom implementation, outweighs the minimal gas saving of just having everyone to modify safeTransfer in their own way and apply custom solutions to react to it from other contracts
A few points here:
This EIP does not do anything to prevent actual token transferability or provide additional UX support that can’t already be done. (your FE UX statement isn’t sufficient for me, as you can make it ‘easy’ by wrapping it in a lib. And tbh, all marketplaces should be checking transferability anyways (as ppl already have a variety of mechanics to block transfers → see Operator Filters, that are not token specific, but context specific). So, even if someone was trying to adjust their UX for general tokens to handle non-transferability, this EIP isn’t sufficient.
On the examples provided point, those cases all still fall under the “non-revert behavior changes based on transferability” cases I mentioned. You could call it “mechanicModifier” if you wanted to, and for any game system that actually wants to do complex on chain dynamic behavior similar to what you describe, it’s likely that this one attribute isn’t sufficient. So I still see this as fairly limited/not generalizable enough for the purposes of those examples.
In general, this EIP, in my opinion, is far too narrow. It seems to be designed for ERC-6059 (which I have critiques of as well), but if the reason is around dynamic on-chain behavior, it’s still severely limiting as it doesn’t take into account other transaction context. Example, the whole Opensea Operator Filter (which I don’t agree with but is a good example of what I mean) does not work here.
Anyways, I can see what you’re trying to put forth, but I feel that there are fundamental flaws with this approach. There’s not much else I can add, so I’ll leave it at that.
Last note:
If the proposal was for a view function equivalent of transferFrom (like checkTransferFrom/checkSafeTransferFrom) with the exact same signature as their counterparts, I could buy that, as it would address the context issues I mentioned.
Great discussion above. I started this thread with a specific use case in mind and did not expect a long conversation on it.
Thus said, I actually like the checkTransferFrom/checkSafeTransferFrom using the same signature, and I suggested something similar above in the discussion because it covers most scenarios — since (in our specific use case) the transferability does not depend on the tokenId but on who you are trying to transfer it to.
I would make a point, that the interface function isNonTransferable(uint256 tokenId) like suggested (ERC-6454: Minimalistic Non-Transferable NFTs) is elegant due to its simplicity (hence flexibility).
IMO it should stay an interface only, NOT a guide on how it shall be implemented.
isNonTransferable(tokenId) is - besides NFT marketplaces - particularily interesting for DeFi, when an NFT shall be used as security e.g. for loans, lending etc. It can only serve as a security, as long as it cannot be transferred (unconditionally).
A side benefit is imho that the implementing contract becomes easy to read/review, as it is easy to grasp the contracts behavior, when isNonTransferable(tokenId) can trivially be used in ERC721’s _beforeTokenTransfer(tokenId), enforcing compliance with the “external” view on the transferability.
For disclosure, we drafted an EIP, where we need a similar mechanism and would rather prefer referencing an already existing standard interface rather than proposing another competitor method. In our case for example the required events of EIP-5192
Well said!
We are also in contact with several projects that have this as the only blocker before launch. They want to have ERC-6454 standardized before launching, so they don’t run into any incompatibility issues if the interface changes.
I suggest we proceed with the EIP process so as to not block the interested parties and finalize the proposal.
We see the current implementation as universal and as minimal as it gets. This seems beneficial as it can be the core building block of many solutions and implementations.
I think that if you have a collection-wide use case based on the receiver, you can add custom logic on top of this to extend the interface specified in the proposal 
As I mentioned on the Final status change pull request, I think there are a couple active questions being discussed here, so I am hesitant to move this proposal to final.
My understanding of the open questions:
isNonTransferable doesn’t accurately report? Returning false but preventing transfers just seems like a minor annoyance, but what about returning true and allowing transfers?0x3 transferable; can address 0x1234...5555 transfer any tokens; can address 0x5555...1111 receive token 0x5 regardless of who would’ve sent it?Do you also have contact with projects on the flip-side? For example wallets, or NFT Marketplaces?
I ask because the EIP process doesn’t enforce any exclusivity. Even if we finalize ERC-6454 as it stands today, if wallets/NFT marketplaces implement a different standard, your contracts will still be incompatible.
I think that’s the flaw with this spec: assuming transferability is solely bound to the token level, which is really limiting.
example: incorrectly determines transferability capability for tokens using marketplace blockers. The proposed spec should take into account receiver/sender addresses. Token level is insufficient in a general sense. Note that transferability constraints outside of tokenId only are extremely desirable (e.g. restricting token transfers outside a set of specific authorized engagers for those trying to create a more controlled token transfer ecosystem).
Tokens that would fail for ALL would fail for a dummy recipient address anyways, so you could pass in a dummy 0xdead address as the ‘fail for all’ check (or define some standard checker address).
IMO, the spec would be ok if:
A dummy address wouldn’t work for tokens limited to a certain owner set. Imagine a token which can only be owned by one of seven addresses, but can be transferred freely between those seven. isNonTransferable would correctly return false, but testing random addresses with transfer would nearly always claim the token is not transferable.
Thanks for your time @SamWilsn!
I think this deserves an explicit mention in the Security Considerations section. Are there any potential problems that could arise if
isNonTransferabledoesn’t accurately report? Returningfalsebut preventing transfers just seems like a minor annoyance, but what about returningtrueand allowing transfers?
I feel you’re taking maybe about malicious implementations. If that’s the case, it is as much of a problem here as it is on any ERC. I could easily produce and ERC721 compliant collection with a behind door that allows me to transfer NFTs to my self. If you’re using this for instance in Defi to secure an NFT as collateral, you must trust the implementation of the ERC6454 on that specific contract as much as you must trust its implementation of ERC721. We could add a note on that, but to me it feels obvious, unless I missed your point.
The existing API can only tell you if a particular transfer (with an exact source and destination) will fail, not if all transfers will fail. That makes a significant difference in UI design.
I think this has been his stronger argument, but we are on your same position as you, we see clear value to this EIP from UI/UX point of view.
This is an interesting approach, and I think it merits exploration. With this interface, is it possible to also check more general questions like: is token
0x3transferable; can address0x1234...5555transfer any tokens; can address0x5555...1111receive token0x5regardless of who would’ve sent it?
I agree it would be an interesting approach. It would require at least the from and to arguments on the view, but this only applies for a specific use case and it would make this proposal no longer minimal. It could be work for a separate ERC.
Do you also have contact with projects on the flip-side? For example wallets, or NFT Marketplaces?
I ask because the EIP process doesn’t enforce any exclusivity. Even if we finalize ERC-6454 as it stands today, if wallets/NFT marketplaces implement a different standard, your contracts will still be incompatible.
We have a marketplace which uses this interface to display non transferability, and few gaming projects working with it already. This implementation comes from a non EVM blockhain where this simple approach was widely used for over a year. There are also a few projects using this ERC on EVM for reputational avatars, in some case together with ERC6059. @tbergmueller also mentioned they’re working on a use case on Defi. We’re also in talks with some wallet teams about supporting these and other ERCs we have proposed.
We’re aware that other alternatives may come in the future, there is even an ERC now which is similar but forces you to emit event on change of state, we already explained how this is limiting for many use cases. However we will be vigilant to point new comers to this ERC if it solves their use cases. Making an ERC go mainstream is no easy task but we think a minimal interface for this use case has the highest chances.
But, isNonTransferrable is incorrect here, since it would still return false which is technically incorrect since it’s not actually transferrable for anything outside those 7. I’m not following how the proposal even addresses that case or what the desired UX behavior is.
In your specific example, the UX would show it’s transferrable, even though it’s not (say it’s a marketplace UX, it would think you could buy the token when in fact, you can’t).