Add EIP-5192 - Minimal Soulbound NFTs #5192
Conversation
TimDaub
commented
Jun 30, 2022
•
TimDaub
commented
- I was looking at many of the current Soulbound token implementations and it upset me that they all revert upon transfer
- At least it'd be nice if developers would allow wallets to understand that a token is permanently non-transferrable
- With my previous attempt at Soulbound tokens (EIP-4973), we got a bit lost in the details
- This attempt is much cleaner: Yes, it still permanently binds a token to an account. But that's fine: Users are doing this and it'd be dogmatic to make that a taboo around here
- Rather, with this change, I think, if implementers adopt it, it'll actually make the life of wallet implementers easier.
- I put status: Review right away. I think this EIP is done and can be peer-reviewed
All tests passed; auto-merging...(pass) eip-5192.md
|
EIPS/eip-5192.md
Outdated
|
|
||
| Upon minting an EIP-5192 token, it must be permanently inseparable from the receiving account. All [EIP-721](./eip-721.md) functions of the contract that transfer the token from one account to another must throw. | ||
|
|
||
| To aid recognition that an [EIP-721](./eip-721.md) token implements soulbinding via `EIP-5192`, upon calling [EIP-721](./eip-721.md)'s `function supportsInterface(bytes4 interfaceID) external view returns (bool)` with EIP-5192's `SOULBOUND_VALUE=0x9e7d7f8` as `bytes4 interfaceID`, a contract implementing `EIP-5192` must return `true`. |
There was a problem hiding this comment.
I think perhaps something even simpler (and much more versatile!) is to add a function soulbound(uint256 tokenId) external view returns (bool tokenIdSoulbound), which would even allow for soulbounding to be managed on a per-tokenId basis. This is by no means necessary though.
There was a problem hiding this comment.
I like the interface you proposed, a token's "soulboundness" can be known implicitly by calling ownerOf(tokenId) in the 4973 spec.
There was a problem hiding this comment.
I like the interface you proposed, a token's "soulboundness" can be known implicitly by calling
ownerOf(tokenId)in the 4973 spec.
no. Unless I'm missing something
Co-authored-by: Pandapip1 <[email protected]>
Co-authored-by: Pandapip1 <[email protected]>
Co-authored-by: Sam Wilson <[email protected]>
Co-authored-by: Sam Wilson <[email protected]>
|
The commit 7bc6ea7 (as a parent of aa08663) contains errors. Please inspect the Run Summary for details. |
|
The commit 8440917 (as a parent of 49e598a) contains errors. Please inspect the Run Summary for details. |
|
The commit f6b0b57 (as a parent of cee63ba) contains errors. Please inspect the Run Summary for details. |
Co-authored-by: aram.eth <[email protected]>
|
seems ready to merge |
|
@MicahZoltu is there anything that we're missing to get this merged? Seems the automerge got stuck somehow |
|
thank you! |
* Add EIP-5555 * 5555->5192 * Add discussions link * Fix line break * Update EIPS/eip-5192.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5192.md Co-authored-by: Pandapip1 <[email protected]> * Update EIPS/eip-5192.md Co-authored-by: Sam Wilson <[email protected]> * Update EIPS/eip-5192.md Co-authored-by: Sam Wilson <[email protected]> * Add function locked(...) * Attempt to fix tests * Update EIPS/eip-5192.md Co-authored-by: aram.eth <[email protected]> Co-authored-by: Pandapip1 <[email protected]> Co-authored-by: Sam Wilson <[email protected]> Co-authored-by: aram.eth <[email protected]>
