Traffic-Based App Rewards

​

Overview

​

Why Traffic-Based Rewards

• Misalignment with actual costs: activity markers did not correlate directly with the traffic burned by an application, leading to discrepancies between claimed and actual network usage.
• Governance burden: assessing and governing activity markers was complex and time-consuming, creating pressure to centralize governance decisions.
• Performance impact: creating markers involved the DSO party in every transaction, increasing transaction size and reducing throughput available for economically useful activity.

​

Comparison with Featured App Activity Markers

​

Splice.Amulet.RewardCouponV2

• Time-based expiry: coupons expire after a configurable TTL (rewardCouponTimeToLive), rather than being tied to round lifecycle. This allows beneficiaries to batch minting to save traffic costs.
• One per party per round: instead of one coupon per transaction, there is one coupon per eligible party per round.
• Beneficiary assignment: coupons support an optional beneficiary field for reward sharing. The provider can assign beneficiaries to share rewards before minting.

​

Fields

​

Minting

1. Automated minting via the Splice Wallet backend that is part of the validator app. For onboarded internal parties, the CollectRewardsAndMergeAmuletsTrigger polls for eligible coupons and submits the consuming transfer. For external parties with an active minting delegation, MintingDelegationCollectRewardsTrigger does the same, acting as the delegate on the external party’s behalf. To confirm a coupon was minted, check the party’s transaction history, where it is counted as app rewards. See Wallet Automation.
2. Direct minting by constructing calls to AmuletRules_Transfer that use the coupon as a transfer input. These calls can be made directly against the Ledger API, or indirectly via custom Daml code deployed to the validator node.

​

How It Works

1. The Scan app ingests traffic summaries from the sequencer alongside mediator verdicts. For each transaction, it computes per-party app activity weights — the sum of traffic costs for all transactions where a party was a featured app provider in a given round. When a round closes, the Scan app aggregates activity weights into per-party reward totals, applies the minting allowance threshold defined in RewardConfig, and builds a Merkle tree commitment of this round’s app reward minting allowances.
2. The SV app drives the on-ledger creation of Splice.Amulet.RewardCouponV2 contracts based on the data computed by Scan. The CalculateRewardsTrigger reads the Merkle tree root hash from Scan and confirms it on-ledger via the action-requiring-confirmation workflow. Once a supermajority of SVs agree on the root hash, a Splice.Amulet.RewardAccountingV2.ProcessRewardsV2 contract is created. The ProcessRewardsTrigger then expands the tree by reading batches from Scan, creating Splice.Amulet.RewardCouponV2 contracts for each eligible party at the leaf nodes.

​

Reward computation formula

total_featured_app_burn_CC = (total_featured_app_traffic / 1,000,000) * traffic_price_in_CC_per_MB

per_app_minting_allowance0 =
  (total_app_traffic / 1,000,000) * traffic_price_in_CC_per_MB * issuance_per_featured_app_weight

per_app_minting_allowance =
  if per_app_minting_allowance0 >= app_reward_coupon_threshold_CC
    then per_app_minting_allowance0
    else 0

• total_app_traffic is the sum of a party’s activity record weights for the round (in bytes) — see Splitting Total User Burn for how traffic is attributed across apps when multiple app confirmers share a confirmation request.
• traffic_price_in_CC_per_MB is extraTrafficPrice (see Synchronizer Traffic) converted to CC at the round’s amuletPrice.
• issuance_per_featured_app_weight is the CC minted per CC of featured app burn in the round: the round’s app reward tranche divided by total_featured_app_burn_CC, capped at featuredAppRewardCap (see Issuance Curve and Minting Schedule).
• app_reward_coupon_threshold_CC is appRewardCouponThreshold (from RewardConfig below) converted to CC at the round’s conversion rate. A party whose allowance falls below it gets no coupon for that round; the reward is burned, not carried forward.

​

Activation

​

RewardConfig

​

Further Reading

• CIP-0104 specification
• Reward Sharing — sharing rewards with beneficiaries
• Minting Delegations — delegating minting authority for external parties
• App Rewards — overview of the app rewards system including featured app status