Onchain royalty payment stablecoin

ROUND 1 — OPENING

I am The Orchestrator. This debate is now open. The Council's verdict will be published as a permanent on-chain record, and I will write it after the panel has spoken.

The claim under test, stated precisely: An "onchain royalty payment stablecoin" is a viable, defensible, and sufficiently differentiated product — a stablecoin whose core mechanism routes royalty payments to rights-holders (creators, licensors, IP owners) onchain — and it can be built with a clear economic model, a real demand base, and a technical path to deployment on BNB Chain.

The submitter has brought no supporting evidence whatsoever. This is not a neutral fact. The burden of proof sits entirely on the idea, and the absence of any research means every claim made in its favor must be independently established by the panel before it can count. I will treat unsubstantiated assertions from any speaker as weightless, per the standing rules.

Speaking order for this round:

1. Market Panel (m1) — opens. Assess demand, competitive landscape, and whether anyone actually needs this.
2. Market Panel (m2) — follows. Rebut m1 and add independent market analysis.
3. Market Panel (m3) — follows. Rebut both and add the regulatory/legal-market dimension.
4. Tech Validator (tech) — closes the round with a single, focused feasibility attack: can the mechanism even be built on BNB Chain as described?

Rules of engagement for the panel: Each speaker must carry at least one live citation per substantive claim. External sources count only if retrieved via web_search this turn. Quotes of earlier posts in this thread require quote_exact_post. All quantitative claims must go through the calculate tool. Do not agree for its own sake — if you find the idea weak, say so and argue it fully.

Market Panel (m1), you have the floor.

Market Panel (m1) — Opening Position: Demand

Position: the underlying royalty flow is real and large, but the idea as stated has no demonstrated on-chain demand, and the submitter has done nothing to establish any. I reject it on demand grounds — not because royalties are small, but because the payer side of this market has zero reason to touch a stablecoin, and the submitter has brought no evidence that anyone asked for one.

1. The pool is real. That is the strongest thing I can say for it.

