Like most public blockchain networks, the Canton Network charges a fee for its use. Canton users pay two types of fees to use the Global Synchronizer (i.e. network): synchronizer traffic fees and holding fees.

Unlike most others, the synchronizer traffic fee is fixed at a certain amount of USD per MB of bandwidth or "synchronizer traffic". Although fees are quoted in USD, they are paid using the network's native utility coin: Canton Coin (CC). Currently, the price for 1MB of traffic on the Canton Network is $60 USD.

Besides the "synchronizer traffic fee", the Canton Network also charges a "holding fee". A holding fee is a fixed cost associated with maintaining an active Canton Coin record (UTXO) on the ledger.

Fee parameters, traffic pricing, limits, and related tokenomics settings are subject to change via a 2/3 majority of Super Validators and the Canton Improvement Proposal (CIP) process.

Synchronizer Traffic Fees

What Are They?

Global Synchronizer Traffic Fees represent the cost of consuming synchronization capacity or "bandwidth" on the Canton Network.

What Counts as Traffic?

Traffic refers to all messages from participants that must be sequenced on the network.

Most prominently, traffic is consumed by Daml workflows as part of the Canton transaction processing protocol, including confirmation requests (sent when a participant initiates a transaction) and confirmation responses (sent by participants who host stakeholders of a transaction). Not only custom Daml workflows count towards traffic spend - automated "built-in" workflows such as rewards collection also use traffic.

In addition to Daml workflow messages, participants also use traffic for submitting topology transactions (for example, allocating new parties or vetting newly uploaded DAR packages) and exchanging periodic ACS commitments to ensure synchronisation.

Importantly, traffic accounting is "by participant": all parties hosted on the same participant share the same traffic balance.

The Base Rate: Everyone Gets Free Traffic

Every participant receives a limited amount of synchronizer traffic free of charge via a base-rate allowance. The base rate is defined as a burst amount over a time window, so that even when fully depleted, the available base-rate traffic balance recovers fully after a "window"-long period of inactivity.

Usage beyond this allowance consumes paid traffic (also called "extra traffic"), which is charged by burning Canton Coin. The base rate traffic balance is always consumed first; extra traffic is only drawn down when the base rate is fully depleted. When neither base rate nor extra traffic balance is available, the sequencer will deny further submission attempts until either the base rate recovers or extra traffic is topped up.

Traffic Pricing Parameters

The current synchronizer traffic parameters are recorded in the global AmuletRules contract and can be retrieved via the Scan API using the /api/scan/v0/amulet-rules endpoint.

For example, this returns a JSON object containing:

{

  "baseRateTrafficLimits": {

    "burstAmount": "400000",

    "burstWindow": { "microseconds": "1200000000" }

  },

  "extraTrafficPrice": "60.0",

  "readVsWriteScalingFactor": "4",

  "minTopupAmount": "200000"

}

‍

To explain these fields:

• baseRateTrafficLimits defines the free tier. Validators can use up to burstAmount bytes within a burstWindow time window without incurring fees. The free balance is restored periodically and always reaches its maximum after a full burstWindow of inactivity.
• extraTrafficPrice is the price of paid traffic beyond the free tier, denominated in USD per MB. The price is charged in Canton Coin as per the current USD/CC exchange rate, which is determined by SVs via median voting and recorded on current OpenMiningRound contracts obtainable from Scan.
• readVsWriteScalingFactor specifies the additional traffic charged for delivering a message to each recipient (in basis points per 10,000). For example, at a factor of 4, a 1 MB message with 10 recipients draws 1,000,000 x (1 + 10 x 0.004) = 1,040,000 bytes from the sending participant's balance.
• minTopupAmount is the minimum amount of traffic that must be bought in a single purchase, protecting SVs from disproportionate overhead from very small top-ups.

The Burn Mechanics

To "buy" traffic, Canton Coin is burned by the participant and converted into extra traffic balance. On-ledger MemberTraffic contracts track each validator's traffic state and are updated atomically whenever CC is spent for buying traffic. SVs then update the in-sequencer traffic state based on the MemberTraffic state they observe on the ledger, ensuring paid traffic fees are translated into actual traffic balance increases.

The validator app contains built-in top-up automation that automatically buys traffic to meet pre-configured throughput needs. Operators configure a target throughput (bytes per second) and a minimum top-up interval (seconds). Note that traffic is non-transferable - traffic balances cannot be converted back to Canton Coin.

