How the Music Industry Lost the Ability to Say No, and How Programmable Permissioning Can Give It Back (REPO IN THE END IS IDEA STAGE!)

Introduction: The Two Crises of Digital Music

When Shawn Fanning released Napster in 1999, it was used by tens of millions of people to exchange MP3 files. Within two years the service was shut down by court order, but the damage was not reversible. The record industry had spent half a century controlling the physical distribution of music — vinyl, cassette, CD — and the MP3 dissolved that control in a single file format. What followed was not a transition but a rout.

The industry’s response was to chase the technology rather than solve the underlying problem. It sued its own customers. It built digital rights management systems that were cracked within weeks. It licensed its catalogue to streaming platforms on terms that maximised short-term volume and minimised long-term artist leverage. And it never solved the structural question that Napster exposed: how do you enforce a copyright when the container itself has no gate?

Twenty-five years later, the industry has a second crisis layered on top of the first. Streaming replaced piracy as the primary distribution channel, but it inherited the same architectural flaw. A file can still be copied without permission; the difference is that the copy is now monetised by a platform rather than traded by a peer. Streaming pays artists a fraction of a penny per stream, and the pro-rata royalty pool means revenue flows disproportionately to the major labels — who are also shareholders in the platforms. In 2024, Spotify demonetised every track receiving fewer than 1,000 annual streams, which by one analysis rendered the overwhelming majority of the platform’s catalogue worthless in the eyes of the platform itself. The value gap did not disappear when the industry moved from YouTube to Spotify. It merely changed address.

Into this gap has stepped a new generation of blockchain music platforms — Audius, PlayTreks, Royal, Opus, Catalog, Sound, and others — promising to disintermediate the industry and route royalties directly to artists. The promise has not held. The fundamental problem is not that blockchain is the wrong technology. It is that these platforms implemented the wrong primitive. They built notary receipts — systems that register whatever you hand them, immutably, without asking whether you had the right to hand it over in the first place. A notary does not stop a forged signature. It certifies it.

What the music industry needs is not a better receipt. It needs a sieve.

Part One: The Structural Problem — From Container to Receipt

To understand why the notary-receipt model fails, it is worth being precise about what a copyright actually is and what the digital transition did to it.

A copyright is a negative right — the right to exclude others from reproducing, distributing, or adapting a work. In the physical era, the negative right was enforced by the physics of the container. A vinyl record could be copied only by pressing another record; a cassette could be duplicated only at generation loss; a CD could be burned, but the burn required a blank disc, a burner, and time. The friction was not legal, it was material. The law sat on top of a physical gate that did most of the enforcement work.

The MP3 removed the gate. A compressed audio file can be copied infinitely, transmitted instantly, and stored on a device the size of a thumbnail. The law did not change — the reproduction right still applies to a digital copy as much as a physical one — but the architecture changed. There was no longer a container that could say no. The file simply was the copy.

Every subsequent attempt to solve this problem has tried to reintroduce a gate at the wrong layer. DRM tried to lock the file itself, but a lock that must be opened by the user’s device is a lock the user can pick. Content ID tried to identify infringing uploads after they were posted, which is a reactive filter — it catches what has already escaped, and it can be gamed by whoever files first. Streaming platforms tried to replace ownership with access, which solved the distribution problem but created a new one: the platform, not the artist, now controls the gate, and the platform’s incentive is to maximise engagement, not to enforce the artist’s terms.

The blockchain platforms tried something different. They said: instead of locking the file, let us register the rights on a public ledger, and let the ledger’s immutability serve as the enforcement mechanism. But this misunderstands what immutability does. An immutable registry of false claims is not an enforcement mechanism; it is a permanent record of fraud.

The result is a system that is worse than the old one in one specific way: the lie is permanent. On a centralised platform, a fraudulent copyright claim can be disputed, reversed, and the fraudster banned. On a blockchain, the fraudulent token is immutable. The fraudster’s wallet holds an asset that cannot be taken away, and the legitimate rightsholder must now fight an on-chain claim that cannot be unmade.

