Documentation/DamlView on Daml ↗
Daml

Reward share agreement

Use the following steps for each featured Registry party (provider or registrar) you control.
1

Determine the Digital Asset Accounting Party

Identify the Digital Asset accounting party that should receive the contractual reward share for the featured party.Before proceeding, confirm:
  • the correct DA accounting party identifier
  • the expected reward share split defined in your commercial agreement
2

Set up Reward Sharing via your hosting validator node

The validator app hosting your featured party can be configured to automatically share Traffic-Based App Rewards with a set of beneficiaries, including the DA accounting party.The setup is documented in the splice docs.

Example configuration

Use this as an illustrative template for a featured party reward-sharing setup. Replace placeholder values with your actual party IDs, the DA accounting party, and commercial split.
- name: ADDITIONAL_CONFIG_REWARDSHARING
        value: |
            canton.validator-apps.validator_backend {
                reward-sharing-config-by-party = {
                    "issuer::1220f3459220955drb1e272c7a1e26b4525645636346641fff8210e3835c99e684638dafd" = {
                        min-ttl-after-sharing = 35h
                        beneficiaries = [
                            {beneficiary = "auth0_007c67dc7c4afbf5bc37f9805e31::12205bcc106efa0eaa7f18dc491e5c6f5fb9b0cc68dc110ae66f4ed6467475d7c78e", percentage = 0.2 },
                        ]
                    }
                }
            }
3

If using an External Party, sign the required delegation contract

If your featured party is an external party, you will need to additionally sign a delegation contract to allow your validator operator to perform minting and reward sharing on the featured party’s behalf.

​
Background information

The DA Registry App enables users to tokenize and manage assets on the Canton Network. As part of the service, the Registry App currently generates Featured App Activity Markers through automation to create activity-based rewards for asset tokenizers in accordance with the current tokenomics guidelines. With CIP-0104: Traffic-Based App Rewards, the mechanism for app rewards will fundamentally change. App rewards will no longer be generated by explicitly setting activity markers. Instead, rewards will be derived directly from measured transaction traffic processed by the network. This transition improves the incentive model by:
  • aligning incentives with productive network usage
  • rewarding applications proportionally to actual network burn generated
  • reducing transaction size and validator workload
  • increasing Global Synchronizer throughput
  • eliminating marker-based reward farming and reducing the governance overhead
Moving to this model requires changes to how Registry App users structure featured parties and reward-sharing setups in order to:
  • generate rewards
  • comply with the updated tokenomics guidelines
  • maintain existing reward-sharing agreements with Digital Asset and other partners

​
Current Registry App Setup

The Registry Utility onboards asset tokenizers with the provider role. Providers can onboard other parties with the registrar role. Registrars can create instruments and manage minting and burning workflows. In token-standard terminology, the registrar acts as the token administrator for an instrument. This setup allows issuers and tokenisation providers to onboard dedicated registrar parties to the registry app while operating shared provider infrastructure. For instruments where the provider party is featured, an operator automation currently creates activity markers for Registry transactions. The corresponding rewards can then be shared:
  • with Digital Asset according to the commercial agreement
  • optionally with additional beneficiaries configured by the provider

​
What Changes with CIP-0104

​
Change in Reward Mechanism

Featured App Activity Markers can no longer be used to mint AppRewardCoupons. Instead, featured parties accrue app reward weight for a transaction based on:
  • the transaction’s total traffic cost
  • the size of transaction envelopes for which the featured party is a view confirmer
The effective reward attribution therefore depends on:
  • how much “traffic” a featured party confirms
  • how many other featured parties participate in the transaction
When multiple featured parties confirm parts of the same transaction, the traffic weight is distributed among them. For Registry App users, this represents a major shift from: “one marker per transaction” to: “traffic-weight-based rewards proportional to confirmed transaction traffic”. Monitoring of traffic-weight metrics already available through the Scan API shows a positive expected economic impact for asset issuers, since a significant portion of network activity is based on asset transactions where their parties play a key confirming role. See CIP-104 Guidance for reference.

​
Reward Share Agreements

On-ledger reward-sharing mechanisms based on activity markers are no longer available. That means the current Registry functionality that allows configuring multiple reward beneficiaries per instrument will no longer exist in its current form. To maintain the existing contractual reward-sharing agreement with Digital Asset, Registry users will need to configure automatic sharing of Traffic-Based App Rewards for any featured Registry party (provider or registrar) on a validator node hosting their featured Registry party. This functionality is part of the Splice 0.6.8 release.

​
Required contractual amendment

To align the contractual terminology with CIP-0104, a small amendment to the existing agreement will be required. The amendment will replace references to: marker-based reward sharing with traffic-based app reward share agreement per party. Separate communication regarding the contractual update will follow in the coming weeks.