Asset HausAsset Haus
Entertainment IP Platform
Back to Case Studies
Entertainment & IP

Entertainment IP Platform

Tokenized entertainment IP operating platform for rights-backed offerings, investor onboarding, registry, and revenue distribution workflows.

Undisclosed Platform Mandate
Deal Size
Multi-Asset SPV Framework
Jurisdiction
Platform capacity
Investors
6-8 weeks
Time to Launch
Asset Type
Entertainment IP & Revenue Rights Platform
Location
MENA / Global
Structure
IP-Backed Digital Securities
Blockchain
Ethereum
Investor Type
Professional Investors
Geography
MENA, Global
Avg. Ticket
Variable
Distributions
Scheduled revenue distributions

Instruments

IP-backed notesRoyalty participation tokensRevenue participation rightsPlatform-level investor registry

Results

target
Undisclosed platform mandate
coverage
Multiple rights-backed offerings
distribution
Automated revenue workflows
status
In progress

Deal context

In Q1 2025, an entertainment rights operator engaged Asset Haus to build a reusable tokenization platform for rights-backed offerings across multiple media categories. The mandate — undisclosed in size and published here as a public summary only — is a platform engagement rather than a single deal: the operator runs repeat offerings and needed institutional-grade infrastructure for investor onboarding, registry controls, and automated revenue distribution that could be reused launch after launch.

The platform serves professional investors across MENA and globally, with variable ticket sizes and platform-level capacity rather than a fixed investor count. Digital securities are issued on Ethereum under a multi-asset SPV framework, with each engagement cycle configured on a six-to-eight-week timeline. Work is in progress.

The structuring problem

Entertainment IP compounds three structuring problems that most asset classes face one at a time.

Rights chains. A revenue right in film, music, or other media sits at the end of a contractual chain: creators, rights owners, operators, and the parties that actually collect the money. Before any token can promise a share of revenue, rights assignment documentation must show that the issuing vehicle genuinely controls the streams it monetizes. That is why rights catalog diligence was a headline complexity factor here — every offering scope had to be approved through an intake and diligence step before issuance.

Royalty data fragmentation. Entertainment revenue arrives from multiple sources, on different schedules and in different formats. A distribution promise is only as good as the reporting behind it, so the platform needed source-level revenue reporting and reconciliation as a first-class function, not an afterthought.

Per-project vehicles on one platform. Each offering needs its own vehicle and its own register, but the operator wanted one onboarding flow, one portal, and one registry framework. The multi-asset SPV framework resolves this: project-level structures plug into shared platform infrastructure.

One framing point matters throughout: the instruments — IP-backed notes, royalty participation tokens, and revenue participation rights — give holders participation in defined revenue streams. Token holders do not acquire the underlying films, songs, or copyrights; creative control and the IP itself remain with the rights owners.

Jurisdiction and compliance constraints

The published structure is a multi-asset SPV framework serving professional investors across MENA and global jurisdictions — a pattern-level disclosure rather than a named regime, consistent with the mandate's confidentiality.

The compliance perimeter has four documented components: professional investor onboarding, rights assignment documentation, transfer controls with investor eligibility enforcement, and revenue reporting controls. Cross-border onboarding was itself a complexity driver — eligibility rules differ by investor jurisdiction and must be enforced in the registry and transfer logic, not just stated in offering documents.

As in every Asset Haus engagement, the securities characterization of each offering, the applicable exemptions, and the rights documentation are matters for qualified counsel in the relevant jurisdictions. Asset Haus provides the infrastructure and coordinates structuring; it does not act as legal counsel, broker-dealer, or placement agent.

Platform modules deployed

Seven modules make up the deployment, mapped to the platform's operating cycle:

  • Token Factory — configures and issues the IP-backed digital securities for each offering under the agreed rights tokenization terms.
  • Investor Portal — the branded front end (portal branding and setup were part of the deliverables) where investors subscribe, view holdings, and receive statements.
  • KYC/KYB — identity and entity verification supporting professional-investor eligibility checks across borders.
  • E-Sign — execution of subscription and rights documentation inside the onboarding flow.
  • Registry — the platform-level investor registry, with controlled per-offering registers beneath it.
  • Escrow Rails — controlled handling of subscription funds through the offering process.
  • Distribution Engine — scheduled revenue distributions to token holders under the configured distribution model.

