EIP-5114: Soulbound Badges

EIPs
, ,
41

It’s still very early but you have to ask more specific questions as e.g. I’m not familiar with the problem of undercollateralized loans.

1 Like
42

This might be out of scope for this EIP, but I think it would be useful to highlight exactly which use-cases this EIP serves that cannot be done off-chain by e.g. signed claims.

One use-case I can think of is when you need time-stamping, i.e. being able to prove that you owned a badge at a specific time point in the past.

2 Likes
43

here’s a table but it’s far from conclusive or complete. But just to get the conversation started.

Claim indefinitely available claim’s existence plausibly deniable by signer claim issuer’s signature valid claim deletable after publishing claim at URL updatable with new signature & content claim timestamped/anchored: Can claim content’s integrity over time be validated? claim for everyone publicly accessible (no privacy?)
on-chain yes* no because Ethereum consensus is witness yes tx only passes Ethereum PoW consensus with valid sig no or depends on implementation no or depends on implementation of smart contract yes if all metadata is hashed yes unless encryption**
off-chain depends on claim’s host server yes, can be deleted from server no, but can efficiently be verified locally yes yes maybe e.g. using open-timestamps/oracles choice of issuer 
* consider EIP-4444
** encryption can get broken over time
1 Like
44

Thanks for the table. Here are some comments:

1) Claim indefinitely available
I would argue that this is independent of on-chain / off-chain. As long as one honest entity serves a copy of the claim, the claim is available. The same is true for on-chain, after EIP-4444.

2) claim’s existence plausibly deniable by signer
I believe this is the same as the first point. As long as anyone can get the claim from at least one honest entity, the signer cannot withdraw the claim.

3) claim issuer’s signature valid
On-chain / off-chain doesn’t matter. Anyone can verify the signature before presenting the claim as valid.

4) claim deletable after publishing
Same as 1) above.

5) claim at URL updatable with new signature & content
This is not possible even off-chain if the claim is content-addressed.

6) claim timestamped/anchored: Can claim content’s integrity over time be validated?
This is is most securely done on-chain.

7) claim for everyone publicly accessible (no privacy?)
Since the on-chain claim can be encrypted, there seems to be little difference between on-chain / off-chain on this point. If the owner wants to reveal only a part of the claim, they could make a ZK-proof, either using an encrypted claim on-chain, or a private claim off-chain.

1 Like
45

Ok this is helpful. But about this “one honest entity” making data available - while in theory it’s easy to manifest: Please name one real data provider that has reliably made data available as Ethereum did considering you wrote something on-chain in 2016 and paid the costs and can still access it.

Bittorrent, the Pirate Bay and the fact that Pulp Fiction is the goddamn best movie on the planet? OK. But much other data isn’t available anymore because nobody cared. The problem isn’t honesty, it’s incentives.

Edit: I have to admit that sadly EIP-4444 changes the outlook quite a lot :confused:

1 Like
46

Please name one real data provider that has reliably made data available as Ethereum did considering you wrote something on-chain in 2016 and paid the costs and can still access it.

I have emails in my Gmail account dating back to 2012. If I wanted to, I could easily make multiple backups of all my emails since then, which is under 2 GB. I would imagine anyone that cared about their badges would also take backups, if they don’t want to rely on third-parties to host their badges.

Anyway, with EIP-4444 in place, the problem of incentivizing data storage is independent of whether the badge is on-chain or off-chain.

47

Invalid example according to my criteria:

  • Gmail has country-biased ToS; they can remove ur data on the basis of contract breach
  • Gmail may be dependent on your credit card and the funds you own. Tomorrow Gmail could ask you to pay to access your email
  • You may accidentially delete all of your data and ask Google to GDPR delete too
  • I’ve been to China, Google is blocked there.
  • Gmail doesn’t periodically publish a merkle root that lets you efficiently verify your data’s integrity
  • Gmail data is only accessible to you. How can you prove to someone else that e.g. you saw a specifc email?
48

As I said, anyone that cared about their badges and didn’t want to rely on third-parties could make backups themselves and store them wherever they want. And again, this problem is orthogonal to whether the badge is on-chain or off-chain. Just to namedrop some projects working on this:

Filecoin
The graph
The portal network (Under construction)

1 Like
49

