Skip to main content
Under CIP-104, app rewards are attributed to featured parties based on the network traffic generated by application workflows. For Registry transactions, such as mints, transfers, burns, and other asset lifecycle operations, rewards are earned by the featured party associated with each 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.
Once you have determined which featured party to use, you will need to configure the contractual reward share agreement. Only one party should be featured: either the registrar or the provider. To ensure Traffic-Based App Reward sharing for the featured party applies only to Registry workflows, isolate that party 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: Asset issuers who manage one or more instruments and do not require separate registrar parties for individual assets. For example, a 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 a single 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 because of compliance or operational security requirements, while still being treated as a single Asset Issuer by the Tokenomics Committee for 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 flexible and supports potential future requirements to split 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 separate Asset Issuers 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