Questions on Global Synchronizer metadata, dedicated synchronizers and reassignment (docs checked 2026-11-02)

Hello. While reading the Canton Network documentation and this forum, I found points that I could not confirm from public material, or where pages seem to say different things. Each question cites the page and the exact wording. Answers to any single question are welcome, and please feel free to correct me if I misread something.

1. What metadata can the Global Synchronizer see?

• Ordering Consensus (last modified 2026-08-21): “Sequencers forward opaque (encrypted) messages. They see metadata — recipient lists and message sizes — but not transaction content.” and “The sequencer strips sender information before delivering messages to other parties.”
• Privacy Model (last modified 2026-05-13): “participants see neither any transaction payload nor metadata like involved participants or parties. The synchronizer sees none of this—only encrypted messages and confirmation results.” and “No metadata leakage about parties not entitled to see an action”.

These two pages read differently to me.

• Are the recipient lists the sequencer sees at the node level or the party level?
• Does the sequencer know the sending node?
• Can operators see timestamps?
• What does the mediator see?

2. How are sequencers and mediators operated, and what logs exist?

• The Canton FAQ says the Global Synchronizer is operated by “~60 independent Super Validators”, and also: “There are currently 13 Super Validator operators who operate the software on behalf of all SVs, of which there are ~60”.
• CIP-0045 also says some SVs share the Foundation’s multitenant SV node.

Questions:

• (a) How many sequencers and mediators does each of the 13 operators run, and how many are there in total?
• (b) Does an operator that runs nodes on behalf of other SVs also see the sender and recipient nodes and timestamps for what those SVs process?
• (c) When one contract or transaction is processed, do all operators take part, or only some? If only some, how are they selected?
• (d) Are logs such as sender and recipient nodes and timestamps stored? Is access to them controlled? How are they audited externally?

3. An approved Global Synchronizer node connecting to a third party’s dedicated synchronizer

Dedicated Synchronizers (last modified 2026-10-26), section “Connecting to a Dedicated Synchronizer”: “The connection requires the sequencer’s endpoint URL and appropriate authentication credentials.” It does not mention Foundation approval.

• When a node already approved on the Global Synchronizer additionally connects to a dedicated synchronizer run by a third party, is any approval from, or notice to, the Foundation or the Global Synchronizer required?

4. Conditions for moving contracts from a dedicated synchronizer to the Global Synchronizer

• Private Validators (last modified 2026-10-19), “Migrating to Global Synchronizer later”: “As needed, reassign contracts that need network-wide visibility from the dedicated synchronizer to the Global Synchronizer.”
• Reassignment Protocol (last modified 2026-05-12): the nodes of the contract’s signatories confirm the reassignment.
• Forum thread Reassignment Risk with Positive Key Lookups (2026-10-02): the reply says “multi-synchronizer is still early stages”, that any stakeholder can submit a reassignment, and that per-package reassignment rules are “not currently on the roadmap”.

Questions:

• Should reassignment currently be understood as an early-stage (alpha) feature?
• Are there additional conditions, such as recognition of the issuer or checks on the issued amount?
• Does the Global Synchronizer separately check the history on the dedicated synchronizer?

5. Dedicated synchronizer requirements and what happens if they are not met

The “Dedicated Synchronizer Requirements” section of the same page says: “a dedicated synchronizer’s validators will be required to burn CC on Canton Network in the near future”, “must remain compatible with the Global Synchronizer at all times”, and “must maintain a persistent connection to the Global Synchronizer for accounting and settlement purposes.”

• What happens if these requirements are not met?
• When will CC burning start and how will it be calculated?
• Is there advance notice and a grace period when requirements change?

6. Can anything prevent normal transactions on a dedicated synchronizer that does not meet the requirements?

Scenario: the issuer’s node and the counterparties’ nodes are all verified on the Global Synchronizer, and the earlier contracts were created there. They then consume and create their own contracts, following the correct procedure, on a dedicated synchronizer that is not approved and does not use CC for fees.

The requirement wording in question 5 only says “required”. I could not find any enforcement mechanism or penalty in the documents, and the connection procedure (question 3) shows no approval step.

• Is there any technical or governance mechanism that can prevent such transactions?
• Can the Global Synchronizer side tell that they happened?
• Is there any penalty for validator status or rewards?

7. Tokens issued beyond their backing

In CIP-0056 (Final, approved 2025-03-31), a Holding is a contract signed by the owner and the issuer, and total supply is optional. I could not find anything saying the protocol verifies that the issued amount matches the backing.

• Does the protocol prevent an issuer from issuing more tokens than its backing, or does it rely on trust in the issuer and registry and on external audit?
• Is there a recommended practice?

8. Criteria for the Global Synchronizer to accept assets issued or exchanged on a dedicated synchronizer

I could not find, in the documents for questions 4 and 7, any criterion for an issuer to be “recognized” on the Global Synchronizer.

• If an issuer recognized on the Global Synchronizer issues or exchanges assets on a dedicated synchronizer, can those assets then be used on the Global Synchronizer without problems?
• Are there conditions?

9. Reassignment versus “consume and recreate”

The Cross-Synchronizer DvP Example (last modified 2026-09-03) only describes reassigning assets to a common synchronizer and then settling. It does not describe consuming a contract and creating a new one on the target side. As noted in question 4, reassignment appears to be at an early stage.

• Is consume-and-recreate a supported pattern?
• Compared with reassignment, which does Canton recommend, and when?

Thank you.