CIP-0104 Switching to Traffic-Based App Rewards -- Simon Meier
- Dear community,please find attached a proposal for improving the quality of the app reward incentives by removing featured app markers and instead basing an app’s rewards on the actual traffic spent on (sub-)transactions that change the state managed by the app.You can find the corresponding PR here: https://github.com/canton-foundation/cips/pull/157. Feedback is most welcome.For your convenience, a copy of today's state of the PR can be read here, and is inlined into the email below.Kind regards,Simon MeierAppendix: copy of the CIP proposal (version from 2026-01-29):
CIP: CIP TBD Layer: Canton, Daml Title: Traffic-Based App Rewards Author: Simon Meier License: CC0-1.0 Status: Draft Type: Tokenomics Created: 2026-01-29 Approved: Post-History: TBDThis CIP proposes to improve the quality of the app reward incentives by removing featured app markers and instead basing an app’s rewards on the actual traffic spent on (sub-)transactions that change the state managed by the app. This is achieved by measuring traffic spent directly on the Global Synchronizer using only sequencer and mediator data. This removes the need for app builders to create
FeaturedAppActivityMarkers in all the right places, and instead measures the actual burn contributed by all activity of an app provider party by default.To enable validator operators to manage the traffic costs incurred by validating (as opposed to submitting) transactions and to foster decentralization of apps and wallets, this CIP also proposes to make protocol-conformant confirmation responses free. Thus validator nodes only pay for the submission of transactions by their users, which is an action that validators can explicitly gate, and charge for, if required.
This CIP further proposes to implement these changes in a way that improves the throughput of the Global Synchronizer, and reduces the transaction cost of app transactions. Concretely it proposes to avoid using the
DSOparty in app transactions for the sole purpose of recording app activity, thereby reducing the size of app transactions, and avoiding the need for the SV nodes to validate and confirm extra sub-transactions concerning theDSOparty.Change the app activity recording such that the traffic cost of each envelope of a successful confirmation request is granted in equal shares as app reward weight for all app provider parties that are informees of the views contained in the envelope. The app provider parties are computed deterministically by reading
FeaturedAppRights as-of the time that the mining round opens.These records are ingested by the SV app based on the mediator verdicts from the mediator scan API, and from the sequencer using a new sequencer traffic scan API. They replace the use of
FeaturedAppActivityMarkers andAppRewardCoupons as activity records. The Daml code forsplice-amuletis changed such that neitherFeaturedAppActivityMarkernorAppRewardCouponcontracts are created anymore.Recall that mining rounds are preannounced and there are always at least two rounds that are open for activity recording, as shown in the following diagram copied from Page 19 of the Canton Coin whitepaper.
This CIP proposes to assign the activity records resulting from a confirmation request to the earliest round that is open at the time the confirmation request was sequenced. That round is always guaranteed to be open for activity recording, and closes the soonest.
The activity record computation is structured such that for a confirmation request that involves only a single app, all traffic spent for that request is attributed to that one app. For confirmation requests involving multiple apps, the computation shares the credit in equal amounts per envelope. This is done as follows:
Compute the informees of an envelope as the union of the informees of the views in that envelope. Use the view hashes visible to the sequencer on the confirmation request to determine the views contained in the envelope.
Determine the app informees as the parties for which a
FeaturedAppRightis active at round start time.Determine
total_app_envelopes_trafficas the total amount of traffic of envelopes that have at least one app informee.Let
total_confirmation_request_trafficdenote the total traffic cost of the confirmation request.For every envelope with
num_app_informees > 0, computeper_app_traffic_weight = (envelope_traffic_cost * total_confirmation_request_traffic) / (total_app_envelopes_traffic * num_app_informees)and attribute
per_app_traffic_weightto every app informee of the envelope.
Note that the computation in Item 5 takes care of distributing the traffic cost not attributed to app envelopes in a weighted fashion among the app envelopes. When all envelopes have an app informee, it becomes
per_app_traffic_weight = envelope_traffic_cost / num_app_informees, as expected.All computations are performed using integer arithmetic. For confirmation requests whose traffic size is below 100 MB, they can be performed with 64-bit signed integers without risk of overflow.
This CIP proposes to change the accounting of the minting allowance of app provider parties away from using many
FeaturedAppActivityMarkerandAppRewardCouponcontracts per party per round, and instead have the DSO create exactly one coupon per round for every party whose app rewards for the round surpass theappRewardCouponThreshold(new Amulet config parameter; default, $0.5).The coupons are valid for
appRewardCouponLifetime(new Amulet config parameter; default, 24h) measured from the time they are created. This allows app providers to batch their minting across multiple rounds and thus lower their traffic cost, and the load on the DSO party.The coupon amounts are computed as follows:
- All SV apps ingest the app activity records using the data from their associated mediator and sequencer to compute the activity records.
- All SV apps compute the per-party app rewards for the round as described in the “App Reward Computation Details” section below.
- All SV apps agree on them with a super-majority of the other SV apps, using an on-ledger workflow.
- All SV apps run decentralized automation that creates exactly one app reward coupon for every party with a non-zero minting allowance.
App rewards for parties below the threshold are burned.
Note that the minting workflows for SV rewards, validator rewards, and the ecosystem development fund from CIP-82 remain unchanged as part of this CIP. Only the workflow for app rewards is changed.
The overall design proposed by this CIP is compatible with creating activity records for both unfeatured and featured apps, thereby keeping it compatible with the reward computation from the Canton Coin whitepaper, which assigns different caps to unfeatured and featured apps. The implementation proposed by this CIP only supports rewarding featured apps for the reasons given in the rationale section on Rewards for Unfeatured Apps.
The CIP proposes to use the following computation to compute the minting allowances for app provider parties in a round:
- Compute the
total_featured_app_trafficby summing up all activity record weights for the round. - Determine the
traffic_price_in_CC_per_MBusing theAmuletRulescontract at round start time. - Compute
total_featured_app_burn_CC = (total_featured_app_traffic / 1e6) * traffic_price_in_CC_per_MB. - Compute the
issuance_per_featured_app_weightusing the issuance computation from the whitepaper withtotal_unfeatured_app_burn_CC = 0andtotal_featured_app_burn_CCas computed above. - Read the
appRewardCouponThresholdfrom theAmuletConfigread from theAmuletRulescontract at round start time, and computeapp_reward_coupon_threshold_CC = appRewardCouponThreshold / CC_conversion_rate_of_round. - Compute the
per_app_minting_allowancefor every party, by computing thetotal_app_trafficas the sum of the app provider’s activity record weights for the round, and settingper_app_minting_allowance0 = (total_app_traffic / 1e6) * 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
All computations that involve CC are performed using decimals with the same precision and rounding mode as Daml Decimals.
The implementation of featured app activity markers supports fine grained, per-transaction activity attribution to multiple beneficiary parties. For scalability reasons, this CIP proposes to replace per-transaction attribution of beneficiary parties with the same construction that is used to manage beneficiaries of SV rewards: as part of minting, the app provider party can specify a list of beneficiaries and the amount of CC they should receive out of the minted allowance.
The
MintingDelegationsintroduced in CIP-73 will support minting app reward coupons from the adjusted workflow for the app provider. Automating the specification of beneficiaries and their amounts is however out of scope for theMintingDelegationsfrom CIP-73. We expect such automation to be built as part of the apps themselves.The CIP proposes to extend the Scan API to make both the data used by the app activity record computation and the activity records themselves available. Concretely:
- Add an endpoint to the Scan API that serves a stream of summaries of the traffic spent on confirmation requests. These summaries contain the per-envelope traffic costs, the total traffic cost, and the hashes of the views contained in an envelope. The stream is served in sequencing time order.
- Add an endpoint to the Scan API that serves the stream of app activity records created for successful confirmation requests.
- Extend the
/v2/eventsendpoint so that the views in the mediator verdicts are annotated with their view hash.
This data enables network explorers to provide both details and summaries of app activity on the network.
Note that the CIP proposes introducing extra endpoints instead of extending the data returned in
/v2/events, so that:- Traffic summaries can be read by clients as soon as the corresponding message has been sequenced, and not only once the confirmation request has been completed, which may be up to 30s later.
- The
/v2/eventsstream is not held up by a potentially delayed app activity record computation.
The Canton Protocol is changed so that the confirmation responses expected to be sent by a confirming participant node become de-facto free. The mechanism works as follows:
- The sequencer continues to charge the traffic cost of a submission to the submitting validator node. This ensures that traffic cost continues to serve as an effective Denial-of-Service (DoS) protection measure.
- The mediator keeps track of the traffic cost spent by validator nodes on protocol-conformant confirmation responses, i.e., responses that match in-flight confirmation requests.
- The mediator regularly reimburses the validator nodes for the traffic spent on protocol-conformant confirmation responses. For scalability, the reimbursements may be batched, but they happen at most after
maxConfirmationResponseReimbursementDelay(new Amulet config parameter; default, 1h).
Thus validator nodes no longer pay for confirmation responses during normal operations. They only need to hold enough traffic to pay for the in-flight responses that have not yet been reimbursed. In case of network errors, validator nodes retry sending confirmation responses, which may lead to extra traffic costs in case the retry resulted in a duplicate confirmation response.
In Version 34 of the Canton Protocol, which is the version used on MainNet at the time of writing, the confirmation responses are the only messages that are addressed to exactly one mediator group. This CIP proposes to exploit this fact to expedite the change to make confirmation responses free as follows:
- Add a boolean dynamic synchronizer flag to the topology state.
- Change the traffic accounting in sequencers such that no traffic is deducted for messages that have only a single mediator group as their recipients.
- Have the SV apps set the flag once all of the SV nodes have upgraded their sequencer to support the flag.
The drawback of the heuristic implementation is that it opens up a DoS attack vector: a validator node could send lots of messages to mediators without paying traffic for them. The proper implementation avoids that problem. When using the heuristic implementation, the SV nodes can detect this DoS vector using the existing sequencer metrics on SV nodes, and handle abuse using IP blacklisting.
This CIP proposes to roll-out the changes in multiple increments:
- Make confirmation responses free using the heuristic implementation
- Make per-envelope traffic cost observable on Scan
- Make traffic-based app activity records observable on Scan
- Switch to traffic-based app reward computation
- Switch to only making protocol-conformant confirmation responses free.
Increments 2 and 3 serve to give the community a preview on the actual switch happening in the Increment 4. In particular, they allow network explorers to build support for as-if analyses for app providers. The caveat being that the view structure of an app's Daml transactions will change once the app no longer creates featured app markers. App providers can use LocalNet, DevNet or TestNet to preview the impact of adjusting their Daml models.
The difference between Increment 2 and Increment 3 is that the first one allows for an approximate computation of the traffic-based app rewards in network explorers using the featured app status at the time of ingestion. Increment 3 implements the precise activity record logic described in this CIP directly in Scan, and thus ensures that all network explorers use the same data.
The minimal delay between Increment 2 and Increment 4 landing on MainNet must be at least 30 days.
The Global Synchronizer for Canton Network incentivizes app builders via an app reward denominated in Canton Coin. This reward was initially granted only to applications that transferred Canton Coin as part of their activity, but this was found to be too limiting: the Super Validators wanted to also incentivize applications that moved assets other than Canton Coin. As a result the Super Validators introduced featured application activity markers (“featured app markers”) in CIP-47, which allowed a featured application to receive rewards for any economically meaningful activity.
This approach also had shortcomings, however: the reward weight generated was not directly correlated to the amount of traffic burned. At the time of writing, roughly 150% of weight is claimed via markers compared to actual traffic burned. The work to assess and govern these markers has become complex and time-consuming, and produces pressure to centralize governance of application behavior.
App markers are also computationally expensive for the Super Validators, decreasing the amount of throughput that can be devoted to economically useful activity. We need a better method for incentivizing app builders that incentivizes economically useful behavior, and improves governance decentralization while decreasing the requirement for human oversight, so that applications are economically motivated to add the highest possible value in each transaction.
This CIP improves the quality of the app reward incentives using the following two changes:
- Measuring the actual traffic burn contributed by an app.
- Enabling validator operators to charge their users for the cost of accessing the network.
These two changes ensure that, in BME, the app rewards received by an app are de-facto paid by the traffic spent by the app’s users. This incentivizes apps to build workflows whose traffic costs are below the value gained by the app’s users, while at the same time encouraging those apps to have their users submit a large number of transactions.
Furthermore, this CIP removes the need to govern the creation of app markers, by replacing them with a uniform mechanism that always records all featured app activity. Doing this uniformly using traffic-weighted app activity records ensures a level playing field among apps, and removes the need to optimize the amount of traffic spent per marker created.
Instead of attributing the traffic spend of each envelope to the app informees of the envelope, one could consider attributing the traffic spend of the whole confirmation request in equal shares across all informees of the whole transaction.
We propose not to do so, as that would not work well with composed transactions. The goal is that app providers get the same rewards for the composed transaction as they would get if the user acted on each of the apps individually. This ensures that the users’ “vote of app value” is independent of how their use of the app came about.
The Canton Coin whitepaper supports both unfeatured and featured applications. The difference between them being the amount of rewards they are allowed to earn per dollar of fees spent by their users. The mechanisms introduced by this CIP are compatible with supporting both featured and unfeatured applications provided there is a scalable means to identify app provider parties ahead of activity record creation.
Thus what is missing to support unfeatured applications is the design and implementation for identifying unfeatured apps. A strawman candidate is to compute the set of unfeatured app providers daily, and require that an unfeatured app provider was involved in sub-transactions costing more than a threshold amount of traffic on the previous day. Designing and implementing a scalable implementation of this idea would however significantly delay the delivery of this CIP, which is why it is not included. However adding support for rewarding unfeatured apps in a future CIP is very much in line with the spirit of this CIP.
One additional proposal for app rewards is to allow an app provider to specify per-transaction weights for how to split the app’s activity record among a set of beneficiaries, who would then ultimately be able tomint Canton Coin rewards for this activity.
The current proposal does not address this feature. The main motivation for not supporting per-transaction beneficiaries is to avoid scalability issues. In particular the following two issues seem important to avoid:
Avoid tracking minting allowances for millions of parties at the DSO level: unnetted, direct reward sharing with app users would encourage apps to share rewards in fine-grained increments, which in turn creates unwanted scalability pressure on the SV app’s implementation of the minting allowance accounting that must run for every round.
Avoid involving the DSO party in most transactions: transactions involving the DSO party are validated and confirmed by all SV validator nodes. They thus carry a high cost, and should be used sparingly.
Supporting per-transaction beneficiaries would require communicating information about different sub-transactions to the SV nodes at scale at the Daml-level. Thus creating a scalability issue by making the DSO party a confirmer of almost every transaction on the Global Synchronizer.
App providers are however free to perform their own accounting to determine how to split the rewards they receive among their beneficiaries. They can retrieve the necessary data from Scan and they can communicate the the minting allowances of their beneficiaries to the DSO on-ledger. They may either perform the accounting themselves or use a third-party data provider that performs the accounting on their behalf.
A given transaction might compose activity from multiple applications. In some cases, a given app provider could argue that their application provides a larger fraction of the overall value generated by that transaction, and therefore their application should receive a larger share of the total rewards generated by that transaction, even if the provider party for that application is not included in a comparable portion of the sub-transactions within the overall transaction. In this conceptual approach, the Daml model defining the app’s behavior would also dictate the weighting to be assigned to that app’s participation in any composed transaction involving that Daml model.
However due to Canton’s privacy, there is no way for the sequencer and mediator to know which Daml models are used in which (sub-)transactions, so value splits defined in a Daml model and cannot be evaluated by the DSO. It may be possible to control the split of rewards within a given sub-transaction, but that would introduce significant complexity to the scope of this proposal.
As a result, this CIP does not address weighting beneficiaries via Daml models, due to the significant increase in complexity this would introduce. We leave it to the community to consider this as a future enhancement.
The certainty about the app rewards gained on traffic spent changes over the duration of a round. It is lowest at its start and highest towards the end of the round. Thus one can expect that rounds with low traffic will see a peak of transactions from elastic demand towards the end of the round. The exact height of these peaks is unclear.
If these load peaks become a problem, then a future CIP can propose adopting an idea like the following deterministically randomized round assignment to smoothen them:
- Round start and end times are assigned such that at any point in time exactly two rounds overlap; and thus there are two candidate rounds for every activity record.
- Every activity record is assigned to one of the candidate rounds in a deterministically randomized fashion using the hash of their record time.
- The probability of the assignment to the later round is managed such that it linearly increases from zero at the round start time to one at the round end time of the prior round.
Thus the later an activity is recorded in a round the more likely it is for that activity to be attributed to the next round, for which the expected reward is more uncertain. Thereby lowering the fluctuation of reward certainty over the duration of a round, which in turn lowers the peaks from elastic demand.
See the Canton Network whitepaper and the Canton Blockchain Protocol whitepaper for more information about confirmation requests, views, and responses.
Canton protocol messages are distributed via the sequencer as a batch of envelopes (proto). An envelope consists of a list of recipients, a list of signatures, and a payload (proto). The envelope payload used to distribute views is called an
EncryptedViewMessage(proto). The view itself is only stored in encrypted form, but the view hash is available in plaintext for the sequencer.We use the DvP example from the Canton ledger model documentation on privacy. See that documentation for diagram notation, context on the example, and formal definitions of concepts like action, transaction, node, informees, and witnesses.
The diagram shows the witnesses of an action in purple, and the informees of the action in blue.
As explained in the Canton docs here, Canton 3.4 creates a view for every action node in the transaction tree if the validator nodes that host their informees are not a subset of their parent view’s informee validators.
Assuming that all parties in the example are hosted on their own validator nodes, the example DvP transaction results in five views, which are each encoded in their own envelope. For efficiency, envelopes only encode the root node of the view, as the subtree below the root node can be recomputed using its associated Daml code.
Below we show three calculation examples to illustrate the activity record computation. The all assume the following envelope sizes for the envelopes containing the node’s views:
- Node 1: 12 kB
- Node 2: 4 kB
- Node 3: 2 kB
- Node 4: 5 kB
- Node 5: 2 kB
total_confirmation_request_traffic: 25 kB
Note that we set
total_confirmation_request_trafficto the sum of all envelopes for the sake of this example. In practice, a confirmation request always contains two envelopes without associated views (one for the mediator view tree, and one or the root view hashes).Note that Bank1 is an informee of Node 2 and 3. Thus
total_app_envelopes_traffic= 6 kB- Bank1 gets the following
per_app_traffic_weightfor Node 2:per_app_traffic_weight = (4 * 25) / (6 * 1) = 16.666 kB - Bank1 gets the following
per_app_traffic_weightfor Node 3:per_app_traffic_weight = (2 * 25) / (6 * 1) = 8.333 kB
Thus Bank1 total activity record for this confirmation request is
24.999 kB, which is equal to total confirmation request traffic of 25 kB when ignoring rounding errors. No other party gets credit for the traffic spent on this confirmation request.Note that Bank1 is an informee of Node 2 and 3; and Bank2 is an informee of Node 4 and 5. Thus
total_app_envelopes_traffic= 13 kB- Bank1 gets the following
per_app_traffic_weightfor Node 2:per_app_traffic_weight = (4 * 25) / (13 * 1) = 7.692 kB - Bank1 gets the following
per_app_traffic_weightfor Node 3:per_app_traffic_weight = (2 * 25) / (13 * 1) = 3.846 kB - Bank2 gets the following
per_app_traffic_weightfor Node 4:per_app_traffic_weight = (5 * 25) / (13 * 1) = 9.615 kB - Bank2 gets the following
per_app_traffic_weightfor Node 5:per_app_traffic_weight = (2 * 25) / (13 * 1) = 3.846 kB
Thus Bank1’s total activity record for this confirmation request is
11.538 kBand Bank2’s total is13.461 kB. They sum up to 24.999 kB, and their ratio is13.461 / 11.538 = 1.166, which matches the ratio of the size of their envelopes7 / 6.Note that both Bank1 and Bank2 still got full attribution for the envelopes involving only themselves. The difference to the first example is that Bank1 no longer gets any extra credit for the traffic spent by their users on the envelopes for nodes 1, 4, and 5.
Intuition: Alice is a featured app because they act as an automated market maker.
Note that Bank1 is an informee of Node 2 and 3; Bank2 is an informee of Node 4 and 5; and Alice is an informer of nodes 1, 2, and 5. Thus
total_app_envelopes_traffic= 25 kB- Alice gets the following
per_app_traffic_weightfor Node 1:per_app_traffic_weight = (12 * 25) / (25 * 1) = 12 kB - Bank1 and Alice each get the following
per_app_traffic_weightfor Node 2:per_app_traffic_weight = (4 * 25) / (25 * 2) = 2 kBThat is they share the credit for Node 2 in equal shares. - Bank1 gets the following
per_app_traffic_weightfor Node 3:per_app_traffic_weight = (2 * 25) / (25 * 1) = 2 kB - Bank2 gets the following
per_app_traffic_weightfor Node 4:per_app_traffic_weight = (5 * 25) / (13 * 1) = 5 kB - Bank2 and Alice each get the following
per_app_traffic_weightfor Node 5:per_app_traffic_weight = (2 * 25) / (15 * 1) = 1 kB
Thus the totals are as follows:
- Alice: 15 kB
- Bank1: 4 kB
- Bank2: 6 kB
Note that the actual view decomposition of an app very much depends on their Daml models, and is best observed in production.
For example the
SimpleAssetcontract used in this example does not make theownera signatory. If theownerwere a signatory, then the new owner would be an informee on theTransferchoice, and thus a corresponding DvP settlement transaction would only contain three views: one for the settlement choice, and one for each transfer.For this reason, this CIP proposes an Incremental Roll-Out, whose first increment makes the view decomposition and traffic costs observable on Scan. Using a LocalNet deployment of this increment, app providers may experiment with their Daml models and observe the view decomposition and envelope sizes. They can also use Daml Studio to observe the full transaction trees from their Daml models, which can be used with enough experience to predict the view decomposition.
TODO: build and reference here
This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal
- 2026-01-29: draft published
--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. Hi Simon,
Seems like a comprehensive document covering a lot of ground! I still need to go through things in depth but from a first read through, it sounds like the CIP is suggesting a 1:1 reward at the level of traffic spend (rather than any multiplier) — so essentially a reimbursement of traffic costs incurred by FAs. Is that right?
My understanding of the initial roadmap/tokenomics was that the multiplier on reward vs spend was there to encourage app development onto the network. (I know that since that we've moved away from that exact model) but do the governance committee feel that this goal has been crossed so the incentive is no longer needed there? It would be great to understand the rationale here.
Also, one thing I think the current marker-based approach has, which would be lost here, is that developers are incentivised to keep traffic costs low — if you're getting a fixed reward regardless of traffic spent, the less you spend, the more you gain. If we swap this to a proportional refund of costs, then the interests between app devs and the ecosystem as a whole are no longer as closely aligned.
I think this is particularly important in a scenario where a large proportion of developers coming to the network will be learning DAML as a new language with its own best practices around efficient contract/transaction design.
Best wishes,
Dave- toggle quoted message Show quoted textHi Dave - not quite rightThis replaces the mechanism of getting credit for your feesThe multiplier remains on top of this true cost allocationOn Jan 29, 2026, at 3:29 PM, Dave M via lists.sync.global <dave=axymos.com@...> wrote:
Hi Simon,
Seems like a comprehensive document covering a lot of ground! I still need to go through things in depth but from a first read through, it sounds like the CIP is suggesting a 1:1 reward at the level of traffic spend (rather than any multiplier) — so essentially a reimbursement of traffic costs incurred by FAs. Is that right?
My understanding of the initial roadmap/tokenomics was that the multiplier on reward vs spend was there to encourage app development onto the network. (I know that since that we've moved away from that exact model) but do the governance committee feel that this goal has been crossed so the incentive is no longer needed there? It would be great to understand the rationale here.
Also, one thing I think the current marker-based approach has, which would be lost here, is that developers are incentivised to keep traffic costs low — if you're getting a fixed reward regardless of traffic spent, the less you spend, the more you gain. If we swap this to a proportional refund of costs, then the interests between app devs and the ecosystem as a whole are no longer as closely aligned.
I think this is particularly important in a scenario where a large proportion of developers coming to the network will be learning DAML as a new language with its own best practices around efficient contract/transaction design.
Best wishes,
Dave
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. Understood, thanks Eric! So would the multiplier vs traffic be at the 100x rate mentioned in the whitepaper, or would it be something different (or TBC?).
Also, do you think a multiplier vs traffic spend could/would incentivise overspend on traffic?
Hi Simon,
thanks for writing this up. I like the direction as the current scheme is quite confusing. A few questions that feel important to pressure-test before we switch ( please take this with a grain of salt as I am just coming up to speed with Canton, so may miss-understand something)-
Reward-gaming via traffic bloat / view fragmentation
How do we prevent apps from intentionally increasing envelope size or fragmenting views just to farm “traffic-weighted” rewards? Maybe an option would be adding an efficiency normalization (e.g., cap marginal reward per confirmation request or scale rewards by some “bytes-per-success” curve) and publishing a cost-per-outcome metric so governance/params can clamp obvious abuse. -
“Free confirmation responses” heuristic + DoS risk
The heuristic (“responses are the only messages to exactly one mediator group”) seems potentially DoS-able. What’s the concrete mitigation and rollback plan for mainnet? A reasonable guardrail could be explicit rate limits/quotas + automated circuit breakers (disable reimbursements if anomaly metrics spike), plus a clear timeline to the “protocol-conformant only” implementation. As an active mitigant we can do ip blacklisting for a nefarious node but probably good to have a "net" to catch things. -
SV disagreements on activity computation / canonical inputs
If SV apps ingest slightly different sequencer/mediator data (lag, missed messages, etc.) and compute different activity, what’s the dispute path and source of truth? I’d suggest defining a canonical hash-committed input snapshot per round (sequencer traffic summary + mediator verdict checkpoints) that SVs attest to—then disagreements are objective (“different inputs”) rather than subjective (“different math”). -
Coupon threshold burns long-tail apps
Burning rewards underappRewardCouponThresholdseems like it could penalize early-stage/low-volume apps? An alternative that keeps DSO load low is to let sub-threshold rewards accrue/roll over until they exceed the threshold (or pay them out on a longer cadence like weekly, I've seen this work in other networks).
Curious how you’re thinking about these—especially (2) and (3), since they feel like the biggest operational risk items.
Regards,
Orion-
- Hi Orion,please find my answers inline belowOn Fri, Jan 30, 2026 at 12:40 AM orion via lists.sync.global <orion=ninerealms.co@...> wrote:
Hi Simon,
thanks for writing this up. I like the direction as the current scheme is quite confusing. A few questions that feel important to pressure-test before we switch ( please take this with a grain of salt as I am just coming up to speed with Canton, so may miss-understand something)-
Reward-gaming via traffic bloat / view fragmentation
How do we prevent apps from intentionally increasing envelope size or fragmenting views just to farm “traffic-weighted” rewards? Maybe an option would be adding an efficiency normalization (e.g., cap marginal reward per confirmation request or scale rewards by some “bytes-per-success” curve) and publishing a cost-per-outcome metric so governance/params can clamp obvious abuse.
Think about this in BME: app providers can submit transactions using their own node, but they'll make no profit on them, and potentially incur a loss.So in BME, app providers gain from app rewards for transactions submitted and paid by their users. If the user is willing to pay the cost of a bloated transaction, then that's fine from a network perspective. However, apps that use bloated transactions risk losing their users to apps that provide the same functionality with less bloated transactions. Thus we can expect that economic competition between apps ensures efficient use of network throughput.For this competition to take place it is important that end-users have to pay the transaction cost. I know of several wallets that have built the necessary features to charge their users for the submission of their prepared transactions.-
“Free confirmation responses” heuristic + DoS risk
The heuristic (“responses are the only messages to exactly one mediator group”) seems potentially DoS-able. What’s the concrete mitigation and rollback plan for mainnet? A reasonable guardrail could be explicit rate limits/quotas + automated circuit breakers (disable reimbursements if anomaly metrics spike), plus a clear timeline to the “protocol-conformant only” implementation. As an active mitigant we can do ip blacklisting for a nefarious node but probably good to have a "net" to catch things.
The risk mitigation in place is tight alerting on the SV operators side plus banning the abusive validator via IP blacklisting. Whether to allow the node operator back on the network or not is then a question for the foundation. The risk of an accidental DoS due to this heuristic is highly unlikely as Canton nodes do not accidentally produce confirmation response spam.Thus a validator sending these messages is actively malicious and has to use modified Canton code to perform the attack. Something that I believe is unlikely to be done by a rational actor on the network in the 3 - 6 months that it will take between rolling out the heuristic and the proper implementation.-
SV disagreements on activity computation / canonical inputs
If SV apps ingest slightly different sequencer/mediator data (lag, missed messages, etc.) and compute different activity, what’s the dispute path and source of truth? I’d suggest defining a canonical hash-committed input snapshot per round (sequencer traffic summary + mediator verdict checkpoints) that SVs attest to—then disagreements are objective (“different inputs”) rather than subjective (“different math”).
The whole computation path is designed to be deterministic. Both sequencers and mediators are implemented as replicated state machines. Thus in theory the SV nodes will always agree.In practice, this is a complex information flow that might initially have determinism bugs. As explained in the section on "Adjust App Reward Accounting" the SVs will first agree on the concrete values using an on-ledger workflow. The planned implementation for that workflow uses a hash-committed snapshot per round as you propose. This also allows to absorb the occurrence of determinism bug into the BFT fault-tolerance budget.-
Coupon threshold burns long-tail apps
Burning rewards underappRewardCouponThresholdseems like it could penalize early-stage/low-volume apps? An alternative that keeps DSO load low is to let sub-threshold rewards accrue/roll over until they exceed the threshold (or pay them out on a longer cadence like weekly, I've seen this work in other networks).
Accumulating minting allowances across rounds is explicitly not done, as that would lead to a "hidden" extra CC supply, which we want to avoid.The threshold's purpose is to avoid spending network throughput on accounting for very low amounts of app rewards. It is thus set to the low amount of 50 cents, which seems adequate given that collecting the 50 cents costs $1 if not done in a batched fashion.If you would like to argue for a concrete lower amount, please go ahead. The 50 cents is a strawman that seemed adequate.Curious how you’re thinking about these—especially (2) and (3), since they feel like the biggest operational risk items.
Thanks for the good questions. I hope my answers are helpful.Kind regards,Simon
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. -
- Dave,
Also, one thing I think the current marker-based approach has, which would be lost here, is that developers are incentivised to keep traffic costs low — if you're getting a fixed reward regardless of traffic spent, the less you spend, the more you gain. If we swap this to a proportional refund of costs, then the interests between app devs and the ecosystem as a whole are no longer as closely aligned.
Orion asked a similar question which I answered here https://lists.sync.global/g/cip-discuss/message/518. I explain there why I believe that the proposal keeps the incentive for app providers to optimize their transaction sizes.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Simon, thanks for submitting this. This is extremely well thought out and
I’ll limit my feedback to the wallet/operator perspective, because this CIP is a massive time saver.
As operators of Loop and LoopSDK, we currently drive close to ~50% of app-level network traffic.
Wallets only see what users submit. We sign and forward transactions, with zero visibility into contract internals,
yet we are the entities incurring the fees.Under the current marker-based system (and we implement in advance CIP-0098 dynamics), the operational burden of accounting for coupons and variable pricing is completely disproportionate to the actual work wallets perform.
This creates friction, unclear outcomes, and often worsens network performance as apps
can generate large volumes of markers with limited economic meaning.Governance around Featured Apps and markers is already more than we should be doing, and as the network scales this will only get worse unless fixed at the root.
This CIP solves the majority of the marker-related issues and is a clear 10x improvement in our opinion.
Shifting incentives from manual oversight to objective, traffic-based measurement is the way to go. We
are a network, we should enforce rules on this level and remove the burden from the app builders.Have some ideas on how we can avoid some pitfalls but I'll let the rest of the
community elaborate since this seems to be a very dynamic discussion.
We fully support the direction and spirit here, and would be happy to endorse or sponsor the effort.Y.
- If you're interested in the Traffic-Based App Rewards CIP you'll likely to find the following Q&A between Brale and Digital Asset to be useful:
Brale:
We could use some help understanding the implications of this proposed CIP on app rewards for tokenization contracts https://lists.sync.global/g/cip-discuss/topic/117528378. It sounds like the rewards would be split among the informees, which would include the signatories and the observers. On most utility tokenization templates, the registrar, provider, operator, and senders/recipients are signatories or observers. Our featured app party is our registrar and provider, so it sounds like we'd get rewards from transactions that create tokenization contracts for our utilities, but does that mean we'd end up splitting them with the operator and any featured app parties that are senders or recipients?
Digital Asset:
The key is that the split is only amongst those parties that are featured apps. The sender, receiver, operator, etc. are not, and once this CIP is through, I'd expect neither are the wallets. So for a straight-up SBC transfer, the SBC registry party is likely the only involved featured party and gets 100% of the weight for the transfer. The resulting rewards are then split 80/20 according to registry commercials.
For a trade in an app like Temple, say, both the asset registries, and the app are likely to be featured. So in a multi-step flow ofagree trade / allocate asset A / allocate asset B / settle A vs B, the traffic spend on the four transactions will be split according to how much of the transaction size the assets/apps contribute. For the first step, likely 100% to the app. For the second and third step, likely 100% or close to 100% to the assets. For the third step some split between app and assets, which I can not yet fully predict. However, it's important to note that the venue (e.g. Temple) is not automatically an informee on all the events that constitute the settlement of asset A. In particular the events that archive and create the holdings should be 100% due to the app provider that manages the asset. So my best guess right now is that the rewards for settlement traffic will be split roughly 1/1/1 between app, asset A, and asset B.
The point of the proposed phase where Scan reports the numbers, but the tokenomics are still not based on traffic yet, is that you can get actual measurements of the above splits before the traffic-based tokenomics take effect. Wayne, thanks for sharing this.
Since wallets are the ones who actually submit the transactions to the network, they are the ones
who incur the fees for this action. According to this CIP and what you write, the fees burned
by the wallets, won't be part of the rewards distributed from the network, since rewards are only
attributed to featured app parties. We believe this is a good thing.To us this makes commercially sense, since it forces the following:
- Wallets actually start charging for the fees they incur and make a business out of it.- Reduce the amount of noise in the network since it will not be economically viable for
those who just farm activity.- Amount of rewards being distributed to the network, to actually go to the apps that create
real state changing transactions.
Importantly, even as a main wallet operator on the network, we still strongly support this
direction, because it is the right long term structure for scaling a healthy app ecosystem.
Y.- toggle quoted message Show quoted textThis is interesting! It wasn't immediately obvious to us the net intended effects of these changes from the perspective of the end user and the infrastructure providers (wallets).
I was discussing with Bernhard and asking these questions but he suggested that others may also be curious so I am repeating the questions here.
Is this understanding (listed below) correct?
In this new model of traffic based rewards:- wallets buy traffic and pay the traffic for transactions but receive no rewards
- the application (token issuer, creator of custom DAML contracts, etc.) gets a share of rewards based on the traffic size of the transaction
- wallets will no longer maintain featured app status
And if this is true, is the baseline expectation that wallets will charge users just to maintain a Canton partyID? Wallets will still be expected to provide services (preapprovals, merges, potentially others) that cost traffic without a rewards offset.
Based on our understanding of these changes (if that understanding is correct), we would expect featured apps to pay wallets directly for access to users or otherwise incentivize on-chain activity from a given featured app provider. The same activity-based actions will be incentivized but it will be negotiated behind closed doors on a B2B basis?On Mon, Feb 2, 2026 at 9:19 AM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:Wayne, thanks for sharing this.
Since wallets are the ones who actually submit the transactions to the network, they are the ones
who incur the fees for this action. According to this CIP and what you write, the fees burned
by the wallets, won't be part of the rewards distributed from the network, since rewards are only
attributed to featured app parties. We believe this is a good thing.To us this makes commercially sense, since it forces the following:
- Wallets actually start charging for the fees they incur and make a business out of it.- Reduce the amount of noise in the network since it will not be economically viable for
those who just farm activity.- Amount of rewards being distributed to the network, to actually go to the apps that create
real state changing transactions.
Importantly, even as a main wallet operator on the network, we still strongly support this
direction, because it is the right long term structure for scaling a healthy app ecosystem.
Y. - Thanks for the question, Anthony. The Brale example that Wayne reposted is oversimplified to explain the mechanics from the perspective of how rewards are split in the context of a DvP between assets and apps. But it's important to note that a user's wallet provider - specificity their hosting node - participates in consensus on behalf of the user and thus is an informee on all the user's views as well.So this CIP doesn't change the fact that wallets can in principle participate in app rewards if they remain featured apps.I do have the expectation that there will be followup CIPs which will make it easy for wallet users to pay for the traffic they consume, though, and at that point the original intent of the tokenomics would be that they capture validator rewards for the user traffic they facilitate, not app rewards.Any such changes are beyond the scope of this CIP, however.On Mon, 2 Feb 2026, 8:20 pm Anthony Merriman via lists.sync.global, <anthony=modulo.finance@...> wrote:This is interesting! It wasn't immediately obvious to us the net intended effects of these changes from the perspective of the end user and the infrastructure providers (wallets).
I was discussing with Bernhard and asking these questions but he suggested that others may also be curious so I am repeating the questions here.
Is this understanding (listed below) correct?
In this new model of traffic based rewards:- wallets buy traffic and pay the traffic for transactions but receive no rewards
- the application (token issuer, creator of custom DAML contracts, etc.) gets a share of rewards based on the traffic size of the transaction
- wallets will no longer maintain featured app status
And if this is true, is the baseline expectation that wallets will charge users just to maintain a Canton partyID? Wallets will still be expected to provide services (preapprovals, merges, potentially others) that cost traffic without a rewards offset.
Based on our understanding of these changes (if that understanding is correct), we would expect featured apps to pay wallets directly for access to users or otherwise incentivize on-chain activity from a given featured app provider. The same activity-based actions will be incentivized but it will be negotiated behind closed doors on a B2B basis?On Mon, Feb 2, 2026 at 9:19 AM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:Wayne, thanks for sharing this.
Since wallets are the ones who actually submit the transactions to the network, they are the ones
who incur the fees for this action. According to this CIP and what you write, the fees burned
by the wallets, won't be part of the rewards distributed from the network, since rewards are only
attributed to featured app parties. We believe this is a good thing.To us this makes commercially sense, since it forces the following:
- Wallets actually start charging for the fees they incur and make a business out of it.- Reduce the amount of noise in the network since it will not be economically viable for
those who just farm activity.- Amount of rewards being distributed to the network, to actually go to the apps that create
real state changing transactions.
Importantly, even as a main wallet operator on the network, we still strongly support this
direction, because it is the right long term structure for scaling a healthy app ecosystem.
Y.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Where in this CIP we mention that wallets will stop being featured apps, I'm confused.
This is a much different conversation and should not be mixed with this one IMO. On behalf of Temple, we would like to express our strong support for this proposal.
From the perspective of an app provider building high throughput, state changing workflows on Canton, this CIP is a big step forward:
- It aligns rewards with actual economic activity by tying app rewards directly to the traffic burn of successful confirmation requests. Moving away from marker-based accounting towards protocol-level measurements reduces ambiguity, gaming surface, and governance overhead.
- It simplifies operations for app builders. Eliminating `FeaturedAppActivityMarker` and `AppRewardCoupon` contracts from app transactions lowers transaction size, improves throughput, and removes a large class of failure modes.
We would also like to actively participate in testing as the incremental rollout proceeds across Devnet, Testnet, and eventually Mainnet.
- Simon, DA team, thank you for putting this together - I believe this is absolutely the direction app rewards should head toward.We have 2 mainly technical questions regarding this implementation:
- By removing the app reward calculation from the critical path of tx processing (our assumption), how much performance improvement do we expect?
- Does observer-only activity get the same level of rewards as signatories (share the traffic weight within an envelope equally)?
Kind regards,Alex--Cumberland - toggle quoted message Show quoted textHi Alex,Until implemented and tested, it's hard to give a precise number on performance uplift, and the performance aspect has to be seen as part of an overall performance & scalability program that we expect to lift performance 2x+ over the next 4-5 months. Before this change, every tx that sets an app marker has the DSO as a counterparty, which means all SV nodes validate and send confirmations. For many transactions, that more than doubles the number of counterparty validators, meaning 2x+ load on mediator, 2x+ load on the sequencer from confirmation messages. It also means the SV validator nodes process far more transactions and UTXOs than they otherwise would, so the SV nodes are strained on all three levels.As written, the observer-only activity does indeed get the same rewards as signatories, but this topic has already been raised and there's an open discussion whether we should change the attribution to only take into account confirmers, not informees. Thoughts on this?BernhardOn Wed, Feb 4, 2026 at 10:46 PM alechen via lists.sync.global <alechen=cumberland.io@...> wrote:Simon, DA team, thank you for putting this together - I believe this is absolutely the direction app rewards should head toward.We have 2 mainly technical questions regarding this implementation:
- By removing the app reward calculation from the critical path of tx processing (our assumption), how much performance improvement do we expect?
- Does observer-only activity get the same level of rewards as signatories (share the traffic weight within an envelope equally)?
Kind regards,Alex--Cumberland--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - toggle quoted message Show quoted textYiannis, it doesn't say that and I apologize if my previous message implied that it did. To recap:1. In Wayne's message the scenario only talked about the asset provider parties and the trading app.2. Anthony asked about wallets and specifically asked whether his understanding was correct that "wallets will no longer maintain featured app status" under this CIP.3. I tried to clarify that the scenario in 1 was merely simplified and that Wallets will still get rewards as they are featured apps and confirmers of various envelopes in such a transaction. I did say that there could be a CIP in the future that changes this but the bottom line regarding this topic was: "Any such changes are beyond the scope of this CIP"
I think we are in agreement here, can you confirm?On Tue, Feb 3, 2026 at 12:28 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:Where in this CIP we mention that wallets will stop being featured apps, I'm confused.
This is a much different conversation and should not be mixed with this one IMO.--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - toggle quoted message Show quoted textHi All,Based on Alex's feedback , Simon has amended the proposal to make the calculation confirmer-based, not informee-based. The rationale is explained in the change PR here.Would anyone be willing to sponsor and/or endorse this CIP so it can go the vote? If voted for quickly, the step to make confirmations free could be slotted into a release very soon and land in the first half of March.Kind regards,BernhardOn Mon, Feb 9, 2026 at 6:02 PM Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:Yiannis, it doesn't say that and I apologize if my previous message implied that it did. To recap:1. In Wayne's message the scenario only talked about the asset provider parties and the trading app.2. Anthony asked about wallets and specifically asked whether his understanding was correct that "wallets will no longer maintain featured app status" under this CIP.3. I tried to clarify that the scenario in 1 was merely simplified and that Wallets will still get rewards as they are featured apps and confirmers of various envelopes in such a transaction. I did say that there could be a CIP in the future that changes this but the bottom line regarding this topic was: "Any such changes are beyond the scope of this CIP"
I think we are in agreement here, can you confirm?On Tue, Feb 3, 2026 at 12:28 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:Where in this CIP we mention that wallets will stop being featured apps, I'm confused.
This is a much different conversation and should not be mixed with this one IMO.--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - toggle quoted message Show quoted textHi Bernhard,Thanks for the clarification.Yes I am in agreement and aligned.Y.On Mon, Feb 9, 2026 at 19:11 Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:Hi All,Based on Alex's feedback , Simon has amended the proposal to make the calculation confirmer-based, not informee-based. The rationale is explained in the change PR here.Would anyone be willing to sponsor and/or endorse this CIP so it can go the vote? If voted for quickly, the step to make confirmations free could be slotted into a release very soon and land in the first half of March.Kind regards,BernhardOn Mon, Feb 9, 2026 at 6:02 PM Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:Yiannis, it doesn't say that and I apologize if my previous message implied that it did. To recap:1. In Wayne's message the scenario only talked about the asset provider parties and the trading app.2. Anthony asked about wallets and specifically asked whether his understanding was correct that "wallets will no longer maintain featured app status" under this CIP.3. I tried to clarify that the scenario in 1 was merely simplified and that Wallets will still get rewards as they are featured apps and confirmers of various envelopes in such a transaction. I did say that there could be a CIP in the future that changes this but the bottom line regarding this topic was: "Any such changes are beyond the scope of this CIP"
I think we are in agreement here, can you confirm?On Tue, Feb 3, 2026 at 12:28 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:Where in this CIP we mention that wallets will stop being featured apps, I'm confused.
This is a much different conversation and should not be mixed with this one IMO.--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Thanks, Bernhard.Cumberland/DRW will sponsor (or endorse).Chris
- toggle quoted message Show quoted textThank you Chris. Anyone willing to second this?On Mon, Feb 9, 2026 at 9:55 PM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:Thanks, Bernhard.Cumberland/DRW will sponsor (or endorse).Chris--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - Five North happy to.toggle quoted message Show quoted textOn Feb 10, 2026, at 4:43 PM, Bernhard Elsner via lists.sync.global <bernhard.elsner=digitalasset.com@...> wrote:Thank you Chris. Anyone willing to second this?On Mon, Feb 9, 2026 at 9:55 PM Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...> wrote:Thanks, Bernhard.Cumberland/DRW will sponsor (or endorse).Chris--
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