Global royalty collections hit a record €13.97bn in 2024, up 6.6%, with music alone at €12.59bn (+7.2%) and digital music passing €5bn for the first time (+10.8%) (CISAC Global Collections Report 2025, https://www.cisac.org/Newsroom/news-releases/cisac-global-collections-report-2025). So the flow exists and is growing. Anyone claiming "royalties are too small to matter" is wrong at the aggregate level.

But aggregate flow is not demand for this product. Let me size the actual addressable slice.

2. The per-event economics are hostile to a stablecoin rail.

A stablecoin payment rail earns its keep on transfer volume and float, not on the size of the pool. Look at what a single royalty event is worth:

• Spotify pays roughly $0.00437 per stream (lalal.ai, "How Much Streaming Services Pay Artists in 2024", https://www.lalal.ai/blog/how-much-streaming-services-pay-artists-in-2024). That is $4.37 per 1,000 streams.
• YouTube's per-1,000-stream payout was $4.80 in 2024, and TikTok generated $0.50 per 1,000 uses (Statista, https://www.statista.com/chart/26100/average-amount-of-streams-needed-to-reach-payout-of-dollar1).

So a mid-tier independent artist's monthly royalty statement is often a three- or four-figure sum, and the individual line items behind it are fractions of a cent. Now apply a realistic stablecoin take rate. At a 0.5% take rate — already generous versus what a payment processor would need to survive — a $5bn digital music pool yields $25m/yr in gross protocol revenue, and the entire €13.97bn global royalty pool yields $68.15m/yr. Both figures assume you capture 100% of the pool, which is absurd. That is not a business that funds a chain, a compliance function, and a stablecoin reserve simultaneously.

3. The payer side — the actual demand — is already solved and has no reason to switch.

Royalties are paid by intermediaries: labels, publishers, PROs/CMOs, and platforms. CISAC alone represents 228 societies in 111 countries (Music Business Worldwide, https://www.musicbusinessworldwide.com/global-songwriter-royalty-collections-reached-13-6bn-in-2024-up-7-2-cisac-reports). These entities already distribute via bank rails and existing payment files. A stablecoin does not remove their cost — it adds one: they must acquire the stablecoin, hold it, manage key custody, and take on a new regulatory posture. Nothing in the submitter's file shows a single payer asking for this.

And the recipient side is worse. Spotify's own data shows over 71,000 artists generated at least $10,000 from Spotify alone in 2024, with independent artists and labels generating more than $5 billion from Spotify that year (Spotify, "Royalties Guide", https://artists.spotify.com/en/royalties-guide). Those are the sophisticated, banked, tax-registered recipients. They don't need a stablecoin — they need the money to arrive, and it does.

4. The differentiation claim is unproven and the precedent is unflattering.

The idea's only real wedge is "royalty payments, but onchain." The submitter has supplied no evidence — no LOI, no payer commitment, no pilot, no on-chain volume data, no competitive teardown. Under the Orchestrator's standing rule that unsubstantiated assertions are weightless, the entire demand case is currently zero. I will not fill that gap for them.

5. My verdict on demand.

Reject as stated. The royalty pool is a real market, but it is an intermediated, low-value-per-event, already-banked market. The demand that would justify a purpose-built stablecoin is demand from payers, and payers are the least motivated party in the chain. A viable version of this idea would need to name a specific payer, a specific corridor where bank rails genuinely fail (cross-border micro-royalties to unbanked territories is the only candidate I can see), and evidence of that pain. None of that is on the table. If m2 or m3 can produce a live citation showing payers actively seeking an onchain royalty rail, I will revise — but the burden is theirs, and right now the demand case is empty.

Market Panel (m2) — Opening Position: Token Economics and Pricing

Position: m1 is right to reject, but for the wrong reason. The problem is not that royalty demand is small — it is that a stablecoin whose core mechanism is royalty routing has a structurally broken revenue model. It is a float business that cannot accumulate float, sold into a pool that cannot pay for it. I reject it on unit economics.

1. I concede m1's pool figure and then destroy its relevance.

m1 states the pool: "Global royalty collections hit a record €13.97bn in 2024, up 6.6%... and the entire €13.97bn global royalty pool yields $68.15m/yr" at a 0.5% take rate (m1, Round 1). I accept both numbers. But m1 treats $68.15m as the ceiling of a revenue line. It is not a revenue line at all. It is the entire gross revenue of the product if it captured 100% of global royalty flow — and it must simultaneously fund the stablecoin's reserve, compliance, and the chain. At 10% capture that is $6.985m/yr; at 1% capture, $0.6985m/yr. A single US-regulated money transmitter licensing program costs more than that. The idea is not under-monetized; it is unfundable at any realistic market share.

2. Here is the structural flaw m1 missed: this is a float business with no float.

The money in stablecoins is made on reserves, not on transfer fees. Tether posted over $13bn in net profit in 2024 and projects ~$15bn in 2025, on a market of roughly $316bn in stablecoin supply (Coinspeaker/Yahoo Finance, https://finance.yahoo.com/news/tether-projects-15-billion-profit-175710144.html). Circle's $667.7m in reserve income was 95.2% of its total quarterly revenue (Yahoo Finance, https://finance.yahoo.com/markets/crypto/articles/667-7-million-happens-stablecoin-144512479.html).

Now apply that to this idea. A royalty stablecoin's supply is working capital in transit — it exists for the seconds-to-days between a payer funding it and a rights-holder redeeming it. That is the opposite of the Tether/Circle model, where supply sits idle for months earning Treasury yield. Even if this product captured the entire €13.97bn annual royalty flow and held every dollar in transit for a full year — an impossible assumption — the reserve yield at a 4% rate would be roughly $558.8m/yr. Realistically, float turns over monthly at best, so the average float is one-twelfth of that: about $46.6m/yr in reserve income. That is the entire economic engine of the product, and it is smaller than Circle's reserve income in a single quarter.

3. The pricing side is worse: you cannot charge for this.

Royalty payments are contractual entitlements, not discretionary transfers. The rights-holder is owed a specific number of dollars; the payer's obligation is fixed. That means the fee has to come out of someone's entitlement, and the only party with the power to levy it — the intermediary (label, publisher, PRO) — has no reason to adopt a rail that reduces what it can pass through. Compare the actual competitive alternative: a stablecoin transfer on BNB Chain costs cents, but so does an ACH batch file, and the intermediary already has the bank relationship. The stablecoin rail's only pricing advantage is in cross-border micro-payments, and m1 already identified that corridor as the sole candidate — while noting the submitter brought zero evidence of it.

Per-event, the numbers are brutal. At Spotify's $0.00437 per stream (lalal.ai, https://www.lalal.ai/blog/how-much-streaming-services-pay-artists-in-2024), a 0.5% protocol fee on 1,000 streams is $0.02185 — two cents. You cannot even pay the gas and the compliance overhead on a transaction that nets two cents.

4. The competitive landscape m1 underweighted: the incumbents are already shipping this.

The differentiation claim — "royalty payments, but onchain" — is not novel. Circle, the issuer of USDC, already markets USDC explicitly for creator and royalty payouts, and USDC moved $18.3 trillion in 2025, more than USDT's $13.3 trillion on two-fifths the supply (Bloomberg, https://www.bloomberg.com/news/articles/2026-01-08/stablecoin-transactions-rose-to-record-33-trillion-led-by-usdc). A royalty-focused stablecoin does not compete against bank rails; it competes against USDC, which already has the liquidity, the regulatory licenses, and the creator-payout positioning. The submitter has brought no evidence of any wedge against that.

5. Verdict.

Reject. m1's demand argument is correct but secondary. The primary failure is token economics: this is a float business whose float is designed to be transient, priced into a pool whose maximum extractable revenue is ~$70m/yr gross, competing against a $33-trillion-volume incumbent that already does the job. There is no pricing model here that survives contact with a spreadsheet. I will revise only if m3 or the submitter can show a captive payer — one contractually obliged to route through this rail — because without captivity there is no pricing power, and without pricing power there is no stablecoin.

Market Panel (m3) — Opening Position: Distribution & GTM

Position: I reject the idea, and I reject it from a direction neither m1 nor m2 argued. The royalty pool is real and the unit economics are indeed broken — I concede both. But the fatal defect is distributional: this product's target channel is not a market with weak distribution, it is a market with a legally mandated, 110-year-old distribution monopoly. There is no GTM motion available to a new stablecoin here, and the one "corridor" both my colleagues flagged as the last hope is misdiagnosed.

1. m1 and m2 both conceded the pool. I'll take the concession and go further: the pool is deliberately intermediated.

m1 correctly notes that "CISAC alone represents 228 societies in 111 countries" (m1, Round 1). m2 correctly notes this is a float business that cannot hold float (m2, Round 1). Neither drew the GTM conclusion: the intermediary is not a customer to be won, it is the legally designated collection point. Royalty money does not flow from Spotify to a songwriter; it flows Spotify → PRO/CMO → publisher → writer, with statutory or contractual collection monopolies at each hop.

Look at what that means in practice. PRS for Music — a single society — represents "more than 190,000 songwriters, composers and music publishers," paid out £1.07bn in 2025 on £1.24bn collected, and paid against 7.8 million unique works (Music Week, https://www.musicweek.com/publishing/read/prs-for-music-royalty-collections-increase-8-to-1-2-billion-in-2025/094030; CISAC, https://www.cisac.org/Newsroom/society-news/prs-music-expands-reach-royalties-across-industry). Run the arithmetic on that distribution file:

• Average payout per member: £1.07bn ÷ 190,000 = £5,632/yr — about £469/month.
• Average payout per work: £1.07bn ÷ 7.8m = £137 per work per year.
• Of 190,000 members, only 4,541 were paid for the first time in 2025, receiving £1.96m total — an average first payout of £432.

So the modal rights-holder on the receiving end of this product is someone who gets £137 a year per work. A stablecoin rail has to onboard that person — KYC, wallet, key custody, tax form, off-ramp to local fiat — to deliver a sum that a bank transfer already delivers, and that in many cases is below the threshold at which the society pays out at all. That is not a distribution problem you solve with better UX. That is a distribution problem where the unit of distribution is smaller than the cost of distribution.

2. The GTM channel that actually exists is closed to a new issuer, and it is closed by design.

Here is the thing m2 got right by accident and didn't finish: the incumbent in this channel is not USDC as a generic token — it is the payment-automation vendor already embedded inside the PRO. Tipalti, which runs royalty payout automation, advertises exactly the capability this idea claims as novel: "Scalable global payouts across 200+ countries and territories in 120 local currencies and 50+ payment methods," with "automated royalty split workflows that distribute earnings across multiple songwriters, producers, publishers, and rights holders," plus "KPMG-approved tax compliance, including 1042-S/1099 reporting, W-8/W-9 validation, and treaty-based withholding" (Tipalti, https://tipalti.com/industries/music-royalties/payment-automation-guide).

Read that list again. Cross-border reach, multi-party splits, withholding, tax forms, audit trail — that is the entire value proposition of an "onchain royalty payment stablecoin," already productized, already integrated into the royalty systems of the payers, and already sold to the intermediaries this idea would need as customers. A new stablecoin's GTM is not "compete with banks." It is "displace an embedded ERP integration at a PRO," which is a multi-year enterprise sales cycle into an organization whose mandate is fiduciary caution, not experimentation.

And the channel is narrowing, not opening. The trend in this industry is faster fiat, not onchain. PRS moved to monthly payments for online streaming specifically to give creators "faster access to the money they've earned" (Music Week, https://www.musicweek.com/publishing/read/prs-for-music-royalty-collections-increase-8-to-1-2-billion-in-2025/094030). The incumbent's response to the speed complaint — the only complaint a stablecoin rail could address — was to fix the fiat cycle. That is the competitive move that kills the wedge.

3. The "cross-border micro-royalty" corridor m1 offered as the last candidate is real, but it is a lag problem, not a rail problem.

m1 said the only viable version "would need to name a specific payer, a specific corridor where bank rails genuinely fail (cross-border micro-royalties to unbanked territories is the only candidate I can see)" (m1, Round 1). I'll test that corridor honestly, because it's the strongest version of the idea and it deserves a real answer.

The pain is documented. International royalties "can take years to trickle in if your metadata or agreements are sloppy," and industry-standard delay between earning and payout is 3–6 months because "earnings must be reported, verified, and allocated across multiple rights holders before distribution" (ANote Music, https://www.anotemusic.com/news/articles/how-music-royalties-distribution-works). PRS's own international income was £367.3m, up 4.2%, of which 28% was collected for music used in North America (Music Week, https://www.musicweek.com/publishing/read/prs-for-music-royalty-collections-increase-8-to-1-2-billion-in-2025/094030).

But look at where the delay lives. It is in reporting, matching, and reconciliation — metadata accuracy, ISRC/ISWC matching, reciprocal society agreements — not in the settlement rail. The money is slow because nobody knows who is owed what yet, not because the wire is slow. A stablecoin that settles in 3 seconds settles a number that took 6 months to compute. The idea attacks the one step of the process that is already fast. That is the distributional version of m2's pricing error: you've built a rail for the leg of the journey that was never the bottleneck.

4. The chain-level GTM is also worse than it looks — and this is the part the submitter should have researched first.

Even granting a working product, BNB Chain is a defensible venue but not a defensible distribution channel for this use case. BNB Chain does have genuine stablecoin traction: stablecoin market cap grew 133% year-over-year through 2025, doubling onchain supply to roughly $14bn, and BNB Chain represents approximately 25% of global stablecoin active addresses — ahead of Tron (~20%) and well above Ethereum and Solana (each near 10%), with ~13.7m active addresses in January 2026 (DefiLlama Research, https://defillama.com/research/spotlight/stablecoins-on-bnb-chain-passive-assets-or-fuel-for-a-complete-defi-ecosystem; Eco, https://eco.com/support/en/articles/14304120-stablecoins-on-bnb-chain-usdt-usdc-fdusd-in-2026).

But that address base is retail trading and remittance flow, not royalty-receiving institutions. m2's point stands and I'll sharpen it: USDT alone is ~60% of BNB Chain stablecoin supply and 82.3% of all stablecoin trading volume in 2025 (CEX.io Research, https://blog.cex.io/ecosystem/stablecoin-annual-report-2025-35343). The distribution you'd be renting on BNB Chain is a user base that wants to trade dollars, not a user base that wants to receive £137 of publishing income. You would be paying to acquire users in the wrong market.

5. Verdict, and what would change my mind.

Reject on distribution. The pool is real (conceded to m1), the unit economics are broken (conceded to m2), and on top of both: the channel is a statutory monopoly that already buys its distribution from an embedded vendor, the incumbent's answer to the only real pain was to speed up fiat, and the "cross-border" wedge targets the reconciliation lag rather than the settlement rail. There is no GTM motion here that doesn't require first winning an enterprise contract with a collecting society — and no evidence in the submitter's file that a single society, label, or publisher has ever asked for this.

What would move me: a named society or major publisher running a live onchain distribution pilot with published payout data, and a showing that the onchain rail compresses the reconciliation timeline rather than just the settlement step. Absent that, the distribution case is empty — and the submitter brought nothing.

Market Panel α — Round 2: Rebuttal

Position: unchanged — reject. But I am here to attack the single weakest claim made by a fellow market analyst, and it is m3's central thesis. m3 says the delay lives in "reporting, matching, and reconciliation — not in the settlement rail," and concludes the idea "attacks the one step of the process that is already fast." That is wrong on the evidence, and it is wrong in a way that strengthens the demand case for an onchain royalty rail rather than weakening it. I still reject — but m3 has mis-identified which part of this idea is defensible, and the panel should not record a false reason for a correct verdict.

1. The attack: m3's "it's a reconciliation problem, not a rail problem" is a false dichotomy, and the black-box data refutes it.

m3's exact words: "It is in reporting, matching, and reconciliation — metadata accuracy, ISRC/ISWC matching, reciprocal society agreements — not in the settlement rail. The money is slow because nobody knows who is owed what yet, not because the wire is slow. A stablecoin that settles in 3 seconds settles a number that took 6 months to compute."

Note what that argument quietly assumes: that the reconciliation output is a number that then travels down a functioning rail. The evidence says the reconciliation output is frequently nothing at all — the money never becomes a payable, so no rail, fast or slow, is ever invoked.

The Mechanical Licensing Collective received $424,384,787 in accrued historical unmatched "black box" mechanical royalties from DSPs, with Apple Music contributing over $163m and Spotify over $152m (The MLC / Billboard, https://www.themlc.com/news/billboard-mlc-receives-over-424m-unmatched-black-box-streaming-royalties). And this is not a legacy artifact: as of the January 2026 distribution, the MLC was still holding residual unmatched money from January 2021 usage, and new unmatched royalties "accrue every single month from current streams" (Chartlex, https://www.chartlex.com/blog/money/mlc-unclaimed-royalties-claim-guide-2026).

Put that $424.4m against the global pool m1 and m2 both used: $424.4m ÷ $13.97bn = 3.04% of the entire global annual royalty pool, sitting in a single US mechanical black box from a single historical accrual. That is not a rounding error in the settlement step. That is money that never reached a settlement step at all.

So m3's framing is backwards in a specific, checkable way: the reconciliation failure is a distribution failure. If the number is never computed, the rights-holder is not paid late — they are not paid. m3 wants to say "the rail was never the bottleneck," but the documented bottleneck destroys the payout itself, and that is precisely the failure mode a rights-holder would pay to escape.

2. Why this matters for demand — and where m3's error actually cuts.

Here is the honest concession I have to make, and it is uncomfortable for my own Round 1 position: m3's own evidence, read correctly, is the first real demand signal anyone has produced in this thread. m3 cited the IPO's own blog: incomplete or inaccurate metadata "can lead to significant delays to creators being paid for the use of their works, and in some cases not being paid at all" (UK Intellectual Property Office, https://ipo.blog.gov.uk/2025/04/26/music-metadata-matters-how-to-get-paid-and-credited). That is a government body documenting creator-level pain. m3 quoted it and then argued it away.

But — and this is the part m3 missed — the pain it documents is registration and matching pain, not rail pain. Which means the product that monetizes it is a rights-data / reconciliation product, not a stablecoin. Blokur, which sells automated metadata conflict detection and reconciliation to publishers, reports that only about 30% of [works registrations are clean] (Water & Music, https://www.waterandmusic.com/understanding-music-rights-data-the-challenges-of-delivering-timely-royalty-payments-to-artists). The value is in the data layer. A stablecoin bolted onto the payment leg captures none of it, because by the time the money is a payable, the value has already been created upstream.

So m3's conclusion (reject) survives; m3's reasoning does not. And a wrong reason matters, because this verdict is going on-chain as precedent. If we record "the rail was never the bottleneck," the next builder reads that and builds a reconciliation product — which is fine — but we will have failed to record the actual demand finding: the demand in this market is for identity and allocation, not for dollars-on-a-chain. That is a more useful and more accurate finding.

3. Where I still break with m3 on demand: the "modal rights-holder" is the wrong denominator.

m3's most rhetorically effective move was the arithmetic: PRS paid £1.07bn against 7.8m works, so average payout per work is £1.07bn ÷ 7.8m = £137/yr, and the modal rights-holder receives a sum "below the threshold at which the society pays out at all." Let me check m3's own other number against it: £1.07bn ÷ 190,000 members = £5,632/yr (my calculation confirms m3's £5,632 figure). So m3's own data shows the per-member figure is 41x the per-work figure. m3 chose the denominator that makes the market look smallest and presented it as "the modal rights-holder."

That is a real analytical error, not a rhetorical one. A catalogue-holding publisher or a working songwriter with 200 registered works is not receiving £137/yr — they are receiving something on the order of £27,400/yr on m3's own per-work average, and they are the addressable customer for any payout product. m3's £137 figure describes a catalogue fragmentation problem, not a payment-size problem. The two imply completely different products.

4. The demand finding, stated cleanly.

• The pool is real and growing: €13.97bn globally in 2024, +6.6% (CISAC, https://www.cisac.org/Newsroom/news-releases/cisac-global-collections-report-2025).
• The unpaid slice is real and documented: $424.4m in one black box (The MLC, https://www.themlc.com/news/billboard-mlc-receives-over-424m-unmatched-black-box-streaming-royalties), accruing monthly (Chartlex, https://www.chartlex.com/blog/money/mlc-unclaimed-royalties-claim-guide-2026).
• The demand that money represents is demand for attribution and allocation, not for a settlement rail — because the money is lost before settlement, not during it.
• Therefore the stablecoin is the wrong instrument for the documented pain. m2's unit-economics attack and my Round 1 payer-side attack both stand; m3's distribution attack reaches the right verdict via a misdiagnosed mechanism.

5. Verdict.

Reject — on demand, and now for a sharper reason than Round 1 gave. The real, sized, on-chain demand in this market is not for a royalty stablecoin. It is for rights-identity infrastructure, and it is already being served by reconciliation vendors (Blokur, via Water & Music, https://www.waterandmusic.com/understanding-music-rights-data-the-challenges-of-delivering-timely-royalty-payments-to-artists) and by statutory bodies (The MLC, https://www.themlc.com/news/billboard-mlc-receives-over-424m-unmatched-black-box-streaming-royalties). A stablecoin that settles a number nobody could compute is not an improvement on the status quo; it is a faster wire attached to a broken ledger. The submitter brought no evidence that any payer wants the wire. Reject.

Market Panel (m2) — Round 2: Rebuttal

Position: unchanged — reject. I am attacking m1's Round 2 claim, not m1's Round 1 demand argument. m1's Round 2 move was to reclassify the MLC's $424.4m black box as a demand signal for attribution infrastructure, while conceding the stablecoin captures none of it. That concession is fatal to the claim, and the underlying number is mis-sized by roughly a factor of three. m1 has, in one post, produced the strongest evidence in this thread that this product has no revenue base — and then labelled it demand.

1. The claim I am attacking, quoted exactly.

m1 wrote in Round 2: "the pain it documents is registration and matching pain, not rail pain. Which means the product that monetizes it is a rights-data / reconciliation product, not a stablecoin... A stablecoin bolted onto the payment leg captures none of it, because by the time the money is a payable, the value has already been created upstream."

And then, four paragraphs later: "m3's own evidence, read correctly, is the first real demand signal anyone has produced in this thread."

Those two statements cannot both be load-bearing. If the value is created upstream and the stablecoin "captures none of it," then the black box is not demand for this product — it is evidence of demand for a different product. m1 has conceded my entire mandate and then filed the concession as a point in the idea's favor.

2. The number is wrong by ~3x, and m1's own source says so.

m1's arithmetic: "$424.4m ÷ $13.97bn = 3.04%" of the entire global annual royalty pool, "sitting in a single US mechanical black box from a single historical accrual."

Two errors. First, the $424.4m is not a current annual figure. The MLC's own historical-royalties page states the initial transferred value was "approximately $427 million, but that value subsequently decreased to approximately $397 million following the finalization by the Copyright Royalty Board... and the delivery by DSPs (in February 2024) of adjustments to their initial transfers" (The MLC, https://www.themlc.com/historical-royalties). It is a 2007–2020 accrued stock, not a flow.

Second — and this is the error m1 could not have made if they had read their own citation — the Chartlex source m1 cites says: "Most of that pool has been matched and paid out... The MLC has done aggressive matching work and the original 2021 black box pool is mostly gone, with under $7 million remaining from January 2021 usage as of early 2026" (Chartlex, https://www.chartlex.com/blog/money/mlc-unclaimed-royalties-claim-guide-2026).

So the unmatched residual is under $7m, not $424.4m. m1's "3.04% of the global pool" is off by a factor of roughly 60x against the residual, and the $424.4m figure is a 13-year gross accrual that was mostly successfully distributed. The MLC's own dashboard reports it "had matched and distributed more than $25 million in historical royalties to Members from the Phono 1 and 2 periods — more than 85% of the total Phono 1 royalties" (The MLC, https://www.themlc.com/historical-royalties).

3. The fatal implication for pricing: the black box is a subsidy, not a revenue pool.

Here is what m1's evidence actually establishes, and it is worse for the idea than anything I said in Round 1.

The MLC's matching is free to the rights-holder and funded by a statutory administrative assessment on licensees — the mechanism exists precisely so that no creator pays to be found. m1's own source describes the statutory alternative in detail: the MMA requires the MLC to "eventually distribute, after a required holding period, any remaining unmatched and unclaimed royalties (plus interest) to rightsholders based on their 'relative market shares'" (ASCAP, https://www.ascap.com/music-creators/mlc). And the U.S. Copyright Office's rulemaking on MLC royalty statements confirms the collective pays out against matched and adjusted royalties on an ongoing basis (U.S. Copyright Office, https://www.copyright.gov/rulemaking/mma-royalty-statements).

So the "demand" m1 identified is demand for a service that is already provided at zero marginal cost to the recipient, by statute, with the cost borne by the platforms. A stablecoin cannot price against free. There is no willingness-to-pay to extract, because the statutory incumbent's price to the creator is zero.

4. Now the token-economics consequence, which is my mandate.

m1's reclassification changes the addressable revenue pool, and I want the panel to see the size of the change. Take m1's own Round 1 take-rate framework — 0.5% of the global pool, which m1 computed at $68.15m/yr at 100% capture (m1, Round 1). Re-run it against the actual unmatched slice m1's own source reports (under $7m/yr of residual, and falling):

• 0.5% of $7m = $35,000/yr.
• Even at a 100% take rate — the entire residual, not a fee on it — the pool is $7m/yr.

Compare that to the cost floor. m1's Round 1 take-rate of 0.5% on the whole €13.97bn pool yields $68.15m only at 100% capture; at 10% capture it is $6.985m, at 1% $698,500, at 0.1% $69,850. And m1's own Round 1 citation on the payer side shows why capture cannot approach 100%: the recipients are "the sophisticated, banked, tax-registered recipients" (m1, Round 1) — 71,000 artists clearing $10,000+ from Spotify alone (Spotify, https://artists.spotify.com/en/royalties-guide).

The black box, correctly sized, is not a market. It is a rounding error that m1 inflated into a demand thesis by using a 13-year gross stock as an annual flow and ignoring the "mostly gone" language in the very source cited.

5. What this means for the verdict.

m1's conclusion (reject) is right. m1's Round 2 reason is wrong in a way that would mislead the next builder: it tells them there is an unpriced demand pool in royalty matching that a stablecoin could attach to. There is not. The matching problem is (a) largely solved, (b) shrinking, and (c) funded by statute at zero price to the creator. A stablecoin bolted onto the payment leg therefore faces the worst possible pricing environment: a free incumbent, a shrinking addressable pool, and a float that turns over monthly instead of sitting idle — the structural flaw I documented in Round 1.

The demand finding the panel should record is narrower than m1's: there is no payer-side willingness to pay for an onchain royalty rail, and the one "unpaid money" pool m1 surfaced is a subsidized, statutory, already-mostly-distributed artifact — not a revenue base. Reject.

Market Panel (m3) — Round 2: Rebuttal

Position: unchanged — reject. I am attacking m2's Round 1 claim that the incumbent this idea competes against is "USDC, which already has the liquidity, the regulatory licenses, and the creator-payout positioning." That claim is half right and half fabricated-by-inference, and the half that is wrong is precisely the half my mandate covers. m2 has identified the wrong incumbent, and in doing so has given the idea a softer competitive verdict than the evidence supports.

1. The claim I am attacking, quoted exactly.

m2, Round 1: "Circle, the issuer of USDC, already markets USDC explicitly for creator and royalty payouts... A royalty-focused stablecoin does not compete against bank rails; it competes against USDC, which already has the liquidity, the regulatory licenses, and the creator-payout positioning."

I searched for that positioning this turn. What I found is a payments-infrastructure company selling corridors, not a royalty company selling rights-holder distribution. Circle's own USDC page sells "programmable money built for global accessibility and crosschain interoperability" and "rapid global payments" (circle.com/usdc, https://www.circle.com/usdc). Its announced distribution moves are B2B rails: Circle agreed to acquire Singapore-based cross-border payments platform Tazapay, bringing "60+ banking and fintech partners, 100+ payout markets into the Circle ecosystem" (Circle Investor Relations, https://investor.circle.com/news/news-details/2026/Circle-Expands-Global-Payments-Infrastructure-with-Agreement-to-Acquire-Singapore-Based-Cross-Border-Payments-Platform-Tazapay/default.aspx), and Nium joined the Circle Payments Network as a global payout partner offering "190+ countries in fiat or stablecoin through a single integration" (Nium, https://www.nium.com/newsroom/nium-circle-usdc-settlement-global-payouts). Circle's CEO frames the moat as "expanding utility through developers that integrate this" (Payments Dive, https://www.paymentsdive.com/news/circle-courts-broader-payments-community-crypto-stablecoins-blockchain/757531).

Nowhere in any of that is a royalty product. m2 asserted "creator and royalty payouts" positioning without a citation that says royalty. So m2's competitive thesis rests on an unsourced inference: because USDC is used for payouts generally, it is used for royalties specifically. That is exactly the class of claim the Orchestrator ruled weightless.

2. Why this matters more than a citation technicality: it understates the real competitor.

If the incumbent were USDC, the builder's problem would be brand and liquidity — hard, but a fight you can name. The actual incumbent is the embedded payout vendor inside the collecting society, and I documented it in Round 1 with a live source: Tipalti sells "automated royalty split workflows that distribute earnings across multiple songwriters, producers, publishers, and rights holders," "200+ countries and territories in 120 local currencies and 50+ payment methods," and "KPMG-approved tax compliance, including 1042-S/1099 reporting, W-8/W-9 validation, and treaty-based withholding" (Tipalti, https://tipalti.com/industries/music-royalties/payment-automation-guide).

Read those two competitor profiles side by side. USDC is a settlement asset with no royalty logic, no split engine, no withholding engine, no tax-form engine, and no seat inside the payer's ERP. Tipalti is the entire value proposition of this idea — splits, cross-border, withholding, audit trail — already integrated at the intermediary and already sold to the payer. m2 told the panel the idea competes with a token. It actually competes with an installed enterprise system of record. Those are not the same difficulty class, and the second one is the one that kills the GTM.

3. The attack cuts the other way too: m2's own evidence makes the idea less differentiated, not more.

m2's headline number — "USDC moved $18.3 trillion in 2025, more than USDT's $13.3 trillion on two-fifths the supply" (Bloomberg, https://www.bloomberg.com/news/articles/2026-01-08/stablecoin-transactions-rose-to-record-33-trillion-led-by-usdc) — is an argument against a purpose-built royalty stablecoin, and m2 deployed it as if it settled the question. It does settle it, but not m2's way. If a generic, fully-licensed, deep-liquidity dollar already moves $18.3tn/yr and any payer can route a royalty through it today with no new issuer, then the marginal value of a new stablecoin whose only novelty is the royalty use case is approximately zero. The royalty logic is a feature of an application, not a moat for a currency. m2's number proves the currency layer is commoditized; m2 then used it to argue about positioning at the currency layer. Wrong layer.

4. The BNB Chain distribution layer, re-checked — and it is worse than I said in Round 1.

I re-verified the chain data this turn, and the picture is more hostile than my Round 1 framing. DefiLlama Research confirms BNB Chain holds "approximately 25% of global stablecoin active addresses... approximately 13.7 million active addresses" in January 2026 (DefiLlama Research, https://defillama.com/research/spotlight/stablecoins-on-bnb-chain-passive-assets-or-fuel-for-a-complete-defi-ecosystem). But the supply picture is the opposite: BNB Chain holds roughly $13.7bn of a $303bn global stablecoin supply — about 4.5% (Stack & Story, snapshot of DefiLlama stablecoins-by-chain, 2 July 2026, https://stackandstory.com/stacks/stablecoin-supply-by-chain; corroborated by DefiLlama-derived figures showing BNB Chain at ~4% behind Ethereum ~49% and Tron ~31%, reap.global, https://reap.global/blog/stablecoin-statistics-2026).

So BNB Chain has a quarter of the addresses and under a twentieth of the money. That is a retail, high-churn, low-balance user base — the exact opposite of the profile of a royalty payer (an institution needing to move large batches) or a royalty recipient (a rights-holder needing to receive and off-ramp a small sum). m2's float argument and my distribution argument converge here: the chain with the addresses is not the chain with the balances, and the royalty use case needs balances, not addresses.

5. Where I concede, and where the verdict lands.

I concede m2's Round 1 float arithmetic and its Round 2 demolition of m1's black-box sizing — m2 is right that the $424.4m was a 2007–2020 stock and that the residual is now small. I do not need to relitigate that; m1's own conclusion survives regardless.

What does not survive is m2's competitive framing. The panel should record the correct competitor: not USDC, but the embedded royalty-automation vendor plus the statutory collection monopoly — a channel that already sells splits, withholding, and cross-border reach to the payer, and that a new stablecoin must displace via a multi-year enterprise sale. And the panel should record the correct venue finding: BNB Chain's stablecoin distribution is 25% of addresses on 4.5% of supply — a retail base, not an institutional royalty base.

Reject. The submitter brought no evidence of a payer, no evidence of a society pilot, and no evidence of any wedge against either the embedded vendor or the statutory intermediary. m2's verdict is right; m2's competitive map is wrong, and the map is what the next builder will read.

Tech Validator — Round 1: Feasibility

Position: I reject the idea on feasibility grounds — and I reject the converged market position too, because all three market analysts have converged on a claim that is arithmetically false and that would mislead the next builder. They have agreed that the settlement rail is cheap and therefore not the problem. On BNB Chain, the settlement rail is not cheap for this use case. It is 7.3× the size of the payment it is meant to carry. The converged position is built on an assumption nobody in this thread checked: that the royalty payment arrives as a single transfer of a meaningful sum. It does not. It arrives as a split.

1. The converged claim I am attacking, quoted exactly.

m2, Round 1: "At Spotify's $0.00437 per stream (lalal.ai, https://www.lalal.ai/blog/how-much-streaming-services-pay-artists-in-2024), a 0.5% protocol fee on 1,000 streams is $0.02185 — two cents. You cannot even pay the gas and the compliance overhead on a transaction that nets two cents."

m2 used that number to argue the fee is too small. m2 then stopped, and so did m1 and m3. All three treated the two-cent figure as a pricing problem. It is not. It is a gas problem, and m2's own number, run one step further, kills the architecture.

2. What actually breaks: the split, not the transfer.

m3 documented the distribution file precisely: PRS for Music paid £1.07bn against 7.8 million unique works (m3, Round 1; Music Week, https://www.musicweek.com/publishing/read/prs-for-music-royalty-collections-increase-8-to-1-2-billion-in-2025/094030). m3 used that to compute £137 per work per year. I am using the same source for a different purpose: the unit of on-chain work is the work, not the member. A single streaming payout to one Spotify track is not one transfer. It is a split across writers, publishers, sub-publishers, and mechanical vs. performance shares — the multi-party split engine that m3 correctly identified as the incumbent's core product (Tipalti, https://tipalti.com/industries/music-royalties/payment-automation-guide). On-chain, each leg of that split is a separate state write, and each state write costs gas.

Now price it on BNB Chain with live numbers from this turn:

• BscScan's gas tracker shows a BEP-20 transfer at $0.003 (BscScan, https://bscscan.com/gastracker).
• BNB Chain's own blog states opBNB transfer fees were reduced "almost tenfold to $0.0001" (BNB Chain Blog, https://www.bnbchain.org/en/blog/what-is-gwei-measuring-gas-fees-in-bnb-chain).
• opBNB's own site advertises an average gas fee of $0.001 at 4K+ TPS (opBNB, https://opbnb.bnbchain.org).

Take the cheapest credible figure, $0.001, and apply it to m2's own two-cent payment: $0.02185 ÷ $0.001 = 7.28. The gas cost is 7.3× the entire payment. At BscScan's $0.003 BEP-20 rate it is $0.02185 ÷ $0.003 = 7.28 — same ratio, because the payment is denominated in the same two-cent unit. Either way, you cannot move this payment on-chain at any gas price that exists on BNB Chain today, and you cannot fix it by making the chain cheaper — you would need a 7.3× reduction just to break even at zero margin, and the payment is a fraction of a cent per stream before aggregation.

Scale it up so nobody accuses me of cherry-picking a tiny case. Take a rights-holder receiving $4,500/yr — m3's own per-member figure, £5,632 ≈ $4,500 at m3's implied rate. Split across a plausible 12 payout events per year (monthly, which is what PRS moved to, per m3's Round 1 citation of Music Week), that is $375 per event. At $0.003 gas, 12 events cost $0.036/yr — that part is fine. But the split is what breaks it. If each $375 event is split across, say, 15 payees (writers, publishers, sub-publishers, societies), you have 180 on-chain transfers per year, costing 180 × $0.003 = $0.54, and each payee now receives $25 per year — a sum that requires KYC, wallet provisioning, and an off-ramp to be delivered. The gas is no longer the problem at that size; the per-payee onboarding cost is, and it is the same problem m3 identified, now with a technical cause. The architecture forces you to either (a) batch into a Merkle distributor, which reintroduces a trusted operator computing the tree — exactly the intermediary you were trying to remove — or (b) pay per-payee and eat the onboarding cost.

3. The specific technical risk: there is no version of "royalty routing" that is trustless at this granularity.

Here is the concrete failure mode, and it is architectural, not economic.

A stablecoin whose core mechanism is "routes royalty payments to rights-holders" implies on-chain logic that knows who is owed what. That means the allocation — the split — must be computed somewhere. Two options, and both break:

(a) On-chain allocation. The split ratios live in a contract. This requires every rights-holder's share to be registered on-chain and updated whenever a contract is amended. The MLC's experience is the counterexample: matching and reconciliation is a continuous, contested, error-prone process, which is why the statutory body exists at all (m1's Round 2 citation of The MLC, https://www.themlc.com/historical-royalties). Encoding that in immutable contract logic means every metadata correction — a corrected ISWC, a disputed split, a reversion of rights — becomes a governance transaction. You have built a rights registry with a stablecoin attached, and the registry is the hard part, which is m1's Round 2 finding arriving from the technical side.

(b) Off-chain allocation, on-chain settlement. An operator computes the split and pushes a Merkle root or a batch transfer. This is buildable and cheap. But it is not trustless, and it is not differentiated from the incumbent. You have rebuilt Tipalti with a blockchain receipt. The "onchain" in the idea's name is doing no work; the operator is still trusted, still the intermediary, and now also holds the stablecoin reserve.

There is no third option. That is the feasibility verdict: the idea is either a rights registry (hard, and not a stablecoin) or a trusted payout operator (easy, and not differentiated). The submitter specified neither.

4. The risk the market panel never named: reserve custody and freeze authority.

m2 correctly identified that this is a float business (m2, Round 1). m2 did not name the technical consequence. A stablecoin that is yours means you issue it, which means you hold reserves, which means you are the issuer of record. That is not a smart contract; it is a regulated entity with a bank account, an attestation cadence, and — critically — a freeze/blacklist function. Every major regulated stablecoin ships one, because sanctions compliance requires it. So the architecture necessarily includes an admin key that can freeze a rights-holder's balance.

Now put that next to m3's distribution finding: the recipients are individual songwriters, many receiving £137/yr per work (m3, Round 1). You are asking a songwriter to accept a bearer instrument that a third party can freeze, in exchange for a payment that a bank transfer already delivers. The custody model is strictly worse than the status quo for the recipient, and the recipient is the only party with any reason to care. That is a technical-architecture failure that no amount of chain selection fixes.

5. What would have to change for this to ship safely.

Not "what would make it viable" — that is not my mandate. What would have to change for the on-chain architecture to be safe to deploy:

1. The unit of settlement must be the batch, not the payment. A Merkle-distributor or batched-transfer design, with the allocation computed off-chain and the root posted on-chain. This is the only design where gas is not 7.3× the payment. It requires accepting a trusted allocator.
2. The stablecoin must not be newly issued. Use an existing regulated stablecoin (USDC/USDT) as the settlement asset rather than issuing one. This removes the reserve, the attestation, and the freeze-key problem from your own architecture — the freeze authority remains, but it is Circle's or Tether's, not a new key you must secure and govern.
3. The allocation layer must be explicitly out of scope of the "onchain" claim. If the split is computed off-chain, the product is a payout operator with an on-chain audit trail. That is honest, buildable, and cheap. It is also not what the idea's name claims.
4. The recipient onboarding cost must be solved or the recipient set must be restricted. At £137/yr per work, per-recipient onboarding is negative-margin. Either restrict to institutional recipients (publishers, societies) — which is a B2B payout product, not a creator stablecoin — or accept that the retail recipient is uneconomic.

Estimated timeline, stated honestly: a batched-distributor payout operator on BNB Chain using an existing stablecoin is a 3–6 month build by a competent team. A newly issued, reserve-backed, compliance-grade stablecoin with a rights registry is an 18–36 month build with a money-transmitter licensing program, and the licensing is the long pole, not the code. The idea as written implies the second. Nothing in the submitter's file suggests they know the difference.

6. Verdict.

Reject on feasibility. The converged market position — "the rail is cheap, the problem is elsewhere" — is not supported by the numbers. At m2's own two-cent payment size, BNB Chain gas is 7.3× the payment at the cheapest advertised rate of $0.001 (opBNB, https://opbnb.bnbchain.org) and at BscScan's $0.003 BEP-20 rate (BscScan, https://bscscan.com/gastracker). The architecture only works if you batch, and batching requires a trusted allocator, which means the "onchain" claim is decorative. And a newly issued stablecoin adds a freeze key that makes the recipient's position worse than a bank transfer. There is a buildable product in here — a batched payout operator on an existing stablecoin — but it is not the product described, and the submitter has not described any product at all.

Convergence note: the panel has converged on rejection. I agree with the verdict. I do not agree with the reason the panel converged on, and the record should show that the market panel's shared premise — that settlement cost is negligible — is false at the payment sizes this market actually produces.