Development Fund Proposal
Traffic-Based App Rewards on the Global Synchronizer
| Field | Value |
|---|
| Authors | Wayne Collier (DA) and Divam Narula (OS) |
| Org | Digital Asset and Obsidian Systems |
| Status | Approved |
| Created | 2026-02-25 |
| Approved | 2026-04-01 |
| PR | #107 |
| Implements | CIP-0104: Traffic-Based App Rewards |
Abstract
This proposal requests funding to develop, release, and deploy the traffic-based app reward system specified in CIP-0104 to the Global Synchronizer. This implementation replaces the current featured app activity marker mechanism with a system that rewards featured applications proportionally to the actual traffic burn their transactions generate on the network.
The core change eliminates the need for applications to create FeaturedAppActivityMarker contracts and instead measures the actual traffic burn contributed by all activity of an app provider party, using sequencer and mediator data directly. Activity is attributed to app providers based on their role as confirmers of transaction views, with traffic cost distributed proportionally across envelopes. This produces a fairer, more transparent, and less governance-intensive reward mechanism that aligns app incentives with genuine network utilization.
The implementation spans Canton node changes (traffic summary and mediator inspection APIs), Splice Scan app changes (temporal contract store, activity record ingestion, reward computation with Merkle-tree based commitments), Splice SV app changes (reward confirmation and coupon creation triggers), Daml model changes (RewardCouponV2, ProcessRewardsV2, CalculateRewardsV2), and wallet app integration. The system is designed to be rolled out incrementally, with traffic data observable on Scan before the actual reward switch, and a dry-run mode on MainNet to detect non-determinism bugs before going live.
Digital Asset expects that when deployed on the Global Synchronizer, this work will reduce the governance burden on Super Validators, eliminate the computational overhead of activity markers on SV nodes, reduce the need for human oversight of application rewards, and establish an objective, traffic-proportional reward system that scales to tens of thousands of featured app provider parties.
Motivation
The Global Synchronizer incentivizes application builders via app rewards denominated in Canton Coin. These rewards were initially granted only to applications that transferred Canton Coin, but this was found to be too limiting. Super Validators introduced featured application activity markers in CIP-0047, allowing featured applications to earn rewards for any economically meaningful activity. This approach has its own shortcomings that now constrain the network's growth.
Connect Reward Weight Directly to Traffic Burn: At the time of writing, reward weight generated by markers is not directly correlated with the amount of traffic an application consumes, creating a misalignment between the rewards an app receives and the value it contributes to the network. This proposal connects reward weights directly to traffic burn, removing misalignments.
Remove Governance Overhead: Assessing and governing featured app markers has become complex and time-consuming. Each application's marker creation logic must be evaluated to ensure it reflects genuine economic activity, creating pressure to centralize governance of application behavior — the opposite of what a decentralized network should encourage. This proposal removes the requirement for human oversight by automatically aligning incentives. Any app that attempts to “game” rewards by submitting excess transactions, or excessively large transactions, will automatically consume higher traffic.
Reduce the Computational Expense on SV Nodes: Featured app activity markers are Daml contracts that involve the DSO party, meaning they must be validated and confirmed by all SV validator nodes. This consumes throughput that could otherwise be devoted to economically useful transactions. Additionally, the current per-transaction creation of AppRewardCoupon contracts via the FeaturedAppActivityMarkerTrigger generates significant on-ledger overhead per round. This proposal removes the requirement to validate and confirm app activity markers, and further reduces computation by generating one AppRewardCoupon per party in each round
Provide Transparency for App Providers: Under the current system, app providers cannot easily observe how their traffic translates to rewards, or compare their reward efficiency against competing applications. This makes it difficult for app builders to forecast and optimize their reward potential. This proposal makes it easier for app providers to understand their traffic costs, and to track the source of their rewards in each round.
Implementing CIP-0104 resolves these issues by replacing subjective markers with objective, verifiable traffic measurement, ensuring that applications driving the most genuine network activity receive proportional rewards without requiring human oversight of each application's reward claims.
Specification
1. Objective
We propose to implement the traffic-based app reward system specified in CIP-0104 in the open-source Splice and Canton repositories, and deploy it on the Global Synchronizer MainNet. The technical scope covers five areas:
Traffic Measurement on the Sequencer and Mediator: Extend Canton's mediator inspection service and sequencer to expose per-envelope traffic costs and view hashes for confirmation requests, enabling the Scan app to compute app activity records from infrastructure data rather than application-created markers.
Activity Record Computation in Scan: Implement a temporal contract store and activity record computation pipeline in the Scan app that ingests mediator verdicts and sequencer traffic data, attributes traffic burn to featured app provider parties based on their confirmer role, assigns activity to the appropriate mining round, and computes per-party reward totals for each round.
BFT Reward Consensus via Merkle-Tree Commitments: Implement a three-stage reward computation (activity totals, reward totals, Merkle-tree root hashes) in the Scan app, with an SV app workflow that uses ActionRequiringConfirmation to achieve DSO consensus on per-round reward root hashes before expanding them into individual RewardCouponV2 contracts.
On-Ledger Reward Accounting: Introduce new Daml templates (CalculateRewardsV2, ProcessRewardsV2, RewardCouponV2) and SV app triggers that create exactly one reward coupon per featured app party per round (for reward amounts above a configurable threshold, default 0.5$), replacing the current many-markers-per-party-per-round approach with a scalable batched workflow.
Incremental Rollout with Dry-Run: Deploy the system in increments — traffic observability first, then activity records, then the full reward switch — with a dry-run mode that exercises the entire minting workflow on MainNet without creating actual reward coupons, to detect non-determinism bugs before going live.
2. Implementation Mechanics
Note that the following sections are based on an initial design of how to implement traffic-based app rewards. They use many concrete names of future components or functions to build. The concrete names are used to improve readability of the grant, but not considered binding. The final implementation may deviate from them.
2.1 Traffic Cost Observability on Scan
Canton's sequencer and mediator inspection APIs are extended to serve traffic summaries for confirmation requests, including per-envelope traffic cost, total confirmation request traffic cost, and the hashes of the views contained in each envelope. The Scan app's existing ScanVerdictIngestion service is extended to ingest these traffic summaries alongside mediator verdicts and serve them via the /v0/events endpoint.
This increment allows network explorers and app providers to compute approximate traffic-based app rewards from production MainNet data, providing an early preview of the new system before the actual switch.
2.2 Activity Record Computation
The Scan app implements a ScanTcsStore — a temporal contract store that maintains both active and archived FeaturedAppRight, OpenMiningRound, and AmuletRules contracts with their archival record times. This enables lookups as-of round start times, which is critical for deterministic computation of which parties were featured app providers when a round opened.
The ScanVerdictIngestion service is extended to compute activity records for each successful confirmation request, implementing the CIP-0104 formula:
For each envelope with app confirmers, the per-app traffic weight is computed as (envelope_traffic_cost × total_confirmation_request_traffic) / (total_app_envelopes_traffic × num_app_confirmers), using integer arithmetic for determinism. Activity records are assigned to the earliest open mining round at the confirmation request's sequencing time.
Canton's mediator inspection service is made crash-fault tolerant to avoid losing mediator verdicts on restarts, improving the reliability of the data feeding the reward computation.
2.3 Three-Stage Reward Computation
A new ComputeAppRewardsTrigger in the Scan app computes rewards for closed mining rounds in three stages, executing the bulk of work directly in SQL:
Stage 1 — ComputeAppActivityTotals: Aggregates individual activity records into per-party activity totals and a single round total, stored in app_activity_totals and app_activity_round_totals tables.
Stage 2 — ComputeAppRewardsTotals: Converts activity totals to Canton Coin using the traffic price from AmuletRules at round start and the CC conversion rate from the round's OpenMiningRound contract. Computes issuance_per_featured_app_traffic_MB using the whitepaper's issuance formula, then derives each party's minting allowance. Parties below the appRewardCouponThreshold (default $0.50) are excluded, with their rewards burned.
Stage 3 — ComputeAppRewardsHashes: Builds a Merkle tree over the per-party reward totals, sorted by party ID and grouped into configurable batch sizes. The root hash serves as the commitment that SV apps must agree on via the DSO's BFT confirmation workflow.
All three stages execute within a single SQL transaction per round for crash-fault tolerance.
Note on appRewardCouponThreshold: If the total reward due to a given featured app party in a given round is less than the cost of the traffic required to mint that reward, the automated minting that would normally take place in the next round phase would cause a net loss for that party. To minimize the likelihood of this harm, coupons for rewards below $0.50 total per round will be burned by the Super Validators, rather than being assigned to the relevant featured app party. The value may be adjusted by the Super Validators as required to serve this purpose.
2.4 SV App Reward Workflow
The SV app implements four new triggers:
CalculateRewardsTrigger: Picks up CalculateRewardsV2 contracts (created by the existing AdvanceMiningRoundTrigger), reads the Merkle-tree root hash from Scan, and submits it for DSO confirmation via ActionRequiringConfirmation. Falls back to BFT reads from other Scan instances if the local Scan does not yet have the data (handling SV onboarding).
ProcessRewardsTrigger: Picks up confirmed ProcessRewardsV2 contracts, retrieves the batch data for the committed hash from Scan, and calls ProcessRewardsV2_ProcessBatch to expand internal Merkle nodes into child ProcessRewardsV2 contracts, or create RewardCouponV2 contracts for leaf batches.
UnhideRewardCouponV2Trigger: Publishes reward coupons that were initially hidden from beneficiaries due to failed package vetting checks, checking periodically for updated vetting state.
ExpireRewardCouponV2Trigger: Archives RewardCouponV2 contracts that have exceeded their appRewardCouponLifetime (default 24 hours).
2.5 Daml Model Changes
New templates are introduced in splice-amulet:
CalculateRewardsV2: Request to the DSO to confirm the root hash for a round's app rewards.ProcessRewardsV2: Stores a hash to be expanded into child batches or reward coupons.RewardCouponV2: One coupon per featured app party per round, mintable via AmuletRules_Transfer or CIP-76 MintingDelegations.
The existing AmuletRules_Transfer choice is modified so that for rounds where traffic-based rewards are enabled, no AppRewardCoupon or FeaturedAppActivityMarker contracts are created. The switch is coordinated via a new AmuletConfig parameter and a governance vote.
2.6 Handling Non-Determinism and Fault Tolerance
The implementation aggregates data from five processes per SV node (sequencer, mediator, Scan verdict ingestion, Scan reward computation, SV app triggers), each using its own database. The chance for non-determinism bugs is non-negligible. Two safeguards are employed:
BFT Absorption: The minting workflow is structured so that the DSO's BFT confirmation process absorbs some non-determinism faults. Rounds progress independently, so a stuck round does not block others.
Dry-Run Mode: Before switching to live traffic-based rewards, the entire workflow runs in dry-run mode on MainNet, executing all steps except the final creation of RewardCouponV2 contracts. This surfaces non-determinism and crash-fault tolerance bugs under real production conditions.
Milestones and Deliverables
Based on the incremental rollout specified in CIP-0104 and the technical design, the project is divided into four milestones over a 6-month period.
Milestone 1: Traffic Cost Observability on Scan
| Months after grant approval |
|---|
| Estimated Delivery | Month 2 |
| Focus | Making per-envelope traffic costs observable on Scan from production MainNet data |
Deliverables:
- Canton: traffic summary and view hash APIs on the mediator inspection and sequencer inspection services.
- Scan app: extended
ScanVerdictIngestion to ingest traffic summaries alongside mediator verdicts.
- Scan API: traffic summaries served as part of
/v0/events.
- Feature flag gating in the Scan app configuration, enabled by default once sufficient testing is complete.
- Integration testing on staging environments (CIRL, DevNet, TestNet).
- Unit and integration tests for traffic summary ingestion and serving.
Acceptance Criteria: Traffic summaries from MainNet confirmation requests are observable on the Scan API, enabling network explorers and app providers to compute approximate traffic-based reward previews.
Milestone 2: Activity Records & Reward Computation Infrastructure
| |
|---|
| Estimated Delivery | Month 4 |
| Focus | Precise activity record computation, three-stage reward computation, and Scan API endpoints |
Deliverables:
- Scan app:
ScanTcsStore temporal contract store for FeaturedAppRight, OpenMiningRound, and AmuletRules with as-of-round-start lookups.
- Scan app:
ScanTcsIngestion service feeding the temporal store from the Ledger API.
- Scan app: extended
ScanVerdictIngestion computing activity records per CIP-0104 formula, with round attribution and confirmer-based traffic weight computation.
- Scan app:
ComputeAppRewardsTrigger implementing the three-stage computation (activity totals → reward totals → Merkle-tree hashes).
- Unit tests validating SQL computations match Scala and Daml decimal computations.
- Activity records served via
/v2/events on Scan.
Acceptance Criteria: Precise per-party activity records and reward computations are available on the Scan API for closed mining rounds.
Milestone 3: On-Ledger Reward Workflow, Dry-Run, and MainNet Deployment
| |
|---|
| Estimated Delivery | Month 6 |
| Focus | Daml model changes, SV app triggers, wallet integration, dry-run validation, and the live switch on MainNet |
Deliverables:
-
Daml: CalculateRewardsV2, ProcessRewardsV2, RewardCouponV2 templates with RewardMintingFactory interface and MintingDelegation support.
-
Canton: crash-fault tolerant mediator inspection service.
-
SV app: CalculateRewardsTrigger, ProcessRewardsTrigger, UnhideRewardCouponV2Trigger, ExpireRewardCouponV2Trigger.
-
SV app: ExecuteConfirmedActionTrigger extended for CRARC_StartProcessingRewardsV2.
-
SV app: SV onboarding support via BFT reads from Scan instances with complete data.
-
SV app: admin API endpoint for archiving stuck dry-run rounds.
-
SV app UI: support for new configuration parameters.
-
Wallet app: RewardCouponV2 and MintCoupon lookup for reward minting.
-
Dry-run mode deployed and validated on MainNet, confirming deterministic reward computation across SV nodes.
-
Minimum two-week delay between deploying Dry-run mode on MainNet and enabling actual traffic-based rewards on DevNet. This means that explorers and app builders will be able to see what results would be generated via traffic-based application rewards, and compare them to existing marker-based rewards. Doing this two weeks before enforcing traffic-based app rewards on DevNet means that this computation will be available four weeks before the new rewards logic gets enforced on MainNet.
-
Governance vote to switch from featured app markers to traffic-based app rewards.
-
Monitoring: metrics and alerting for trigger health and hidden reward coupon counts.
-
Resolution of any issues arising during MainNet deployment.
-
All code merged into the open-source Canton and Splice repositories with appropriate unit and integration test coverage.
-
Updated Splice documentation covering the traffic-based reward configuration, new Scan API endpoints, RewardCouponV2 lifecycle, dry-run mode operation, and SV onboarding interaction with reward accounting.
-
Featured app weights and mechanisms for adjusting those weights as proposed in the corresponding CIP-0104 amendment.
Acceptance Criteria: Traffic-based app rewards are live on the Global Synchronizer MainNet, with RewardCouponV2 contracts being created for featured app provider parties each round. Dry-run validation has confirmed deterministic reward computation across SV nodes prior to the live switch. Scale testing confirms the system operates within acceptable bounds at 2026 MainNet scale.
Milestone 4: Protocol-Conformant Free Confirmation Responses
| |
|---|
| Estimated Delivery | Month 6 |
| Focus | Canton protocol changes |
Deliverables:
- Canton: protocol changes so that it only reimburses protocol-conformant confirmation responses as described in CIP-104
- Splice: infrastructure to switch from the heuristic free confirmation responses to the protocol-conformant free confirmation responses.
Acceptance Criteria: MainNet is switched to only reimburse protocol conformant free confirmation responses.
Funding
Total Funding Request: 8,500,000 Canton Coin (CC), plus an early completion bonus of 1,050,000 CC, for a total of 9,550,000 CC.
Payment Schedule:
| Milestone | Amount (CC) | Trigger |
|---|
| 1 – Traffic Cost Observability | 500,000: Digital Asset500,000: Obsidian Systems | Committee acceptance of deliverables |
| 2 – Activity Records & Reward Computation | 1,000,000: Digital Asset1,000,000: Obsidian Systems | Committee acceptance of deliverables |
| 3 – On-Ledger Workflow, Dry-Run & MainNet, Co-Marketing Kickoff | 2,000,000: Digital Asset2,000,000: Obsidian Systems | Successful MainNet deployment and committee acceptance |
| 4 - Protocol-Conformant Free Confirmation Responses | 1,500,000: Digital Asset | Successful MainNet deployment and committee acceptance |
Payment Modalities: Minting rights are to be emitted directly to Digital Asset and Obsidian Systems separately so that each grant recipient can self-mint the CC as specified above.
Early Completion Bonus
We propose an Early Completion Bonus if the work of Milestones 1-3 is completed and deployed on MainNet ahead of the estimated 6-month schedule. We focus on Milestones 1-3, as they deliver the complete functional change. We exclude Milestone 4 (protocol-conformant confirmation responses) from the early delivery criterion, as its roll-out can likely only land with the second Logical Synchronizer Upgrade on MainNet, and its precise delivery time is outside the control of the delivery team for traffic-based app rewards.
| Early Completion | Bonus Percentage | Bonus Amount (CC) |
|---|
| Milestones 1-3 available on MainNet five (5) months after grant approval | 15% of Milestones 1-3 | 525,000: Digital Asset525,000: Obsidian Systems |
Volatility Stipulation
As this project is expected to complete within 6 months, the grant is denominated in fixed Canton Coin.
Co-Marketing
Upon the deployment of traffic-based app rewards, Digital Asset will collaborate with the Foundation on:
- A technical blog post explaining the traffic-based reward mechanism and its benefits for app providers.
- Highlighting the feature in the quarterly Canton Development Fund report.
- Ask Me Anything calls for the application developer community
- Active participation in Slack and Telegram application developer channels
Licensing
All code introduced as a result of work on this proposal will be made available in the Splice Open Source repo, under Apache 2.0 license.
Rationale
The proposed implementation addresses each of the motivating concerns through design choices grounded in the CIP-0104 specification and validated against the existing Splice architecture.
Traffic Measurement at the Infrastructure Layer
By computing app activity from sequencer traffic costs and mediator verdicts — data that already exists as part of the Canton protocol — the system eliminates the need for applications to create on-ledger activity markers. This removes the DSO party from app transactions, reduces transaction size, frees SV validation capacity for economically useful transactions, and makes the reward signal impossible to game through marker creation logic.
Confirmer-Based Attribution
CIP-0104 attributes traffic costs to the confirming parties of transaction views rather than all informees. This is the right choice because confirmers are the parties whose validator nodes actively validate and confirm sub-transactions, directly increasing network integrity. It also gives apps more flexibility to optimize Daml workflows (e.g., adding choice observers for batch optimization) without impacting their rewards.
Scalable Batched Reward Accounting
The current system creates many AppRewardCoupon contracts per party per round via the FeaturedAppActivityMarkerTrigger. The new system computes rewards off-ledger in the Scan app using SQL, achieves DSO consensus on a single Merkle-tree root hash per round, and creates exactly one RewardCouponV2 per party per round. This reduces on-ledger overhead by orders of magnitude and is architecturally compatible with scaling to 100,000+ featured app parties.
Incremental Rollout with Dry-Run Safety
The three-increment rollout (traffic observability → dry-run activity record creation → live switch) gives app providers months of advance visibility into how their rewards will change, while the dry-run mode exercises the full minting workflow under real production conditions before any actual Canton Coin is minted. This graduated approach minimizes risk to the network's economic integrity.
Design Alternatives Considered
| Approach | Advantages | Disadvantages | Decision |
|---|
| Informee-based attribution (reward all informees of a view) | Broader reward distribution | Rewards parties that don't actively validate; discourages batch optimization via choice observers | Not selected per CIP-0104 |
| Per-transaction beneficiary splits defined by app provider | Fine-grained reward sharing | Creates scalability pressure from tracking millions of parties at DSO level; requires DSO party involvement in most transactions | Not selected; apps can implement their own reward sharing using Scan API data |
| Ignore envelope structure (attribute total traffic equally across all confirmers) | Simpler computation | Does not work well for composed transactions; an app's reward would depend on how user activity was composed, not on the app's actual contribution | Not selected per CIP-0104 |
| Weighting via Daml model (app models define their own reward weight) | Apps control their reward share | Canton privacy prevents sequencer/mediator from knowing which Daml models are used; significant complexity increase | Not selected; left for potential future CIP |
| Big-bang deployment without dry-run | Faster delivery | High risk of non-determinism bugs in production affecting actual Canton Coin minting | Not selected; dry-run mode is essential given five interacting processes per SV node |
