Creates EIP-5114: Soulbound Token

[MicahZoltu]

No description provided.

[eth-bot]

All tests passed; auto-merging...

(pass) eip-5114.md

classification
updateEIP

• passed!

[TimDaub]

Wouldn't using tokenURI here be better than tokenUri as then the bytes4 signature of the function address in Solidity is equal to e.g. that of EIP-721?

[MicahZoltu]

I considered it, but I don't think 721 compatibility matters much because the ownerOf signature is different and owner lookups require custom code, so this token won't natively work with existing ERC-721 tooling.

Perhaps there are specific tools that don't need to do owner lookups but do need to URI lookups that would benefit from consistency across methods?

Personally I would like to see a compelling reason to break the superior (IMO) naming convention of capitalizing only the first letter of acronyms (it avoids situations like XMLHTTPRPC with XmlHttpRpc).

[TimDaub]

IMO naming convention arguments should be out of scope of this EIP. But a separate EIP could make normative statements on function capitalization conventions.

I was mainly arguing for consistency with EIP-721 but it's not a hard objection from my side.

[TimDaub]

Could an EIP-5114 Soulbound token be bound to another EIP-5114 token? Are hierarchies permitted? What about loops?

[TimDaub]

What is your take on EIP-165 and do you plan to use it here?

[MicahZoltu]

Could an EIP-5114 Soulbound token be bound to another EIP-5114 token? Are hierarchies permitted? What about loops?

I am a big fan of allowing hierarchies. In fact, I wonder if this EIP should be modified such that it allows for binding to not only ERC-721 tokens but also to ERC-5114 tokens so you can have hierarchies?

In theory loops are possible I suppose, but it would given the strict rules about immutability, the whole loop would need to be created at once. At first glance, this doesn't seem to be a problem worth resolving, but it may be good to mention it in the security considerations section that tooling should look out for it and protect itself from getting caught in an infinite loop/recursion.

[MicahZoltu]

What is your take on EIP-165 and do you plan to use it here?

I think it is a good idea. Would love a PR that adds support for it as I'm not super knowledgeable about how to implement it. If no one submits a PR I'll probably take some time at some point after this is merged as a Draft to figure out how to add it.

[MicahZoltu]

I have added a note about loops to security considerations. I also changed it to just require binding to an NFT, with EIP-721 being merely an example. The only real requirement is that the thing being bound to has an address and a tokenId.

[TimDaub]

What is your take on EIP-165 and do you plan to use it here?

I think it is a good idea. Would love a PR that adds support for it as I'm not super knowledgeable about how to implement it. If no one submits a PR I'll probably take some time at some point after this is merged as a Draft to figure out how to add it.

to send a PR on EIP-165, would I send it to this origin/branch: MicahZoltu-patch-1?

[MicahZoltu]

to send a PR on EIP-165, would I send it to this origin/branch: MicahZoltu-patch-1?

The simplest option is to just click on a line or drag-select a handful of lines and leave a comment with a suggestion block like:

```suggestion
<proposed changes go here>
```

That will put the suggested change inline in the PR that can then be one-click committed.

Another option is to do as you suggested and submit a PR against my branch.

A final option is to wait until this is merged as a Draft, and then submit a PR to modify the EIP once it actually exists.

[wschwab]

as much as I appreciate the sentiment, it seems out-of-scope to me to specify the nature of the storage, as it is outside the Ethereum network

the requirement for immutability is also questionable to me - I could see a use for a URI that can deliberately be changed or change itself over time

[MicahZoltu]

If we don't constrain the storage, then the tokens functionally become mutable. By asserting immutability throughout, we enable applications/users to build caching systems that they cannot built if we only encourage the behavior.

[TimDaub]

Immutable data doesn't exist. From what I understand, only content-integrity assuring identifiers exist that can indicate mutation. Replication can be used to fallback on non-mutated backups. IMO, e.g. asking to "content-address" resources in tokenURI would fit better.

"Censor"able is for sure the wrong term as it can mean all sorts of non technical stuff.

Anyways, I agree with @wschwab. For interoperability e.g. between wallets, whether data is mutable or not is out of scope.

[MicahZoltu]

