CIP-0120 - Traffic-Based Validator Rewards and Confirming Validator Incentives - David Richards, Simon Meier and Bernhard Elsner

1. Is it possible to provide some plain-text examples of validator incentives in the current implementation vs. this future proposed implementation?  A typical featured application runs its own validator in a 1-of-1 set-up today and tentatively will be required to multi-host its parties into a 3 validator set-up in the future.

Plain text examples provided below.

Current Implementation (Traffic Purchase-Based)

• In the current model, validator rewards are based entirely on the Canton Coin (CC) that is burned to purchase traffic, not based on individual transactions.
• Taking the CIP-0112 Settlement example transaction from the document where the transaction size = 400 bytes. There's no impact on the validator's rewards for executing the transaction, only when the validator subsequently burns CC to replace the traffic that was used in that transaction (or when the CC was burned initially to pay for the traffic that was used - however you account for it).
• If a validator operator burns CC to buy 400 bytes worth of traffic (it will likely burn CC to purchase much more than 400 bytes of traffic since that's such a low amount and will likely be under the minTopupAmount for burning CC), they receive 100% of the validator reward weighting allocation for that specific burn.
• This happens regardless of whether they actually spend the traffic or which validators confirm the transactions.
• The Reward Pool & Cap: These CC burn amounts act as reward weightings. At the end of the process, all weights are totalled across the network, and the round's validator reward pool is divided proportionally among all validators based on their share of the total. During periods of high network activity, the validator rewards portion of all rewards that round hit a hard 20% cap. The impact of this current cap is that during traffic spikes, validators' rewards are limited and fail to scale appropriately with their actual workload.

Proposed Implementation (Traffic Spend-Based)

• Under the new CIP, rewards are not based on CC burn for traffic but on the actual bytes of traffic spent during a successful transaction commitment.
• In the CIP-0112 settlement scenario—a 400-byte transaction with three 100-byte views (Root, Debit, Credit) where the executor, sender, receiver, and admin parties are all decentralized across 3 nodes each—the activity records are split as follows:
  • The Submitting Validator: The node submitting the transaction (the executor wallet submitting node) receives the full 70% share of the transaction's activity record weight.
  • The Confirming Validators: The remaining 30% of the activity record weight is divided among the nodes confirming the transaction. Because every party in this scenario is hosted on 3 nodes, this 30% pool is fully captured and distributed exactly like this:
    • Executor Nodes: The 3 nodes earn a combined 38.89% of the confirmation reward pool (12.96% per individual node = 51.84 reward weight).
    • Admin Nodes: The 3 nodes also earn a combined 38.89% of the confirmation reward pool (12.96% per individual node = 51.84 reward weight).
    • Sender Nodes: The 3 nodes earn a combined 11.11% of the confirmation reward pool (3.70% per individual node = 14.8 reward weight).
    • Receiver Nodes: The 3 nodes earn a combined 11.11% of the confirmation reward pool (3.70% per individual node = 14.8 reward weight).
• The Reward Pool & Cap: Just like the current model, these activity records are totalled across the entire network, and the validator reward pool is divided proportionally among the nodes that earned them - no change there. However, to offset the fact that submitting validators now share 30% of their rewards with confirmers, the proposed CIP increases the dynamic minting cap from 20% to 30% during high-burn periods. The impact of raising this cap is straightforward: it gives validators the necessary headroom to access unminted CC supply during traffic spikes, ensuring their final compensation better reflects their actual workload rather than being prematurely cut off.

2. Do confirmations cost actual traffic?

3. Is it correct to assume that the baseline expectation for a validator's rewards will increase after this change e.g. 20% today vs. 21% (0.7 * 30%) in the future?

4. If featured applications are required to multi-host and co-validate transactions, is this change in tokenomics really needed?  Multi-hosting / co-validation services can charge the featured app directly for this service