EIP-4973 - Account-bound Tokens

EIPs
, , ,
61

I’m very interested in the topic of SBT or abt. I’d like to express my personal views on whether there can be a way to “bind” tokens from an economic perspective, such as adjusting on the basis of erc721

  1. It greatly increases the cost of transfer and makes users almost reluctant to actively transfer NFT. However, in extreme cases (such as the leakage of wallet private key), the wallet needs to be replaced, and the wallet owner can also have a way to save his assets.
  2. For the same erc721, all NFTs must be transferred at the same time, which will maintain the consistency of the owners of the transferred NFTs.
62

The “soul wallet” would need to provide the upgrade and recovery mechanism.

63

The cost of transferring the ERC-721 that tokens are bound to wouldn’t change. The soulbound token points at a soul (ERC-721), and the soul (ERC-721) is owned by an address. If you move the soul, nothing changes about the soulbound tokens so there is no extra gas costs.

64

I don’t think adding complexity to wallets (the things that are most critical to be secure, which means simple) is the right solution here.

65

Something is going to have to take the complexity. I also like your ENS proposal. I don’t think making the soul bound token or account bound tokens conditionally moveable from their root is the solution.

So either attach them to an ENS where the ENS owner can be transferred and the account bound tokens are making attestations on the ENS domain, or put them on a recoverable wallet.

66

Maybe I missed something, but I don’t think anyone is arguing in favor of allowing bound tokens to move away from what they are bound top. The disagreement I think is entirely on what is the sun of things that the tokens can bind to. Addresses, names, private keys, NFTs, etc.

67

@MicahZoltu I think you’ve convinced me that Soul (ERC-721)-bound is preferable to Account-bound.

Regarding whether limiting the scope of the Soul (e.g. NBTs) is preferable, I’m not quite sure yet. In the case of ENS, the resolved address can be different to the owner – isn’t it more likely that users would want to bind their ENS to their Soul rather than vice-versa?

68

The smartcontract will only ever be able to transfer the amount of token you approve. This is done, in part, as a security measure for ERC20 token holders.

A similar security could be implemented in Account-bound Tokens. The address must first approve the NTT SmartContract to receive tokens from there.

You will pass your university’s pre-established rules. It could be sending your diploma or some badge of misconduct.

It’s a little difficult to cover all the cases like being in a political party today that after 20 years becomes an enemy of the current government with persecutions. The solution is for the user to understand the risks before signing the contracts.

69

The reason I like binding to any NFT is so that users can make these decisions for themselves. If you want your soul to be an ENS name you can have that, or if you want it to be a ClyptoKitty you can. You could even bind your soul to a contract that issued a single NFT that can’t move if you really want address binding (I still think it is a bad idea, but if people disagree they can functionally achieve it).

Regarding ENS specifically, they are transferable, and they cannot change to soulbound without deploying an entirely new system.

1 Like
70

I think that’s quite a likely path to adoption.

That said, one argument in favour of account-bound tokens is that there’s potentially no cost to receiving one, whereas with the other option, one must have something to bind to. That also doesn’t necessarily need to cost the user anything (even gas, if it’s separately minted/transferred), but what I’m driving at is that users shouldn’t think they need to pick an illiquid jpeg in order to prove things about themselves.

Regarding ENS specifically, they are transferable, and I doubt they cannot change to soulbound without deploying an entirely new system.

Sorry, yes – wasn’t thinking through.

1 Like
71

@ra-phael @rsquare Chris Chung and I had an account-bound tokens get-together at NFTBerlin to talk about the standard’s future and what other plans we have. Below I’m copying the full notes to the Ethereum Magicians forum. Alternatively you can also read them here on hackmd.

Token Binding Working Group Meeting Berlin

Date of meeting: 2022-05-25
Time: 3pm
Location: Berlin, NFTBerlin event

Participating

RSVP

(pls add yourself)

  • TimDaub
  • Raphael Roullet
  • Chris Chung
  • Rahul Rumalla

Agenda

(please add agenda items if you have any)

  • (Tim): mini update state of ABTs/SBTs
  • (Tim): Gather feedback about transitioning standard from using “non-transferrable” to “non-separable.”
  • (Tim): Present Otterspace’s effort to make an informed decision about using event Transfer.
  • (Tim): For event Transfer discuss mapping of input parameter values: from, to, id.
  • (Tim): How to move forward with EIP-5107 “Name-bound tokens”: Add initial draft for Name-bound tokens by TimDaub · Pull Request #5107 · ethereum/EIPs · GitHub
  • (Tim): What about Micah’s proposal on “NFT-bound tokens”?

Minutes

