We have to be clear here; despite what others have implemented and whether or not those tokens implement the transfer functionality, strictly speaking, they’re not soulbound according to its definition.
For POAP, it’s great that they made the technical decision not to block the transferability. For any future project not wanting to block transferability, I suggest simply using ERC721. But those projects are not to be confused with soulbound tokens.
I think you’re misinforming your fellow users with this statement, unfortunately - I doubt you have the authority to control what merits a standard:
The difference between ERC721 and ERC4973 is that they can signal the lack of transfer and tracking functionality with supportsInterface. My point is that there’s a relevant difference between implementing a useful feature-detection mechanism (ERC4973) and naively disabling transfer functionality (revert in ERC721 transfer).
This example is structurally false.
The social contract between USDC and its users is that all transfers generally work, and only unless you’re engaged in criminal activity do they won’t (because you end up on a ban list).
With ERC4973 tokens, the social contract with the users is that no token can ever be transferred. Your example is structurally false as USDC uses their ban list as the last means to circumvent criminal activity. In that case, they don’t care about the criminal’s user experience. Hence just having transfer revert is fine.
But clearly, we don’t want to treat all soulbound token users as USDC treats criminals…
Instead, if we want to provide a nice user experience on wallets, it is critical making the user understand that they cannot ever transfer certain tokens and, e.g., show advice in a wallet. If we implemented this functionality by having transfer functions revert upon calling, it’d create a confusing scenario as it’d require someone to look into the contract code specifically. A machine cannot tell whether a revert within a tokens transfer function means: (1) the token is soulbound, (2) the user has entered the wrong inputs (3) a myriad of other possibilities.
Since ERC4973 can signal transfers not being implemented via supportsInterface and since ERC721 can signal transfers being implemented, an ERC721 with disabled transfers cannot signal any specific information to a wallet. It can just notify the user that the on-chain call they’re about to send will fail - which is a really bad user experience.
Instead, with ERC4973, the transfer button can, thanks to supportsInterface, be hidden when the token is displayed. Potentially, the wallet implementer can even choose to educate the user about this new type of ownership experience.
To me, having ERC4973 get adoption can be the start of a new chapter. So far, we’ve implicitly assumed that all blockchain properties must have tracking and transfer functionality according to the societal norm that is “private property.”
ERC4973, a token that doesn’t make many implicit assumptions, can challenge these perceptions by, e.g., allowing someone to soulbound a token to a smart contract and then implementing wildly new ownership concepts.
Within Radical Exchange’s “Partial Common Ownership” concept working group, we’re exploring what properties “Harberger Property” would exhibit, and SBTs owned by smart contracts may be a good foundation.