A Gap in the current reward framework 

For data consumers operating on Canton today, the economics of onchain workflows are shaped by a reward system that was not designed with their use case in mind. Understanding why requires a closer look at how Canton’s featured app rewards currently work, and where that model falls short.

Featured app rewards used to rely on activity markers to reward relevant activity even when it does not transfer Canton Coin. However, this system has become flawed: the reward weight claimed via markers is not well correlated with the actual traffic generated, validating these markers is complex, and this creates pressure toward centralization (Super Validators must control where and when markers are placed). Furthermore, these markers consume computational resources and reduce the throughput available for useful activity.

For oracle users specifically, this misalignment is significant. Oracle workflows, whether they involve on-demand data requests or continuous feed publication, generate real, measurable onchain traffic. Yet under the current model, that traffic does not translate into proportional recognition within the reward framework. The result is a structural disconnect between the activity data consumers generate and the incentives the network distributes, which creates friction as usage scales.

Better Oracle Economics Through Traffic-Based Rewards

Addressing this disconnect requires shifting the basis of reward attribution away from markers and toward actual network usage. From an oracle consumer’s perspective, this is a meaningful change, and one that has concrete implications for how oracle-related workflows are priced and sustained on Canton.

From Kaiko’s perspective, this evolution changes how oracle-related usage can be reflected in the reward system. When users consume Kaiko oracle services and generate asynchronous traffic on Canton, part of the associated network cost may now be indirectly offset through the app reward mechanism. Kaiko’s services may therefore help users improve the effective economics of their onchain activity through the network’s own reward logic. The key point is that this evolution introduces a cost-offset dynamic, creating a credible path through which a portion of network fees may be compensated.

For users of Kaiko oracle services, the main benefit is improved alignment between the activity they generate and the incentives distributed by the network. Under the new model, rewards are linked to observed traffic and confirmation structures rather than activity markers. This means that when an application relies on oracle-powered data flows and those flows generate eligible onchain transactions, the resulting activity may be more directly reflected in Canton’s reward logic.

Kaiko’s request response oracle for Canton enables users to request licensed market data on demand, while the pull oracle enables the publication of real-time market data from offchain APIs to Canton. Both oracles are part of Kaiko’s Data On-Ramp solution. In both cases, the customer funds an oracle-related workflow that supports a useful business process, whether a data request or a data point validation mechanism based on an artifact of the offchain feed. This new approach may improve the economics of that workflow by making the related network activity eligible for traffic-based reward attribution, subject to the applicable rules. The customer value proposition should therefore be framed around cost efficiency and scalability. As oracle usage grows, users need the economics of their onchain workflows to remain sustainable. Reducing the friction of integrating high-quality market data into Canton applications becomes possible when part of the activity generated by those integrations may be reflected in the reward framework, depending on eligibility, transaction structure, and network conditions.

Users should distinguish between the network fee, the potential reward effect, and the oracle service fee. The network fee reflects the cost of executing activity on Canton. The reward effect may offset part of that cost where the relevant conditions are met. The oracle service fee reflects the value of accessing reliable, validated, production-grade data. Together, these components define the effective cost of consuming oracle services on Canton. This oracle service fee can be structured as a marginal pay-per-use fee, charged per request or per validation process. For customers, this creates a transparent pricing model directly linked to oracle consumption. For oracle providers, it also ensures that the economics of providing oracle services remain sustainable independently from the network’s reward mechanics. Importantly, this does not change the cost-offset narrative: the oracle fee pays for the data service, while the reward mechanism may improve the effective economics of the associated network activity.

It is also important to clarify that paying a higher oracle service fee does not increase the network reward. Transaction network fees depend on transaction size in bytes and on whether a transaction occurs, not on the amount paid. Reward attribution is therefore linked to the technical footprint of the transaction and the relevant confirmation structure, not to the price of the oracle service. Where appropriate, oracle service fees can be positioned in dollar terms while being collected in Canton Coin. This preserves native Canton settlement mechanics while reducing uncertainty linked to CC price volatility, making budgeting and forecasting easier for enterprise users.

How CIP-0104 Implements This Change

The mechanism through which this shift is implemented is CIP-0104, a tokenomics proposal that evolves app rewards on Canton by basing them not on activity markers, but on the actual traffic generated by transactions that modify the state managed by the application. Specifically, app activity markers are replaced by traffic-based rewards, measured directly on the Global Synchronizer using sequencer and mediator data. This allows each app provider to receive a reward share proportional to its observed traffic costs, simplifying governance and aiming to improve fairness among apps. Canton now rewards actual usage rather than marker optimization. CIP-0104 also proposes making protocol-compliant confirmation responses free, so validators no longer pay for the traffic associated with simply confirming. Thus, validator nodes only pay for their users’ transaction submissions.

CIP-0104 therefore aims to align rewards with the actual network cost incurred by app usage, simplify the lives of app builders, reduce the load on the network and service providers, and finally improve decentralization.