I'm not following your claim here that immutable data doesn't exist. If you ask IPFS for something by content hash, you will get either that exact thing, or you will get nothing (if it can't be found on the network). There is no situation where you would get a different result from someone else or at a different point in time.

Regarding censorable content: I tend to agree that censorable content is fuzzy here, and I wish we could nail down something a bit more concrete. What I want to avoid is people linking to content that a provider can remove at a future point in time. The goal with these badges is that they are permanent, they aren't something that comes and goes over time. If you link out to a traditional https resource, the host of that resource/owner of the domain can remove it. Similarly, the domain may be seized and changed or taken away. Something like IPFS on the other hand allows anyone to ensure the content survives, you don't have to rely on a single operator.

[TimDaub]

"immutable data"/content-addressable criteria:

I agree with you that some networks of computers can create the illusion that some data is immutable. But on the basis of a principle, the data isn't immutable. E.g. on IPFS/Ethereum/Bitcoin when you run a full node, there's nothing stopping you from going into the chain data directory and switching a few bits. You can always mutate the data. It's likely though that the system maintaining the data will notice and e.g. notably fail or repair itself. That's what I meant by "Replication can be used to fallback on non-mutated backups (in a distributed system)."

How I'd describe it is that by requesting data using content-addressing, a user can guarantee to themselves that they'll either receive the exact data corresponding to the content-address, or nothing at all (e.g. when content-address and data don't align).

I think "content-addressing" is a better term than e.g. "immutable". I guess another usable term could be "tamper-proof" or "tamper-resistant."

data availability guarantees/non-censorable:

I'd strongly opt for e.g. "highly-available data" rather than "non-censorable." From my perspective, censorship is about withholding information in the interest of a few. Data availability, on the other hand, is a term from the blockchain research world that describes the concept of retaining and serving data within e.g. a p2p network. E.g. all EVM storage has high data availability, and anything stored in the Bitcoin blockchain too.

For IPFS, actually, it doesn't have data availability built-in. To pin an IPFS content hash, one has to personally deploy a dedicated node that continues to make the content hash available within the distributed hash table. IMO, if you wanted the ultimate data availability for Soulbound Badges, it'd probably be best to store the contents of tokenUri on-chain as e.g. a struct. I'm not kidding. It's because if you outsource delivering extremely high-quality data availability to other networks not aligned with Ethereum (e.g. IPFS), it may be that one day they just go down/stop working while Ethereum still works.

Now talking about storing the badge's metadata on-chain, I think it's obligatory I bring up #735

[MicahZoltu]

Lets move this conversation over to the discussions-to link as I'm hoping this will get merged as a draft soon and I don't want this conversation to get lost.

[KillariDev]

Is this requirement necessary? I believe you can bind EIP5114 to any address?

[MicahZoltu]

The EIP references EIP-721, so it requires it (not all editors agree on this policy).

[KillariDev]

Hmm, in abstract it says that EIP5114 requires it to be bound to another NFT, and gives example of EIP721. In section "Backwards Compatibility" Its stated that EIP721 HAS to be used as a soul. I think the EIP should be more specific if EIP721 as a soul is mandatory, or is some other token or EIP also acceptable.

[MicahZoltu]

Any EIP that matches the interface ownerOf(uint256 id) I think is the actual requirement. EIP-721 is an example of that, as is EIP-5114.

[lightclient]

Please use one space after each period.

[MicahZoltu]

Fixed.

[SamWilsn]

I'm not sure why this EIP needs to exist. Are there many use cases for nontransferable tokens? Why should implementers prefer this EIP over, say, EIP-4973?

Seems like this EIP needs a Motivation section ;)

[MicahZoltu]

I see what you did there. I may consider adding a motivation after this has merged as a draft, but as it isn't required I would like to move forward without it for now.

Changes addressed.

[small-tou]

Some suggestions and opinions:

1. Does soulbound token binding bind humans to address, or address to address? Or is tokenId and address bound? This is a topic worth exploring.
2. How to unbind soulbound token after binding? Unreleasable binding may cause some problems, but this kind of release is definitely not arbitrary release, what is it?
3. Does soulbound token need to be compatible with widely used standards such as erc721 and erc20? I think it is necessary, otherwise it will bring a lot of ecological compatibility problems to create a token standard.
4. Who initiated the binding of the soulbound token? How to ensure that no one can generate a soulbound token for an address without consent, it is a serious topic, if someone can generate a soulbound token for you without consent, it will be a very serious disaster.
5. What are the specific scenarios of soulbound token? It needs to be supplemented by some specific scenarios in different fields to define the exact characteristics that SBTs should have.

btw. We are also exploring some scenarios about soulbound token, which can be used as a reference, but our scenario is a further Paired bounding scenario, which creates a new identity for the address and stores the relationship between the paired address at the same time. It is an extend of the standard erc721, and its characteristics are mainly:

• implement from erc721, most NFT usage scenarios are seamlessly compatible
• non-transferable and non-sellable, one person can only have one valid Token at the same time.
• mint paired soulbound token through multi-signature flow, Mint will issue 2 Soulbound Tokens at one time.
• can be destroyed through multi-signature flow, and new Soulbound Token can be minted with other addresses after burn.

Behind the token, we store the relationship between two tokens, and the bounding relationship can be queried through the contract interface.
But we haven't considered making it a standard yet, because his scene is still very limited, and it's more of a social network attempt.

we write a contract at: https://github.com/marryinweb3/ERC721-520
and implement a dapp at: https://marry3.love

we can talk about soulbound tokens more at here

[MicahZoltu]

@Yu-Tou These are good questions/comments, but they should really be made over at this EIP's discussions-to link (https://ethereum-magicians.org/t/eip-5114-soulbound-badges/9417/17). Would you mind posting the same thing over there so it doesn't get lost when this PR is merged?

[small-tou]

ok ,thanks