A needs-driven approach to music NFT metadata

At Water & Music, we’ve extensively detailed the growth and evolution of the music NFT market over the past few years. Our recent sales report showed that music NFTs did over $86M in primary sales revenue in 2021, and the market has continued to expand since. Despite a relative macro market downturn as we continue through a “crypto winter,” the music NFT segment continues to thrive, with successful daily drops occurring across many minting platforms. Moreover, new use cases and forms of “utility” around music NFTs are emerging every month, from music NFT streaming aggregators like Future Tape and musicOS, to curatorial spaces like Gallery, and analytics tools like Dune.

That said, we are also entering a critical infrastructural crossroads in the music/Web3 landscape — where NFT-curious artists and platforms are looking to build next-gen experiences with richer context for fans and collectors, but the NFTs themselves don’t contain the information needed to drive these use cases forward.

This brings us to the unglamorous yet critical topic of metadata in music and Web3. In the context of music NFTs, metadata can include but is certainly not limited to:

• Which creators and collaborators are included in a release,
• How that release relates to others in a given drop or collection, and
• How that release has been used, compiled, curated, and/or sold over time.

One of the main benefits of engaging with Web3 is that there is a practically unrestrained design space for what information an artist wants to include with their NFT, and how exactly they want to include it (e.g. embed it directly in the token metadata, or point to it via a decentralized file storage system like IPFS or Arweave). In some ways, lower metadata requirements are a benefit to artists by limiting the amount of friction in place for experimentation.

But this open design space is a double-edged sword that leaves music NFT metadata in a relatively fragmented, undefined place. This is in stark contrast to the “traditional” music industry, where metadata requirements as part of the distribution of a track are strict, and standards-setting industry bodies like DDEX act as guides on what kind of data is required and the structure that it may be submitted in.

Even simple fields such as the title of the track, the entities involved in its creation, and the types and locations of media associated with the token can go a long way in facilitating discoverability and indexing in the NFT market, which will become increasingly important as the catalog of tracks released as NFTs continues to grow. And yet, most of these fields are nonexistent for many of the NFTs that exist to date. (As we’ve discussed in previous articles, this lack of core music metadata around NFTs has created significant challenges for us from a research perspective, especially around standardizing data collection for our NFT database and conducting analyses of secondary sales of NFT drops.)

Outside of the basic information around an NFT that can be derived from on-chain activity — i.e. a token was created through a contract by an address, listed, and then bought by an address — metadata provides color that is essential for the development of a greater level of context for an artist or project. Hence, we argue that a core element in moving towards an environment that will support accelerated development of the music NFT landscape is the establishment and propagation of best practices around metadata.

Solving the music NFT metadata issue has been a growing point of discussion over the past few months in the music/Web3 community, with repeated conversation across Discord, Twitter, and Telegram groups to bring attention to the issue and attempt to suggest solutions. There have also been some attempts to standardize music NFT metadata across multiple platforms, such as the schema working group around Catalog’s V2 launch, and the subsequent incorporation of that schema into Mint Songs’ V2 contracts. Outside of Ethereum, Metaplex has also put forth a proposal for a music NFT standard built on Solana.

At large, standards are an essential aspect of any infrastructure at scale. They provide a common understanding and communication for the propagation of data, lowering the barriers for experimentation and increasing the interoperability of systems. That said, standards also require a thoughtful, methodical, and often drawn-out approach to pull off, involving juggling competing incentives across multiple stakeholders. Historical attempts to force standards without universal buy-in have often resulted in poor adoption and unhelpful complexity (as detailed in the famous XKCD cartoon).

Similarly, developing a music NFT metadata schema from scratch will be a long, involved process requiring wide consensus from multiple parties. As a more generalist reference, the EIP (Ethereum Improvement Proposal) process is a good example of how this can be done effectively, as defined in EIP-001, and is something that the industry should look to as the conversation develops. Even still, this process can take months or even years depending on what a given EIP is targeting, see Anett’s guide here. Discourse and participation around this kind of metadata refinement process also tend to favor those with already highly technical backgrounds, and are not often grounded in tangible use cases and perspectives that artists themselves can relate to.

Hence, to start our own journey into opportunities around music NFT metadata at Water & Music, we decided to try a slightly different approach. Rather than seek to define another “new standard” for music NFT metadata, we aim simply to present the clear rationale for why it is required, the tangible use cases for which better metadata will accelerate development, and the key areas for consideration in developing this standard in the future.