This is the problem the Cryptographic Sieve is designed to solve. Not by making the ledger more trustworthy — a ledger cannot be trustworthy about facts it has not verified — but by moving the gate before the ledger. The sieve does not register what it is given. It refuses what it can prove is wrong, and it carries that refusal forward into every subsequent derivative.

Part Two: The Web3 Shortcut — Why Registration Without Verification Fails

The blockchain music platforms that emerged after 2017 made a genuine architectural bet: if you replace the label, the distributor, and the collecting society with a public ledger and a smart contract, you remove the intermediaries who capture the value. Audius, PlayTreks, Royal, Opus, Catalog, Sound, and a dozen others built variants of this thesis. The bet was not wrong in principle. It was wrong in sequencing.

Every one of these platforms built the registration layer first. Almost none of them built the verification layer.

The mechanic is consistent across them. A user connects a wallet, uploads an audio file, signs a transaction, and receives a token that represents the work. The platform may compute a hash of the file to prove that a specific byte sequence was uploaded at a specific time. It may store metadata — title, artist, duration. It may even offer royalty splits among collaborators, configured by the uploader at the moment of minting. What it does not do is ask a single prior question: does this work already exist, and does it already belong to someone else?

That question is answerable. The infrastructure to answer it has existed for two decades. Gracenote maintains acoustic fingerprints of tens of millions of commercial recordings. AcoustID and MusicBrainz maintain open databases of audio fingerprints and music metadata. ACRCloud provides content recognition as a service. Shazam’s parent company has catalogued the commercial music of the world. The ISRC system assigns unique identifiers to sound recordings; CISAC’s databases track musical works and their writers across collecting societies. National copyright offices maintain registries. The Internet Archive, IMSLP, and the EU’s public domain registries catalogue works whose protection has lapsed.

A serious verification layer would query these sources. It would fingerprint the uploaded file and compare it against the known corpus. It would check whether the uploader’s claimed authorship conflicts with an existing ISRC, an existing CISAC work registration, or an existing on-chain token from another platform. It would check whether the work is in the public domain and, if so, in which jurisdictions. It would flag a match before a token was minted, not after.

None of the major Web3 music platforms do this. The reasons are structural rather than accidental.

The first is cost. Fingerprinting every upload against a commercial database costs money per query. On a platform whose entire pitch is permissionless, frictionless onboarding, a per-upload verification fee is an architectural contradiction. It also creates a bottleneck: verification requires a verifier, and a verifier is an intermediary, and the whole point was to remove intermediaries.

The second is the oracle problem. A blockchain cannot look up Gracenote. Someone — a server, a multisig, a decentralised quorum — has to perform the lookup and report the result on-chain. Whoever performs that lookup becomes a trusted party, and the moment you have a trusted party, you have reintroduced the centralisation the platform was built to escape. Rather than solve this, most platforms simply skipped it.

The third is incentive. A platform’s growth metric is the number of works registered. Every verification step is a potential rejection, and every rejection is a user who does not mint and does not return. The commercial pressure pushes toward a posture of deliberate blindness — a hands-off approach to user-generated content that functions as both a growth strategy and, conveniently, a shield against liability. Whether or not that framing is stated openly, the effect is documented: unlicensed versions of major-label catalogues have appeared on these platforms because nothing in the pipeline checked them against a rights database.

The fourth is legal design. By positioning itself as a protocol rather than a service, a platform can argue that it is not the party making the infringing reproduction — the user is. The Digital Millennium Copyright Act’s safe harbours and the EU’s intermediary liability regime reward platforms that do not actively monitor. Counterintuitively, building a verification layer can increase liability exposure, because a platform that performs verification is a platform that has knowledge, and knowledge is what triggers the obligation to act. The rational move for a platform optimising for legal risk is to check nothing.

The consequence of all four pressures is the same: first-to-mint wins. If verification is absent, the only thing standing between a fraudster and a permanent on-chain claim over someone else’s work is the fraudster’s willingness to sign a transaction. Whoever registers first holds the token, and the token is the only artefact the platform recognises. The legitimate rightsholder — who may never have heard of the platform, who may not have a wallet, who may be deceased with an estate that has not yet noticed — has no way to pre-empt the registration, and often no way to learn that it happened.

