EIP-4973 - Account-bound Tokens

EIPs
, , ,
41

I tried my best to read the entire discussion above. I didn’t see my particular concern addressed, but if it is, please point me to it.

Nearly all of the examples above reference what I would call “good tokens”: diplomas, certificates of attendance, licenses, etc. Things that people want to have. So, when an institution such as a university issues a diploma, I “want” that token attached to me, and I fully understand why everyone involved, the institution, I myself, and any person to whom I show the token does not want it to be transferable. I understand all of that, and there’s no need to explain.

My concern is when some institutions almost immediately come to understand that they can issue un-desirable tokens into a person’s wallet without asking that person.

For example, the fact that I belong to “The Group Opposed to the Government” who speaks out loudly against the institution. I, as the recipient, am left with nearly no recourses in this case. I can either (a) get a new wallet – very undesirable as it contains other tokens that I want – my diploma for example, (b) revoke (i.e. burn) the token which doesn’t really solve the problem as the existence of the token in my wallet’s history remains and the institution can choose to ignore the revocation, or (c) keep the token in my wallet and hope that being part of “The Group Opposed to the Government” doesn’t some day become a capital offense.

In its rush of excitement, the above proposal seems to ignore the obvious and foreseeable downside of institutions being able to send a “tag of ill repute” to an unlucky recipient that cannot be wiped clean.

So as to not allow you to underestimate the importance of this issue, I ask you to read and comment on this piece I wrote a few years ago. I think this issue is literally a matter of life and death.

I would appreciate your conscientious response.

42

What a timely initiative, I’m very glad to join the discussion here.

Like many of you, I’ve read the recent paper from Weyl et al with gusto, and believe that this standard will be transformative for Ethereum, in terms of social scaling, enabling new forms of ownership and markets, fixing existing applications (e.g. DeFi) such that they are fairer and safer, and so on. I think that this will take real-world experimentation with a very limited standard to see what works and what doesn’t; it’ll take time.

It seems like there’s still quite a lot of debate about the scope of the ownership/binding of these tokens, or other user-security concerns like loss of access. I think that highlights the value (A/S)BTs will have to users, but I agree with @TimDaub that this EIP should not consider this; i.e. don’t try to over-solve more generic UX issues here.

As @ligi mentioned, UX solutions like smart contract wallets do exist. Similarly, there are solutions for message-passing between Ethereum and L2s. If we leave revocability and reissuance up to the implementer, there are no new problems to solve here as I understand.

Re: the name of the standard, I’d invite @ligi and @TimDaub to reconsider SBTs over ABTs once more, with this in mind: the context of the effort is to empower human actors that use the network.

To quote the DeSoc paper:

Our key primitive is accounts, or wallets, that hold publicly visible, non-transferable (but possibly revocable-by-the-issuer) tokens. We refer to the accounts as “Souls” and tokens held by the accounts as “Soulbound Tokens” (SBTs).

It’s true that individuals can run multiple accounts (indeed, it’s the reason why Sybil is a problem), but I don’t think it helps to make that differentiation here. SybilBot Pro#2912 doesn’t have a soul, but it has an account that can give and receive attestations. What’s the difference? It’s that we don’t care about the accounts, because we can’t verify them as having Souls in the context of an ecosystem of these tokens and the users that hold them.

Note there is no requirement for a Soul to be linked to a legal name, or for there to be any protocol-level attempt to ensure “one Soul per human.” A Soul could be a persistent pseudonym with a range of SBTs that cannot easily be linked.6 We also do not assume non-transferability of Souls across humans. Instead, we try to illustrate how these properties, where needed, can naturally emerge from the design itself.

I think Account-Bound, while technically true today, does not reflect the goal of the initiative. I won’t die on the hill, but I think it’s worth a good re-think.

43

Someone can do this today, no need for a standard for that and a standard cannot prevent it.

5 Likes
44