We brought together several interested parties within the Water & Music community — artists, builders, lawyers, as well as people that have been involved in the development of traditional metadata standards and implementation — and set out key topics for initial investigation. The conclusion of these conversations landed on three key areas, which form the outline for the rest of this article:

• Operating from an angle of prioritizing active use cases, which will help with defining what should be in-scope of the recommendations for metadata. (Too much scope, and a metadata standard can negatively impact platforms’ ability to implement it; too little scope, and its usefulness is diminished.)
• Examining whether universal identifiers in aspects such as the media and the entities involved would be useful for platforms building solutions to the defined use-cases.
• Understanding the rights and licensing involved in an NFT, and how this affects platforms, artists, and rightsholders from a metadata perspective.

Working with the W&M community, we identified four specific categories of use cases emerging around music NFTs — focusing on those use cases that provide greater context on top of music NFT purchasing and engagement behavior, instead of merely serving as a marketplace.

A few important caveats to this approach:

1. There are likely additional areas that we didn’t think of, and new use cases will likely be developed over time.
2. Platforms may cover more than one use case in their respective features. (Web3’s inherent design, which incentivizes open supply chains, means that feature differentiation from platform to platform will be less defined within a reasonable time period.)

Use case 1: Music player

This use case covers aggregating and making music NFTs available for playback within a streaming-like UI. The most basic form of “utility” built for Music NFTs are platforms that allow users to listen to music that has been released, either with on-demand, interactive, and/or non-interactive functionality.

Many “minting platforms” themselves (for example Sound.xyz or Catalog) have this functionality, and may benefit from increased metadata availability should they wish to ingest NFTs minted through outside contracts.

Metadata requirements for this use-case are likely to focus on those which enhance the user’s experience within the platform, e.g. navigating from track to track and providing additional context to what they are listening to. There may additionally be a requirement for linking NFTs to any “traditional” identifiers that the recording or work have been assigned as part of being distributed to the wider music industry (e.g. ISRC and ISWC codes), especially if there are third parties and rightsholders involved in the rights breakdown.

Examples (we covered many of these platforms in our recent analysis of music NFT aggregators):

• Future Tape
• Spinamp
• Sleevenote/Supercollector
• Ooh La La

Use case 2: Curation

This use case covers platforms that enable the ordered presentation of music NFTs, often alongside other linked media. The curators in question can be artists, collectors, labels, and/or the platforms themselves, with the UI often focused on the sharing of NFT galleries or playlists, drawing either from on-chain data or solely from data generated within the application itself.

There is strong cross-over with the Music Player use-case, and metadata requirements are likely to be similar.

Examples:

• Tellie
• Context
• Gallery
• JPG.space
• Several music NFT platforms like Catalog, Sound, and Nina are also expanding into curation with their own on-platform features

Use case 3: Social

As the market for NFT experiences grows, so has the emergence of “Web3 Social Media,” differing from “Web2” Social Media through the promise of user-owned social graph data.

The metadata requirements for Social media platforms are likely to focus on identity and relationships among entities, in addition to the base-level requirements defined by Music Players.

Examples:

• musicOS
• gm.xyz
• Campground
• Lens
• Farcaster
• Huddln

Use case 4: Analysis and accounting

This use case covers dashboards and tooling to inform creators and collectors about the state of the music NFT market as a whole. Such tools tend to focus on the performance and financials associated with NFT drops, as well as tracking subsequent sales and plays.

Metadata requirements for this use case are likely to center on the identity of contributors alongside the financial data that can be derived through on-chain activity. Furthermore there are certain kinds of data that are required to be collected off-chain, such as a song’s performance on streaming services like Spotify and Apple Music.

Examples:

• Water & Music 🙂
• Dopr
• Zapper.fi
• Floor
• Bello
• Reveel

The examples provided here are specifically startups in the Web3 ecosystem. Inevitably, as the market grows, “Web2” platforms will continue to explore how they can integrate NFTs into their offerings (for example, Spotify’s recent addition of NFTs on select artist profiles, alongside wider NFT display capabilities for users on Instagram and Twitter).