This is worse than the Web2 equivalent. A fraudulent Content ID claim on YouTube can be disputed, adjudicated, and reversed; the claimant can be penalised and their access to the system revoked. YouTube’s own system is full of exploitation — the case of the folk musician whose own recordings of public domain songs were claimed by a troll who simply filed first is a documented example — but the claim is at least contestable, and the platform retains the ability to correct it. On a public blockchain, there is no such correction. The fraudulent token is immutable. The fraudster’s wallet holds an asset that cannot be clawed back, and the legitimate rightsholder must now litigate against a cryptographic record that will outlast the court case.

The industry has a phrase for this: garbage in, immutable garbage out. A registry that verifies nothing is not a rights management system. It is a timestamping service with a token attached. Timestamping is genuinely useful for resolving priority disputes between two honest parties who both claim to have created something. It does nothing whatsoever against a dishonest party who registers something they never owned — and it actively arms them, by handing them an immutable, tradeable, platform-recognised claim that the legitimate owner must now overcome.

The US Copyright Office has moved in the opposite direction. Its 2024 report on copyright and artificial intelligence declined to endorse registration of purely machine-generated works, and the broader jurisprudential drift is toward demanding that a claim of authorship rest on something verifiable rather than something merely asserted. A blockchain token is an assertion. It is not evidence of authorship, and it is certainly not a substitute for the chain-of-title inquiry that a real rights management system requires.

This is the gap the Cryptographic Sieve is built to close — not by making the ledger more trustworthy, since a ledger cannot be trustworthy about facts it has never checked, but by moving the gate before the ledger. A registration that cannot verify authorship should not be permitted to mint. A fingerprint that matches an existing work should not produce a token. A claim over public domain material should not survive a challenge.

The next part describes how the contract does this, piece by piece.

Part Three: The Cryptographic Sieve, Piece by Piece

The contract is a single Solidity file implementing an ERC-1155 multi-token model, in which Root Masters and fractional Derivative Edit Licenses (DELs) are governed by one ledger. What follows is a walkthrough of each mechanism and the specific problem it addresses.

1. The Gradient Similarity Gate (`registerTrack`)

The entry point to the system is the registerTrack function, which accepts an acoustic fingerprint hash, a declared parent token ID, and a checked similarity score. The contract reads that score against a tiered matrix that is hardcoded into the bytecode and therefore cannot be manipulated after deployment.

The tiers are:

90–100% — Plagiarism Zone. The transaction reverts. No token is minted. This is the gate that the notary-receipt model lacks. A ripped master cannot be registered because the fingerprint has already been claimed by its legitimate owner, and the contract refuses the duplicate.
40–80% — Gradient Zone. Recognisable sampling or structural mimicry. The submission is accepted only if the uploader consents to a programmatic royalty split, interpolated linearly across the band from 5% at a 40% match to 30% at an 80% match. The consent is not a legal document; it is a boolean parameter in the transaction. If the uploader does not accept the split, the mint reverts. This is the “suggestive isolation” mechanism from the architectural blueprint, implemented as a hard economic constraint rather than a recommendation.
81–89% — Forensic Band. The submission mints, but it is clamped to the maximum royalty rate and flagged for validator review. This band exists because the difference between “recognisable sampling” and “substantial reproduction” is not a clean line, and the contract does not pretend it is. A validator can later adjudicate.
0–39% — Clean Derivative. A baseline royalty of 1%, recognising that even a clean derivative inherits something from its ancestor.

The critical design choice here is that the gate is not a verdict. It does not decide whether a work is infringing in the legal sense. It decides whether the uploader has accepted the economic consequence of the similarity score they have declared. A producer who samples a track at 60% similarity and accepts a 20% royalty split has not admitted infringement; they have entered a licensing arrangement. A producer who rejects the split is denied the mint, because the system will not facilitate a relationship that the rightsholder has not consented to.

This is a contractual solution to a copyright problem, not an enforcement solution. The distinction matters: enforcement is reactive and punitive, while the sieve is proactive and transactional. It does not need to prove infringement; it simply refuses to issue a licence without the rightsholder’s participation.

