feat(rights): MuzixRightsOffering — on-chain term-sheet registry + Sapta pilot#37
Merged
Conversation
…pta pilot
Artist publishes a draft offering of distribution / sync / master /
publishing rights (single asset or whole catalogue) with base economics.
Labels, IP buyers, distributors, and sync agencies submit counters: either
accept the base outright via acceptBaseTerms, or propose modified
Economics with an off-chain memo. Counters can post a refundable MUSD
bond as earnest. Artist picks one counter to accept; offering flips to
Accepted and acceptedCounterId is the canonical on-chain commitment
reference. Losing counters remain Pending until each bidder calls
withdrawCounter to recover their bond.
Contract is settlement-token-agnostic (IERC20 + SafeERC20), so it deploys
unchanged against MUSD on whichever L1 holds the token — create-protocol
L1 in production or muzix L1 for early testnet runs.
Sapta pilot ships two drafts via script/DeploySaptaPilot.s.sol:
- Album: 3-yr exclusive distribution, $25K upfront / $50K MG / 6500 bps
to artist, worldwide, 30-day reply window.
- Catalogue: 5-yr exclusive full rights, $150K upfront / $400K MG /
7000 bps to artist, worldwide, 45-day reply window.
Numbers are placeholders for the pilot bootstrap — tune in the script or
update the draft via updateDraft before publishing. docs/sapta-pilot.md
walks bidders through how to participate (acceptBaseTerms vs
submitCounter), how acceptance works, and how the off-chain subject
manifest hooks into the on-chain subjectHash + subjectURI fields.
Out of scope (downstream contracts wire these against an accepted
offering's terms): upfront / MG settlement, royalty execution against
MuzixStreamingOracle data, KYC gating, rights NFT issuance.
31 new Foundry tests cover authoring lifecycle (create/update/publish/
withdraw/expire), counter intake (custom terms + acceptBaseTerms +
zero-bond + below-minimum-bond), acceptance/rejection flows with
bond accounting, and access control (NotArtist / NotBidder paths).
Full suite: 46/46 passing.
New `/contracts` route in the explorer UI: pick a template, edit parties / splits / terms in a visual editor, watch a plain-English draft assemble live, then deploy the encoded calls from a wallet. Templates (all map to existing primitives — no new Solidity required): - Recording royalty split → MuzixCatalog.mintMusic + setRoyaltySplit - Featured-artist add → MuzixCatalog.setRoyaltySplit (re-split) - AI training license → MuzixAIProvenance.setProvenance - Sync license (film/TV) → mint+split with off-chain JSON terms Pieces: - lib/contract-templates.ts — typed schema + 4 templates with validate() / draft() / onchain() functions per template. - lib/contracts.ts — minimal ABI fragments + env-driven addresses (NEXT_PUBLIC_MUZIX_CATALOG, NEXT_PUBLIC_MUZIX_AI_PROVENANCE, NEXT_PUBLIC_MUZIX_CHAIN_ID). - components/ContractBuilder.tsx — parties editor with live bps gauge + auto-balance, term fields, side-by-side prose draft, on-chain plan preview. - components/DeployPanel.tsx — viem v2 wallet flow (custom transport via window.ethereum), late-binds the minted tokenId from the Transfer event so step 2 (setRoyaltySplit) can use it, computes provenanceHash via the on-chain pure helper's binding, gracefully degrades to "copy calldata" when contracts aren't configured or no wallet is present. - /contracts gallery + builder route, nav link, homepage CTA.
The static prerender of /contracts/[slug] renders the encoded-calldata preview, which calls resolveCall before any tokenId exists. Throwing broke the build. Preview path now substitutes 0n for the placeholder tokenId; the live deploy loop still throws if it ever hits the same state at runtime.
abhicris
pushed a commit
that referenced
this pull request
May 25, 2026
… minter (#48) 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: Pattermesh <173408993+Pattermesh@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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
Ship the on-chain "term sheet" registry that lets an artist publish a draft offering of distribution / sync / master-licensing / publishing rights (single album or whole catalogue), and lets labels / IP buyers / distributors / sync agencies submit counters — either accept the base outright or propose modified economics. The artist picks one counter to accept; the on-chain record is the commitment, and downstream settlement contracts execute payment + rights transfer against it.
The contract is settlement-token-agnostic (`IERC20`), so it deploys unchanged against MUSD on whichever L1 holds the token — create-protocol L1 in production (where MUSD lives for agentic operations + Switchboard payments) or muzix L1 for early testnet runs.
Sapta pilot drafts
Numbers are placeholders for the pilot bootstrap; tune in the script or update via `updateDraft` before publishing.
What's on-chain
Out of scope (downstream contracts wire these against an accepted offering's terms)
Test plan