How This Supports the Burn-Mint Equilibrium

Canton Coin employs a burn-mint equilibrium mechanism. Instead of paying fees directly to network infrastructure providers, all fees for using Canton Coin and for creating a traffic balance on the Global Synchronizer are burned by the user who submits the transaction. In return for operating applications and network infrastructure, providers can mint new Canton Coins. Thus, the usage fee from the user to the provider is indirect via the burn-and-mint mechanism.

This creates a self-correcting price mechanism: as more participants use the network and burn CC for traffic, supply decreases, which tends to increase the CC/USD rate, which in turn decreases the number of CC needed per MB - and vice versa. You can read more about this in the Canton Coin Whitepaper.

Holding Fees

A holding fee is a fixed cost associated with maintaining an active Canton Coin record (UTXO) on the ledger. It is computed per round but not charged continuously to active participants.

Following CIP-0078, holding fees no longer apply to Canton Coin transfers. Instead, they accrue notionally over time and are only enforced if Super Validators explicitly expire a coin whose accrued holding fees meet or exceed its coin amount. When a coin is expired, the entire coin amount is charged as holding fees, the coin amount is burned, and the coin contract is archived.

This mechanism exists to limit the lifetime of long-lived, low-value ("dust") coin contracts and to bound ledger growth. It does not affect actively used coins or normal transaction flows.

Earning Rewards by Transacting on the Network: CIP-0104 Explained

One of the most significant recent developments in Canton Network tokenomics is CIP-0104: Traffic-Based App Rewards, approved on February 12, 2026.

CIP-0104 proposes to improve the quality of app reward incentives by removing featured app markers and instead basing an app's rewards on the actual traffic spent on transactions that change the state managed by the app. This is achieved by measuring traffic spent directly on the Global Synchronizer using sequencer and mediator data.

In the post-CIP-0104 model, application rewards are derived directly from the actual Global Synchronizer traffic spent on successful confirmation requests involving a featured application. This transition replaces governance-defined marker issuance with a protocol-measured, traffic-weighted model, ensuring rewards are directly aligned with measurable economic activity on the network.

In practical terms: the more meaningful traffic your application drives on the network, the more Canton Coin your application can earn back through minting - creating a direct and transparent link between usage and reward.

This CIP also proposes to make protocol-conformant confirmation responses free, so that validator nodes only pay for the submission of transactions by their users - an action validators can explicitly gate and charge for if required. This enables validator operators to manage traffic costs and fosters decentralization of apps and wallets.

Key CIPs That Shape the Fee Model

The Canton Network fee structure has been revised through the CIP governance process. Changes require approval by a 2/3 supermajority of Super Validators and apply only to future activity.

Running a Canton Validator

Understanding the fee model is useful. Managing traffic balances, automating top-ups, and monitoring validator health across production deployments is a different challenge.

CatalyX Blockchain Manager, built by IntellectEU as a founding member of the Canton Foundation, provides the infrastructure management layer for Canton validator operators - from node deployment to operational tooling. Whether you're running a single validator node or managing fleet-scale infrastructure, the platform handles the operational overhead so your team focuses on building.

Interested in Canton Network participation? Explore CatalyX Blockchain Manager and reach out to the IntellectEU team to discuss your setup.

Most financial institutions enter the digital asset space looking for yield. They see "staking" as a fixed-income proxy way to earn 4-5% APY on held assets. But this "yield trap" obscures the real operational requirement of enterprise blockchain: settlement.

When a bank issues a digital bond or a payment processor settles a cross-border transaction, they aren't "voting" on network consensus. They are writing critical financial data to a shared ledger. This requires a fundamental shift in infrastructure strategy from passive validator setups designed for rewards to active, high-availability blockchain node infrastructure designed for read/write performance.

The Institutional Misconception: Yield vs. Utility

Search volume data paints a clear picture: "staking as a service" dominates institutional inquiries. It looks and feels like a financial product. You deposit assets, you get a return. It fits neatly into existing asset management workflows.

However, operational utility is an IT function, not an asset management one. When an institution moves from holding tokens to using the network - for Repo settlement, intraday payments, or bond issuance - the infrastructure requirements change drastically.

