Skip to main content
Under CIP-104, app rewards are attributed to featured parties based on network traffic generated by application workflows. For Registry transactions, such as mint, transfers, burns, and other asset lifecycle operations, rewards are earned by the featured party associated with the workflow. To earn Traffic-Based App Rewards, one of the following parties must be featured:
  • Provider party
  • Registrar party
The featured party that earns app rewards for Registry transactions is considered the Asset Issuer for the purposes of CIP-116 locking requirements, regardless of the legal structure of the deployment or whether the controlling entity acts as an issuer, registrar, custodian, or technology provider. Use Only One Featured Confirming Party for Registry Workflows For Registry workflows, only one of the following parties should be featured:
  • the provider party, or
  • the registrar party.
Isolation of Featured parties

In order to ensure the sharing of Traffic-Based App Rewards for the featured party only relates to registry workflows, the party should be isolated from unrelated operational workflows as much as possible. The registrar party should primarily:
  • maintain records of ownership
  • maintain minting, burning, and transfer criteria for asset tokens
The provider party should primarily:
  • Onboard registrars to the Registry App according to predefined criteria
Other operational functions should use separate parties wherever possible, including:
  • Wallets
  • DEXs
  • market makers
  • lending protocols
  • payment processors
  • other fee-generating application functions
Your featured Registry party (provider or registrar) should not also be used for unrelated application workflows.

​
Example 1: Asset Issuer with Single Registry Infrastructure

Recommended for
An asset issuer who manages one or multiple instruments and does not require separate registrar parties for individual assets. A good example is the CSD with many CUSIPs or a custodian with many different assets under custody. Why choose this setup?
This is the simplest operational model. It minimizes party management while allowing all Registry workflows to share the same registrar. Recommended setup
  • One provider party
  • One registrar party shared across all instruments
  • Separate provider and registrar parties
  • Either the provider or the registrar should be featured

​
Example 2: Asset Issuer with Segregated Registrars

Recommended for
Asset issuers that require separate registrar parties for individual instruments due to compliance or operational security requirements, while being treated as a single Asset Issuer by the Tokenomics Committee for the purposes of featured-party eligibility and locking requirements. Why choose this setup?
This allows each instrument to have its own registrar while minimizing the number of featured parties, keeping reward attribution straightforward, and maintaining a single featured Asset Issuer party under the provider. This setup is also most flexible and supports potential future requirements to split out the different featured parties (see example 3). Recommended setup
  • One featured provider party
  • Multiple unfeatured registrar parties, one per instrument or use case

​
Example 3: Tokenization Provider Supporting Multiple Issuers with respective reward share agreements

Recommended for
  1. Tokenization providers that onboard multiple independent asset issuers, where each issuer is considered a separate Asset Issuer by the Tokenomics Committee for the purposes of featured-party eligibility and locking requirements.
  2. Organizations that require separate Traffic-Based App Reward sharing agreements for individual assets.
Why choose this setup?
This setup allows separate commercial agreements or separate reward accounting for individual assets or issuers. It aligns with the Tokenomics Committee’s treatment of a separate Asset Issuer for featured-party eligibility and locking requirements. Recommended setup
  • One unfeatured provider party
  • One featured registrar party per issuer
  • Configure a static Traffic-Based App Reward sharing agreement for each featured registrar