Music CIP Ideation

Developers CIPs
, ,
1

Been fiddling with ideas for CIPs to solve a handful of the challenges with bringing the music industry closer to Cardano and resolving some of the biggest problems with the current set up.

Here are two to explore and take a look at.

Mandatory Royalty Withholding CIP for Statutory Compliance in the Music Industry

Verified Usage Proofs for the Music Industry applications of Hydra Head Solutions

2 Likes
2

@shaggyrax I think anyone who knows this industry and/or has worked on CIP-0060 implementations would agree there has already been a need for systems like this. I understand some details of the implementation would likely depend on project funding, though in the meantime you’d be welcome to plan CIP submissions around both these ideas. These considerations will help fill out the writing & prepare for initial review:

• Especially since Amazon Kindle & smaller-scaled PoD & other delivery-on-demand platforms use this same withholding & W-8BEN regime for royalty distribution, would I be wrong to feel bad if such an innovation were confined to “music assets on Cardano” and not extended to other media like books? Otherwise (i.e. if there’s no practical constraint) could these CIPs be generalised to all asset types with potentially withheld royalties and proofs of purchase?

• Both systems appear to have a strong dependence on CIP-0113 but this isn’t elaborated enough for general readers to understand how the “Freeze & Seize” capabilities would be applied to the escrow account. Is the implication that effectively those funds are (as per your example in the Motivation) the USA Government’s property and can be frozen or seized from that point onward?

  • Maybe the answers to such questions would already be known by anyone working directly in the industry: but especially if you plan to apply for CAP funding, these details & potential vulnerabilities of the proposed system should also be understandable by non-insiders: including CIP editors and key developers of the CIP-0113 framework.
  • If only for illustrative purposes I think people would be curious whether “freeze & seize” for a “global” account would allow the whole payment framework to be shut down — if not cleaned out — over a relatively small number of targeted royalty recipients.

• The CIP-0113 connection also suggests you might commit early to ensure proper co-development with the work-in-progress WSC PoC itself, whose developers have asked project leaders to implement according to guidelines here & work with other teams to ensure that the resulting minted tokens and logic will be mutually interoperable:

… so perhaps you could post an issue on that project in advance and enquire what might need to be done to suggest that your system can or could be considered CIP-0113 compliant when that in fact becomes a CIP (it is not yet… only a candidate at this point). If a GitHub issue is too much overhead at this early stage, we’ve also created a CIP-0113 dev channel on the CIP Discord.

This item in your draft(s) also suggests a time dependency, as well as care to be taken in proposal language, especially when using the terms “CIP” or “standard”:

Accelerator Pilot: Use this CIP as the basis for your Spring 2026 Accelerator demo.

Given that the CIP-0113/-0143 candidate itself is still in an open-ended period before becoming a CIP, and that your framework appears to depend on a CIP-0113 implementation, you likely won’t have a CIP yourself for either “Royalty Withholding” or “Verified Usage” by then… only CIP candidates still under review.

  • Both authors and community must remember that a document posted as a Pull Request in the CIPs repository is not a CIP until it’s merged… and any full disclosure for fundraising or other competition should indicate this: otherwise assessors or voters might be misled.

In the meantime I understand you currently just want to get these ideas out into the community and I am very happy to see this :nerd_face: (cc CIP co-editors @ryun1 @Thomas_Vellekoop) and so also understand it’s still in an originally ideated form. However I think conforming to the CIP-0001 specification sooner rather than later would help get a better quality of review: especially from key CIP-0113 developer & prolific CIP reviewer @colll78 and any others who might provide an advance review.

Whenever you do try to standardise these documents, here are some items to fix:

  • numbers before section titles are deprecated because they present challenges to document longevity and interoperability (e.g. parsing & especially cross-linking).
  • please rename or merge non-standard names for sections (generally by renaming into sub-sections of the canonically titled sections).
  • Path to Active should be broken down more precisely with “implementation” vs. “active” criteria (2 separate lists) and should include where a reference implementation would be coming from.
  • CIP tags are CIP- followed by 4 digits, and CIP names are CIP followed by a cardinal number. So you can properly say CIP-0113 or “CIP 113” but CIP-113 is an error. Yes I know the cool-kid developers don’t care about this, nor comply with it, but editors generally have to correct this in the review process anyway which causes delays. If we allowed the “errors” in merged documents we’d have more search engine fragmentation and added complexity in manual text searches: which nobody wants either. :sweat_smile:
4 Likes