Fair. For you does “off-chain” mean that the data isn’t available on Ethereum, e.g. storing on Filecoin is off-chain too from the Ethereum user perspective? Does “on-chain” mean: data is on Ethereum, but e.g. not Filecoin?

Because generally, I’ve been using “off- and on- chain” to say: data is stored in a network with similar data availability guarantees as BTC, ETH, Filecoin (not thegraph though).

50

I also want to add that there are more nuances in the details depending on e.g. what type of claims people host. E.g. nobody may want to host dissident claims or Wikileaks data, and everybody is fine with hosting politically neutral images of cats. But e.g. society might still want to host politically-sensitive data in the interest of the public. And individuals can decide by their ethics and not foreign-country laws.

In their famous post on web3, Moxie seemed to avoid this angle when criticizing: Moxie Marlinspike >> Blog >> My first impressions of web3

It’s what Vitalik describes as “Control as Liability/Responsibility”: Control as Liability

I wrote about it in a similar vain saying that running a blockchain node helps collectively coordinate around e.g. alegality: Ethereum Is The Newsfeed We Deserve

51

For I have known the “on-chain”, is metadata on-chain, and people know it very well too. But this in case, just the metadata. If in a broad view of “on-chain” should be fully on-chain, not only the metadata, but the all the metadata indicated should be fully on the Ethereum blockchain as well.

Anyway, also anticipating the fully on-chain solution.

52

I vote for a “Burn” mechanism. You have the right to cut ties with an authority.

53

I don’t think the benefits provided by a burn (given that history is viewable so you can never completely remove knowledge that you had the badge at some point) are worth the loss of immutability (which results in an inability to cache indefinitely).

Plans now that this is merged as draft: Add Motivation. Add EIP-165 support. Add rationale for on-chain vs off-chain claims (timestamping, standardized/public lookup location).

55

I’m beginning to think that the use case for this proposal can be expanded beyond personas.

What if I have an NFT that represents a project or DAO?

Consider this use case…
There is some 3rd party or collective that have reputation as experts in risk analysis. They mint badges e.g. A (low risk), C (medium risk), AA (very low risk) in this chronological order to the NFT.

I can use events emitted to find out history of these credit ratings over time. Maybe project/DAO received a C when crypto market was really down and other times the market was up.

Just saying, soulbound badge don’t have to be for a persona but anything an NFT can represent. But then the name for EIP probably needs to change to indicate this. Name could also indicate that receiving these badges is immutable.

Plus, not sure how you would enforce the NFT to represent personas only?

1 Like
56

I have been thinking about adding EIP-165 as a requirement and I’m a bit hesitant. While I’m a big fan of EIP-165 and think most contracts should implement it, I don’t think it should be a requirement of this EIP because that would lock us into always having to use EIP-165 even if a future better mechanism for interface discovery becomes available. Luckily, EIP-165 supports introspection of EIP-165 support so someone can first check to see if 165 is supported by a token prior to checking to see if this is supported using 165 (or whatever future introspection mechanism they use).

For now, I think I’ll add a recommendation to include some mechanism for introspection and reference EIP-165 as an example of such a mechanism.

57

I have updated the EIP with a few minor changes as seen Update eip-5114.md by MicahZoltu · Pull Request #5346 · ethereum/EIPs · GitHub

  • The collection URI is now pure.
  • Added metadataFormat pure method for discovery of the metadata file format and version.
  • Added a note in specification that implementers SHOULD also implement something like EIP-165.
  • Cleaned up some wording.

I went back and forth on whether content addressability should be required by this EIP. On the one hand, it feels overly prescriptive/restrictive to tell people how the data must be served. On the other hand, using non-content-addressable metadata links makes it so a token author can functionally censor a user, just as they could if the metadata was mutable. I ended up sticking with requiring both immutability and content addressability.

