Royalty (Module)

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:

  1. 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 and IPA 2 are the ancestors of IPAs 3 and 4.
  2. Royalty NFTs (RNFTs) - each IP Asset has an IP pool that has 1000 ERC-1155 royalty NFTs associated. The holders of these RNFTs can claim tokens that are in the associated IP pool. Each RNFT represents the right to claim 0.1% of those gains.
  3. License minimum royalty percentage (%) - the minimum amount of RNFTs that the owner of the IPA wants from all its derivatives -> IPA 1 has the right to claim 50 tokens (5% of total supply) of RNFT2, RNFT3, and RNFT4.
    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 100 RNFT5 (10% of total supply) 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.
  4. Royalty Stack - the number of RNFTs that each IP Asset reserves for all its ancestors:
    1. IPA 1 as root reserves 0 RNFT1 since it does not have any ancestors
    2. IPA 2 reserves 50 RNFT2 to IPA 1
    3. IPA 3 reserves 50 RNFT3 to IPA 1 and 50 RNFT3 to IPA 2
    4. IPA 4 reserves 50 RNFT4 to IPA 1 and 100 RNFT4 to IPA 2
  5. IP Pool - Each IP Asset has an IP pool. Monetary inflows related to an IP Asset commercial exploration and/or from minting licenses flow to the IP pool. Each RNFT holder has the right to claim their share of those monetary inflows.
    The IP pool contract is also the ERC-1155 RNFT contract for each IP Asset.
  6. Ancestors Vault - Each IP Asset except any root IPA has an ancestors vault. When a derivative IP Asset is created, the ancestors vault is deployed and it receives a number of RNFTs equal to its royalty stack:
    1. Ancestors Vault 2 receives 50 RNFT2
    2. Ancestors Vault 3 receives 100 RNFT3
    3. Ancestors Vault 4 receives 150 RNFT4

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 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 mint a license, link to parents, or 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

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. IPAs 1 and 2 as ancestors of IPA 4 claim their share of RNFT4 which is reserved for them in the ancestors vault via claimFromAncestorsVault. IPAs 1 and 2 can claim at any time. Any royalty value accrued before the RNFT4 is claimed remains in the ancestors vault reserved for IPAs 1 and 2 to claim later. Each ancestor only needs to claim once on a derivative ancestors vault to obtain the RNFTs. After obtaining the RNFTs the user can start claiming directly from the IP pool.

  1. A new IPA Asset 5 mints a license from IPA 4 and pays 1M USDC as a license minting fee to IP Pool 4.

  1. Any address can call distributeIpPoolFunds which will take a snapshot of each RNFT4 holder and send the tokens to Split Main. Split Main is a contract deployed by an underlying splitting tool being used called 0xSplits and there is one such contract per chain (0xSplits documentation link in "Additional Resources" section at the end).

  1. Any address can call claimFromIpPool on behalf of an RNFT4 holder. It will transfer any accumulated balance to the said RNFT4 holder address:
    1. 50k USDC are claimed to the IP pool 1 which holds 50 RNFT4
    2. 100k USDC are claimed to the IP pool 2 which holds 100 RNFT4
    3. 850k USDC are claimed by the third RNFT4 holder which in the picture happens to be the address of the IP Asset 4 but could also be any contract or EOA

Note: in the example above there are 850 RNFT4 in circulation that can be bought or sold in the market while 150 RNFT4 will always remain in their ancestors' IP pools and not in circulation. The value these 150 RNFT4 represent is therefore included in their ancestors' RNFTs - RNFT1 and RNFT2.

Full flow overview:

For additional context, we can refer to the difference between 100% and the cumulative royalty stack of each IPAsset as the RNFT circulating supply percentage which by IPAsset is:

  • RNFT1 circulating supply = 100%
  • RNFT2 circulating supply = 95%
  • RNFT3 circulating supply = 90%
  • RNFT4 circulating supply = 85%

After the 1st distribution, a second distribution can be triggered which will distribute the remaining 100k USDC that went to IP Pool 2.

So please note that the owner of IPAsset 2 - which happens to control 95% of the RNFT2 - ends up receiving - out of the 1M USDC payment shown in the image:

  • 95k = 1M USDC x 10% (royalty percentage of the license between IPA2-IPA4) x 95% (percentage of RNFT2 the owner controls)

As for the owner of IPAsset 1 - which happens to control 100% of the RNFT1 - ends up receiving:

  • 55k = 1M USDC x [5% (royalty percentage of the license between IPA1-IPA4) + 5% (royalty percentage of the license between IPA1-IPA2)] x 100% (percentage of RNFT1 the owner controls)

So when selecting a royalty percentage that your IPAsset will demand from future derivatives please consider that you may not own all the RNFT of your newly created IPAsset and adjust the said royalty percentage accordingly.

Note: The logic above may be adjusted after the beta version.

EthDenver BUILDLathon - Claiming Process

Specifically for the EthDenver BUILDLathon - will be sharing below the steps that allow claiming via Etherscan. In the future, there are plans for the SDK to support royalty claiming so the instructions below will be temporary.

  • Step 1: Determine which IPAsset to claim royalties for and find it in the dashboard

  • Step 2: Claim from RNFT from the ancestors vault on Etherscan - can find the ancestors vault address here:

  • Step 3 - If no holder owns all 1000 RNFTs then:

    • Step 3.1 - Call distributeFunds on the split clone address mentioned in the image above - in this case the address - "0x3723d82ed518c4354e3275bb09b92511bfb2e2fd". For the input "accounts" in the function distributeFunds can copy the array "NFT Holder array" from the image above - in this case - [0xb69d3277be50b0b851695bc010131a83933132db,0xd1c26a88acb4b41e9b84577065c7110c4ea7c4c8] and paste the array on Etherscan.
    • Step 3.2 - Call claimFromIpPool on the RoyaltyLAP.sol to claim the royalties.
  • Step 3 - If there is one holder that owns all 1000 RNFTs (see image below) then:

    • Step 3.1 - Call claimFromIpPoolAsTotalRnftOwner on the RoyaltyLAP.sol to claim the royalties.

Additional resources

0xSplits documentation -