CIP-0104 Traffic-Based App Rewards Marked Approved as Canton Foundation Merges Document Update
An update to the CIP-0104 text was merged on 27 October 2026. The document now lists the tokenomics proposal as approved that day, replacing featured app markers with traffic-based reward accounting.
A pull request updating the text of CIP-0104, the Canton Improvement Proposal titled "Traffic-Based App Rewards", was opened in the canton-foundation/cips repository on 27 October 2026 by GitHub user pedrodneves. It was merged into the repository as a commit at 13:56 UTC the same day. The commit is signed off from a canton.foundation email address.
The version of the document now on the main branch lists the proposal's status as Approved, with an approval date of 27 October 2026. The CIP, authored by Simon Meier and created on 29 January 2026, is classified as a Tokenomics proposal covering the Canton and Daml layers. Its post history references both the original discussion and a later amendment thread.
From markers to measured traffic
According to its abstract, CIP-0104 removes featured app markers and instead bases an app's rewards on the actual traffic spent on (sub-)transactions that change the state managed by that app. Traffic is measured directly on the Global Synchronizer using only sequencer and mediator data.
The document says this removes the need for app builders to create FeaturedAppActivityMarker contracts "in all the right places". The Daml code for splice-amulet is changed so that neither FeaturedAppActivityMarker nor AppRewardCoupon contracts are created anymore. Activity records are instead ingested by the SV app from mediator verdicts and from a new sequencer traffic scan API. The computations implement the Featured App Guidance v2.0b, according to the text.
The CIP also proposes making protocol-conformant confirmation responses free, so that validator nodes pay only for submitting transactions on behalf of their users. It further proposes not using the DSO party by default in app transactions, which the document says reduces transaction size and avoids extra validation work for SV nodes. Activity records from a confirmation request are assigned to the earliest mining round open at the time the request was sequenced.
Key parameters in the approved text
The specification sets out several configuration changes:
- Featured app reward cap: set to 0.79, allowing minting of at most 79 cents for every $1 of burn.
- App category metadata: each featured app right carries one of three categories: basic featured app (the default), featured asset-moving app, or featured asset.
- Operations parties: apps can list extra parties that submit transactions in their name. The SV app checks that these are distinct across featured apps.
- App composition weight: defaults to 1.0 and is used when splitting extra burn among featured assets.
- extraFeaturedAssetsActivityWeight: default 0.2, the extra activity weight shared among featured assets used in transactions submitted by asset-moving apps.
