feat(rights): Labelton.sol — rights registry + multi-variant ERC-1155 minter (#39)#48
Merged
Merged
Conversation
… minter Introduce LABELTON, the rights-tokenization product of the Muzix protocol. A `Master` is the canonical rights record for a piece of music — it anchors industry identifiers (ISRC, UPC, ISWC), commits to off-chain MIR / legal / financial-ID payloads by content-hash, and pins an immutable cap-table. A `Variant` is an ERC-1155 token class derived from a master (Master, Single, Album, Remix, Stem, SyncEdit, Cover, Instrumental, Live, Other). Every variant mints 10000 units fanned across the master's cap-table proportionally to each holder's basis-point share. ERC-1155 balance IS the share — no parallel cap-table mapping needed. Issuance is wallet-sovereign: the artist or any cap-table member calls `registerMaster` / `mintVariant` directly. The protocol owner (Muzix DAO) does not gate issuance — it only configures which variant kinds are mintable, the verifier addresses, and the pause switch. The root mint of a master always lands at the same set of wallet holders defined by the cap-table; variants of that master inherit the cap-table by construction. Off-chain payloads (MIR fingerprint, legal-entity dossier, financial-routing record) are referenced by content-hash; the on-chain record commits to those hashes at master registration and is immutable thereafter. Replacing a hash means registering a new master. Integration with the existing muzix contracts (MUSD, MuzixCatalog, MuzixRightsOffering #37, MuzixStreamingOracle #36, MuzixAIProvenance) is documented in docs/labelton-architecture.md and tracked as follow-up issues. This commit ships: - src/Labelton.sol (401 LoC) — the contract - docs/labelton-architecture.md — integration story + open design questions Out of scope here (tracked as follow-up issues): - MUSD distribution wired against Labelton.capTableOf - MuzixCatalog cleanup now that LABELTON owns cap-tables - MuzixRightsOffering -> Labelton handoff after counter accept - Oracle consumer rewire - AIProvenance ERC-1155 owner-check path - Foundry test suite for Labelton.sol - Verifier signature enforcement forge build: clean (13_098 bytes deployed) forge test: 15/15 existing tests pass — no regressions Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
Welcome to kcolbchain, @Pattermesh — glad you're here. 🌱 Here's what happens from this PR:
While you wait:
What happens after your first merge
Thanks for writing the code. We're building this to last. |
This was referenced May 24, 2026
docs: LABELTON — the rights primitive music has been missing on-chain (joint thought-leadership)
#49
Merged
abhicris
pushed a commit
to kcolbchain/research
that referenced
this pull request
May 24, 2026
Position brief cross-posted from kcolbchain/muzix#49. Argues that prior Web3 music product waves (Royal, Audius, Opulous, Sound, Catalog) shipped on top of an implicit rights model — never the rights primitive itself. The missing primitive is a music token whose root mint at master generation lands at a fixed cap-table defined in the same transaction, with industry legal identifiers (ISRC / UPC / ISWC / IPI) anchored on-chain and off-chain dossiers hash-bound. LABELTON is the contract that implements this primitive (kcolbchain/muzix#48). This brief documents: - The gap prior waves left unfilled - The music industry's existing legal identifier system as the primary-key layer on-chain has mostly ignored - The LABELTON primitive (cap-table IS the rights structure) - Two architectural innovations worth claiming: ERC-1155 supply == basis-point share, and standalone owner-gated registry pattern - The Muzix DAO / LABELTON product / CR8 chain stratification - Five open design questions Co-authored: @abhicris + @Pattermesh. Co-authored-by: Pattermesh <173408993+Pattermesh@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
abhicris
pushed a commit
that referenced
this pull request
May 24, 2026
…#49) Co-authored joint thought-leadership piece (Abhi + Patty) framing the LABELTON model: - The gap prior Web3 music waves (Royal, Audius, Opulous, Sound, Catalog) left unfilled — products on top of an implicit rights model that was always either off-chain or weakly bound. - The legal-system primary keys the music industry already runs on (ISRC, UPC, ISWC, IPI / IPN) and why on-chain music has mostly ignored them. - The LABELTON primitive: the cap-table IS the rights structure, set at master generation, by the artist's wallet, with legal identifiers attached and off-chain dossiers hash-bound. - Two architectural innovations worth claiming: ERC-1155 supply equals basis-point share (no parallel cap-table mapping needed), and a standalone owner-gated registry pattern (LABELTON does not extend MuzixCatalog; provenance contracts attach by reference). - The Muzix DAO / LABELTON product / CR8 chain stratification, with the explicit "DAO sits above, not inside" anti-pattern claim. - The two-architect origin story (Abhi infra-first, Patty rights-first, converged 2026-05-25). - Five open design questions in public, mapped to the design-discussion issues on the repo. - The "what LABELTON is not" positioning: not a DSP, not a fractional royalty marketplace, not catalog-backed DeFi — the protocol underneath all of those. References the Labelton.sol PR (#48), the RFC (#38), and the design issues (#45, #46, #47). Co-authored-by: Pattermesh <173408993+Pattermesh@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
🤖 Audit verdict: Code is well-designed with proper input validation, access control, and reentrancy guards; no malicious payloads, supply-chain risks, credential leakage, or functional bugs detected. Audited by the kcolbchain PR pipeline. See pipeline docs. |
abhicris
approved these changes
May 25, 2026
Contributor
abhicris
left a comment
abhicris
left a comment
There was a problem hiding this comment.
Approved. Code is solid — wallet-sovereign mint per the cap-table-immutability invariant, bounded cap-table (≤64), correct OZ ERC-1155 + Ownable + ReentrancyGuard usage, ISRC/UPC/ISWC uniqueness with reverse lookups, custom errors matching repo style.
Two follow-ups I'll file post-merge so we don't lose them:
Tests — The PR body marks forge test for test/Labelton.t.sol as a follow-up commit on this branch, but that commit never landed; merging this lands the first muzix contract without a same-PR test suite (MUSD / Catalog / Provenance / #36 / #37 all shipped with tests). New issue: bring test/Labelton.t.sol to parity — happy path + every revert + ERC-1155 balance ↔ shareBps invariant + reverse-lookup integrity + DAO-config endpoints.
Architecture-doc alignment — docs/labelton-architecture.md says "CR8 chain (own L1 OR LUX subnet — open)". That's been decided since (2026-05-24): MUSD + CR8-USD live on Arbitrum via Create Protocol's stablecoin-toolkit, payments route through Switchboard (x402 / AgentEscrow / ZAP), Lux primitives integrate. Doc needs a short update.
Minor nit (not blocking): capTableOfVariant reverts with MasterDoesNotExist(v.masterId) when the variant is the missing thing. Readable but inconsistent — could be a VariantDoesNotExist error.
Merging as-is per the "merge 1 by one" steer.
This was referenced May 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduces LABELTON, the rights-tokenization product of the Muzix protocol. Wires the contract + the architecture doc; tests come in a follow-up commit on this branch.
This PR closes #39 and ships the first concrete deliverable under the LABELTON RFC at #38.
What this ships
src/Labelton.sol(401 LoC) —Masterregistration +VariantERC-1155 minting.Ownable): variant-kind toggles, verifier addresses, pause switch.docs/labelton-architecture.md— integration story, design principles, open design questions, file layout.Out of scope (tracked separately under #38)
Labelton.capTableOf— feat(integration): MUSD distribution against Labelton cap-table #40Design decisions baked in (each documented + tracked)
registerMaster/mintVariantdirectly. No admin gate.VariantKind.Masterenabled by default. Other kinds require explicit DAO opt-in.MasterParamsstruct calldata wrapper. Necessary to avoid stack-too-deep on the event emit; documented inline.Test plan
forge build --sizesclean (Labelton: 13,098 bytes deployed — well under EIP-170 24KB limit)forge test— 15/15 existing tests still pass (no regressions in MUSD / MuzixCatalog / MuzixAIProvenance)forge test— newtest/Labelton.t.solsuite (follow-up commit on this branch; held for design-read first)forge fmt --checkNotes for reviewers (@abhicris)
MuzixAIProvenancearchitectural pattern (separate, owner-gated, hash-bound) rather than extendingMuzixCatalog.MuzixCatalog's royalty surface becomes redundant once this lands — see refactor(catalog): retire royalty splits from MuzixCatalog now that Labelton owns them #41 for the cleanup.(offeringId, acceptedCounterId)is the canonical on-chain commitment reference"), LABELTON closes exactly that loop. feat(rights): MuzixRightsOffering → Labelton handoff after counter accept #42 wires the handoff.cc @Pattermesh