FINAL EIP-5192 - Minimal Soulbound NFTs

2 Likes

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!

1 Like

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.

2 Likes

@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 :slight_smile:

1 Like

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!

account abstract,,,,,,,,,

Implemented in Add EIP-5192 - Minimal Soulbound NFTs by TimDaub · Pull Request #5192 · ethereum/EIPs · GitHub thanks for making this suggestion.

1 Like

Sounds great @TimDaub, sorry that I didn’t make the PR earlier, pretty was busy with project work :slight_smile:

EIP-5192: Minimal Soulbound NFTs was accepted today and is now available at https://eips.ethereum.org/EIPS/eip-5192

Attempting to move to “Last Call”: Move to Last Call by TimDaub · Pull Request #5549 · ethereum/EIPs · GitHub

last call is active until 2022-09-12: EIP-5192: Minimal Soulbound NFTs

EIP5192 is now final.

2 Likes

Just to understand the compactness of using EIP-5192 in NTTs that revert on throw. With just a few lines of code, a lot can be done that can help indexers to identify Soulbound tokens.

What follows is a proposed change set for an NTT contract throwing on all transferring functions that EIP-5192 was proposed to added. It’s a total of 6 additions: Add first cut ERC5192 interface by TimDaub · Pull Request #6 · public-assembly/curation-protocol · GitHub