2. Signature Carry-Forward and the Playback Customs Agent

The second mechanism is the signature carry-forward. When a derivative is registered, the contract stores the parent token ID in the derivative’s metadata. This creates a lineage chain that is walked during revenue routing. The root creator’s signature — represented by the on-chain parent pointer — is carried forward immutably.

The playback side is handled by reportPlayback, a function callable only by registered playback agents (streaming APIs, Web3 players, connected DJ hardware). When a playback agent calls this function with a payment, the contract routes the revenue upward through the lineage chain. If the track has no valid signature — meaning it was never registered through the sieve — the playback agent has no token to reference, and the payout engine returns zero. This is the “Zero-Key, Zero-Play” protocol: no valid, ledger-verified signature means no payout, not because a moderator decided so, but because the arithmetic has no other branch.

3. Immutable Revenue Splitting

The revenue splitting mechanism is the most technically intricate part of the contract. Rather than storing a list of recipients and iterating over them (which would be gas-prohibitive and vulnerable to griefing), the contract uses an accumulator dividend model. Revenue for each token ID is distributed via a 1e18-scaled accPerShare variable. Each holder’s claimable balance is the product of their token balance and the delta in the accumulator since their last settlement.

The routing logic is as follows: when revenue arrives for a derivative, the contract takes the derivative’s declared royalty percentage and sends it upward to the parent. The remainder is distributed to the derivative’s current holders via the accumulator. The parent then repeats the process, taking its own royalty percentage and sending it further upward, until the root is reached. The loop is bounded by a MAX_LINEAGE_DEPTH constant, which prevents unbounded gas costs from deep remix chains.

The critical property is that payouts are pull-based, not push-based. The contract never makes an external call during routing. Revenue accumulates in the claimableOf mapping, and holders withdraw it themselves via a claim function. This eliminates reentrancy risk by construction and ensures that a single blocked recipient cannot halt the entire routing chain.

4. The Copyfraud Defund Switch (`penalizeCopyfraud`)

The final mechanism addresses the inversion that has plagued copyright enforcement for decades: entities falsely claiming ownership over public domain material. The case of the folk musician whose own recordings of public domain songs were claimed by a copyright troll through YouTube’s Content ID system is the canonical example — the fraudster exploited a gap in the audio content recognition database because the recordings had not been fingerprinted, and the system treated the first registration as authoritative.

The penalizeCopyfraud function is a validator-only switch that can lock an asset’s payout parameters to zero, freeze its transfers, and slash the uploader’s staked deposit. The fingerprint is then burned into an on-chain public-domain registry, so any future re-upload of the same acoustic content reverts at the registerTrack gate before a token can ever exist.

This is the structural inversion of the Content ID model. Content ID says: we will assume you own it until someone complains. The sieve says: we will not let you register it until the fingerprint is clear, and if you lied, we will make sure you can never try again. The validator quorum requirement means that a single malicious validator cannot defund a legitimate asset; a majority is needed. And the slashed stake is not burned — a portion is routed to the reporting archivist, creating an economic incentive for public-domain monitoring.

Developer Note: Copyright Compliance Before Testnet and Before Production

Before testnet, the first question is whether a Derivative Edit License is a copyright licence in the legal sense or merely a contractual access token. Under EU law, exclusive rights — reproduction, communication to the public, adaptation — can only be transferred or licensed by the rightsholder. The contract must be able to point to an actual chain of title, not just an on-chain mint. Confirm that your registration flow captures a written assignment or licence from each Root Master creator, with territorial scope and term stated. A token that says “licence granted” is not the same as a licence that is enforceable in a member state court.

Moral rights are the second constraint. In most EU jurisdictions — distinctly in France, Germany, and the Nordics — attribution and integrity rights are inalienable. A derivative minted by a sandbox must carry the root creator’s name forward in the metadata, or you are building a system that mechanically facilitates infringement of droits moraux, whatever the contract says.

