Shared Ownership of Creative IP

What the asset has to do

A collective produces something — a character, a story, a world. That output needs an on-chain representation that supports four things at once:

Proportional ownership of the IP, allocated by the attribution mechanism.
Governance over what happens to it — licensing terms, treasury, versioning, further issuance.
Revenue claims against any monetisation, including monetisation of derivative work.
An incentive surface for bringing in outside help without diluting creative control.

Those last two are in tension with the second, and resolving that tension is most of the design.

Structure

Two token types, one asset

Governance rights and economic rights travel together by default in most designs. Separating them is what makes generous reward compatible with coherent creative direction.

Voting and non-voting

Content tokens are ERC-1155, minted per piece of IP, in two classes sharing one asset.

	Voting	Non-voting
Economic rights	Yes — proportional revenue claim	Yes — proportional revenue claim
Governance rights	Yes — licensing, treasury, versioning, minting	No
Typical holder	Core creators of the work	Fans, bounty contributors, promotional collaborators

The reason to split is a problem every collective hits. Communities want to reward participation generously, and they want decisions made by the people accountable for the creative work. If reward and control are the same instrument, every act of generosity is a transfer of authority, and collectives respond by being stingy.

Consequence worth noting. Non-voting holders have money at stake and no vote. That is a legitimate governance grievance, and the honest defence is that the alternative — no economic participation at all — is worse for them. It is a trade-off, not a free lunch.

Revenue and derivatives

Revenue from any source — licensing, merchandise, advertising, derivative works — accrues to holders proportionally, net of an ecosystem tax:

r_i = \frac{h_i}{\sum_j h_j} \cdot (1 - \tau)\, V

Derivative agreements route a royalty upstream automatically, so remixed work continues to pay the original:

V_{\text{parent}} \mathrel{+}= \lambda \, V_{\text{derivative}}

The ecosystem tax $au$ is what connects an individual asset's success to the value of the network as a whole. Without it, the network token is a loyalty point; with it, it is a claim on aggregate economic activity.

The collective's wallet

Each collective gets a smart wallet bound irreversibly to its content token — a token-bound account (ERC-6551), where the account belongs to the asset rather than to a person. Revenue lands there, the collective governs it, and control migrates from the founding lead to the holders over time.

One consequence found late in implementation: these accounts are not upgradeable by design. Making them upgradeable means deviating from the standard, which costs you the audit surface of widely-reviewed public code and composability with future integrations. We stayed compliant and planned account migrations instead of upgrades. I still think that was right, and it cost real work.

Constraint

Why pooling exists

The least obvious part of the architecture, and the one I would most want another designer to take away. Pooling was not an economic optimisation. It was a securities constraint.

The concentration problem

A token whose value derives predominantly from the efforts of a single identifiable entity looks, to a US regulator, like a security. As a working heuristic during design we treated concentration above roughly half of a token's value from one entity as the danger zone, and applied it at every level of the asset cascade — content tokens, pool stakes, network token alike:

\max_{e \in \mathcal{E}} \; \frac{V_e}{\sum_{e'} V_{e'}} \; < \; \tfrac{1}{2}

For a single piece of IP licensed to one commercial partner under an agreement promising regular future payments, that condition fails immediately. The holder's return depends on one counterparty's ongoing efforts. That is close to the textbook shape of an investment contract.

Diversification as a design response

There are two ways out, and we specified both.

Structure the agreement. A single lump-sum licence settled upfront does not create an ongoing dependence on the licensee's efforts. Recurring payments from one entity do. The commercial terms are part of the token design, which is not where most teams look for them.

Diversify the revenue. Pool many assets so that the claim is against a basket, with many licensees on the demand side and many creators on the supply side. No single entity drives the value, and the concentration condition holds by construction.

This is why the general pool exists at all, and why a claim on it can become transferable earlier than a claim on one asset. The pooling architecture is a legal mechanism wearing an economic costume.

It has follow-on consequences. If any asset can join any pool, the dominant strategy is to join all of them and maximise expected fee income, which is a spam problem. So allocation was made exclusive — an asset sits in the general pool or its own specialised pool, not both — and entry requires staking the asset rather than passing a governance vote, so admission carries skin in the game rather than relying on discretionary approval that would itself be a centralisation point.

Terminology is part of the design

One durable lesson. Early in the work, counsel had every use of the word "share" removed from all documentation in favour of "stake". Nothing about the mechanism changed. The concern was that the vocabulary a system is described in becomes evidence about what it is.

Naming is not decoration in this domain. It is part of the artefact, and it is cheaper to get right at specification time than after it appears in a whitepaper, a UI, and a year of public communication.