If we run our own dedicated synchronizer, do we still need to connect to the Global Synchronizer?

Running your own synchronizer on Canton used to mean paying a licence and sitting outside the network's fee economy. That's ending, and the wiring question changes with it.

Think of a synchronizer as the clerk who stamps each message with its place in the queue, so both sides of a trade agree on what happened and when. The Global Synchronizer is the clerk everyone shares, staffed by the Super Validators, the firms that vote on how Canton runs. A dedicated synchronizer is a clerk you hire, or rent from a provider, for your own workload.

The short answer, as of 12 November 2026, is no for your machines and yes for your money. Under the plan now on the table, your participant nodes (the servers that hold your slice of the ledger) would not need a Global Synchronizer connection to keep working. Your organisation still would, through one party called the paymaster, which burns Canton Coin there for the traffic you use. That plan is a draft, and the current docs say something stricter.

Why this came up this week

Two things landed on 10 November. Digital Asset published an MOU it signed with Progmat, a Japanese security token platform. The two plan to tie tokenised Japanese government bonds to the book-entry transfer register, the official record of who owns each bond, and they say they'll start studying a service that lets financial institutions use Canton nodes without building their own. The release names no synchronizer.

The same day, Moritz Kiefer of Digital Asset posted a draft CIP (a Canton Improvement Proposal, the network's change process) setting out how dedicated synchronizers would pay their way.

If a bank in Tokyo rents a Canton node through a service like that, this is the first question its architecture team asks. I think it's the right one, because the answer decides who in the bank holds Canton Coin and who signs off on the bill.

What is confirmed

ConfirmedCIP-0129, Universal Burn and Synchronizer Pricing, carries the status Approved in the Canton Foundation's CIP repository, with an approval date of 23 October 2026. It says traffic on dedicated synchronizers "doesn't burn anything" today and has "historically" been paid for through licence fees to Digital Asset.

The approved framework moves every synchronizer running production workloads onto burn at the Global Synchronizer's list price, which the CIP gives as $60 per MB of traffic before rewards. Volume pricing and commitment discounts are left to a second CIP.

So the money side is settled in principle. Dedicated synchronizers are set to pay into Canton Coin. The timing isn't settled. CIP-0129's own table puts universal burn in Q1 2027 and volume pricing in Q3 2027, and calls those dates "ambitious estimates", not deadlines.

What is announced

AnnouncedThe Canton docs page on dedicated synchronizers, which I read today, lists three obligations for anyone running one. Its validators, the firms running nodes that confirm transactions, "will be required to burn CC on Canton Network in the near future". The synchronizer "must remain compatible with the Global Synchronizer at all times". And operators "must maintain a persistent connection to the Global Synchronizer for accounting and settlement purposes", because that connection is how fees are calculated and the burn is paid.

The same page draws a line on reach. Participants connected to both synchronizers can transact on either. A participant connected only to the Global Synchronizer "cannot interact with contracts on the dedicated synchronizer". Canton Coin operations always run on the Global Synchronizer.

These are the network's own docs, so they stay at announced. Nobody outside the project has yet shown them working for a named institution.

What is proposed

Draft, not adoptedThe 10 November draft, named the Dedicated Synchronizer Paymaster Model, sits as pull request 289 in the Foundation's CIP repository and was still open when I checked today. It's the first technical step of universal burn. The dedicated synchronizer would report its traffic in 10-minute intervals, and a trusted paymaster would pay for it after the fact by burning Canton Coin on the Global Synchronizer.

Then comes the sentence that answers the question. In the draft's words, "a gSync outage has no effect on the dSync and participants can connect only to the dSync with no requirement to also connect to the GSync."

Three details matter to an operations team.

• No traffic enforcement in this phase. A message is never rejected because a node has run out of traffic credit.
• Discounts would be an off-ledger agreement between the Super Validators and the operator. The draft's example burns for 50MB when the report shows 100MB used.
• A side deal could let a paymaster burn late, up to 14 days in one of the draft's examples, to smooth the cost.

The synchronizer would be registered on-ledger by a Super Validator vote that names its paymaster. The paymaster would earn validator rewards on what it burns, and app rewards too if it holds a featured app right. Yiannis Varelas of Five North replied the same day that his firm would like to sponsor the draft.

Where the docs and the draft disagree

Not confirmedSide by side, the docs say the operator must stay connected and the draft says participants needn't. Not confirmed, and this is my own reasoning, but I think both can hold at once, because the obligation moves from every node to one party. Your trading nodes run on a private road, and the toll is paid at the main gate by whoever you name as paymaster.

For a bank that's a cleaner design than it first sounds. A Global Synchronizer outage wouldn't stop your settlement. Your sensitive flows wouldn't share an ordering service with the whole network. But the toll booth still stands on the main road, so somebody in your organisation, or at your provider, holds Canton Coin, buys traffic with it and answers for the burn being right.

That last part is where my day job lens kicks in. In this phase the draft says the operator and paymaster "are trusted" to report usage correctly. The traffic report is the record the whole bill rests on, and it's self-reported. If I sat on a bank's controls team, I'd want to know who reconciles that report, against which logs, and how often.

What is still open

The draft is a draft. It has no CIP number yet, and nothing says when the Super Validators vote on it. CIP-0129 calls its own timeline an estimate. The docs page and the draft disagree on connectivity, so one of them has to change. Progmat's release doesn't say whether its node service would use the Global Synchronizer, a dedicated one, or both.

Reach still cuts one way. A participant that sits only on your dedicated synchronizer can't touch Canton Coin, or contracts assigned elsewhere, until it connects. If your workflow needs a cash leg or a counterparty on the shared network, you'll connect anyway, and the road question becomes a junction question.

What to ask your vendor

If you run a dedicated synchronizer today, which legal entity becomes your paymaster when the licence ends?

The Sunday letter tracks this draft to its vote. Get it on Substack.

References and further reading

1. Moritz Kiefer (Digital Asset), CIP Draft: Dedicated Synchronizer Paymaster Model, cip-discuss, 10 November 2026 (lists.sync.global)
2. Canton Foundation CIPs, pull request 289, Add DSync Paymaster Model CIP (Status: Draft, open when read on 12 November 2026) (github.com)
3. Yiannis Varelas (Five North), reply offering sponsorship, cip-discuss, 10 November 2026 (lists.sync.global)
4. CIP-0129, Universal Burn and Synchronizer Pricing (Status: Approved, 23 October 2026) (github.com)
5. Canton documentation, Dedicated Synchronizers, read 12 November 2026 (docs.canton.network)
6. Canton documentation, Connecting a Validator to Multiple Synchronizers (docs.canton.network)
7. Digital Asset, Strategic collaboration toward accelerating the on-chain transformation (Progmat MOU), 10 November 2026 (blog.digitalasset.com)