To expand @MicahZoltu’s point above a bit for clarity -
This discussion is for an ERC, meaning we’re trying to define a standard way of accomplishing a goal in the context of existing capabilities. All the capabilities of doing anything described in the ERC already exist in Ethereum today, and the goal of this proposal is just to land on a shared way of building something to make it easier for developers that build or consume something.
The reason no standard we can devise will ever, by definition, prevent the abusive case described is that no one forces anyone else to use the standard. If ERC-4973 will have some “reject” (or preemptive “accept”) functionality - the malicious party (the government in this case) will simply create a non-standard token that doesn’t have that functionality. They can do it irrespective of ERC-4973 ever finalising, regardless of how it will look like.
I hope this clears things up. :slight_smile:

Re: @JamesLefrere and Tim’s points about finalising this standard for accounts only and having a separate ERC for NFT owners: I think it’s a reasonable path forward to enable people to start building soulbound tokens faster and iterate - as long are we’re explicitly comfortable with one token not being both account-boundable and token-boundable. Seems ok to me, since solving the global case in a clean way requires a much stronger definition of an “object” on-chain than we have right now (where “object” can be both an address and a token).
Anyone thinks having a separate ERC for token-owners is not the way to go?

2 Likes
45

I would much rather see this standard switch over to soul binding, and just no one creates a standard for account binding because I personally think that is a deeply flawed design that compromises user security and implies promises that cannot be kept. That being said, the standardization process is open, and I don’t have to agree with a standard for it to exist. :smile:

46

Personally, I’m much more interested in ENS-Bound tokens than Account(address)-Bound ones just because I think abstracting addresses away is generally the path forward for the ecosystem (counterfactual wallets ftw) - but I accept that for the time being account addresses are still the dominant identity in Ethereum.
My concern with trying to solve for soulbound-everything in this ERC is that as far as I’m aware there is no standard for an Object primitive we can refer to as the Owner. Addresses look differently from ENS domains which look differently from ERC721 tokens etc.

A couple of us had a chat about what some theoretical potential “ERC-XXX: Referenceable Object” could look like (details below since this is a tangent), but unless you have a clever workaround I’m not sure how we could solve a generic ERC4973 without solving this first - which will block this ERC for some undetermined amount of time. I think no matter how we design Referenable Object in the future we’ll design it to allow for standards that are backwards compatible with tokens that only return addresses as owners as 721 already does that now. If you have a way around this that will allow for generic ERC4973 owners without a standard for objects I’d love to scratch this point completely :slight_smile:

“ERC-XXX: Referenceable Object” tangent

If this is interesting to pursue we should probably take this to a separate threat to avoid derailing the conversation for this EIP.
What we’ve been talking about is a potential interface that can draw some inspiration from EIP 137 to create a standard mapping to any address or token - a super rough sketch of it is something like an object address being a recursive chain of references from a base address to a specific object ID. A pointer is a string in the form [address:ID1:ID2:…]. The address can be an account or a contract, and there can be an arbitrary number of IDs for contracts that hold more than one object type. Null ID1 is a reference to the address itself, which makes this backwards compatible with existing ownership models that return an address.

To illustrate: if we have a contract at address A that issues two types of NFTs, X and Y, we can refer to any specific NFT issued by A by providing a reference like A:X:32

Is this something worth pursuing further? Is there something already in place/worked on that I missed aimed at the same problem?

1 Like
47

ENS names are ERC-721 tokens, so soul binding can just be to any ERC-721 and it would cover everything from Crypto Kitties to Bored Apes to ENS names, all with one relatively simple standard.

3 Likes
48

As far as design, I would just do something like:

interface SoulBoundToken {
	function ownerOf(uint256 tokenId) external view returns (address erc721Contract, uint256 erc721TokenId);
}

Super simple, works with all ERC-721 tokens as souls (which includes ENS names), and isn’t blocked by anything.

1 Like
49

Yeah, I guess I was thinking explicitly about the 137 namehash node definition but there’s no reason to actually go that route. Was this another case of Tom overthinking things? (Narrator: “It was”)

Just to clarify: if this is a unified interface (so address owners should be allowed) - in case the owner is an account address and not a token, what should the return value be? ERC-721 states that

callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a “black box”

So we can’t just return 0 for erc721TokenId

50

I recommend not allowing address owned assets. I think this is a big security risk for users and shouldn’t be done. If someone really wants an address to own an asset, they can setup a contract wallet that looks like an NFT with a single item.

51

I agree from a purist perspective, but from a pragmatic standpoint in that case I think we should go the two standards route. Rationale: People are going to account bind tokens whether we think it’s a good idea or not, and so standardisation is the best harm-reduction course. If you do it, and least do it in a way that plays nice with the rest of the ecosystem.
We can and should then encourage people to take the optimal path and bind to tokens by explaining the merits for that path.

52

An alternative path towards standardizing name-bound tokens using ENS can now be found here:

53

I disagree with this pretty strongly. In my experience, the act of creating a standard results in people assuming that it is a good idea and secure. If there is no standard, then people are more likely to dig and figure out why there is no standard and sometimes they learn that it is a bad idea during this process and then they do something different.

There will probably be some people who do address bound tokens, despite there being no standard, and there may be someone who decides to write a standard for it. However, I think it would do the ecosystem well to at least delay that as much as possible and get people used to using NFT bound tokens instead, hopefully prior to people doing address bound tokens. If we can normalize NFT bound tokens first, then I think address bound tokens are less likely to take off.

54

What is the advantage to name binding instead of the more generalized ERC-721 binding?

55

There’s probably even bigger security concerns to bind tokens to an ERC-721.

Anyone can create an ERC-721 that doesn’t respect the assumptions from the eip, and could therefore take advantage of users who will want to bind a SBT to it.
NFT ownership is not as secure as account ownership as it relies on the issuer of the NFT being honest. I think makes sense to implement this EIP as-is as an ethereum account doesn’t rely on a honest third-party assumption.

I would like to think that’s the case but being in a community of active smart-contracts developpers, that’s not what I witness on a daily basis, quite the opposite actually. Devs don’t wait for standardization to implement features they want/need and this EIP is wanted before everyone implements their own standards, making it impossible for large entities (wallet providers, etherscan, zapper, …) to accurately represent it accurately. (btw, since the SBT paper, I already saw 3 different implementations of it)

1 Like
56

I’m not sure where the honest third party assumption is?
The non-separatable token is still non-separatable, regardless of the (already existing) possibility of a malicious contract.

57

IMO this is a “feature”, not a “bug”. I specifically want any address-bound tokens to fail to gain adoption, and if there is not consistency across projects (due to lack of standard) then there is less likely to be integration into things like etherscan, wallets, zapper, etc. and when there is integration it won’t work reliably, which reduces adoption and incentivizes people using better standards like NFT bound tokens.

58

Ok, so for the sake of going fast enough to prevent fragmentation in the ecosystem, let me quickly recap where we are:

  1. Whether or not standardising account-bound tokens is a good idea, having a standard for a generically bound token that can capture both ABTs and token-bound tokens is not trivial and will take a while. Having just one of the two in a standard is much easier and can be released sooner to prevent too much fragmentation from building up.
  2. It doesn’t seem that there is a significant call for waiting for a generically bound token, most of the voices here are either for the two separate standards with a potential future third generic or just for token-bound and not ABT at all.
  3. So whether or not standardising ABTs is a good idea, I think (?) the general temperature of the room is that token-binding is something we want and end up doing and shouldn’t be blocked by the ABT discussion.

Tim, Enrico and I have put up a separate proposal for a name-bound token (Tim posted above, link here for convenience). I propose we focus there on making sure we’re making progress with name/token bound tokens, and keep this discussion specifically about ABT. Are we happy with that? It’d be a shame to block something we’re generally for because of something else that’s more contentious.

3 Likes
59

It can also be bound to a recoverable wallet which addresses the point you brought up with the ens bindings.

I think what we need here is a set of suggested recipes so that users and developers know that for soul safety they can bind the tokens to a recoverable wallet.

60

This would mean to user can’t upgrade/switch wallets, which is also bad.