This is probably discussed above (I haven’t read the whole discussion), but I’m pretty strongly against this concept. Users MUST be able and encouraged to rotate their keys regularly, and especially when compromised. I would be less bothered by this specification if it explicitly prevented EOAs from owning assets, and everything had to be owned by a wallet of some kind. However, that prevents people from upgrading/migrating wallets when there is a problem with the wallet or a better version comes out, which is nearly just as bad of a problem.
2 Likes
@MicahZoltu, thanks for your feedback. By answering you, my goal is to integrate your objection to the current form of the document as close as possible.
I first want to say that the current iteration of the specification does indeed foresee users’ keys getting compromised, as the “Exception handling” section details:
Given the non-transferable between accounts property of ABTs, if a user’s keys to an account or a contract get compromised or rotated, a user may lose the ability to associate themselves with the token. In some cases, this can be the desired effect. Therefore, it is suggested to implement re-issuance and potential revocation processes on the issuer side to enable recourse when it is not.
This document is deliberately abstaining from offering a standardized form of exception handling in cases where user keys are compromised or rotated.
In cases where implementers want to make account-bound tokens sharable among different accounts, e.g., to avoid losing access when keys get compromised, we suggest issuing the account-bound token towards a contract’s account that implements a multi-signature functionality.
I believe, however, that your objection originates in the idea that the specification makes no normative statements (e.g., “MUST”) on whether recoverability MUST be implemented. Rather, it’s outlined as optionality, e.g., implementers can decide.
To address your comment, first, I want to be skeptical about your observation that everybody should always write contracts that support frequent key rotation. I’m bringing this up as I, at large, observe the Ethereum community being non-compliant with this norm by, e.g., coupling many valuable core functionalities directly to accounts.
A recent popular example is Optimism’s airdrop attempt to 250k historically active accounts. In this case, albeit according to your statement, frequently rotating keys MUST be allowed and encouraged; the OptimismPBC, an organization closely associated with figureheads of the EF, has decided to account-bound the airdrop rewards. On an anecdotal level, I’m also sad to say that I’ve lost countless chances to potential airdrop rewards. Thousands of dollars are stored on accounts I’ve lost access to, all because members of the Ethereum community have NOT complied with your normative statement.
However, on the other hand, by liquifying stakes as staking tokens, e.g., in protocols like Uniswap, what’s important to highlight positively, is that many DeFi applications must be aware of the problems that account binding has. E.g., naively implemented, a contract could assume a lender’s account and their capacity to prove key-control via a signature to re-access their collateral. However, most protocols, at least from what I understand, have chosen to fungifying liabilities in subtokens.
So, e.g., when a user lends tokens to Uniswap, they get a stake token back that allows them to redeem their collateral from any other account (e.g., users can transfer stake tokens). Implementing staking with special staking tokens allows collateral to be account-agnostic and encourages simplified key rotation.
What’s clear, however, is that albeit the Ethereum community has aspirational goals towards non-account-binding, those ideals are far from being norms.
The most naive way to comply with your requirement would be to allow users to transfer ABTs between accounts. Another one would be, as you suggested, only giving contracts the ability to receive account-bound tokens.
However, I believe this would defeat the standard’s purpose as users would probably be better off using, e.g. EIP721 or EIP1155 tokens. Unless you see a productive way of framing EIP4973 as account-bound tokens with a “friendly” transfer function, I’d like to ignore these options to integrate your feedback as I think it’d lead to staleness or abandonment.
Instead, I was wondering if you feel like your requirement is fulfilled by adding the following to the specification:
- In the “Specification” section, we add a normative statement that, using
event Attestandevent Revoke, implementers MUST provide an application-specific migration mechanism to encourage key rotation. And additionally, - in the “Exception Handling” section, we reproduce a shorter version of our argument here on the forum to rationalize the decision.
Would this address your requirement?
3 Likes
@MicahZoltu, with some more time to think, here’s an additional mechanism that represents a compromise between binding tokens to accounts while encouraging key rotation in, e.g., case of key loss/compromise.
In my last post, I categorically excluded the option that’d allow an ABT holder to “friendly transfer,” as I said it’d mean users should rather use EIP-721 or EIP-1155 tokens.
I then suggested adding a normative statement about ABT needing to be transferrable in the case of key compromise but that the actual behavior should be left to the implementer.
With this post, I want to outline an additional possibility that talks about implementing “friendly transfers” in a particular way, namely exclusively with the Attestation issuer’s consent.
E.g., permissive “friendly transfers” implemented in ABTs would mean that implementers would be better off by implementing, e.g., EIP 721 or 1155. A friendly transfer that EIP-4973 could achieve is one where the original Attestor of an event Attest has to accept an Attestation receiver’s “friendly transfer” request.
E.g., say we have a university issuing EIP-4973 tokens to students - but we want to continue to encourage students to rotate keys for safety frequently. However, we also don’t want students to sell their credentials - as the university; we want a degree of control and transparency over which students have our issued credentials.
In that case, a function where both the signature of the Attestation issuer (the University) and the Attestation receiver (the student) is necessary to execute a “friendly transfer” successfully could be an appropriate process.
E.g., as a university, we’d ask students to submit proof to a process that sufficiently motivates a “friendly transfer” of their credentials to a new account. Upon proof review, as the university, once the student starts the key rotation process, we support the transfer process through the university signature.
2 Likes
Moving some of the active conversations Tim and I have been having to here so that broader community can engage as well.
The topic of consent management & reassignability hasn’t yet detailed here, albeit very important. I tend to see ABTs through the lens of the following 4 vectors
- Issuance - who issues the ABT
- Attestation - how the ABT came into existence
- Revocability - being able to revoke/burn an ABT
- Reassignability - reassigning the ABT to another account
An extreme case to account for is someone minting an ABT with sensitive / compromising metadata and then sending it to someone without having any ability to get rid of it. With the flexibility or minting an ABT to any address and having Revocability via the _burn(), this is significantly derisked. I’m interested in collecting more input on actively accounting for consent when it comes to Issuance of ABTs.
Another extreme case to account for is account loss or moving ABTs across accounts/wallets but with the same person. Since there is potential to capture identity & reputation within ABTs, there’s a need to extend functions around reassignability of the token. Note that, we need to distinguish between “transferability” and “reassignability”. The former is initiated by the account owner itself while the latter doesn’t make that strict assumption and can be proxied to another account
Reassignability (and Attestation) needs to defer the details of how it can be managed and under what conditions to the implementor. The implementor can then deploy governance measures in order to execute the reassignment.
I propose to consider the inclusion of _reassign(), perhaps to a pre-assigned account address, included during the mint and maybe captured as a separate mapping.
3 Likes
This is basically saying, “any system that uses this should be censorable”, and I’m not sure which is worse, censoring users or compromising user security.
Yes, it is a huge problem in Ethereum that we should try extremely hard to fight against, rather than supporting this behavior. While I’m against preventing people from doing things that are (IMO) bad, I feel pretty strongly that we shouldn’t reinforce such behavior. Pretty much every security expert will tell you the exact same thing, which is keys MUST be rotatable. Many developers ignore the advice of all security experts and build systems that don’t support key rotation, but this doesn’t mean we should encourage that behavior.
Proposed Solution
IIUC, the goal of soulbound tokens is to make it so a token can’t be separated from the rest of the activities of a particular actor. One could achieve this by binding tokens to something like an ENS name, rather than an account. Imagine some NFT is owned by alice.eth. If the owner of alice.eth changes, then the owner of the NFT changes. If Alice has 10 NFTs, she cannot separate them as they are all owned by the owner of alice.eth, they can never be transferred to bob.eth and since alice.eth will always have a single owner, they can never be owned by multiple people or distributed to multiple people.
With a scheme like this, Alice can use an EOA or a contract wallet, and roll her keys, and change her wallet provider. Each time, she merely needs to change the ownership of alice.eth and all of her soulbound tokens will follow her.
While Alice could sell alice.eth to Bob, she would functionally have to sell her entire identity to Bob. She cannot sell just a small piece of it. Similarly, if Bob wants those soulbound tokens he would have to fully take on the identity of Alice. He could not merge alice.eth and bob.eth identities.
5 Likes
Binding to ENS name has its own tradeoffs. The ownership of ENS can expire & change while the tokens are still bound to it and without active awareness of the owner - I feel that this approach defeats the whole purpose of binding tokens to an actor in general. Although it addresses some risks you mention while also presenting a different set of opportunities, it seems to introduce a whole new set of tradeoffs. There’s no reason why another spec for ENS-bound tokens couldn’t live in parallel to this approach.
Although, the approach I proposed above about this EIP supporting reassign-ability, wouldn’t that solve the problem of key rotation in part? Keen to hear your thoughts on that.
1 Like
There is no way to actually bind tokens to an off-chain actor, you can only do something that proxies for it. I think the ENS binding approach solves the problem in an ideal way in the vast majority of cases, and the failure mode of “forgot to renew my domain and didn’t pre-register it for 100 years” I think is less common and less bad than “I need to upgrade my contract wallet but can’t” or “the system decided to censor me”.
I’m pretty strongly against this because it introduces a vector for censorship into the system, and I’m a huge proponent of building censorship resistance into all systems on Ethereum (especially standards).
in regards to the recently released paper by Puja, Vitalik and Glen Decentralized Society: Finding Web3's Soul, I was wondering if the name SBT would not be better than ABT?
The Souls concept described in the paper makes a lot of sense imo.
There’s an argument to be made that it’s probably easier to market by being a little bit more abstract.
I think that sufficient adoption/marketing is a requirement for it to work at scale (enough to convince protocols to integrate this new standard and make it wildely adopted).
It also conveys a broader idea of which entities can issue these tokens (as Souls is more abstract than accounts), and can make it easier to think about novel applications with it.
Also, this is just my opinion, but I think SBT sounds better, which is not so important but still.
An oblivious downside to this is ofc obfuscation as the name is not as clear as ABT, but we can make the same remark about the name NFT.
I talked to @TimDaub about this and he didn’t seemed opposed to this idea :
E.g. in reference to vitalik et al.'s paper where they specifically say that souls are e.g. represented as "accounts" we could get away with calling EIP-4973 "soulbound" tokens
I would be happy to hear your opinions on this.
4 Likes
Prompted by @vitalikbuterin et al.'s fantastic paper, with the Otterspace team we hacked together an EIP-4973 contract and shipped a minting interface.
- Blog post 1: The Otters go Soulbound — Otterspace
- Blog post 2: Shipping EIP-4973's Soulbound tokens to test net
- Demo app: https://badges.otterspace.xyz/
- Front end code: GitHub - otterspace-xyz/badges: EIP-4973 contributor badges for DAO. A protocol implementing Account Bound Tokens / Soul Bound Tokens or Non-Transferable NFTs.
- Back end code: GitHub - otterspace-xyz/otterspace-contracts: The Solidity contracts for EIP-4973 contributor badges for DAO. A protocol implementing Account Bound Tokens / Soul Bound Tokens or Non-Transferable NFTs.
- Otterspace website: https://www.otterspace.xyz/
there are some discussions right now about cross-rollup NFT wrappers, that complies with the ethereum vision of moving to L2 for general computation.
But if the ABT (or SBT) is non-transferable, doesn’t it prevent “holders” from moving it to L2’s, and if that’s the case, doesn’t it restrict the use-cases for it quite a lot ?
Schools or conventions for example won’t want to pay L1 gas to issue these tokens, but if they use a particular L2, there’s a risk that the ABTs distribution gets fragmented over different L2, making it harder to design some of the use-cases highlighted in the paper.
It would be good to think about a way to make it available to any L2.
@TimDaub suggested the option of having an app that allows you to re-attest a L1 token to L2. (or from L2 to L2)
Another way would be to have some kind of message-passing standard between L2s that would allow for (among other things) checking the existence + propreties (like ownerOf) of an ABT/SBT token on a different chain.
3 Likes
Oliver Klingefjord on the RadicalExchange Discord wrote another original take which I thought was important to document here [in response to reading @vitalikbuterin et al.'s paper on SBTs]:
I enjoyed the paper, but don’t get why soulbound tokens (essentially public attestations) need to be tokens at all. You could just have them be self-verified datapoints signed by the receiver and the senders private key, and host it on IPFS.
If you imagine these SBTs to represent something fairly “big” (like attendence to a uni course), as opposed to a positive compliment, that makes sense. But I could see an interesting future of reputation systems where everyone can attest to each other in all sorts of things, and systems could aggregate these attestations in complex ways using ML for multi-dimensional reputation
I guess if you have a blockchain hammer, everything looks like a token nail
1 Like
I opened a separate topic over at ethresearch about this: Authentic Event Logs - Execution Layer Research - Ethereum Research
1 Like
To expand on the idea of using ENS as the user’s “soul”, one can further generalize this to allow any NFT to be a “soul” (ENS names are just ERC-721 tokens). Essentially the idea would be that a soulbound token is one that is bound to an NFT. Whoever owns the NFT, also owns all of the attached soulbound tokens.
In my mind, the idea with soulbound tokens is that a collection of them cannot be merged or separated, and to achieve that you really just need to bind them to something. NFTs are, IMO, an ideal “soul” for this use.
As a fun thought experiment, this means that a Bored Ape or Crypto Kitty would be your soul, and all of your POAPs and whatnot could be bound to that soul.
4 Likes
That is an interesting idea, although it plays on different assumptions & user needs i.e., binding a collection of NFTs to another non-transferable token. I quite like idea in general but I do think it solves a different problem set than this EIP, while also enabling new possibilities. I think it should be a different EIP altogether, being mindful about bloating the scope of this too broad.
2 Likes
What problem do you believe this EIP is solving?
Binding to an NFT / ENS name is a good way to solve for key rotation and might be applicable to some use cases but doesn’t work when you want stricter non-transferability.
This works well if we’re talking about identities like “nick.eth” that accumulated a lot of reputation over time. The more reputation you build the less inclined you are to sell your ENS.
But let’s say you want access to an exclusive club where membership is very valuable, represented by a specific Soulbound token and must be earned through a 6 month training program (not bought). I could create a fresh ENS name, get that SBT and sell that ENS to you, effectively selling that membership and tarnishing what it means to be a member.
1 Like
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 thefromfield is taken from the transaction’sfrom; andevent Revoke(to, id)where thefromfield is taken from the transaction’sfrom; and
Maybe not a blocker but something to consider: this conflicts with GSN-style transactions (see ERC-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.
5 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? 
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?
3 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).