I also changed the name to Soulbound Badge in a follow-up PR (Update eip-5114.md by MicahZoltu · Pull Request #5348 · ethereum/EIPs · GitHub). I feel like Soulbound Badge offers the best pithy description of what this is, as “token” comes with some connotations around it regarding transferability and fungibility.

58

I like the general idea behind this!

The main question I have is – what’s the advantage of forcing immutability rather than having it be optional?

Optionality could be implemented as


function immutable() external view returns (bool _immutable);

Or even


function immutable(uint256 tokenId) external view returns (bool _immutable);

The same pattern could be used to make burning optional (which would also require mutability).

Providing the return values of these functions are required to be immutable, this would allow immutable implementations to retain all the benefits of the original proposal, but also enable implementations that require mutability and/or burnability.

Is there a downside to this?

And on the reasoning behind making EIP-165 optional.

I’m not sure I understand. A few points:

  • This is going to be the case for a huge number of interfaces so I’d imagine addressing this would be a part of any future proposal.
  • There’s no reason to think EIP-165 and any future mechanism would be mutually exclusive.
  • EIP-165 itself would likely be able to indicate support for a replacement mechanism.
  • A future interface detection mechanism may require an amendment to this spec to enforce it anyway

I’m trying to figure out what sequence of events would lead to an EIP-165 requirement causing problems later down the line, so let me know if I’m missing something here!

59

Immutability allows aggressive caching, and content-addressing gives a strong guarantee of non-censorability to the user. One can certainly imagine a different standard that didn’t come with these guarantees and it would serve a different set of use cases that may be valuable to some people. This standard specifically aims to solve the set of use cases where censorship resistance and cacheability are desirable.

I think what you have described (censorable/mutable badges) could be useful for many people, but I think that should be a separate standard. I generally favor small concise standards that solve one specific problem rather than large standards that try to solve multiple problems simultaneously.

On the EVM, everything comes with a cost so if there exists a better way to do interface detection in the future one would reasonably want to drop EIP-165 support for new stuff at some point.

Can you give an example of this? I’m struggling to think of a hypothetical introspection that would require changes to this specification.

60

I think there’s a sliding scale here between extremely narrowly defined standards and extremely broad standards. I agree that there are issues with creating standards that are too broad. But there are also issues with creating standards that are too narrow.

Standards are, by definition, created to allow for compatibility and interoperability between a variety of implementations. The “single purpose” you refer to is a matter of framing. Your framing is:

  • A standard for immutable badges that attach to NFTs

Whereas my proposed framing is:

  • A standard for badges that attach to NFTs

Both of these framings could be described as “single purpose” from their respective viewpoint.

My sense is that allowing implementers to choose between mutability or immutability does not overly complicate this interface, and that forcing immutability pushes this into the “too narrowly defined” category.

My point was that it would require amendments to this spec if it were to be required, in the same way that if you want to require EIP-165 it must be defined in the specification.

If the point of a standard is interoperability, and interoperability is dependent on interface detection, then what’s the point of a standard that doesn’t offer this? If an implementer doesn’t want to offer interoperability, then they can choose to diverge from the standard.

61

While what you propose does allow implementers to do more (it reduces constraints), it narrows what users can do (increases constraints). Caching is a prime example here: If you allow implementers to mutate badges, then people writing code that interacts with those badges cannot aggressively cache the results and they MUST constantly re-check to see what the latest state is. This is removing options from users in favor of giving more options to badge authors. I can see an argument to be made for making this trade, but it is not a free trade as you have implied.

I don’t believe interoperability is dependent on standardization of the interface detection mechanism. Take token lists for example, this is an off-chain mechanism for figuring out what is an ERC-20 token and it works fine without ERC-20 tokens implementing any specific standard.

A given wallet may only support badges that are ERC-5114 + ERC-165 and that would be perfectly reasonable. However, there is no reason that a wallet couldn’t support ERC-5114 badges that are not ERC-165 compliant, and there is still value in being able to assert that this is an ERC-5114 badge.

Separate from technical reasons, I do think there is value in being clear to users what they are getting. We have seen a lot of people build “DeFi” apps over the past couple years that are absolutely not decentralized at all. By having this standard assert that ERC-5114 badges are censorship resistant/immutable, we give future users something very clearly defined to rally around and this may help reduce user confusion. You will be able to say, “that is not an ERC-5114 token” rather than saying “yes, that is an ERC-20 token, but it has an owner that can freely mint however much they want and rug pull you at any point”. If a token is ERC-5114 compliant (as defined currently), then just verifying compliance is enough to give strong guarantees to the user what they are getting and it makes it much harder for people to steal the term and make it mean something it wasn’t intended to mean.