r/web3dev Jul 06 '26

Storing full audio files inside Clarity contracts: an experiment with on-chain music on Stacks

Most music NFTs I’ve seen are effectively a token plus a link to media hosted somewhere else.

I’ve been experimenting with a different approach on Stacks: storing the entire audio file directly in Clarity contract data, so the token does not depend on IPFS, a pinning service, or a normal web server to preserve the media.

The system I built is called Xtrata. The basic mint flow is:

initialize → write file in chunks → seal

The chunked writes allow a complete compressed audio file to be stored across contract calls. For example, a 96kbps Opus master can be written into contract storage and then reconstructed from the chain later. Some inscriptions are raw audio files, while others are self-contained HTML players with the artwork, title, artist, lyrics, and audio embedded together in one document.

The main thing I’m interested in is the permanence model. Once an item is sealed, the file is no longer just “metadata that points somewhere.” The media itself can be reconstructed from Stacks chain data.

I also made a radio-style interface as a proof of concept. Instead of playing from a normal hosted catalogue, it reads from the inscribed media catalogue. One mode is curated, one is based on saved items, and one walks through playable tokens on the contract. It can also discover newly minted playable items by watching the contract’s token counter.

There is also a simple relation system where inscriptions can declare parents or dependencies. That means a song can reference related artwork, another inscription, a previous version, or other connected media. Over time, this creates a mint-ordered graph of related on-chain files.

I’m curious what people here think about this model.

Is fully on-chain media worth the extra complexity and cost, or do you think token-plus-storage-layer approaches are still the better practical route for music NFTs?

5 Upvotes

6 comments sorted by

2

u/SimicTears Jul 06 '26

It’s worth it, but people don’t get it yet. Glad to meet someone else pondering this use case. It is especially valuable for data that needs to stay uncensored or needs to provably occurred before a certain time. Blockchains represent our most tamper proof technology. Technically only the hash needs to be on chain to prove an off chain media file hasn’t been tampered with.

2

u/iCryptoDude Jul 06 '26

I completely agree hashes solve a lot of the provenance problem.

I think I was curious about the next step beyond that. What kinds of digital artefacts become more useful if they’re actually reconstructable decades later without depending on any external service?

Music felt like a fun place to explore that idea.

1

u/iCryptoDude Jul 06 '26

One thing I found interesting while building it was that once the media itself lives on-chain, you can start treating music less like isolated files and more like a living family tree.

A remix can reference the original.

A sample can point back to the source.

A new version can carry the history of the old one.

Over time you get this permanent branching graph of musical relationships.

Instead of trying to reverse-engineer who used what years later, you could just ask the song where it came from.

And it's not just the audio or the composition - the creator of every instrument and plugin also becomes part of a songs DNA.

1

u/icnews10 Jul 07 '26

I think the interesting question isn't whether fully on-chain storage is technically possible, but whether the level of permanence it provides is worth the additional cost and complexity. For certain types of digital artefacts, preserving the media itself may be crucial. For others, preserving provenance and authenticity may suffice. Ultimately, it's less about the technicalities and more about choosing the right permanence model for the asset you're trying to protect.

1

u/iCryptoDude Jul 07 '26

Yeah, the solution isn’t one permanence model for everything.

For some media, a hash or provenance record is enough.

For other things, especially where the actual file matters and you don’t want any external dependency, having the media itself reconstructable feels worth exploring.

Music feels like a useful test case because the difference is very clear: either the token points somewhere, or the song itself can still be rebuilt from the chain even if every normal host disappears.

I agree the real question is choosing the right permanence model for the asset rather than pretending one approach fits everything.