Traffic-weighted rewards

The first key change is that rewards are now traffic-weighted. Initially, activity is recorded using Sequencer and Mediator data. The CIP replaces the use of markers as activity records, calculated by observing confirmation requests and their envelope and view structure. The confirmers of a view become the basis for attribution: the traffic credit for a successful confirmation request is allocated to the app provider parties proportionally to the size of the envelopes where they appear as confirmers.

To elaborate on what a confirmer is, it is important to note that in Canton, a transaction is divided into views, each representing a relevant part of the content. The confirmers of a view are precisely the parties whose validators must verify the view and send a positive confirmation. If a view doesn’t receive all the necessary positive confirmations, then the corresponding transaction cannot be committed. Confirmers are therefore essential for validating a view, and this is why CIP-0104 proposes using them as the basis for attribution.

The app provider parties are determined via the [FeaturedAppRight] as they exist at the start of mining rounds. The activity records are then ingested by the Super Validator app from mediator verdicts made available through the mediator scan API and from a new endpoint on the sequencer side. 

The implementation consequence is that the [splice-amulet] Daml code is modified so that [FeaturedAppActivityMarker] and [AppRewardCoupon] are not created as before, no longer serving as activity records.

Round allocation

Regarding round allocation, it should be noted that mining sessions are announced in advance and that at least two sessions are always open for activity recording. Thus, mining rounds overlap (at least two rounds open for activity recording). The CIP proposes attributing each activity record to the earliest round that is open at the time the confirmation request was sequenced (and which will therefore close earliest).

Activity record calculation

The CIP presents the details of activity record calculation, including the fact that for a request involving a single app, all traffic is attributed to that app, and that for a request involving multiple apps, the credit is divided equally between envelopes. Thus, we determine the confirmers per envelope, then we isolate the confirming apps (the parties that have an active [FeaturedAppRight] at the beginning of the round), we then calculate the total traffic of the envelopes that contain at least one confirming app, and finally for each envelope with at least one confirming app, we assign a point to each confirming app:

Per_app_traffic_weight = (envelope_traffic_cost * total_confirmation_request_traffic) / (total_app_envelopes_traffic * num_app_confirmers)

Reward accounting

The CIP adjusts reward accounting by changing how app rewards are minted. Instead of creating multiple [FeaturedAppActivityMaker] and [AppRewardCoupon] contracts per party per round, the DSO (Decentralized Synchronizer Operator) creates one coupon per round for every party, only if the round’s reward exceeds a threshold [appRewardCouponThreshold] (default $0.5).

Coupons have a lifespan [appRewardCouponLifetime] (default 24 hours from creation), allowing app providers to batch their minting across multiple rounds, thus reducing their traffic costs and the load on the DSO. Note that amounts below the thresholds are burned, and therefore no coupon is issued.

Regarding the details of app reward calculations, the proposed implementation only supports featured apps. In summary, the round-based calculation method involves summing the weights to obtain [total_featured_app_traffic], reading the traffic price [traffic_price_in_CC_per_MB] via [AmuletRules] at the start of the round, calculating the corresponding CC burn [total_featured_app_burn_CC], deducing [issuance_per_featured_app_weight] using the whitepaper’s issuance formula by setting [total_unfeatured_app_burnCC=0], applying the coupon threshold (converted to CC via the round’s conversion rate), and finally calculating the minting allowance per app provider proportionally to its [total_app_traffic], then setting it to 0 if it falls below the threshold.

Canton: The Infrastructure Built for Regulated Finance

To appreciate the full scope of what this shift means, it helps to understand the environment in which it operates. Canton is a blockchain infrastructure designed for institutional and regulated markets. Unlike most public blockchains, which prioritize universal transparency, Canton allows financial institutions, asset managers, market infrastructures, and other regulated participants to exchange assets and data on a shared network while preserving confidentiality, compliance, and operational control.

Its key innovation is to combine interoperability with selective privacy. Participants and applications can interact through a common infrastructure layer without exposing all transaction data to every network member. This is particularly relevant in financial markets, where sensitive information must often be shared only with the parties directly involved.

Canton therefore aims to combine the benefits of distributed ledger technology, such as automation, synchronization, and reduced post-trade friction, while meeting the governance and confidentiality requirements of regulated finance. The Canton Validator Network supports this architecture. Validators validate the transactions relevant to them, while Super Validators operate the Global Synchronizer, which provides the shared ordering and coordination layer.

Canton’s tokenomics define how network usage, fees, and rewards are structured within the ecosystem. They determine how activity on the network is paid for, how incentives are distributed, and how economic participation is aligned between users, validators, and application providers. CIP-0104 should be understood in this context: as a proposal to adjust how app rewards are allocated based on actual network usage, and a concrete step toward making Canton’s economic model work better for the participants who are building real, data-driven applications on top of it.