Deliverables around the modules included the SPV framework, rights tokenization terms, the revenue distribution model, an investor reporting template, and the compliance and transfer-control configuration.

Investor and rights-holder workflow

On the rights-holder side, each offering begins with rights intake: asset and revenue-source diligence that produces an approved offering scope. Rights assignment documentation is completed, the vehicle is set up within the SPV framework, and the offering is configured from the platform's standing terms — the step that turns a repeat launch into configuration work rather than a new build.

On the investor side, professional investors onboard once through KYC/KYB and eligibility checks, execute documents via e-sign, and fund through the escrow rails. Their positions are recorded on the relevant offering register, and from that point they receive investor statements and scheduled distributions through the portal. Because onboarding and eligibility live at the platform level, an investor approved for one offering can be admitted to subsequent launches without repeating the full cycle, subject to the eligibility rules of each offering.

Registry, settlement, and reporting logic

The registry design is two-tier: a platform-level investor registry above controlled per-project registers, so each vehicle keeps a clean, auditable record of its own holders while the operator manages one investor base.

Revenue logic follows the documented workflow: source-level revenue reporting and reconciliation feed investor statements, and the distribution engine then executes scheduled payouts to token holders according to the distribution model. Reconciliation deliberately sits upstream of automation — distributions are calculated from reconciled figures, not raw source data.

Transfer controls complete the loop. Investor eligibility is enforced at the registry level on any transfer, keeping secondary movement within the professional-investor perimeter. These are controlled transfer workflows; nothing in the structure creates an open market or guarantees liquidity.

Outcome / current status

The engagement is in progress. The published status is deliberately limited: the platform infrastructure supports multiple rights-backed offerings, the distribution model runs on automated revenue workflows, and the mandate size remains undisclosed. No raise totals or per-offering results have been published, and the disclosure level is a public summary only. What the case already demonstrates is the pattern — a reusable rights-backed issuance and distribution stack rather than a one-off deal.

What operators can reuse

  • Separate the platform from the project. Build onboarding, registry, and distribution once at the platform level; let per-project SPVs and registers plug in. Repeat launches then become configuration, not construction.
  • Scope revenue rights precisely. Define exactly which streams token holders participate in, and document the rights chain that delivers them. Participation in defined revenue is not ownership of the underlying IP — say so plainly.
  • Treat royalty reconciliation as core infrastructure. Multi-source revenue reporting must be reconciled before the distribution engine runs; automated payouts built on unreconciled data just move errors faster.
  • Enforce eligibility in the registry, not just the documents. Professional-investor restrictions and transfer controls belong in the transfer logic itself, especially with cross-border investors.
  • Bring counsel in at rights intake. Rights assignment and offering characterization are jurisdiction-specific legal work; sequence qualified counsel before issuance, with the platform enforcing what the documents require.

Related resources

Modules Deployed

Token FactoryInvestor PortalKYC/KYBE-SignRegistryEscrow RailsDistribution Engine

Compliance

  • Professional investor onboarding
  • Rights assignment documentation
  • Transfer controls and investor eligibility
  • Revenue reporting controls

Deal Complexity

  • Rights catalog diligence
  • Multi-revenue source reporting
  • Cross-border investor onboarding
  • Entertainment IP controls

Deliverables

  • SPV framework
  • Rights tokenization terms
  • Revenue distribution model
  • Investor reporting template
  • Compliance and transfer-control configuration
  • Brand and investor portal setup

Have a Similar Deal?

Let's discuss how we can help structure your investment.

Apply this pattern

Use this as a platform-ownership pattern.

If your team needs tokenization infrastructure under its own brand, start with architecture, governance, registry, investor workflow, and transfer-control review.

Own the platformEmail the team