EIP-4973 - Account-bound Tokens

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

@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?

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.

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

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.

2 Likes

@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

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