Location

NFTBerlin

Attendees:

  • Tim Daub
  • Rahul
  • Raph
  • Chris

State of the ABTs/SBTs

Heightened engagement of 4973 on twitter.

Account-bound tokens are starting to emerge as a term.

Name-bound tokens proposal created as a spin-off for ENS-bound token standard to help focus the discussions.

Let’s aim to keep discussions focussed around the specifics of Account-bound tokens on EIP thread of 4973.

Decision making

Decisions that are made on design and implementation must be done through the EIP thread on ethereum magicians forum.

How do we make decisions on certain contentious features in terms of placing something in the spec versus suggestions that users have the choice to implement or not.

Making sure we have discussions that are tracked and traceable so we can be efficient in being productive and be knowledgeable about the rationale and motivations behind any of the decisions being made.

Naming

Account-bound might be more specific than soulbound.

Non-separability seems to be less loaded than non-transferability where the baggage of ownership is a contentious point.

Token may not even be the appropriate term for the structure of what we might want to be “soulbound”. Maybe we should be more technically descriptive about the function that we are trying to capture or even revisit the intended macro-goal of bindingness.

Design

Backwards compatibility for the event signatures may help integrateability: i.e.transfer .

Potentially any “breaking changes” to compatibility can be supported by a clear design intent for the new approach which differentiates it from other tokens. Narrowing down and being very specific can help with adoption.

Initially from was removed from the attest and revoke fields. It should be re-introduced to 4973 but the underlying problem needs to be addressed elsewhere.

3 Likes
72

Lovely.
currently working on a product that has the potential to be huge, and you had me on integrateability because it’s going to be hard to adopt this if it doesn’t have not backward compatibility with specs like ERC-721

1 Like
73

Alternative naming suggestions:

Identity Bound Tokens (IBTs)
User Bound Tokens (UBTs)
Personal Identity Tokens (PITs)
User Designated Token (UDTs)

The names suggested so far are not great, especially “Soul Bound Token”. If we want blockchain utilities to go mainstream, it would help to start using mainstream language when naming them. Most native English speakers hadn’t even heard the word “fungible” before NFTs became popular, but I digress.

1 Like
74

In a new post, we’re addressing some of the misconceptions on Twitter and here on the forum about Account-bound tokens:

2 Likes
75

Proposing a new set of changes to EIP-4973: A disassociation mechanic using function burn. Details: Include disassociation mechanic by TimDaub · Pull Request #5136 · ethereum/EIPs · GitHub

1 Like
76

I found EIP-4494 and it’s interesting as a mechanism to both store ABTs off-chain and implement consensual minting towards connecting two accounts. More details: EIP-4494: Extending ERC-2612-style permits to ERC-721 NFTs - #32 by TimDaub

77

That’s not true.

I can envision a possibility – (1) a smart contract is deployed that allows anyone to register themselves as someone who will accept no soul bound tokens. (2) in order to be compliant with the standard, any minting contract must consult that registry first and only create the token if the address is not in the registry.

There are probably a Turing-complete number of other possible solutions.

78

@MicahZoltu is correct: https://nftevening.com/mcdonalds-nft-collection-has-a-nasty-racial-slur-hidden-in-the-mcrib/

Preventing misuse is in the scope of the Ethereum governance community. Make no mistake, I’m just one dude in my basement writing here. And my goal isn’t to build digital identity either. The use case is very narrow, a common interface for account-bound tokens. If you have concret technical insights, please get in touch and you can cowrite.

Note, our document existed before Vitalik’s paper. I’m not involved in that. Neither are my coauthors. Misuse has to be discussed more globally within crypto/Ethereum and not within ABT spec. Happy to help ofc.

79

I would consider this to be a best practice/good idea rather than a standard. IMO, standards are for facilitating communication between two parties and providing guarantees/constraints on what is valid over that communication channel. What you are proposing is a “negative standard” in that it isn’t specifying anything about how two things communicate but rather specifying conditions on which two things should not communicate.

FWIW, I can understand the argument for calling such things a standard, but to me that feels like scope creep on the term “standard” that I would prefer to avoid.

2 Likes
80

This last change to eip-4973 is really well designed,

I think it addessed concerns about the need to add some “authorization” process, while retaining full flexibility of the eip, and providing a clearer path for the implementers of this standard to let users keep control over their tokens.

On the subject of SBTs, I feel that this change addresses the concerns of most of the reactionary critics of vitalik et al. paper. By baking-in revocation into the standard, we let the user the ability to distinguish publicly between wanted and unwanted tokens, therefore enlarging the scope of this eip in a healthy way.

1 Like