Mailing Lists/“Validator” renaming proposalsSource on lists.sync.global ↗

“Validator” renaming proposals

globalSyncForum5 messagesstarted 09-05-2025
Also mentions:CIP-0056CIP-0103
  1. #1Francois Branciard05-08-2025source ↗

    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

  2. #2Wayne Collier06-08-2025source ↗
    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. 
  3. #3Francois Branciard14-05-2026source ↗
    Over the past several months, I’ve been increasingly focused on a question that seems central to the future of programmable markets and institutional tokenization:

    If settlement becomes atomic and programmable, can compliance continue to operate as a sequential, off-chain process built around legacy workflows?

    Recent discussions around “atomic compliance” on Canton strongly resonate with me — particularly the idea that sanctions checks, Travel Rule obligations, and compliance outcomes should be resolved within the same coordinated transaction flow as settlement itself.

    I believe regulation is increasingly pushing the industry in this direction, especially with the GENIUS Act, CLARITY Act, and broader global focus on real-time supervisory expectations for tokenized financial systems.

    The area I’ve been exploring through CompliLedger / TokenProof is what comes next beyond transaction-level compliance:
    - persistent governance state
    - rule/version lineage
    - reproducible compliance proofs
    - lifecycle enforcement
    - solvency and authorization validation
    - deterministic audit replay across the lifecycle of an asset or transaction

    In other words, not just “was this transaction compliant at execution time,” but:
    - what rules were active,
    - what proofs were relied upon,
    - what governance state existed,
    - and can the decision be reproduced deterministically later?

    I’m currently looking to validate whether this broader infrastructure direction resonates with:
    1. a major issuer, and
    2. a financial institution or market participant

    particularly within the context of Canton, tokenized markets, and institutional digital asset infrastructure.

    Would genuinely appreciate perspectives from others building in this space:
    - Does this problem resonate?
    - Are institutions beginning to think about compliance and governance as part of the transaction architecture itself rather than an external process layer?
    - Is there interest in deterministic, lifecycle-level proof infrastructure beyond atomic transaction compliance?

    Happy to connect directly with anyone exploring similar architecture challenges.

    Maranda, Founder - Compliledger
  4. #4Wayne Collier29-05-2026source ↗

    Hi all,

    We have submitted a new open-source (Apache-2.0) proposal to the Canton Development Fund: PR #375 — Canton Launchpad.

    • The PR: https://github.com/canton-foundation/canton-dev-fund/pull/375

    • The Problem: According to the official 2026 DevEx Survey, "Local Development Frameworks" are the single most critical gap in our ecosystem, with 41% of developers spending the longest time just getting their environment setup and node operations right.

    • The Solution: Canton Launchpad is a lightweight desktop developer control plane (built using Tauri v2 and React Flow) that wraps natively around the canonical cn-quickstart Docker Compose stack plus additional features like snapshot restore etc..

    We have deployed an interactive frontend Proof of Concept (PoC) demonstrating how the tool resolves three major survey bottlenecks:

    1. Visual Handshake Verification: The UI features a real-time topology canvas that polls participant Admin APIs to verify synchronizer connectivity (ListParticipantSynchronizerPermission), lighting up connections from offline to active.

    2. Instant Sandbox Snapshots: To eliminate the frustration of waiting 10 minutes for a container cold-boot when resetting ledger states, we built a one-click local snapshot and restore engine. It saves and hot-reloads PostgreSQL and participant node volumes in seconds.

    3. Structured JVM Exception Decoding: Launchpad intercepts cryptic JVM gRPC exceptions (such as empty trust store SSL anchors) and decodes them into friendly, plain-English troubleshooting actions.

    As a standalone public contribution, we are also publishing the underlying error dictionary as a community resource (canton-error-glossary) on GitHub.

    What We Are Looking For:

    • Ecosystem Feedback: We would love input from teams building on Canton. How does your team currently manage sandbox state, and what is your biggest bottleneck with LocalNet diagnostics?

    • SIG Review & Champion: We are looking to align with the Daml Language & Developer Tooling and dApp Integration SIGs, and are seeking a Tech & Ops Committee member to champion the proposal to place it on the upcoming review agenda.

    We look forward to hearing your feedback and working together to make local Canton development a seamless experience.

    Best regards,

  5. #5two Dev Fund proposals from NODEJUMPER05-06-2026source ↗

    Hi,

    We're a NODEJUMPER team, and we've submitted two Dev Fund proposals. We'd really value feedback from this list, and for the second one we're also looking for a champion.

    1. ISO 20022 ↔ Canton Settlement Adapter (#403): An open-source library that translates ISO 20022 bank messages (pacs.008/pacs.002/camt.05x) into CIP-0056 transfers and DvP via CIP-0103, and back. This proposal already has a champion, and we'd greatly appreciate feedback on the scope and approach:

    https://github.com/canton-foundation/canton-dev-fund/pull/403

    2. Rust SDK for Canton Network (#407): A production-grade Rust SDK featuring an async Ledger API client, daml-lf-archive-based DAR codegen (SCU-aware), CIP-0056 support, and distribution as a dpm component. We're still looking for a champion for this proposal, and would also greatly appreciate any review or feedback:

    https://github.com/canton-foundation/canton-dev-fund/pull/407

    Happy to answer questions or walk through either proposal in more detail. Thanks for taking a look.