I’m really impressed by the simplicity of this EIP! It accomplishes its goal in an elegant way, and its goal is the most minimal increment of a long-term feature. Perfect!
One problem with never being able to transfer the token is that
you will never be able to rotate the corresponding crypto key.
From this perspective it is not clear at all whether it should be an extension of a NFT.
It should probably be more like a map of User_ID to public key pairs, where the UID is randomly set at creation, and you can rotate a key corresponding to a UID
This is out of scope, has been extensively discussed in EIP-4973 and frankly it is wrong. The standard doesn’t require the token holder account to be an EOA. An account can be represented by a contract. We’re all responsible users and lecturing people what not to do is IMO not the role of the EIP process/document.
@TimDaub I read various posts, discussions and documents, and really appreciate your (and ra-phael and MicahZoltu’s) efforts around this topic.
With the idea of trying to start with a minimal first-step, I was wondering how about introduce a very simple function (and therefore an interface) that checks transferability (or boundedness) of a token?
function locked(uint256 tokenId) external view returns (bool)
This will allow wallets to check for transferability for UX, allows implementers more freedom around mint/burn and maybe even allowing transfers in certain situations. Lastly the
supportsInterface() will have a more meaningful role when it says that it supports transferability/boundedness checks.
If you think this is a different can of worms I can move this suggestion somewhere else.
Let me know what are your thoughts, as you’ve been working on this for quiet a while
yeah, @aram I think this is a good idea as it’ll still allow someone to inseparably bind a token to an account, but leave that choice to the user (which IMO should ultimately have the freedom of decision).
The effect is that it can shut up the nay-sayers arguing for better key rotation practices in SBTs as the interface is neutral towards the concept of permanent locking.
Here’s what I suggest: Please send the proposed interface design change to my GitHub TimDaub/EIPs so that I can propose it to ethereum/EIPs, thanks!
Implemented in Add EIP-5192 - Minimal Soulbound NFTs by TimDaub · Pull Request #5192 · ethereum/EIPs · GitHub thanks for making this suggestion.
Sounds great @TimDaub, sorry that I didn’t make the PR earlier, pretty was busy with project work
EIP-5192: Minimal Soulbound NFTs was accepted today and is now available at https://eips.ethereum.org/EIPS/eip-5192