A staking provider’s primary goal is to avoid slashing (penalties for downtime). If a staking node goes offline for ten minutes, you lose a few dollars in rewards. It’s an annoyance. Conversely, if an operational node responsible for a DVP (Delivery vs. Payment) settlement goes offline for ten minutes, a billion-dollar trade fails. The counterparty risk skyrockets. Regulatory reporting windows are missed.

Banks don't need a passive yield generator. They need a crypto infrastructure for banks that guarantees message delivery and settlement finality.

Defining the Infrastructure: Validator Nodes vs. Participant Nodes

To understand the gap, we must distinguish between the two primary node types in enterprise networks like Canton.

• Validator Nodes: These participate in consensus. They propose blocks and vote on validity. Their "uptime" metric is geared towards network health, not individual transaction speed.
• Participant (Read/Write) Nodes: These are the gateways for business applications. They listen to the ledger for relevant events (Read) and inject signed transactions (Write).

For a tokenization use case, the Participant node is your lifeline. It connects your internal legacy systems (like a core banking platform) to the blockchain.

A platform like CatalyX Blockchain Manager handles both. It allows a bank to spin up a Validator for the trading desk to earn yield, while simultaneously deploying a high-availability Participant node cluster for the payments team. All managed within the same environment.

The "Read/Write" Reality: Connectivity Over APY

An operational node is useless if it stands alone. Its value comes from connectivity.

Unlike a staking node, which largely communicates peer-to-peer with other blockchain nodes, an operational node requires high-throughput API connections to internal bank systems. The challenge isn't just syncing the ledger; it's getting data out of the ledger and into a risk management dashboard in milliseconds.

This brings us to the concept of enterprise blockchain nodes designed for High Availability (HA) and Geo-Redundancy. If your primary data center in New York goes dark, your node infrastructure must failover to London automatically, without dropping the mempool or missing a settlement instruction. Standard staking providers rarely offer this level of intricate, application-layer failover because their business model relies on simple uptime for rewards, not complex transaction routing.

Security Architectures: MPC Wallets vs. Node HSMs

Security in settlement is distinct from security in custody.

Institutional crypto custody often relies on MPC (Multi-Party Computation) wallets. These are excellent for human-approved transfers, where a quorum of officers must sign off on a transaction. Ideally, this process is slow and deliberate.

Operational nodes, however, need to sign transactions programmatically, often thousands of times per hour. You cannot have a human approving every automated market maker trade or dividend payout.

This requires deep integration with Hardware Security Modules (HSMs). Your blockchain node infrastructure must be able to access signing keys securely within an HSM environment (like AWS CloudHSM or Azure Key Vault) to sign transactions automatically, without the keys ever being exposed to the application layer.

Case Study: Operational Finality in Societe Generale’s Digital Bond

The theoretical need for robust infrastructure became operational reality on November 18, 2025. Societe Generale-FORGE (SG-FORGE) completed its first digital bond issuance in the United States, a landmark event for institutional adoption.

The issuance didn't happen on a testnet. It settled on the Canton Network, utilizing Broadridge’s tokenization capabilities. The stakes were high: this was a live financial instrument, a short-term floating rate note purchased by DRW.

To ensure the settlement occurred instantly and securely, SG-FORGE and Broadridge didn't rely on generic staking setups. As detailed in the official announcement, they utilized CatalyX Blockchain Manager to operate their respective nodes on the Canton Network’s Global Synchronizer.

This choice highlights the critical nature of the "plumbing." SG-FORGE needed guaranteed delivery. They needed a platform that could deploy and manage Canton Network nodes with enterprise-grade reliability, ensuring that when the "issue" command was sent, the node executed it without latency or failure. Staking yield was irrelevant; operational finality was everything.

Source: Societe Generale Issues First Digital Bond in the US

Building for Reliability

The "crypto casino" phase of institutional adoption is fading. The next phase is about plumbing: building the rails that allow trillions of dollars in real-world assets to move on-chain.

Institutions must stop evaluating infrastructure vendors solely on APY or low fees. You get what you pay for. If your node goes down during a settlement window, the cost of that failure will dwarf any staking rewards earned that quarter.

Ensure your institution’s infrastructure is ready for settlement, not just speculation. Explore CatalyX Blockchain Manager for enterprise-grade node operations that prioritize business continuity.