Before considering why and what data we should be requiring as part of Music NFT releases, it’s worth highlighting a core consideration to any recommendations: The challenges in getting good data into the system, even if clear guardrails exist.

Metadata is not a sexy topic, and often represents a chore within the creative process. Using a previously mentioned example, despite the Catalog schema being defined, many of the fields are still being left empty by artists who have minted NFTs on Catalog or Mint Songs. As noted by the platform founders, in some cases the fields are not available through their UI yet, but there also appears to be little demand in general.

This is a continuation of one of the key metadata challenges in the traditional music industry, namely, getting high quality data as close to the source of truth as possible. Over the years there have been multiple attempts from projects to build workflows that make this easier, through alternative apps like Session (formally Auddly). Despite this, it remains a relatively unsolved problem in the music industry at large, and the emerging music/Web3 ecosystem is likely to be no different. Blockchain in particular is “garbage-in, garbage-out” infrastructure from a data perspective; because it is immutable, if it ends up registering faulty data in a transaction, that faulty data will live on the blockchain forever unless another transaction is verified to overwrite it.

The prospect of “solving” music metadata in Web3, and the wider industry at large, is as much a behavioral and cultural issue as it is a technical issue. Detailing metadata is one of the many, and growing, tasks that an artist and their team has to complete as part of releasing a track. Therefore, it is important to approach this subject with balance. On the one hand, extensive metadata defined as part of an NFT drop could unlock significant context and utility. On the other, onerous expectations on artists will inevitably result in unfilled fields at best, and friction in the release process at worst.

Below we present a collation of metadata requirements around music NFTs, based on the platform use cases defined above.

Some general rules:

– Where possible, we have not included data that can be derived through on-chain transactions (such as mint date, sales data, etc.) as this would introduce redundancy.

– Where possible, artist and collaborator IDs should be verifiable / on-chain IDs (for example wallet addresses).

– In general, we are taking as reasonably minimalist of an approach to metadata as possible, in order to cover the widest number of use cases while also hopefully paving the smoothest and most user-friendly path forward to adoption by multiple platforms and artists simultaneously. More specifically:

• We assume that NFT metadata should be permanent and immutable — therefore we have not included relevant music-industry information that could change over time, such as a songwriter’s publisher or PRO, or a given song’s split of revenue.
• We have also not included “traditional industry” identifiers like ISRCs or ISWCs, due to the assumption that doing so would introduce friction into the NFT release cycle (and that the underlying issues around identifying recordings and works can be solved elsewhere — see further down below for an explanation).

Identifiers

Once the metadata parameters have been established, it’s important to think about the types of identifiers that can be utilized as part of a music NFT’s metadata.

When thinking through different options, it’s important to consider that the usefulness of an identifier is correlated with:

• Its accessibility and the ease with which it can be applied, and
• The trust that one can have as to its accuracy, validity, and breadth of acceptance.

In this regard, we have two good examples within the “traditional” music industry, the ISRC (sound recording identifier) and the ISWC (composition identifier).

ISRCs are registered by agents, usually labels and distributors, from “stems” that are provided by the central registration entity. This means that they are often relatively quick to attain, but there are sometimes challenges with regards to their accuracy, due to the open assignment nature of part of the identifier.

By contrast, ISWCs are issued by CISAC through PROs. To register for an ISWC, a songwriter must be a member of a PRO and have an IPI; the PRO then registers on their behalf on the central registry. This ensures accuracy and prevents duplication, but comes at the cost of time.

Both of these identifiers require working with third-party registration entities, which causes friction in the release process. Hence we propose that neither ISRCs nor ISWCs are a good fit for inclusion in music NFT metadata. Instead, there should be efforts made to link Music NFT metadata to “traditional identifiers” via a secondary data layer. At large, the problem of streamlining and verifying traditional IDs around recordings, songs, artists, and collaborators is a wider industry issue that Web3 alone won’t solve.

On the personal ID front, there is currently significant work ongoing within the world of “Web3 identifiers”, led by companies such as disco.xyz, Gitcoin through their passport and Otterspace who are epxloring “soulbound tokens”. ENS provides “human readable” (although non-permanent) identifiers, while Decentralized Identifiers (DIDs) v1.0 recently became an official recommendation from the World Wide Web Consortium (W3C).

