feat(oracle): MuzixStreamingOracle — on-chain consumer surface (spec Phase 1)#36
Merged
Conversation
…s spec Phase 1) Implements the Phase-1 MVP described in oracle/SPECIFICATION.md: the on-chain consumer-facing contract that authorized pushers submit verified streaming-revenue records to, and that downstream MUSD royalty distributors read from. Scope (matches IStreamingRevenueOracle in the spec): - Per-DSP registry with per-DSP min-confidence override (default 7500 bps). - Authorized pusher set + per-pusher 1h cooldown (spec §2 "Rate limiting"). - Period sanity: periodStart < periodEnd, periodEnd <= block.timestamp. - Append-only history with per-(catalog, dsp) latest pointers for cheap on-chain reads, plus a getRevenueForPeriod view for off-chain RPC consumers. - isDataFresh / freshnessWindow (default 24h, admin-configurable). - Pausable circuit breaker (spec §3 "Fail-Safes"). - subscribeToUpdates emits an event so off-chain indexers can pre-filter their watch list without paying for storage. Out of scope (tracked for later phases): on-chain consensus, node staking/slashing, dispute window, Chainlink fallback, cross-chain. 35 new Foundry tests cover the registry, pusher auth, confidence floor (default + per-DSP override), period invariants, cooldown across single + batch submissions, freshness, period-sum aggregation, pause/unpause, and out-of-bounds history access. Full suite: 50/50 passing.
4 tasks
6 tasks
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
Implements the Phase-1 MVP described in
oracle/SPECIFICATION.md: the on-chain consumer-facing contract that authorized pushers submit verified streaming-revenue records to, and that downstream MUSD royalty distributors read from. The spec has been merged for ~6 weeks (#15); this PR ships the contract that turns it into something callable.src/MuzixStreamingOracle.sol— Ownable + Pausable, custom errors, matchesMuzixAIProvenancestyle.test/MuzixStreamingOracle.t.sol— 35 new Foundry tests.oracle/README.md— status table + integration snippet now that the contract exists.Scope (matches
IStreamingRevenueOraclefrom the spec)minConfidenceScoreoverride (default7500bps).periodStart < periodEnd,periodEnd <= block.timestamp.getLatestRevenue(catalogId)semantics.getRevenueForPeriodview for off-chain RPC consumers (unbounded — documented; on-chain consumers should use the per-DSP latest pointer or index events).isDataFreshwith admin-configurablefreshnessWindow(default 24h per spec).subscribeToUpdatesemits an event so off-chain indexers can pre-filter their watch list without paying for storage.Out of scope (tracked for later phases of the spec)
The deployed contract trusts the off-chain node network for consensus and enforces only the focused on-chain invariants above. The node-network reference implementation is the next ship.
Test plan
forge buildclean (only expectedblock.timestamplints in oracle freshness/period checks)forge test— 50 / 50 passing (35 new + 15 existing across MUSD / MuzixCatalog / MuzixAIProvenance)