Add initial draft for Name-bound tokens #5107
Conversation
| /// @dev This emits when ownership between ENS nodes of any NBT changes by any mechanism. | ||
| /// This event emits when NBTs are created (`from` == 0x0) and destroyed | ||
| /// (`to` == 0x0). | ||
| event Transfer(bytes32 indexed _from, bytes32 indexed _to, uint256 indexed _id); |
There was a problem hiding this comment.
Why not have a mint and burn event instead? Seems like that would be more clear than Transfer(0, ...) and Transfer(..., 0, ...)
There was a problem hiding this comment.
That is the "industry standard" with all tokens 😬
|
|
||
| We have adopted the [`EIP-165`](./eip-165.md) and `ERC721Metadata` functions purposefully to create a high degree of backward compatibility with [`EIP-721`](./eip-721.md). We have deliberately used [`EIP-721`](./eip-721.md) terminology such as `function ownerOf(...)` and `event Transfer` to minimize the effort of familiarization for `EIP-XXXX` implementers already familiar with, e.g., [`EIP-20`](./eip-20.md) or [`EIP-721`](./eip-721.md). | ||
|
|
||
| ## Copyright |
There was a problem hiding this comment.
Security Considerations section is required.
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| We have adopted the [`EIP-165`](./eip-165.md) and `ERC721Metadata` functions purposefully to create a high degree of backward compatibility with [`EIP-721`](./eip-721.md). We have deliberately used [`EIP-721`](./eip-721.md) terminology such as `function ownerOf(...)` and `event Transfer` to minimize the effort of familiarization for `EIP-XXXX` implementers already familiar with, e.g., [`EIP-20`](./eip-20.md) or [`EIP-721`](./eip-721.md). |
There was a problem hiding this comment.
This should be in the rationale, rather than the backwards compatibility section.
Co-authored-by: Micah Zoltu <micah@zoltu.net>
|
Is this an attempt at SBT tokens? |
| /// @title Name-bound tokens | ||
| /// @dev See https://eips.ethereum.org/EIPS/eip-XXXX | ||
| /// Note: the ERC-165 identifier for this interface is 0x6352211e. | ||
| interface IERCXXXX /* is ERC165, ERC721Metadata */ { |
There was a problem hiding this comment.
This interface does not seem to define anything really. Is this still work in progress?
All of this can be accomplished by 721 or 1155. What you may want to specify is a getter function signaling whether a token is "soulbound" or not, but enforcement of that via transfer is still up to the particular token.
There was a problem hiding this comment.
I disagree on this I think. The specification for a soulbound token defines ownerOf and it defines that the result of ownerOf is immutable across temporally disconnected calls. This means that if you call ownerOf and get back XXX, you can be confident that if you call ownerOf again at any point in the future you would get the same result.
There was a problem hiding this comment.
@axic would it help if along with the interface definition, we checked in a reference implementation to this PR?
There was a problem hiding this comment.
This is an interface. The only thing what can be prescribed is what the semantics should be, but it cannot be enforced via an interface description. Reference implementations are out of scope.
There was a problem hiding this comment.
I think you should consider working together with @MicahZoltu since you both are pursuing a "soulbound" token standard. (see #5114)
If you look on Ethereum Magicians and the PRS here on GitHub you'll see that @MicahZoltu and I are indeed closely interating albeit having varying opinions. I think their Soulbound Badges are cool and @MicahZoltu was eager to contribute a lot to 4973. But this proposal is specifically about binding tokens to an ENS hashnode and so it is quite different from what's suggested elsewhere. |
|
@TimDaub Please push an empty commit so that the new CI can run. |
|
Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s): (fail) EIPS/eip-xxxx.md
|
| @@ -0,0 +1,86 @@ | |||
| --- | |||
| eip: 5107 | |||
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
yes |
|
I'm closing this PR, but since it's licensed as CC0, anyone can repropose it and merge it. |
|
The commit 57d60d3 (as a parent of e799739) contains errors. Please inspect the Run Summary for details. |
https://hackmd.io/nbwzGZcHQaqZXHyuCSar6g