EIP-4973 - Account-bound Tokens

The same can be done with contract wallets, private keys, or even real life identities. In the end, you have to pick some thing that is the “soul”, and bind assets to it. There is nothing you can do to stop the sale of that soul though. I think it is better to acknowledge this and design around it, rather than trying to pretend it doesn’t exist.

Even if you choose to use private keys, one could still develop a system where an actor “farms” reputation (or whatever) on that private key without knowing the key and then sells the underlying key later. (e.g., you could setup something that runs in AWS in a secure enclave where you can prove that no one knows the key except the final buyer).

Hence, my suggestion is to replace event Transfer(from, to, id) with:

  • event Attest(to, id) where the from field is taken from the transaction’s from; and
  • event Revoke(to, id) where the from field is taken from the transaction’s from; and

Maybe not a blocker but something to consider: this conflicts with GSN-style transactions (see EIP-2771: Secure Protocol for Native Meta Transactions), where the from field of the transaction is indeed authenticated but meaningless (because it is a relayer, not the original user).

Additionally, I don’t think new events are needed since they don’t directly contribute to the primary goal of this EIP, defining non-transferrable tokens. Improving the traceability of from is a separate issue that does not need to be conflated with this EIP in my opinion.

4 Likes

I think there might be some semantic ambiguity in this thread that might be creating some artificial friction. Namely, I think some people treat the goal as non-transferability (a token cannot move from entity A to entity B in any form). In contrast, others treat the goal as non-separability (a token cannot move separately from Object X, whether the object is an entity or another token).
Non-transferability seems only to be (weakly) possible when bounding directly to an account, but with the tradeoffs of requiring a failsafe transfer mechanism to allow for key management.
Non-separability allows for easier underlying account management but with the tradeoff of allowing for easier transferability that would require out-of-protocol social coordination to prevent.

If I’m reading the room correctly it seems like the prevailing opinion here is that non-separability answers the bulk of the motivation for the initial proposal - so it might be useful to disambiguate and explicitly agree that we’re pursuing non-separability instead of non-transferability for the sake of making progress? :slight_smile:

As long as people are clear about what non-separable tokens are and what they are not I think most use-cases will be met by this design and the ability to bind to things like ENS addresses. If later on we see there’s still an unmet need for strict non-transferability, we’ll design a separate EIP answering this requirement specifically (which as this thread has shown is a much harder problem than might appear on the surface).

Edit:
One point about the ownerOf signature if we want to go the non-separable route is that specing the signature to return address means every ownership check will have to recursively resolve to the current owning address which can get pretty gas-expensive: imagine if I want to check if tomcohen.eth has several ABTs - each ABT will have to resolve who owns tomcohen.eth and return it to me instead of just verifying tomcohen.eth is the owner and me checking what address owns tomcohen.eth (or if tomcohen.eth owns a government-ID ABT and that ID has an ABT itself for my driving licence and the recursion there). Are we sure we want to keep the signature as is? Do we have a more flexible signature we can use instead?

2 Likes

If you want soul binding to NFTs (e.g., ERC-721), then you’ll need to adjust all of the signatures to indicate the ERC-721 token that is the soul. This includes ownerOf as well as both of the events.

Essentially, the binding is to a particular NFT, not to an address. So when you ask who is the owner of soulbound token X, you get back a pointer to an ERC-721 NFT rather than an address. You can then off-chain resolve that to a current owner if your application needs to do that, but if you are just trying to figure out the collection owned by alice.eth then you wouldn’t need to resolve to an address at all (and in fact, alice.eth doesn’t even need to have a resolver setup for this to work).

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.

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.

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

4 Likes

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

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:

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

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.

2 Likes

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

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

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.

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.

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

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.

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

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

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.