The gradient gate itself must not be treated as a substitute for the legal test of substantial part. A 40% fingerprint match is not a legal finding. If you auto-approve at that threshold, you may be issuing licences for uses that a court would call infringing, which shifts liability onto the platform. Conversely, if you auto-reject at 90%, you may be rejecting legitimate fair quotation, parody, or pastiche — mandatory exceptions under Article 17(7) of the DSM Directive that cannot be contracted away. The gate needs a documented human or validator appeal path for the plagiarism floor, not just a revert.

The platform classification question is the most consequential for the playback side. If you are running anything that stores and gives the public access to user-uploaded content, you may be an online content-sharing service provider under Article 17 of the DSM Directive. Article 17(4) sets out three cumulative conditions for the liability defence: best efforts to obtain authorisation, best efforts to ensure unavailability of specific works for which rightsholders have provided relevant information including fingerprints, and expeditious action upon notice. Your “verified signature or zero payout” architecture is strong evidence of best efforts, but you also need a documented intake channel for rightsholder fingerprint submissions and a published policy on how quickly submitted fingerprints are added to the live gate. Document this as your Article 17(4)(b) evidence.

Article 14 of the DSM Directive, which covers faithful reproductions of public domain works of visual art, is limited to visual art. If you are using it as the legal basis for penalizeCopyfraud on audio works, you are stretching the provision beyond its literal scope. You need a separate legal theory for audio public-domain claims, which in most member states means showing that the copyright term has expired under applicable national law. And the term is not uniform: the Steamboat Willie example is instructive — the film entered the US public domain in 2024 but remains protected in Germany until 2058 because of an 1892 bilateral treaty. A single boolean publicDomainFingerprint cannot represent this. Your archive registry needs per-jurisdiction provenance metadata, and penalizeCopyfraud should only be callable when the validator has attested to that metadata off-chain.

If your sandbox will be used with generative AI tools — stem separation, melodic suggestion, mastering assistance — you need to know that EU copyright law does not in principle protect content autonomously generated by AI. The CJEU’s standing test, from Infopaq and Painer, requires a work to be an “author’s own intellectual creation” that reflects the author’s personality. A derivative registered by someone who simply prompted a model and accepted the output may not qualify as a protected work at all, which means your gate could mint a DEL for something that has no underlying copyright to license. Decide whether your registration flow requires the uploader to warrant substantial human creative input, and whether that warranty is an on-chain attestation or a term of service.

Finally, the text and data mining question. If your fingerprint nodes are scraping audio from streaming platforms or IPFS to build the similarity database, you may be relying on the Article 4 TDM exception, which applies only where the work was lawfully accessed and the rightholder has not reserved their rights in a machine-readable manner. Your developer needs to answer three questions before testnet: what is the lawful access basis for every source the nodes crawl, does the crawler respect machine-readable reservations with an audit log, and can the system exclude a work from the similarity corpus if a rightholder later opts out. A contract that penalises copyfraud while its own oracle commits TDM without checking the reservation is not a credible enforcement layer.

Conclusion: The Sieve as Infrastructure

The music industry’s problem has never been a lack of copyright law. It has been a lack of architecture. The law says a reproduction is infringing; the architecture says a reproduction is a file that can be copied infinitely with no friction. Every subsequent attempt to bridge that gap — DRM, Content ID, streaming licences, blockchain notaries — has placed the gate at the wrong layer.

The blockchain generation of platforms made the same mistake in a new register. They built registration without verification, minted tokens without checking whether the underlying work already belonged to someone, and in doing so converted a timestamping service into a machine for producing immutable fraudulent claims. The absence of a public-database check was not an oversight. It was the logical consequence of a business model that measured success in works registered, and a legal strategy that rewarded not knowing.

The Cryptographic Sieve places the gate at the layer where the copy actually happens: the container. A master file that cannot be unboxed outside a verified sandbox is a file that carries its own permission structure. A derivative that carries its parent’s signature forward is a derivative whose revenue can be routed automatically. A fingerprint that is checked before registration is a fingerprint that cannot be forged.

This is not a political programme. It is infrastructure. And infrastructure, unlike ideology, does not require anyone to be persuaded before it starts working.

Find the repo HERE.