The royalty module defines the logic through which the 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
- The 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

Royalty Policy - LAP

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 Main components

To understand the LAP royalty policy - using the diagram above as reference - the main components to highlight are:

IP Asset (IPA) - an entity that from the perspective of the royalty policy can be considered a:
1. Root: an IP Asset that has no parents -> IPA 1 is a root
2. Derivative: an IP Asset that has parents and/or ancestors -> IPAs 2, 3, and 4 are derivatives
3. Parent: the IP Asset from which a derivative has a direct license agreement within the derivative chain -> IPA 1 is the parent of IPA 2 and IPA 2 is the parent of IPAs 3 and 4.
4. Ancestor: all the IP Assets that precede another IP Asset in a derivative chain including the parents -> IPA 1 is an ancestor of IPAs 2, 3, and 4.
IP Royalty Vault - Each IP Asset has an IP Royalty Vault. Monetary inflows related to an IP Asset commercial exploration or from minting licenses flow to the IP Royalty Vault. Each royalty token holder has the right to claim their share of those monetary inflows.
Royalty Tokens (RT) - the IP Royalty Vault contract is also the ERC-20 contract for the RT of each IP Asset. Each IP Asset has 100,000,000 royalty tokens associated, where each token represents 0.000001% of those gains. The holders of these RTs can claim revenue tokens that are in the associated IP Royalty Vault. Each RT represents the right to claim a certain % of those gains.
License minimum royalty percentage (%) - the minimum amount of RTs that the owner of the IPA demands from all its derivatives -> IPA 1 has the right to claim 5% of the total supply of RT2, RT3, and RT4.
There is a special case in which if a new IP Asset 5 joined the derivative chain with both IPAs 3 and 4 as parents, then IPA 1 would have the right to claim 10% of the total supply of RT5 given that IPA 1 is an ancestor of both IPAs 3 and 4. That is why the royalty percentage is said to be a minimum percentage as it can be higher if an IPA is a common ancestor of both parents of a new derivative.
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. Any IP Asset can have infinite derivatives. Derivatives, due to gas costs, can have a maximum of 2 parents and 14 ancestors equivalent to 3 levels of a binary tree where 2+4+8=14. A few possible configurations 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 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:

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.

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.
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.