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
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.
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:
- 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.
- 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.
- 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
- 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.
- 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.