The environment for identifiers in Web3 is developing quickly, and it’s likely that things will look very different in the next 6 to 12 months. For now, our recommendation is that artist and collaborator IDs should be as on-chain as possible when included within music NFT metadata. For persons, this means wallet addresses until a universally accepted alternative emerges (for example one of the projects mentioned above). This may create challenges where wallets become compromised, but for now it feels like the most practical solution.

Considering multiple collaborators (or people to be paid) on an NFT can become more complicated from a logistics and identity verification perspective. That said, multiple projects such as 0xSplits and Reveel are working towards “on-chain” solutions to provide the environment to facilitate multiplayer payment metadata through wallet addresses. (At Water & Music, we recently published an extensive research project on split protocols for music/Web3 projects, which you can read here.)

Rights & licensing

Platforms that exploit the rights associated with music use are required to obtain licenses for their use from all the relevant rightsholders.

In general, there are three specific rights that must be licensed, the Master Rights, Performing Rights, and the Mechanical Rights. It is important for platforms that are building on top of Music NFTs to be informed of the liability that could be carried by providing access to certain NFTs, and what additional information they should be seeking. This is a complicated process, and one that is clearly not well understood by the Web3 community to date.

The recent poll within the Decentraland DAO that struck down the “decision” to obtain a blanket license from SOCAN via a community vote is a prime example that has been discussed widely within the W&M community. The situation with Decentraland is problematic for a number of reasons:

1. The proposal itself is misleading. Through SOCAN, the DAO could get coverage for one part of the rights picture, but in doing so would then need to enter lengthy negotiations with every other relevant rightsholder to get full coverage (which was not explained in the proposal).
2. Rights licensing is an extremely complex area of the music industry, and it is unrealistic to expect a decentralized community of token holders to be able to make an informed decision
3. The entire concept of licensing a DAO for a decentralized platform that serves multiple uses is an untested area with little in the way of precedent, so it is reasonable to expect that there will be years of back-and-forth negotiation before a standard procedure emerges.

Rights and licensing are relevant to the discussion around metadata in Music NFTs as, executed correctly, it could contain the information required to make informed decisions around what licensing should be in place.

However, we urge caution around the idea that Music NFT metadata should be modeled as the source of truth for rights information. Rights ownership and “splits” are highly contested and subject to change over time. Seeking agreement from each interested party to affix rights information into a permanent format, as they would be in Music NFT metadata, is unrealistic at scale and would introduce unreasonable friction.

Another element worth describing is the emerging proliferation of “Creative Commons” licenses attached to music NFTs. This is an interesting development in that, in theory, there could be a collection of content that could be made available to platforms building experiences for artists that do not require licenses in place. Though, in this case, it will be important to ensure that all rights are cleared through CC provision, rather than just some of them. For example, if a performer offers a music NFT through a CC0 license, but it exploits the composition of a writer that is a member of a PRO then the Performing (and likely, Mechanical) Rights must be licensed regardless. Further to music rights, there are additional rights that may need to be licensed for additional content that is included with the NFT, for example the album artwork or the lyrics.

Therefore, we propose that included within a Music NFT’s metadata is a field that informs whether the NFT includes rights that must be licensed for exploitation, ideally at a rights-by-rights’ level granularity. We recommend that the metadata does not attempt to describe who the platform should attempt to license the content from, due to the issues identified around permanence of those statements highlighted above.

If a Music NFT is licensed through a CC license, then the information around which CC license has been chosen should be made available in the Music NFT’s metadata. (Creative Commons themselves recently issued new guidance on CC0 licensing for NFTs, which you can read here.)

In conclusion, we propose taking a more minimalist, needs-driven approach to ironing out a music NFT metadata schema that is grounded in the modern artist/fan journey in Web3, instead of adopting a more standards-driven approach that we have seen elsewhere in the music and tech industries. The purpose of this approach is to foster more of the creative, boundary-pushing experimentation we are witnessing in the music/Web3 ecosystem today, while ensuring sufficient interoperability, synchronicity, and continuity among future experiences built on top of music NFTs.

Hopefully, this thesis will be a launching pad for more scalable, coordinated communication of the issues at stake. We would love to work with music and Web3 professionals and with anyone interested in the W&M community to codify the above principles into a proper schema. If you are interested in helping us out, join our membership or reach out at members@waterandmusic.com — we would love to hear from you!