Configure a Featured Party
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.
Guidelines for featured parties
Use only one featured party for Registry workflows
Only one party should be featured: either the registrar or the provider.Isolate featured parties
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
- Onboard registrars to the Registry App according to predefined criteria
- Wallets
- DEXs
- Market makers
- Lending protocols
- Payment processors
- Other fee-generating application functions
Recommended setup examples
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- 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.
- Organizations that require separate Traffic-Based App Reward sharing agreements for individual assets.
- One unfeatured provider party
- One featured registrar party per issuer
- Configure a static Traffic-Based App Reward sharing agreement for each featured registrar