background/tokenomics/traffic_tokenomics

[giscus[bot]]

background/tokenomics/traffic_tokenomics

https://docs.sync.global/background/tokenomics/traffic_tokenomics.html

[waynecollier-da]

A general overview of traffic management:

Traffic management has two main aspects:

Making sure the node has enough CC to purchase more traffic
Making sure the node doesn't run out of traffic before it has time to purchase more.
You might imagine that you can handle this by setting up a lower and upper bound for traffic, so that any time a node reaches the lower bound it immediately buys enough traffic to reach the upper bound; and then making sure that you always have enough CC in the node's wallet to buy at the upper bound for, say, several days or weeks. But traffic topups work don't quite work this way, because the lower bound does not automatically trigger a new topup.

Instead, the node operator sets

a target throughput: how much traffic (in bytes) they think they will consume per second
a minimum topup interval: How long to wait until topping up again
Multiplying these together gives the topup amount. So if you set 20 MB/sec as your throughput and 100 seconds as your interval, your topup amount is 2000 MB.

So when does your node top up in this example? The node tops up traffic when its balance falls below 2000 MB, and it has been at least 100 seconds since the last topup.

This second condition--the time elapsed since the last topup--is where a node can run into trouble: a node gets a burst of activity that drains its traffic balance to zero before the minimum topup interval is complete, and the node goes silent.

Why the time delay, instead of simply topping up immediately? To help the node operator avoid spending down the node's CC without a chance to intervene, in the case of a bug (or an attack) that causes runaway submissions.

This is fundamentally a defensive stance for you as a node operator: you operator need to monitor the node actively to get these settings right. Set the topup interval too short, and you could run out of Canton Coin before you notice it. Set it to long, and your node could run out of traffic before the next topup.

Both problems do come up: a node with a long topup window gets a burst of new user activity, and stops transacting. Or a node has too little Canton Coin in its operator wallet, runs out, and fails to purchase new traffic, which also stops the node from transacting.

The Splice team has provided a sample traffic monitoring dashboard here:

https://github.com/hyperledger-labs/splice/blob/main/cluster/pulumi/infra/grafana-dashboards/canton-network/synchronizer-fees-validator.json

If your node does run completely out of traffic it's possible to top up its balance through another node, either using Denex Gas Station, or by using direct traffic purchase commands via party hosted on a node other than the one that ran into trouble:

https://docs.dev.sync.global/app_dev/validator_api/index.html#buying-traffic

[kctam-da]

How to read one's Validator reward and Liveness reward

Each node operator receives a validator reward in each round. The validator reward is divided into two parts:

• Validator reward due to burning CC: Almost all CC burn nowadays is for traffic purchase. Currently the capped reward issuance rate for this reward is 0.2.
• Liveness reward: This is the reward for a node being available to validate and confirm transactions. Note that this reward will be capped and finally removed (per CIP-96).

The validator reward a node operator receives is the summation of these two types of rewards. If a node has not purchased traffic in a given round, it only receives the liveness reward.

All information about reward is available to most explorers. Here are two examples from Cantonscan.

Example #1
https://www.cantonscan.com/event/12203ddc6863a65f60f2e01846f131e47b9af7d9229fb573a8d20030f2a7c6ea1e2f:0

This is a minting transaction. From “summary” in the “Raw JSON” data, we can see

      "inputValidatorFaucetAmount": "17.1414858240",
      "inputValidatorRewardAmount": "17.1414858240",

The inputValidatorRewardAmount is the liveness reward in CC. As in this example, these two numbers are the same. This means that no CC was burned, and the Validator Reward received in that round was just the liveness reward.

Example #2
https://www.cantonscan.com/event/1220fde4281a970a8ec98c04790605d9ab91759d95583385af36a87557cf1f777873:0

This is another minting transaction. From “summary” in the “Raw JSON” data we can see

      "inputValidatorFaucetAmount": "16.3784067086",
      "inputValidatorRewardAmount": "252.2274633124",

The Validator Reward is the total reward the node operator received. And the Validator Reward due to burning CC is 252.2274633124 - 16.3784067086 = 235.8490566038

How the Validator Reward due to burning CC is calculated

Here is the transaction of traffic purchase which caused the CC burn in Example #2:
https://www.cantonscan.com/update/1220c226734df11a2bbc8cc6cbfd045db0d5c0bd811b79499d8abca061c37302dab2

We can see most of the details of this transaction in event ID 0. Here is the calculation.

• At round 86545, 3 MB traffic was purchased.
• At a traffic fee of $60/MB, the cost was $180.
• CC price was $0.15264 in this round.
• The traffic cost in CC  = 1179.2452830189

A Validator Reward Coupon was created (event ID 7) to record this CC burn.

  "templateId": "67fa..a791:Splice.Amulet:ValidatorRewardCoupon",
  "contractId": "0037..1b8a",
  ..
  "createArguments": {
    "dso": "DSO::1220..accc",
    "user": "kora-mainNetValidator-1::1220..a7d0",
    "round": {
      "number": "86545"
    },
    "amount": "1179.2452830189"
  },
  "createdAt": "2026-03-08T17:12:53.908Z",
  ..
},

The traffic purchase was made in round 86545 (recorded in the coupon), created at 2026-03-08T17:12:53.908Z.

The Validator Reward Rate for this round 86545 is 0.2. Therefore the actual Validator Reward due to burning CC = 1179.2452830189 * 0.2 = 235.8490566038, which is exactly how we observed in Example #2.

Note:

• The Validator Reward Coupon is created in every traffic purchase, not during a transaction is being processed by the Global Synchronizer. If transactions are processed within the free traffic (200 kB per 20 minutes), no traffic purchase is needed and therefore there is no Validator Reward for those transactions.
• The minting transaction (Example #2) happened in round 86548 and the time of the transaction was 2026-03-08T17:37:54.052Z. The minting is always three rounds (~20-30 minutes) after the actual activity (burning CC). You can refer the Canton Coin Whitepaper about the phases of a round.

[waynecollier-da]

To clarify, it's true that nearly all CC burn today results from traffic purchases. But to be clear, all CC burn that results in Validator rewards comes from traffic purchases. The only other CC burn that happens is when the Super Validators burn UTXOs whose value is lower than their accumulated holding fees, and that burn does not produce any rewards.