⏩

Skip the Read - 1 Minute Summary

The Royalty Module allows you to have automatic revenue flow between an IP Asset and its ancestors.

There are two common ways revenue flow happens:

1. Minting a License. An IP Asset ("C") mints a license from a parent ("B") that costs 100 USDC. B is a child of A, such that it goes A▶️B▶️C. A specifies that any descendant must share 5% of its revenue. Because C is a descendant of A, when C goes to pay B 100 USDC to mint a license, 5 USDC gets sent directly to A such that B only gets 95 USDC.
2. Tipping Directly. An IP Asset ("B") represents a comic book story about an Azuki character named John. B shares 5% of its revenue with its parent IP Asset ("A") - which represents the Azuki character John itself - due to a license agreement they made when A allowed B to use its character. Someone tips 100 USDC to the comic book ("B") for being very well written. 5 USDC automatically gets shared with A.

The Royalty Module defines the logic through which multiple participants in a derivative chain share capital with their ancestors. The main high-level components are:

• Derivative chain - how the different IP Assets are connected and establish parent/derivative relationships between them
• Royalty policy - each royalty policy has a set of rules through which IP Assets share value. The current existing royalty policy is called "Liquid Absolute Percentage." In the future, different royalty policies can be whitelisted by protocol governance and added to the existing royalty module

Royalty Policy - Liquid Absolute Percentage

Royalty policies are defined as a component of the license agreement between two IP Assets. An IP Asset without any parents can mint licenses with different royalty policies while a derivative IP Asset inherits the royalty policy of its parents

The Liquid Absolute Percentage (LAP) royalty policy defines that each parent IP Asset can choose a minimum royalty percentage that all of its downstream IP Assets in a derivative chain will share from their monetary gains as defined in the license agreement.

LAP Terminology

There are a few terms:

1. IP Royalty Vault - Each IP Asset has an IP Royalty Vault, which acts as a pool for all monetary inflows related to an IP Asset's commercial exploration or from minting licenses. Each royalty token holder has the right to claim their share of that pool.
2. Royalty Tokens (RT) - the IP Royalty Vault contract is also the ERC-20 contract for the RTs of each IP Asset. Each IP Asset has 100,000,000 RTs associated, where each token represents 0.000001% of those gains. The holders of these RTs can claim the Revenue Tokens (defined below) that are in the associated IP Royalty Vault.
3. Revenue Tokens - these are the tokens that are actually used for payment (ex. ETH, USDC, etc). Royalty Tokens can be used to claim the revenue tokens.

🪙

Whitelisted Revenue Tokens

At the moment, a token must be whitelisted by Story Protocol to be used in the royalty module.

This is the only whitelisted token right now on Sepolia testnet. You can mint tokens directly from that link.

4. Royalty Stack - the number of RTs that each IP Asset reserves for all its ancestors:
   1. IPA 1 as root reserves 0 RT1 since it does not have any ancestors | Royalty Stack = 0%
   2. IPA 2 reserves 5% RT2 to IPA 1 | Royalty Stack = 5%
   3. IPA 3 reserves 5% RT3 to IPA 1 and 5% RT3 to IPA 2 | Royalty Stack = 10%
   4. IPA 4 reserves 5% RT4 to IPA 1 and 10% RT4 to IPA 2 | | Royalty Stack = 15%

Derivative chain configurations

The derivative chain can assume multiple configurations. Derivatives, due to gas costs on Sepolia, can have a maximum of 2 parents and 14 ancestors equivalent to 3 levels of a binary tree where 2+4+8=14. Note that this is why we are building Story Network, "The World's IP Blockchain", which will solve many of these limitations and be available for public testnet soon. A few currently possible configurations (given the restraints) are explained below:

• Configuration 1: shows the 3-level binary tree with each derivative always having 2 parents
• Configuration 2: shows a configuration of 14 ancestors where each derivative has 1 parent
• Configuration 3: shows a configuration where IPA 4 is a derivative of its parent (IPA 5) and its parent's parent (IPA 6) to showcase that it is a valid configuration

Multiple other configurations are valid in addition to the ones above, which are meant just to showcase a few examples of what is possible.

The IP graph with LAP royalty policy is restricted to a royalty stack of 100%. It will revert when minting a license that would make the royalty stack go higher than 100%.

Licensing and LAP Royalty Flow Key Moments

• Registering an IP Asset on the platform: when registering a new IP Asset the user does not need to make any royalty-related decision. After registration, the user is free to (i) mint a license, (ii) link to parents, or (iii) do nothing.
• After IP Asset registration
  • Flow 1: The user decides to mint a commercial license first
    • By doing so: The user gains the right to mint as many commercial licenses as it wants of any royalty policy in the future in exchange for not being able to link to parents via commercial licenses
    • Non-commercial licenses are independent of commercial ones and can always be minted and used to link to parents by any IPA asset
  • Flow 2: The user decides to link an IPA to the parents' first
    • By doing so: The IPA inherits the same royalty policy of its parents as well as their ancestors and the royalty stack
    • The user can mint as many commercial licenses as it wants as long as they belong to the same royalty policy as its parent IPAs

LAP Royalty Payment and Claiming Flow

The first step to being able to claim royalty revenue is to obtain royalty tokens from the IP that will receive them in the future. There are 3 ways to obtain royalty tokens of a given IP:

• Be the IPA creator: the IPA creator receives 100%-Royalty Stack % of the IPA royalty token supply in its IPA address
• Own an IPA that is an ancestor of the IPA that receives revenue: the ancestor IPA has the right to claim a % of the royalty tokens of a derivate IPA
• Buy royalty tokens in the market: in case the royalty tokens are in the market anyone can buy them

Once any address owns royalty tokens of a given IP it is entitled to its pro-rata share (% of the total supply of royalty tokens owned) of any future revenue token (that is whitelisted in the RoyaltyModule.sol contract inflow to that IP.

In the image below, IPA 1 and IPA 2 - due to being ancestors of IPA 4 - call collectRoyaltyTokens to get their 5% and 10% of RT4 supply, respectively. Note that, even if IPA 1 and IPA 2 do not collect the RT4 before a revenue token payment is made, those revenue tokens will not be lost and will be reserved in the IpRoyaltyVault for IPA 1 and IPA 2 until collectRoyaltyTokens is called.

Now, let's imagine a scenario where a new IP Asset 5 intends to join the derivative chain as a derivative of IP Asset 4. An example flow sequence below:

1. IP Asset 5 pays 1M USDC in royalties to its parent IPA 4 by calling payRoyaltyOnBehalf. Note that the royalty process is the same whether the payment is the license minting fee or any other royalty payment - with the difference being that the license minting fee is made via payLicenseMintingFee and is mandatory upon derivative creation.

2. Any address can call snapshot in the IpRoyaltyVault 4 contract. The snapshot function saves how much percentage of RT4 each token holder had at the snapshot moment. These percentages allow for splitting the 1M USDC paid in royalties among each RT4 holder. Note that snapshot does not need to be called on every payment - there can be multiple payments accumulated between each snapshot call. There is a minimum time interval between snapshots to contain the number of snapshots for gas-related reasons.
3. The RT holder address can call claimRevenueByTokenBatch and claimRevenueBySnapshotBatch to claim revenue tokens. In the current example:
   • 50k USDC are claimed to the IPA 1 which holds 5% RT4
   • 100k USDC are claimed to the IPA 2 which holds 10% RT4
   • 850k USDC are claimed by IPAsset 4 which holds 85% RT4

Note: Any RT4 holder can claim - whether it is a smart contract, IPA, or EOA.