Programmatic, instant, verifiable compensation for ongoing use of creator work.
A royalty is a payment to a rights-holder for ongoing use of their work. Music royalties pay songwriters and performers every time a song is played. Patent royalties pay inventors every time a product embodying the patent is sold. Franchise royalties pay the brand owner a percentage of each franchisee's revenue. Book royalties pay authors per copy sold. Oil and gas royalties pay landowners per barrel extracted.
In every case the same three parties exist: the rights-holder, the user of the rights, and the collection intermediary that sits in between tracking usage, collecting payment, and settling disputes. That intermediary is where traditional royalty systems break down.
What Traditional Royalty Systems Get Wrong
Manual accounting. ASCAP and BMI rely on self-reported performance counts, sampled datasets, and statistical extrapolation to figure out who gets paid. Most royalties are approximations.
Slow settlement. Music royalties take 3-9 months to reach the rights-holder after a stream. Book royalties are paid quarterly or semi-annually. A songwriter whose track goes viral in January sees the money in Q3 at best.
Enforcement gaps. Unauthorized use goes undetected by default. Rights-holders hire services or sue to recover what they're owed. Most small creators don't have the leverage to do either.
Rights fragmentation. A single song has recording royalties, mechanical royalties, sync royalties, and performance royalties, each collected by different bodies, often in different countries, often on different schedules.
Opacity. The rights-holder can't easily audit the collection intermediary. "Hollywood accounting" is the canonical case: a film grossing $500M somehow "loses money" on paper because the counting happens inside a black box.
These aren't bugs. They're the structural limits of a system where the collection intermediary is a trusted off-chain entity and the underlying usage is tracked by third-party reporting. Move the tracking onchain and the usage becomes the ledger directly, every use-event emits a verifiable log, the royalty calculation is a pure function of that log, and the settlement happens in the same transaction that records the use.
How Onchain Royalties Work on Whop
Whop's royalty engine is a live product called Content Rewards, already running at contentrewards.xyz. Every content use-event on Whop routes through it. The royalty split is encoded in the Move module handling the event, no invoicing, no reconciliation, no quarterly statement. Payment flows in the same atomic transaction as the use.
| Recipient | Share | What this represents |
|---|---|---|
| Content creator | 50% | Direct compensation for creating the work |
| Community / signal group | 25% | The community that contextualized and distributed the work |
| Indicator referenced | 20% | The tool or strategy that generated the underlying insight |
| Whop platform | 5% | Platform take for infrastructure, curation, distribution |
The indicator referenced attribution is the novel piece. When a signal caller publishes an analysis that references their Indicator Marketplace strategy, and someone pays to read that analysis, the indicator creator earns 20% of that use automatically. The content creator earned by using the indicator, the indicator creator earns by having their tool cited. Two rights-holders, one royalty flow, zero negotiation.
How the Cascade Flows
A reader pays 5¢ to unlock a paragraph. The 5¢ enters the Content Rewards module and fans out in the same transaction:
→ 5¢ paragraph unlock paid by reader
→ 2.5¢ to the creator's .whop name
→ 1.25¢ to the signal group the creator belongs to
→ 1¢ to the indicator strategy referenced
→ 0.25¢ to WhopEvery rights-holder in the chain earns from the chain's output. None of them wait for a monthly statement. None of them trust a collection intermediary's self-reported counts. The blockchain log is the ledger and the ledger is the payout instruction.
Shelby as the Attribution Oracle
The source of truth for every royalty calculation is Shelby's tamper-proof onchain read log. Every byte-range served, every ACE decryption event, every download is timestamped and recorded onchain. A creator cannot pay a bot farm to inflate view counts, every "view" requires a corresponding ACE decryption request or Shelby byte-range request, and the blockchain log is the only input the royalty function reads from.
The effect: royalty payouts are computed directly from cryptographically verifiable usage. There is no sampling, no estimation, no statistical extrapolation. The thing that happened is the thing that got paid for.
Indicator Royalties: Per-Profitable-Signal as the Ongoing Royalty
For indicator creators the royalty mechanic is even tighter. The creator gets paid per profitable signal fired, not per subscriber, not per month, not per download. Revenue tied directly to performance. An indicator that fires 3 profitable signals per day earns substantially more than one that fires 1 per week, even if both have the same subscriber count.
This is the royalty model a patent-holder would have if the patent paid them every time it actually created value for a licensee, rather than per licensed unit regardless of outcome. It's only possible because the "use" is verifiable onchain, the profitable signal is a recorded event, not a self-reported metric.
Royalties vs. Licensing
Licensing is the terms under which a work can be used. Royalties are the ongoing payments that flow when those terms are met. A license is a contract. A royalty is a cashflow. The Perpetual Attribution License (PAL) sets the terms, what's allowed, what triggers compensation, what rights transfer on derivative work. Royalties are what actually moves through the pipe the license defines. Content Rewards is the royalty engine. PAL is the licensing framework. They're complementary, not duplicative.
Related: Licensing for the Perpetual Attribution License. Streaming Payments for the payout rails royalty distributions settle onto. Consumption-Based Pricing for the buyer-side mechanics that generate the royalty events.