Update EIP-5192: Change name to "Lockable tokens"

[TimDaub]

When this standard was created, the term "Soulbound tokens" was cool and new. Many people understood that a Soulbound token is "bound to a soul," and so it is a permanently locked token of an account. But since then, it has become clear that a Soulbound token is an umbrella term for all kinds of tokens that break conventional norms around private property assumptions. And besides, EIP-5192 implements dynamic locking of a token. So "Lockable Tokens" is a much better term for this specification and also for developers arriving at it in the future.

I'm hence asking the EIP editors to make an exception regarding changing the contents of this EIP. The interface has not changed. Developers can still rely on using this token standard. The only change is an improvement in terms of accuracy in identifying what it is: A lockable token.

[eth-bot]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

---

(fail) eip-5192.md

classification
updateEIP

• eip-5192.md is in state final at the head commit, not draft or last call or review; an EIP editor needs to approve this change
• This PR requires review from one of [@axic, @SamWilsn, @Pandapip1]

[sullof]

Good move.

[Pandapip1]

I'm in two minds about this.

1. The correct way to refer to an EIP outside of the EIPs repository is [EIP-X](https://eips.ethereum.org/EIPS/eip-x). As such, changing a name shouldn't cause any issues, and so in this regard I am inclined to approve this.
2. The name is not part of a normative section, and although this does change the Specification section, it is a minor wording change. In this regard, I am again inclined to approve this.
3. I recognize many people don't follow the official recommendation in 1, and that the citation itself will change. In that regard, I am not inclined to approve this.

@SamWilsn what do you think

[sullof]

It makes sense. Still, calling the EIP with a strong reference to soulbound tokens, while that is just a specific use case, seems misleading to me.

[Pandapip1]

The title shouldn't be changed. I think that the rest is fine.

[SamWilsn]

The criteria for updating a final EIP:

[...] only be updated to correct errata and add non-normative clarifications.

Even though the currently accepted definition of soulbound doesn't match exactly what this proposal provides, I don't think this qualifies as an errata or clarification.

[TimDaub]

The title shouldn't be changed. I think that the rest is fine.

That'd make it quite confusing IMO. If we didn't change the title but referenced SBTs as "lockable tokens" internally. I think it should either be decided that this patch is 100% taken or 100% declined (which is both fine with me).

2. The name is not part of a normative section, and although this does change the Specification section, it is a minor wording change. In this regard, I am again inclined to approve this.

This is my view as well.

3. I recognize many people don't follow the official recommendation in 1, and that the citation itself will change. In that regard, I am not inclined to approve this.

To be fair, a citation always has a date attached to it, so before date X you'd cite it as "Minimal Soulbound tokens" and after the date you cite it as "Lockable tokens." I see no issues with that.

[TimDaub]

Even though the currently accepted definition of soulbound doesn't match exactly what this proposal provides, I don't think this qualifies as an errata or clarification

People now generally take Vitalik et al.'s paper as the canonical definition for SBTs and so when they see this specification many are usually confused. I think it's a mistake we've called it "Minimum Soulbound Tokens."
It's a mistake as this EIP may be used to build Soulbound tokens where a set of functionality is locking. But according to Vitalik et al.'s definition, SBTs contain many other features too which this specification doesn't live up to (e.g. community recovery, account abstraction, etc.). E.g. Weyl has told me that EIP-5192 and EIP-4973 aren't SBTs as they don't tick all the boxes.

[TimDaub]

Btw. I think it's problematic that there is another proposal called "Lockable ...": https://eips.ethereum.org/EIPS/eip-5058

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.