Agree that it can be a good way to use ABTs but I think it’s too opinionated to be put into the standard, imo it restrict use-cases for it quite a bit.
Entities can choose to implement the standard with mintWithPermission if they want to but ABT’s scope is way larger than that.
Btw, it’s not easy to decide where we draw the line between interface and implementation, but I feel like specific behavior like minWithPermission should be dealt with at impl. level
I suggest that we standardize mintWithPermission outside of this standard (in another EIP). It can also be useful for any EIP-721 token. And generally, we probably also want another variant of mintWithPermission where the from mints for the to (mintWithPermission is implemented where to needs permission from from).
The tokens definitely do need to be transferrable, in case people want to rotate keys or if they want to move to a more effective system of organizing things.
But one should not be able to transfer tokens to a different human
One simple way to do it is to allow transfers only to accounts with the same label, where the label is a fully qualified name of the human.
In this case “Alice XYZ” will be able to transfer her tokens to another wallet with a label “Alice XYZ” but not to a wallet with a label "Bob 123’
That is easy to overcome.
I set the sub-domain, I transfer the NFT, then I reset the sub-domain.
I don’t think there is a way to enforce that limitation. So, the possibilities are either to allow transfers (maybe blocking approvals) or to disallow them.
It seems to me a solution similar to the attempts of forcing a royalty on ERC721, despite that the standard does not support it.
If I want to abuse that, how can someone block me from implementing a “mintWithPermission” function that actually does not require any permission?
Major changes are coming to ERC4973: We’re extending the Soulbound item capabilities of World of Warcraft. Namely, because you can “give” and “take” items to others.
I’ll take some time to adjust the standard’s document, but the new interface is actively being developed over in the reference implementations GitHub: Language develop standard towards Soulbound items · rugpullindex/ERC4973@27a62d1 · GitHub
In case you’re looking for a naive implementation of “Soulbound tokens” that non-separably binds an EIP-721 to an account, I recommend you check out EIP-5192 - Minimal Soulbound NFTs
Have been thinking more about the inclusion of balanceOf. The original argument about it needing it to inform the reputation based on number of ABTs you have seems flawed.
For example, if you have 5 ABTs, with 5 different tokenURIs, it may not very useful to know that a user has 5 ABTs in total. It is perhaps rather more useful to know if a user has an ABT of a certain type of tokenURI 
It is perhaps rather more useful to know if a user has an ABT of a certain type of tokenURI
I believe it was me that mentioned the use case for balanceOf. I can imagine that doing the spec for this EIP is particularly difficult as it has to be loose enough to fit many use cases, and remain as minimal as possible.
You’re saying that tokenURI indicates a “certain type” but that I believe is implementation specific. For example, each student receives individual tokenURI’s that says they passed (with additional info like grade etc.) but they could be for the same qualification type. It could be that the ABT contract address represents a type (of qualification), or does it? There could be separate ABT token contracts for each school year, or departments etc. Again, implementation specific.
For a community giving the same type of ABT token to an address (the use case I mentioned earlier), balanceOf would indicate strength of e.g. approval/trust given from the community; each tokenURI could point to text input of why a particular community member decided to give this ABT token. In this case, the ABT contract address could indicate a certain type. Still an implementation detail I feel that can work within the spec.
I know that the latest spec has removed Revoke but I believe a rethink is necessary.
Hard to predict of course without running this in the wild but imagine a scenario that an ABT has built great reputation but was somehow duped by an outfit that then did something terrible, like a rugpull. Then anyone who had built up a good reputation/business from holding that ABT would then be affected unfairly.
A worse scenario could be that the community is unaware about the bad actor, since they still hold the ABT that continues to affirm them as a good actor, unknowingly, relationships would continue as normal.
I believe in these scenarios, the issuer should be able to recall the ABT from the bad actor, in order to save the ABT’s trust level and for it not to affect all others holding and the issuer of the token unduly.
I understand the argument that it can be used by the issuer for manipulation but any well functioning community would devalue that ABT token anyway.
So a rethink to introduce Revoke again in some form, I believe is necessary, else it could seriously affect trust/adoption if the above type of scenarios happen often.
Hey, we just renamed Revoke to Transfer(owner, address(0), tokenId) in the reference implementation. It’s syntactically it’s different, semantically it is the same.
Updated EIP-4973 with the long-intended changes here: Adjust EIP-4973 interface to add `function give(...)` and `function take(...)` by TimDaub · Pull Request #5209 · ethereum/EIPs · GitHub
function give and a function take that both respectively allow minting a token consensually between two addresses using EIP-2098 and EIP-1271 (so can be used to proxy consent too)event Transfer
function burn(...) to function equip(...)
As there have been questions about how to generate the compact signature required to pass function give(...) and function take(...) and since specifying the code within the .md document, I’ve opted to create a JavaScript function using ethers that can generate the signature and also informs the structure of the inputs.
The resulting section “EIP-712 Typed Structured Data Hashing and EIP-2098 Compact Signature Creation” is more concise now and points to the .mjs files: EIP-4973: Account-bound Tokens
Just released v0.4.0 of the ABT reference implementation to catch up with the specification: ERC4973/changelog.md at master · rugpullindex/ERC4973 · GitHub
posted a rant on Twitter about the toxicity of working on SBTs in the Ethereum community: https://mobile.twitter.com/timdaub/status/1557997701874286593
We moved EIP-4973 into “Review”.
Should EIP-4973 include consensual revocation? EIP-5484 proposes it: EIP-5484: Consensual Soulbound Tokens
We probably want to implement EIP-5267: Retrieval of EIP-712 domain for improved developer experience and dynamic domain retrieval.
I’m trying to understand the “roles” defined in the EIP712 structure Aggreement(active,passive)
If A want to create a “give” request to B, he first asks B to sign Aggreement(active=A, passive=B), but then A could issue a “take” instead of “give”.
Instead, I think the agreement should be TransferAgreement(from,to,token). That is, the signature should describe the token movement direction, not the user issuing the transaction.
The signer of this structure depends on the inactive side of the transaction (you could argue that actually both sides sign, as sending this transaction requires the “giver” or “taker” to sign it.)
In another note, you could support meta-transactions by having the signatures of both “giver” and “taker”:
e.g.
move(address giver, address taker, bytes giverSig, bytes takerSig, string tokenURI)
@dror, thanks for your comment it’s all relevant and valid. I’ll respond to it in more detail in the future.
In the following post, I want to highlight a problem we’ve encountered in the music NFT industry. As a quick aside, these days, I work as a tech lead on https://neume.network, and we’re essentially building a socially scalable data pipeline to extract and augment on-chain data. For all of the music NFTs hosted on Ethereum, in contrast to the Graph Protocol, at Neume, we’re not trying to make contract storage data more accessible. Instead, we want to build a list of music NFTs that users can listen to via an app like Spotify.
A quick disclaimer: My work on Neume Network is financed by hifilabs.co, and they’re creating https://musicos.xyz, an audio player built on the music NFT data that we’re indexing with the Neume Network software.
Now: As it’s a lot of work to extract music metadata from smart contracts, today we got some users’ feedback, and to my surprise, it sounded like we had unconsciously optimized for indexing the big curated music NFT platforms like https://sound.xyz, https://beta.catalog.works/, https://zora.co/, and https://www.mintsongs.com/ V2.
But truly, this was never our intention: But I was caught off guard by the user feedback, and so this post is somewhat a reflection on what happened and led to problematic emergent effects.
See, for https://musicos.xyz, as it’s an audio player like Spotify, we naturally wanted to index the best possible and probably also most popular platforms. So when starting the project, we intuitively went for the popular ones - those that we knew provided nicely sounding songs.
And when they launched musicos a few days ago, I suddenly found myself confronted with the following user feedback questioning the credible neutrality of the Neume Network indexer. Here’s what users said:
Additionally, an artist I am I fan of had this to say on Twitter:
So let us unpack what is being discussed here. In my own words: Guspy, Supersigil, and thepark.eth are all asking for their tracks to be listed on the music-os app we had just released. And they did so by pointing out an interesting dynamic in the music NFT space. guspy mentions that the music they had minted through a custom contract on https://www.manifold.xyz/ isn’t showing up on music-os. They’re saying that having their contract being indexed is posing a challenge: And that instead, had they minted their song on Catalog, Sound, or MintSongs, then it probably would have made it into music-os.
Extrapolating their statements here, too, we can reason that any track that gets lots of exposure through a music player may fare better on first and secondary sales. So potentially, for guspy et al., having their songs exposed on music-os can potentially mean an improvement in income. Or anyways that their songs are listened to at all.
In the post by Supersigil below, they help double down on the argument, namely that artists need to be given the option to “be their own platforms” and that hence the favoritism of Neume Network to implement the big music NFT platforms first is a challenge to all artists hosting independent contracts.
There’s also an interesting insight in their posts: Namely that the platforms are curated by genre or type of music. And so, despite some artists’ work having the potential for popularity - they may never end up being exposed to larger audiences given the moderation policies of the respective platforms.
And there’s actually more context to unpack here: Historically, the big platforms like sound.xyz and catalog.works have been heavily curated - or at least that’s how their music sounds to my ears. I can back this up with visitor data, too, as I had played around with a minimalist website that allowed users to listen to sound.xyz and catalog.work’s songs on a website I called https://tracks.lol.
For a brief moment in time after its release, it gathered a notable listener community and was widely shared on Twitter despite the website having any meaningful web design or other functionality. Below’s a screenshot of the page, or you can see it yourself by visiting: https://tracks.lol:
And what my intention had been here is that I had been experimenting in the true sense, and so I carefully controlled the website’s utility to test the music’s popularity.
As you can see, there weren’t any fancy animations - no marketing website to convert users. All there was a single page that played music from sound.xyz and catalog - with the hypothesis being that people would still like this arguably “shitty” website because it played nice music! And oh boy, did they! Here’s a screenshot of my plausible.io tracker, and you can access the numbers yourself by clicking the following link Plausible · tracks.lol
So clearly, it couldn’t have been my sick web design skills or the amazing utility you got from the website’s controls. The reason people briefly shared the page was the music on it was nice.
And let me reassure you, this is also the qualitative feedback I’m gathering from anyone that I manage to expose to sound.xyz and catalog’s tracks! They’re doing a great job in properly curating NFTs to seed the initial consumption network.
And I’m capable of negating that argument, too: Where if you’d built a website that focuses on listing the highest grossing NFT sales on OpenSea, you’d end up not with an aesthetically pleasing newsfeed of NFTs: You’d just get a seemingly random list of Bored Apes, and, in fact, I can prove this to you right away by asking you to visit: Top sales | Context where at the time of writing, the four latest updates in the feed are apes - boring!
But despite curation platforms like sound.xyz and catalog.works accelerating the music NFT industry in the first place, there is a sort of tragic story in this utility provision too, which are the problems pointed out today by thepark.eth, Supersigil, and guspy: Namely, that while curation can excel an artist’s work, it’s also gatekeeping other artists from putting their latest tracks in front of a larger audience. And it discriminates against genres.
In the end: This capability to curate who and what song is gonna be popular comes with a lot of influence, and so: curating, gatekeeping, and/or censoring: Those actions create power structures. Structures that are actively being misused today to seek further self-serving profit.
It is actually well documented, and just a recent prominent example is CoryxKenshin’s rebellion about Youtube’s arbitrariness, favoritism, and racism in moderating potentially harmful content. It highlights a few faults.
The fact that those who moderate do so opaquely - with non-consistent guideline interpretation. With potential implicit bias and little public accountability. Governance, as we say in the crypto-sphere, doesn’t seem to be a meaningful keyword.
But OK - what has any of this to do with EIP-4973 and Account-bound tokens? And yes, at least for now, this post has been overfocusing on the problems and not a solution. It’s a principle I work by called “problem-driven development,” and so now, since we’re sufficiently informed, let’s discuss a potential solution.
A thesis I have been pursuing with https://rugpullindex.com, the Neume Network, and now also with Account-bound tokens is how infrastructure provision and making it broadly available to any players in a market can produce a wealth-transfer or generally broader equity. With rugpullindex.com I’ve seen this because others built mobile apps based on my API. With Neume Network, we’ll see this effect emerge as developers are capable today of replicating the https://musicos.xyz experience by using our GPL-3 licensed Neume Network crawler or by simply using our data set at neume-network/data.
As pioneered by Sabre and Amadeus in the airline industry, by commoditizing and co-owning the infrastructure - namely the database that holds all future flights - similarly, we’re able to create competition around the supply of good music NFT metadata offerings: And we postpone what Ben Thompson calls “Aggregation Theory,” an effect of profit-seeking and monopolizing a market’s supply side.
But enough with the theory: Simply put, what the above means is that EIP-4973 can make the data structure for consensual music curation available to anyone with a wallet using account-bound tokens to express agreements on-chain. And it simultaneously removes relevancy from the big curation platforms like sound.xyz and catalog. So how would it work?
See EIP-4973 is a truly peer-to-peer contract in the sense that no single individual or group has different privileges when interacting with the contract. This isn’t true for many contracts, by the way! Most EIP-20 contracts implement permissioned minting, and so do EIP-721 tokens to preserve artificial scarcity.
But EIP-4973 doesn’t implement such hierarchical logic. It’s flat, and instead, for two addresses (EOAs or contracts), if both addresses provide a valid signed message, then an Agreement over a document hosted at string tokenURI may be etched to the chain.
That storing of a consensual agreement can be done two ways - and surprisingly, it’s NOT done through minting, but instead, we implement two bulky functions called function give and function take. Here’s a drawing of how they work.
from can give an ABT to to and is the sender of the transaction.to can take an ABT from from and is the transaction’s sender.I’m linking the reference implementation code snippets below in case you want to dive deeper. But for continuing to read this post, it’s not necessary to understand them deeply.
To clarify: The result of both of these functions is that a new token is minted to address to: And their validation method is similar. Namely, both need two valid signatures of string tokenURI from address from and address to. Their difference is who represents the active part on-chain and who just provides a signature. The figure below outlines the difference in both cases:
For function give(address to, ...), address from must wait for address to's signature to arrive and can only then send the transaction on-chain to cement their agreement. Whereas in the case of function take(address from, ...), address to takes the ABT from address from and hence has to include their signature.
So these primitive functions have been deliberately called “give” and “take.” It’s because, in the World of Warcraft universe, where Soulbound items were first implemented and since this in-game metaphor has become EIP-4973’s baseline, players could also “give” and “take” certain items.
In case a player completed a quest, the NPC often “gave” the player items: But it was at the player’s discretion to preserve them in their bag. Likewise, although this challenges the “consent” metaphor, players could “take” items from a dragon or firelord they had slain earlier.
So going back to our initial story of how EIP-4973 Account-bound tokens can help the music NFT industry’s curation problem, here’s what I’d like to say:
Right now: It is a one-way street where artists are practically dire for having their tracks minted on popular curation websites. It’s also a problem as the infrastructure for curation is proprietized - so assuming this moat strengthens further over time: It’ll also negatively raise the bar for unestablished artists to publish.
And we must acknowledge that the above-mentioned dynamic won’t go away overnight too. Instead, given our thesis that commoditizing infrastructure can break markets, I think by using EIP-4973 for consensual on-chain curation of music NFT playlists, I think we could achieve more equitable outcomes if more people could become curators.
It is because standard adoption can initially level the playing field of access to attention. Instead of one website being able to promote their tracks and build potentially proprietary solutions, with EIP-4973, we have a primitive that can express bidirectional agreements between curator and artist.
And sure, we could implement contracts where the curator is in charge of administering the listing. But I think that’s an unwise design, given how reproducible content is curated nowadays. Rather, if the authors and the curators mutually agreed on which tracks end up on what lists - I believe this would carry a higher signal when compared to curator-only feeds.
Additionally, by making the curation infrastructure usable by anyone, a greater degree of competition would improve outcomes and reduce the risk of a single party monopolizing.
Wide-scale adoption of this standard would incentivize indexers and other NFT infrastructure providers to implement its interfaces and make the on-chain data symbolizing publicly-visible agreements broadly available.
If you’re deep in the traditional music industry, you probably know how complicated moral rights can get - and here’s a standard that can potentially solve some of this domain’s questions.
So how would this end up looking? Here’s a sketch:
event Transfer(address from, address to, uint256 tokenId) is sent.Now, it’d be great if, additionally, a “curation release signal” could be emitted that clarifies to music NFT indexers when a new song is released. And that could happen after having reached an agreement between the artist and curator.
Remember, minting an NFT is not laying claim to license your work permissively. An artist retains all copyright, and so technically speaking, unless there’s a specific agreement put in place, reproduction of a music NFT is simply a legal grey zone many seem to tolerate for now.
Hence this whole essay on chainifying two parties’ agreement - Since the string tokenURI's content would detail the conditions under which curator and artist have decided to collaborate to release the NFT.
For the curator, there’s no clarity on whether they’re allowed to reproduce the artist’s song on their site. And for the artist, there’s transparency regarding what can be done with their work and what can’t.
So that’s it, that’s why EIP-4973 Account-bound tokens could drive curation in the music NFT industry. Anyways, this is a very long post, so I’d now like to start concluding it.
In this post, we’re documenting the problems of the emerging music NFT industry and how the aggregation of music NFT supply creates suboptimal outcomes for independent artists.
Our thesis is that well-curated media content is useful to anyone but that it can also easily lead to power abuse.
To combat this potential negativity and to “break the curation market,” our thesis is that the commoditization of infrastructure can help level the playing field. And specifically, it means that by mainstreaming consensual content curation, a new ecosystem of dApps could emerge that serves curators and artists alike.
EIP-4973 Account-bound tokens are the basis for expressing consensual agreements on-chain. Their lack of permissions in minting makes them ideal to be applied broadly and in a true peer to peer fashion.