muzix
Infrastructure for music finance — catalog tokenization, atomic royalty settlement, streaming oracle, AI provenance. Speaks ISRC, UPC, ISWC; settles in MUSD.
MuzixAIProvenance, MuzixStreamingOracle (#36), and MuzixRightsOffering (#37) are merged. Labelton rights-tokenization is in draft (2026-05-25). MUSD stablecoin contracts are deployed to testnet. See the repo for current state.
What Muzix Is
Muzix is the infrastructure layer for music finance. It connects musicians, labels, distributors, streaming platforms, fans, and — increasingly — AI buyers, through a shared on-chain settlement layer.
It is not a music app, a marketplace, or a fan-token platform. It is the layer that music apps, labels, distributors, AI platforms, and financial products plug into. Identifiers are DDEX. Settlement is MUSD. Rights are first-class on-chain primitives.
The Problem
- Artists wait 6–18 months for royalty payments to clear through 5+ intermediaries.
- Cross-border payments lose 3–8% to FX and banking fees — devastating in emerging markets.
- Catalog valuation is opaque. No liquid market, no price discovery; selling outright is often the only option.
- Rights data is fragmented. ISRCs, UPCs, ISWCs and ownership shares live in incompatible silos across labels, publishers, PROs, DSPs.
- AI usage is invisible. Catalogs are being trained on without a clean rights, attribution, or payment trail.
- Sub-cent payments never arrive. Micro-royalties die in payment-rail overhead.
Four Pillars
Catalog & rights as on-chain primitives
Masters and variants as ERC-1155, basis-point shares as token balances, ISRC/UPC/ISWC stored as first-class identifiers with reverse-lookups.
Atomic, programmable royalty payouts
Revenue lands, splits execute in one transaction across every cap-table holder — denominated in MUSD, settled cross-border at the same cost in Lagos and Los Angeles.
Capital against verified future revenue
Royalty advances, catalog-backed lending, revenue swaps, and music-index strategies — collateral is the on-chain cap-table plus oracle-verified streaming feeds.
Provenance for the AI era
Opt-in AI-usage flags, model-lineage records, and DDEX-MEAD-aligned permissions bound to the catalog token — so AI buyers see consent and rightsholders see attribution.
Use Cases
Different actors get different value out of the same protocol surface. The contracts they touch differ; the settlement asset (MUSD) and identifier system (DDEX) do not.
Publish terms, get paid weekly, keep the cap-table
- Mint master + variants directly from your wallet — no admin gate.
- Publish a term sheet via
MuzixRightsOffering; bidders counter, you accept. - DSP revenue flows through
MuzixStreamingOracleand splits atomically in MUSD. - Decide AI training permissions at the token level — opt in, opt out, or license per buyer.
Move from quarterly waterfalls to settlement-on-arrival
- Anchor existing ISRC / UPC / ISWC catalog into
Labeltonwithout re-licensing — registration commits cap-tables on-chain. - Ingest DSR-shaped reports into
MuzixStreamingOracle; route per-territory revenue in MUSD. - Treasury sees the same audit trail every counterparty sees; disputes drop because the cap-table is the contract.
Underwrite verifiable streams, not paper estimates
- Collateral is the on-chain cap-table; expected revenue is oracle-attested DSP throughput.
- Royalty advances and catalog-backed lending settle in MUSD; recoupment is enforced by the split.
- Fractional offerings sit behind Reg-D / Reg-CF wrappers issued through
MuzixRightsOffering.
Train and query with consent, attribution, and payment baked in
- Query Muzix-indexed catalog via IPTO; every result carries an AI-usage permission and provenance hash from
MuzixAIProvenance. - DDEX-MEAD AI flags map directly to on-chain permission state — opt-out is honored at the protocol layer.
- Pay once at runtime in MUSD; rightsholders are fanned the same atomic split used for streaming royalties.
See it animated
Two interactive labs walk the protocol surface at different zoom levels. Both are single-file canvas labs — open and play, no wallet, no build.
Mixdown — the closed loop, end to end
Sapta records, mints into Labelton, posts a term sheet via MuzixRightsOffering, picks a bidder, oracle ingests DSP revenue, MUSD pays the cap-table atomically — then a remix variant, an AI-training license, a sync drop, and a catalogue-wide bundle layer in. All four personas appear on the same timeline.
Labelton — rights-primitive zoom-in
Sibling to Mixdown, focused on the rights anchor. Master registration, ISRC uniqueness, cap-table arithmetic, variant minting (remix, sync edit, stem), governance-toggled variant kinds, and dispute-proof identifier collisions.
Controls: space play/pause · n step · r restart · ← / → jump scenes. Scene scripts live in SCENES.md and LABELTON-SCENES.md next to the labs.
Contracts (current surface)
| Contract | What it does | Status |
|---|---|---|
| Labeltonsrc/Labelton.sol | ERC-1155 master + variant registry. ISRC / UPC / ISWC as first-class on-chain identifiers. Cap-table = token balance, immutable post-registration. | draft · 2026-05-25 |
| MuzixRightsOfferingsrc/MuzixRightsOffering.sol · #37 | Pre-mint term-sheet registry. Artist publishes draft economics; bidders accept-base or counter; one is accepted. Sapta album pilot is the first live offering. | merged |
| MuzixStreamingOraclesrc/MuzixStreamingOracle.sol · #36 | Verified streaming-revenue feed per (catalogId, DSP, period). Confidence floor, freshness, pausable circuit breaker. DSR-shaped ingestion. |
merged |
| MuzixAIProvenancesrc/MuzixAIProvenance.sol | Opt-in registry binding a catalog token to either a human-only attestation or a set of erc721-ai model references + IP-lineage URIs. Owner-gated writes. | merged |
| MUSDsrc/MUSD.sol | Fiat-backed music stablecoin, built with stablecoin-toolkit. Per-DSP-payout atomic splits via _distribute; pull-payment, batch-payout, ERC-20-Permit. |
testnet |
| MuzixCatalogsrc/MuzixCatalog.sol | v0 ERC-721 catalog NFT. Being superseded by Labelton as the rights anchor; future path is artwork / release-art only. |
retiring |
DDEX 2026 Mapping
DDEX is the music industry's settled metadata + reporting standard family — it is how labels, distributors, publishers, PROs, and DSPs already exchange data. Muzix does not replace DDEX. It anchors DDEX records on-chain and makes them programmable. Every Muzix surface maps to a DDEX message family.
Subway map · DDEX message suites routed through Muzix contracts
Double-ring stations are Muzix contracts (transfer hubs). Single-ring stations are DDEX-native industry actors. The DDEX subway-map idiom — one line per message suite, transfer stations where flows converge — is reused here so the table below has a visual anchor. Inspired by DDEX's own industry data-flow map.
| DDEX standard | What it carries | Muzix surface | How we anchor it |
|---|---|---|---|
| ERNv4.3 / 4.4 · JSON + XML | Electronic Release Notification — labels → DSPs / distributors. Releases, tracks, territory, deal terms, pricing pointers. | Labelton.registerMaster + mintVariant |
UPC and per-track ISRC anchored on-chain as unique strings; off-chain ERN payload bound by mirHash at registration. |
| DSRv4.x · flat-file + JSON | Digital Sales Reporting — DSPs → labels / publishers. Per-territory streams, downloads, gross-to-net, currency, period. | MuzixStreamingOracle |
Per (catalogId, DSP, period) push with confidence floor and freshness; on-chain becomes the canonical revenue feed for atomic splits. |
| MEADv2.x · AI flags 2024+ | Media Enrichment And Description — moods, BPM, instrumentation, genre, plus AI-training permission and AI-exclusion flags. | MuzixAIProvenance + AI usage flags |
MEAD AiTrainingPermission / AiTrainingExclusion map directly to on-chain permission state on the catalog token; opt-out is enforced before any IPTO query returns the asset. |
| RIN-M / RIN-Sv1.x | Recording Information Notification — studios / producers. Session lineage, performer credits, mixing/mastering attribution. | Labelton.mirHash + MuzixAIProvenance humanLineage |
Off-chain RIN document hashed; bound to the master at registration. AI-provenance contract carries the human-vs-AI split for the same recording. |
| MWNv1.x | Musical Work Notification — publishers → societies. Composition shares, songwriter splits, controlled-vs-non-controlled. | Labelton.iswc + composition cap-table |
ISWC stored as unique on-chain identifier; composition splits expressed as a separate Labelton master with its own cap-table when separation from the recording-side cap-table is required. |
| MWLIdraft 2025+ | Musical Work Licensing Information — sync, micro-sync, and AI-training license terms. | MuzixRightsOffering |
License terms posted as economics on the offering; bidders accept-base or counter; accepted counter is the on-chain commitment reference for downstream license issuance. |
| CWR bridgeDDEX-CWR Bridge 2.0 · 2024 | Bridge from DDEX MWN to CISAC's CWR — composition data exchange between publishers and PROs / societies. | Labelton.iswc + off-chain CWR payload |
ISWC is the join key; CWR file hashed and bound off-chain to the composition-side Labelton master so PROs reconcile against the same record on-chain. |
| PIEv1.x | Pricing Information Exchange — wholesale pricing, deal pricing, per-territory price tiers. | MuzixRightsOffering economics |
Upfront, minimum guarantee, royalty bps, and term sit on the offering economics; PIE per-territory rates can be referenced off-chain via the same offering id. |
| AVS2024+ controlled vocabularies | Allowed Value Sets — controlled vocabularies for variant kinds, genres, AI usage categories, party roles. | Labelton.VariantKind + governance config |
Master / Single / Album / Remix / Stem / SyncEdit / Cover / Instrumental / Live / Other map to AVS variant types; DAO config toggles which kinds are mintable. |
| DPIDv2 attestation | DDEX Party Identifier — labels, distributors, publishers, societies as canonical party IDs. | capTable addresses + identity registry |
Cap-table addresses are the canonical on-chain parties; DPID ↔ address binding lives in a sibling identity registry (DID-based) so off-chain DDEX messages reconcile to on-chain payees. |
| Choreography2024+ workflow defs | Standardised message-exchange workflows between DDEX parties (delivery, ack, takedown, dispute). | Cross-contract flows | Registration → offering → acceptance → revenue ingest → split is the on-chain analogue of a DDEX choreography; off-chain ack messages bind by master id. |
Companion identifier work: ISCC (International Standard Content Code, ISO 24138, 2024) — content-derived fingerprint. ISCC complements ISRC by hashing the actual audio; Labelton's mirHash is the slot for an ISCC binding when the rights holder wants content-anchored as well as identifier-anchored attribution.
Agentic AI usage of music routes through IPTO — Muzix is the data-provider layer
Streaming distribution (Spotify, Apple Music, etc.) remains a separate channel — Muzix-anchored catalog can flow there unchanged. Agentic AI access and training route through IPTO, which carries license, attribution, and runtime payment for every query. Muzix is one of the data-provider layers into IPTO: it indexes and makes catalog usable on behalf of label / artist / producer / IP-owner collaborators, with MEAD-aligned AI permissions enforced at the protocol layer and rightsholders fanned in MUSD. Integration is on the roadmap; the on-chain surface is already shaped to receive it.
Technical Architecture
| Layer | Component | Tech |
|---|---|---|
| Identifiers | ISRC · UPC · ISWC · DPID · ISCC | On-chain strings + hashes; off-chain DDEX payloads bound by content hash |
| Rights | Labelton — masters & variants | ERC-1155, basis-point shares = balance, cap-table immutable post-registration |
| Offerings | MuzixRightsOffering | Term-sheet registry, accept-base / counter / accept flow |
| Revenue | MuzixStreamingOracle | DSR-shaped feed per (catalogId, DSP, period); confidence + freshness gates |
| Provenance | MuzixAIProvenance | Human-only attestation or model-token + lineage URIs; MEAD-aligned |
| Stablecoin | MUSD | Fiat-backed, built on stablecoin-toolkit; atomic splits |
| Chain | EVM L2 | OP Stack settlement to Ethereum; deployment topology still being finalised — see repo |
| AI surface | IPTO integration | Catalog flows through IPTO for agentic AI access; MEAD permissions enforced before query returns |
Roadmap
Phase 1 — Foundation · MUSD contracts on testnet · basic royalty split · MuzixAIProvenance merged · MuzixCatalog v0.
Phase 2 — Rights tokenization · Labelton ERC-1155 master/variant registry with DDEX identifiers · MuzixRightsOffering term-sheet flow · Sapta album pilot.
Phase 3 — Revenue + finance · MuzixStreamingOracle live with DSR ingestion · royalty advances against verified streams · catalog-backed lending.
Phase 4 — DDEX + AI rail · ERN / DSR / MEAD reconciliation tooling · MEAD AI-permission enforcement · IPTO integration for agentic AI queries · DPID ↔ address registry · first label integration.
Repository Structure
muzix/
├── src/ # Solidity — Labelton, MUSD, RightsOffering, StreamingOracle, AIProvenance, Catalog
├── test/ # Foundry tests
├── script/ # Deploy + pilot scripts (Sapta)
├── node/ # Chain node configuration
├── oracle/ # Streaming revenue data feeds
├── docs/ # Architecture, specs, DDEX mappings
└── deploy/ # Deployment configs