“Validator” renaming proposals
The term "validator" typically refers to participants in public blockchains with staked assets and sign blocks or transactions to reach consensus. However, Canton validators operate differently—they don't receive economic security from stakers, but instead earn rewards based on utility metrics like uptime and Canton coin activity.
From the architecture, I see Validator nodes functioning as gateways to access the global synchronizer operated by Super-Validators.
The name "Validator" is confusing.
Super-Validators are the true validators, using a 2/3 voting mechanism with BFT consensus.
In the schema, we see that "Validator" serves two distinct roles: one for Users and one for Application Providers:
- As a User Validator, it provides functionality for Canton coin operations: transfer offers and burning coins to purchase traffic bandwidth for applications.
- As an Application Provider Validator, it offers all the previous functionality plus the ability to serve new applications (DAML) that need to access the global synchronizer.
For nodes operators, the level of operational complexity varies between these cases.
- For basic Canton coin functionality (including MPC wallet integration, transfers, and burning coins for traffic purchases), I propose renaming "Validator" to "Gateway."
- When additional DAML applications are supported beyond Gateway functionality, I propose renaming "Validator" to "Bridge.". “Bridge” adds the notion of stateful functionality, whereas “Gateway” remains stateless. In our case, this means that Bridge hosts stateful transactions for the new DAML application parties it serves.
This also makes sense for existing private Canton networks (like those handling RWA or others things) to use either a "Bridge" or "Gateway" to access the global synchronizer.
- If they only need Canton coin functionality (such as using it as collateral for their business?), they can deploy a Gateway.
- If they need to deploy specific DAML smart contracts for UTXO transaction trees and their business integration, they should deploy a Bridge. Node operators, regarding Bridge, will have stronger incentive to host “featured” Daml application than unfeatured application as rewards will be higher ( not capped).
If customers don't need to purchase traffic for their DAML applications or aren't interested in using Canton coin transfers (for collateral or other use cases), do node operators running "Gateway" or "Bridge" services to the global synchronizer have any incentive to serve them?
I think renaming "Validator" to "Bridge" or "Gateway" will add clarity to the relationships between node providers, custody providers, and application providers.
The term "Super-validator" can remain unchanged, or it could be simplified to just "Validator."
- +1 on the proposal to change terminology. In the context of corporate audits, the terms "Validator" and "Super Validator" trigger many conversations and written clarifications. Defining the difference between both, with the context intact would be a challenge.By simplifying the name to "Gateway" and "Validator" the contextual meaning is restored and straight forward.
- Hi, FrancoisThis is an interesting perspective, but it's important to note that Validator nodes do sign transactions to reach consensus, and they do host unique state for their users. In fact, each Super Validator node includes a Validator, plus a Synchronizer node; only the Validator nodes sign transactions and come to consensus.In fact, in Canton, the blockchain that matters is a composed / aggregate chain formed among the set of Validator nodes that host parties engaged in transactions with each other. Each unique set of Parties involved with each other forms a new blockchain among themselves, stored on their respective Validator nodes. Each Party composes all the chains they participate in, forming a global composed ledger linked by parties that participate in more than one chain.Still, you raise some interesting points. Validator nodes do act something like bridges or gateways among different Canton subnets. A party hosted on a given Validator may validate transactions on multiple private Canton blockchains, so in that sense they do sort of act as gateways to different Canton subnets. They're different from bridges and gateways on other networks, though, in that transactions across subnets can be fully atomic, just as if they were inside a single subnet, with the same cryptographic guarantees.
- Validators in other blockchains do not host unique state for their users, that's why many of us find it confusing. That's means Validators are also Curators for parties.
- toggle quoted message Show quoted textValidators are actively part of consensus for the parties they host - the name is quite intentional as they are performing the act of validation in this context and do provide key security for updates for those hosted partiesThe liveness rewards will soon be crowded out by activity rewards and are a temporary incentive to operate infrastructureOn May 6, 2025, at 12:02 AM, Francois Branciard via lists.sync.global <francois.branciard=kiln.fi@...> wrote:Validators in other blockchains do not host unique state for their users, that's why many of us find it confusing. That's means Validators are also Curators for parties.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. - @Francois: Yes, that's true: built in to the idea of privacy is that some parties will see data that's not available to others. So you're right that in addition to validating transactions, the Validator nodes curate data for the parties they host. A validator might host only a single party, meaning that all the data on that Validator is known to that party alone. Or a Validator may host multiple parties, which all must then trust that the Validator operator will respect privacy boundaries among them.
To reflect the dual role of validating and hosting data for served parties, I propose that we understand Canton Validator as either a Shard Validator or Shard Operator.
Sharding is an existing concept in blockchain technology. This helps explain that Canton has no global shared state, but rather shards that can be bridged together.
Super-Validators operate shard containing governance and Canton Coin issuance and rewards parties allocation.
A basic Shard Validator operates data for hosted parties. If parties hold CC. Validator has responsibility for CC asset recovery (including identities and database backups). Signing for parties on this Validator can be delegated to an MPC provider.
An “application provider” Shard Validator operate as a basic Shard Validator but also new DAML deployed on it.
For application rewards does it go the “Validator operator party” ? or another party ? The part that deploy the .dar ?
Please let me know if I've made any mistakes or misinterpreted anything.
- Thanks, FrancoisI think the closest thing to shards within Canton would be the "Stakeholder Groups" formed by parties that share a common set of contract UTXOs, and transact among themselves. They send cryptographic proofs of consistency to each other, and form their own private chain/ledger that's the core building block of privacy in Canton.Any transaction that involves a new group of stakeholders automatically creates a new chain/ledger. But any partyID always sees all of their ledgers at once, composed into a single view, on any Validator hosting that Party. There's no bridging required to do this: the state controlled by that PartyID gets formed as part of each transaction involving the party.
- I would like to learn more. Very interesting topic.
Thank you for the thread.
After spending more time and several weeks working with Canton, I now agree that the term "Validator" makes sense since the Validator Operator Party appears as "provider" in transactions. For example, in a pre-approval of a party hosted on a validator (other than the operator's own), we see the operator validator party listed as the provider of this transaction. This demonstrates the Validator's cryptographic role in building trust for transaction trees and states of the network, not just a gateway.
In the Canton explanation 3.3 documentation, I notice there's no mention of "Validator" but rather a term called Submitting Participant Node (SPN) . In practice, I know there's both a participant pod and a validator pod. Could we say that the SPN consists of both the validator pod and participant pod?
I agree that shard is better for describing the global state of a DAML contract (and transaction trees) across all relaying parties interacting with it. A shard represents a functionally coherent (DAML contract) state. So yes, it can involve multiple validators since different parties can be hosted on several validators. From the perspective of a single validator, we can say that the validator provides "data availability" for its hosted parties regarding the DAML contract shard. Since the terms "shard" and "data availability" are established concepts in blockchain semantics, using them may help clarify our discussion. I'm open to corrections if I've misrepresented anything.
Currently, the term "Super-Validator" is used in two different contexts.
First, there are true Super-Validators who run actual SV infrastructure (mediator, sequencer, BFT) and have the authority to onboard new Validators as SV sponsors and vote on governance CIPs. Maybe add Operator name will help to distinguish them : SV Operators or Operator SV’s’
Second, there are entities called Super-Validators who merely have SV reward weights for various reasons: they might be node operators, wallet providers, app builders, etc. I would prefer to call these "Validators with super-weights" rather than Super-Validators.
From a node provider's point of view, running validators with super-weights is not the same as running/operating SV
- On Tue, Aug 5, 2025 at 11:52 AM, Francois Branciard wrote:
Could we say that the SPN consists of both the validator pod and participant pod?
Yes, that's a fine way of thinking about it.
Digital Asset will start updating its documentation to talk about Validator nodes all the time, combining the validator pod and the participant pod into one concept, to align more closely with how we talk about Splice and the Global Synchronizer.
