Royalty & Revenue in Story Protocol

The blog will summarize the documentation for the royalty module on Story, a decentralized network for managing intellectual property (IP) assets. The module details how revenue flows between parent and child IP assets, including scenarios where revenue is generated through licensing and direct tipping. We’ll get into different royalty policies, including Liquid Absolute Percentage (LAP) and Liquid Relative Percentage (LRP), as well as external policies that users can create without the standard whitelisted structure. We will also touch upon the various configurations for derivative chains, including limitations on the number of ancestors and parents when under specific commercial and royal license policies.

Liquid Absolute Percentage vs Liquid Relative Percentage vs External Royalty solutions

Royalty policies are integral to the revenue-sharing process, outlining the specific rules for sharing revenue within a license agreement. These policies come in two forms: whitelisted or native policies (such as LAP and LRP), and external policies, which are fully customizable by users. These are pre-defined policies created and managed by the protocol. They require governance-led whitelisting to ensure the proper distribution of royalty tokens to ancestors. Governance will also play a pivotal role in selecting which ERC-20 tokens will be accepted as Royalty payments in revenue tokens. Bear in mind royalty policies are only to be implemented when the IP Asset is allowed to be commercially used. 

Liquid Absolute Percentage (LAP): In this policy, each parent IP Asset sets a minimum royalty percentage that all downstream IP Assets in the derivative chain must share. For example, if IP Asset 'C' is a derivative of 'B', which in turn is a derivative of 'A', 'A' will still be entitled to a share of 'C's revenue, as defined by the initial agreement between 'A' and 'B'.

Liquid Relative Percentage (LRP): This policy functions similarly to LAP but applies only to direct derivatives.For example in a derivative chain: A → B → C, 'A' would only receive a percentage of 'B's earnings, but not 'C's.

External Royalty Policies: These are customizable policies users create to implement unique royalty distribution rules. They can be registered without permission and have the flexibility to define their own logic for royalty calculations and distribution. This opens up possibilities for complex revenue-sharing models tailored to specific use cases. For instance, an external policy could grant discounts to certain users based on their contribution to the platform

Derivative Configuration

Every connection between an IP Asset and its derivatives is regulated by a single royalty policy. While IP Assets without parent relationships can mint licenses with a variety of royalty policies, derivative IP Assets automatically inherit the royalty policies of their parent assets. This allows for consistency across derivative chains. The derivative chains themselves can be configured in several ways, including binary trees or linear chains, with current limits allowing for up to 1024 ancestors and 8 parents per IP Asset. Importantly, the total royalty percentage for any asset is capped at 100%, preventing illogical revenue-sharing scenarios. "When IP is registered as a derivative of another, automatic royalty flow is created between the two assets. Royalty is defined in code as an ERC-20 token, where each token gives you rights to % royalty on that IP." -@StoryProtocol on X

When an IP Asset is initially registered on Story, users aren’t required to make immediate decisions regarding royalties. They can choose to mint licenses, link their asset to parent IPs, or take no action at all. Two key flows dictate how licensing and royalty sharing proceed:

1. Flow 1: If users mint a commercial license first, they can create an unlimited number of commercial licenses under any royalty policy, but they will not be able to link that asset to parents using commercial licenses. Non-commercial licenses remain separate and can still be minted.
2. Flow 2: If users link to parent IP Assets first, their asset inherits the royalty policies of its parent(s) and ancestors, allowing them to mint commercial licenses, but only under the inherited royalty policies.

A license minting fee is a one-time payment required when a new derivative IP Asset is created by minting a license from a parent IP Asset. This can be seen as the initial price for the right to create a derivative work, and it is mandatory whenever a new derivative is registered. The payment is processed through a dedicated function called payLicenseMintingFee, which emphasizes its specific role in the creation of derivative assets.

In contrast, other royalty payments refer to ongoing revenue that a derivative IP Asset generates, which is shared with its parent IP Assets according to the royalty policy in place. These payments can occur in various scenarios, such as:

• Direct tipping, where someone tips a derivative IP Asset as a show of appreciation for the content.
• Sales revenue, such as when a derivative IP Asset generates income through the sale of a product, with a portion of that revenue shared with the parent IP Asset. These payments are made via the payRoyaltyOnBehalf function, which covers a wider range of royalty distributions beyond just license minting fees.

Both license minting fees and royalty payments follow the same royalty policy that governs the relationship between parent and derivative IP Assets. The only difference lies in the trigger and purpose of the payment: one is for creating new derivatives, and the other is for ongoing revenue generated by those derivatives.

For example, if IP Asset 'C' wants to create a derivative of IP Asset 'B', and 'B' has a 10% royalty share using the LAP policy, 'C' would pay a 100 USDC license minting fee, with 10 USDC (10%) going to 'B’s parent (if applicable) and 90 USDC staying with 'B'. If someone later tips 'C' 50 USDC for their work, 5 USDC (10%) would go to 'B’s parent, and the remaining 45 USDC would stay with 'B'.

IP Royalty Vault

The IP Royalty Vault serves as a pool for all revenue associated with an IP Asset. Each vault has an associated ERC-20 token called a Royalty Token. When payments flow into a vault, they are initially considered "pending." The snapshot function is then called to finalize the distribution of these pending funds. This function records the percentage of Royalty Tokens held by each address at the time of the snapshot. This snapshot creates a record of how the revenue should be split proportionally among Royalty Token holders. The snapshot function is not automatically triggered with each payment to reduce gas costs; therefore, users need to be holding the Royalty Tokens when the snapshot is called to be eligible to claim their share of the pending value. Outflows from the vault happen when Royalty Token holders claim their share of the revenue. This is done through specific functions like claimRevenueByTokenBatch, claimRevenueBySnapshotBatch, claimRevenueByTokenBatchAsSelf, or claimRevenueBySnapshotBatchAsSelf, depending on whether the claim is made by a regular address or an IP Royalty Vault

Conclusion

The Royalty Module in Story Protocol is designed to ensure that creators and IP holders are fairly compensated throughout the lifecycle of their IP assets. By utilizing a blend of whitelisted royalty policies, customizable external policies, and an automated IP Royalty Vault system, Story Protocol provides a seamless and efficient way to manage IP revenue in the decentralized world.

Have thoughts or feedback? Join Chainflow on Discord or follow us on Twitter/X!