Canton Network CC

Claim: Canton Network publishes a detailed cryptographic inventory (Supported Cryptographic Schemes page) listing all supported signing/encryption algorithms, key specs, and formats. Digital Asset published a forum post (April 2025) acknowledging quantum risk, tracking NIST PQC standardization, and outlining a pluggable approach to adding new schemes. The inventory is versioned and maintained in official docs.

Coverage basis: Official documentation and forum post constitute a public, evidence-supported risk acknowledgment. Not a formal, layered threat model with per-attack-surface analysis.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: The cryptographic inventory is comprehensive and well-structured, listing scheme names, configuration strings, key formats, KMS provider mappings, and default schemes. The forum post is a single public statement, not a formal threat model, but provides sufficient evidence of risk acknowledgment for a Stage 1/2 evaluation.

The inventory is maintained in official docs (docs.canton.network). The threat model post references NIST IR 8547 and NCSC guidance. No per-layer attack-window classification (long-exposure, short-exposure, structural) is published.

• https://docs.canton.network/global-synchronizer/reference/crypto-schemes
• https://docs.canton.network/overview/learn/cryptographic-keys
• https://forum.canton.network/t/da-position-on-post-quantum-cryptography/7877

Claim: The risk assessment is supported by the official cryptographic inventory page, the DA forum post, the Quanton proposal's detailed cryptographic scope, the FC 2026 paper (eprint 2025/1368), and the OpenZeppelin Technical Risk Assessment which independently evaluates Canton's post-quantum posture.

Coverage basis: Multiple public sources support the assessment, including official docs, independent research, and protocol proposals.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: Evidence links are primary sources. The OpenZeppelin report independently corroborates the assessment. Evidence is sufficient to verify risk acknowledgment and inventory claims.

The evidence record is adequate for a Stage 2 project. It does not include transaction examples, reproducible analytics, or formal audit attestations for the quantum-critical scope.

• https://docs.canton.network/global-synchronizer/reference/crypto-schemes
• https://forum.canton.network/t/da-position-on-post-quantum-cryptography/7877
• https://github.com/canton-foundation/canton-dev-fund/pull/222
• https://openzeppelin.com/hubfs/OpenZeppelin%20%7C%20Technical%20Risk%20Assessment%20on%20Blockchain%20Networks.pdf

Claim: All production spend authorization uses classical signatures: Ed25519 (EC-Curve25519), ECDSA-SHA256 (EC-P256, EC-Secp256k1), or ECDSA-SHA384 (EC-P384). Party keys authorizing Daml transactions, CC transfers, and topology changes are entirely classical. The Quanton proposal targets PQC verification but is not deployed. The BOLTS QFlex pilot is experimental only.

Coverage basis: Official documentation, forum confirmation, GitHub code, and all public evidence confirms classical-only signatures in production.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Active production spend authorization remains entirely Ed25519/ECDSA-only. A CRQC can forge transaction signatures, enabling theft of all on-chain assets.

Assurance: Multiple primary sources confirm classical-only signatures. The Quantum-critical vulnerability is independently verifiable from protocol documentation and public code.

Canton's pluggable architecture supports adding new schemes, but no PQ scheme is implemented in production. The EVM integration (Zenith) adds secp256k1 dependency for Ethereum-compatible accounts.

• https://docs.canton.network/global-synchronizer/reference/crypto-schemes
• https://docs.canton.network/overview/learn/cryptographic-keys
• https://forum.canton.network/t/several-questions-regarding-the-integration-of-centralized-exchanges-with-canton/8317

Claim: Canton identities are built from a namespace (hash of the root public key) and a random string. Public keys are exposed in topology transactions (NamespaceDelegation, OwnerToKeyMapping) stored on the synchronizer. All namespace and participant keys are classical ECC. Public keys are long-exposure (persisted in topology state). No PQ/hybrid account controls exist.

Coverage basis: Official identity management and topology documentation confirms classical key exposure and namespace derivation from classical public keys.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Namespace root keys are classical and their fingerprint is the namespace identifier. Rotating the root key changes the namespace, breaking all associated identities and contracts. This makes root key migration to PQ fundamentally disruptive without the proposed (but unimplemented) ZKP-binding mechanism.

Assurance: The identity management model is well-documented. The namespace derivation vulnerability is a structural quantum-critical blocker that the FC 2026 paper explicitly addresses but has not resolved in production.

Root namespace keys are typically kept offline, reducing immediate exposure, but the public key is always visible in topology state. Intermediate keys can be rotated through topology transactions without namespace change, but the root remains the fundamental trust anchor.

• https://docs.canton.network/global-synchronizer/deployment/identity-management
• https://docs.canton.network/overview/learn/cryptographic-keys

Claim: Canton uses a proof-of-stakeholder model with Super Validators operating sequencers and mediators. All consensus-critical authentication uses classical signatures: sequencer-authentication keys (Ed25519/ECDSA), protocol signing keys (Ed25519/ECDSA), mediator confirmations (Ed25519/ECDSA), topology transactions (Ed25519/ECDSA), and CometBFT governance keys (Ed25519). No PQ or hybrid authentication exists.

Coverage basis: Official consensus and security documentation, SV configuration guides, key management docs, and GitHub code confirm classical-only consensus authentication.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Consensus authentication is entirely classical. A CRQC could forge sequencer messages, mediator confirmations, and topology transactions, enabling validator set manipulation, parameter changes, and consensus compromise.

Assurance: The SV governance model is documented with BFT thresholds. The underlying signature dependency on Ed25519/ECDSA is confirmed by key management docs listing supported schemes. No PQ path exists for any consensus-critical key type.

Super Validator governance uses weighted voting with 2/3 confirmation threshold. On-chain voting creates long-exposure public keys for SV operators. CometBFT governance keys are generated as Ed25519.

• https://docs.canton.network/overview/reference/sv-governance-reference
• https://docs.canton.network/global-synchronizer/production-operations/sv-security
• https://docs.canton.network/global-synchronizer/production-operations/key-management

Claim: Canton uses blinded Merkle trees for transaction commitments and ACS commitment exchange between participants. The commitment scheme uses SHA-256 hashing which is quantum-safe (NIST Category 1). Canton does not use KZG commitments, pairings, or other quantum-vulnerable polynomial commitment schemes. State binding and script authorization rely on classical signatures (Ed25519/ECDSA) for topology transactions and contract authorization.

Coverage basis: Official protocol documentation and security architecture description confirms Merkle-tree-based commitments with SHA-256, absence of pairings/KZG, and classical signature dependency for authorization.

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The avoidance of KZG/pairing-based commitments is a structurally positive design choice for quantum safety. SHA-256-based Merkle commitments are NIST Category 1 quantum-safe. The vulnerability lies in the signature layer authenticating state transitions, not the commitment primitive itself.

Partial credit (0.25) awarded for quantum-safe commitment primitives and deliberate avoidance of pairing-based schemes. Full credit is not appropriate because script authorization and state binding ultimately depend on classical signatures.

• https://docs.canton.network/protocol
• https://docs.daml.com/canton/architecture/security.html
• https://www.canton.network/protocol

Claim: Canton achieves privacy through sub-transaction decomposition, selective disclosure, and per-recipient encryption rather than zero-knowledge proofs. No pairing-based ZK systems (Groth16, PLONK) are used. Transaction views are encrypted using symmetric session keys (AES128-GCM), with session keys distributed via asymmetric encryption (ECIES with EC-P256 or RSA-OAEP with RSA-2048). The encryption primitives are classical and vulnerable to store-now-decrypt-later.

Coverage basis: Official protocol page, Halborn analysis, and Canton documentation confirm architectural privacy without ZK proofs, reliance on classical encryption for confidentiality.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Privacy encryption uses classical ECIES (EC-P256) and RSA-2048. Historical encrypted transaction views are vulnerable to store-now-decrypt-later attacks. For an institutional network processing $4T+ monthly repos, this represents massive exposure of proprietary trading data.

Assurance: The architectural avoidance of ZK proofs is well-documented and independently analyzed by Halborn. The SNDL vulnerability is acknowledged in the DA forum post. No PQ key encapsulation mechanism (e.g., ML-KEM) has been integrated for session key distribution.

0.50 Implementation Score reflects the positive structural design (no quantum-vulnerable proof systems) while acknowledging that the encryption layer remains classically dependent. The Quanton proposal explicitly defers PQ encryption to a potential Milestone 4.

• https://www.canton.network/protocol
• https://www.halborn.com/blog/post/need-to-know-privacy-how-canton-solves-the-confidentiality-integrity-trade-off
• https://docs.canton.network/global-synchronizer/reference/crypto-schemes

Claim: Canton nodes use TLS for gRPC/HTTP APIs. TLS keys are classical (not specified as PQ or hybrid). Node identity uses classical signing keys (Ed25519/ECDSA) for sequencer client/server authentication and inter-node communication. No hybrid PQ key exchange (e.g., X25519Kyber768) deployment is evidenced.

Coverage basis: Official key management and security documentation describes classical TLS and node identity keys. No PQ or hybrid transport protection is deployed.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: P2P transport is not consensus-critical or spend-critical; a CRQC compromising node-to-node TLS would enable eavesdropping and man-in-the-middle but not direct asset theft. This is a lower-severity quantum vulnerability in the overall attack surface, but remains applicable.

The Quanton proposal discussion notes that hybrid PQ key exchange (X25519Kyber768) is deployable today without PQ certificates, but no evidence of deployment exists. The DA forum post acknowledges TLS PQ support as outstanding.

• https://docs.canton.network/overview/learn/cryptographic-keys
• https://docs.canton.network/global-synchronizer/production-operations/key-management

Claim: Canton Wallet SDK and MetaMask Snap use Ed25519 and secp256k1 for transaction signing. KMS support (AWS KMS, GCP KMS) is documented for classical EC keys (EC-P256, EC-P384 for signing; RSA-2048 for encryption). No PQ key support exists in any wallet, custody, HSM, or signing workflow.

Coverage basis: Wallet SDK source code, KMS configuration docs, and Quanton proposal confirm classical-only wallet/custody paths with no PQ support.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No PQ wallet, custody, or HSM path exists. Institutional MPC custody users cannot migrate to PQ keys even if protocol support were added, since HSM/KMS vendors (AWS, GCP) do not yet support ML-DSA/SLH-DSA/FN-DSA for signing operations.

Assurance: The Quanton proposal explicitly scopes out signing infrastructure changes. The KMS providers (AWS, GCP) documented for Canton do not list PQC algorithm support. This is a critical dependency gap for institutional migration.

MPC custody users may be unable to retain their classical keys in the long term. The FC 2026 paper acknowledges that seedless/ECDSA users cannot use the proposed ZKP-binding migration mechanism.

• https://docs.canton.network/global-synchronizer/production-operations/key-management
• https://docs.canton.network/global-synchronizer/production-operations/sv-security
• https://github.com/canton-foundation/canton-dev-fund/pull/222

Claim: Approximately 0% of value-at-risk is quantum-protected. All ~38.7B CC circulating supply (~$6B market cap, ~$4T+ institutional RWAs on the network) remains under classical key control with no PQ migration path deployed. No freeze, deprecation, burn, or policy mechanism exists for unmigratable vulnerable value.

Coverage basis: CoinMarketCap/CoinGecko market data, official blog posts on institutional RWA volume, and absence of any deployed migration mechanism.

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: 100% of value-at-risk remains quantum-vulnerable with no migration path deployed. The $4T+ institutional RWA volume represents one of the largest quantum-exposed value pools in blockchain.

Assurance: Market cap and supply data from multiple independent sources (CoinMarketCap, CoinGecko). Institutional RWA figures from official Canton blog and independent reports. Coverage assessment is straightforward since zero protection exists.

Coverage threshold: <25% → score 1 from table. The CC token launched July 2024 with no premine. There are no legacy UTXOs with exposed keys in a traditional UTXO model, but topology transactions expose public keys for all identities, and EVM integration exposes secp256k1 addresses.

• https://coinmarketcap.com/currencies/canton-network/
• https://www.coingecko.com/en/coins/canton
• https://docs.canton.network/global-synchronizer/reference/crypto-schemes

Claim: No treasury, exchange, custodian, bridge, foundation, or protocol wallet has been migrated to PQ protection. Super Validator keys, Canton Foundation keys, and institutional participant keys are all classical. USDCx (Circle) was deployed on Canton but uses CIP-56 with classical key dependencies. No PQ-native wallet path exists.

Coverage basis: All documented key types are classical. No evidence of any PQ-protected wallet, treasury, or custody deployment exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The absence of PQ wallet protection is a direct consequence of the protocol's classical-only production status. Even if protocol support were added, wallet/custody integration represents a substantial coordination challenge across the institutional ecosystem.

Canton's permissioned identity model means institutional participants are known legal entities. This could facilitate coordinated migration, but no migration process is defined or deployed.

• https://docs.canton.network/global-synchronizer/production-operations/key-management
• https://docs.canton.network/global-synchronizer/production-operations/sv-security

Claim: No legacy vulnerable pools have been identified, measured, deprecated, or frozen. All value is current and active under classical keys. The namespace architecture means root keys cannot be rotated without breaking identities, creating an unmigratable vulnerability class. The protocol has no mechanism to freeze, burn, or deprecate quantum-vulnerable accounts.

Coverage basis: Protocol documentation confirms namespace fingerprint derivation from classical root keys and the inability to rotate root keys without namespace change. No deprecation mechanism exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Root namespace keys cannot be rotated without changing the namespace, creating permanently unmigratable classical trust anchors for all identities.

Assurance: Documentation is explicit that root namespace keys cannot be rotated. The FC 2026 paper proposes a ZKP-binding mechanism for seed-holding EdDSA users, but this is unimplemented and does not cover ECDSA or seedless users.

The Quanton proposal acknowledges this limitation and describes the ZKP approach for a subset of users. The broader unmigratable key problem for ECDSA/seedless deployments remains unaddressed in production.

• https://docs.canton.network/global-synchronizer/deployment/identity-management
• https://docs.canton.network/global-synchronizer/production-operations/key-management

Claim: The Quanton proposal (April 2026) describes a phased approach: verification libraries first, then key migration without address changes as a follow-up milestone. The FC 2026 paper (eprint 2025/1368) describes the migration mechanism. The DA forum post (April 2025) outlines the general approach. The BOLTS QFlex pilot explores an alternative third-party path. No formally adopted roadmap with activation criteria, governance milestones, or committed dates exists.

Coverage basis: Quanton proposal is an open, unreviewed PR. The FC 2026 paper is academic research. The DA forum post is informational. No adopted protocol roadmap exists.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The Quanton proposal is a detailed technical proposal, not an adopted roadmap. The FC 2026 paper provides academic credibility but is not a governance-approved plan. The BOLTS QFlex pilot is a third-party integration, not a native protocol roadmap.

The proposal/design phase qualifies for 0.25 Implementation Score. A formal, governance-approved migration roadmap with committed milestones, Super Validator voting, and activation criteria would raise this to 0.50 or higher.

• https://github.com/canton-foundation/canton-dev-fund/pull/222
• https://forum.canton.network/t/da-position-on-post-quantum-cryptography/7877
• https://chainwire.org/2025/12/10/bolts-launches-quantum-resilience-pilot-on-canton-network-to-future-proof-6t-real-world-assets/

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education materials, or migration prompts exist in production. Canton's pluggable architecture allows new scheme registration but no PQ schemes are registered. Users cannot create PQ-protected accounts or migrate existing accounts to PQ keys.

Coverage basis: All production documentation and tooling (Wallet SDK, MetaMask Snap, KMS guides) confirms classical-only support. No migration tooling or user education exists.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Users cannot create PQ-protected accounts or migrate existing accounts to PQ keys. No migration path is accessible to any user, institution, or application.

Assurance: The absence of migration accessibility is confirmed by the complete absence of PQ scheme support in production documentation, tooling, and configuration.

The Quanton proposal's stated scope is verification only; migration tooling and accessibility are explicitly deferred. No user-facing education or warnings about quantum risk have been identified.

• https://docs.canton.network/global-synchronizer/production-operations/key-management
• https://docs.canton.network/global-synchronizer/deployment/identity-management

Claim: No migration enforcement mechanisms exist. There is no deprecation of classical signing keys, no freeze mechanism for vulnerable accounts, no mandatory migration deadline, no restricted withdrawals for classical-key accounts, and no unsafe-path blocking. No exchange, custody, bridge, or wallet coordination for PQ migration has been initiated. Super Validator governance can approve protocol changes but cannot compel participant-level migration.

Coverage basis: Protocol documentation shows no enforcement mechanism for key deprecation or migration. Governance documentation confirms BFT voting for protocol changes but no migration enforcement powers.

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: No enforcement mechanism exists to compel migration or deprecate vulnerable keys. The protocol's permissioned identity model enables coordination but does not provide enforcement tools.

Assurance: Canton's institutional identity model (known legal entities as participants) is structurally favorable for coordinated migration but this advantage is unrealized without enforcement mechanisms or coordination processes.

The protocol supports synchronizer minimum-scheme negotiation which could theoretically restrict allowed signature schemes, providing a future enforcement path. This capability exists in the architecture but is not configured for PQ enforcement.

• https://docs.canton.network/overview/reference/sv-governance-reference
• https://docs.canton.network/global-synchronizer/production-operations/key-management

Claim: Canton has general security support channels (DA support, community Slack) and Super Validator governance for protocol changes. No bug bounty program, quantum-specific incident response playbook, or quantum-related vulnerability disclosure process has been identified. The protocol includes emergency repair operations but these are designed for ACS inconsistencies, not quantum attacks.

Coverage basis: Documentation confirms support channels, governance processes, and repair operations but nothing quantum-specific. No bug bounty program identified.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The absence of a quantum-specific IR playbook is treated as an assurance-only matter under the v3.1 Note-Only Caveat Rule. It does not create a new quantum-vulnerable path but limits operational readiness. The score of 0.00 reflects that no quantum-specific emergency process exists, not that this is a quantum-critical vulnerability.

The OpenZeppelin Technical Risk Assessment notes that Canton has 'no bug bounty programme' and 'limited transparency into on-chain activity.' The Halborn blog recommends penetration testing and hardening review specific to Canton deployments.

• https://docs.canton.network/overview/reference/sv-governance-reference
• https://docs.canton.network/appdev/faq
• https://docs.canton.network/global-synchronizer/canton-console/advanced-operations

Claim: The Quanton proposal targets NIST-standardized algorithms: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and FN-DSA (Falcon, in NIST standardization process). The proposal discusses jurisdictional requirements (CNSA 2.0, BSI, ANSSI, NCSC, ASD) and maps algorithm choices to use cases. No PQC algorithms are implemented in production. The BOLTS QFlex pilot uses the proprietary SDFT protocol, not NIST-standardized PQC.

Coverage basis: Quanton proposal is a development fund proposal targeting NIST standards; not yet implemented. BOLTS QFlex uses a non-standard protocol.

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The Quanton proposal demonstrates strong algorithm selection methodology aligned with NIST and international standards. However, this is a proposal only. The BOLTS QFlex pilot's use of SDFT (proprietary) rather than NIST-standardized PQC is noted as a concern for that integration path.

The proposal correctly identifies ML-DSA as the baseline, SLH-DSA for conservative/high-value use cases, and FN-DSA for compact signatures. The discussion of jurisdictional diversity (BSI preferring SLH-DSA, CNSA 2.0 mandating ML-DSA-87, ANSSI including FN-DSA) is sophisticated and appropriate for an institutional network.

• https://github.com/canton-foundation/canton-dev-fund/pull/222
• https://csrc.nist.gov/groups/ST/post-quantum-crypto/

Claim: No independent cryptographic implementation audit of the core protocol's signing, encryption, or key-management code has been identified. Quantstamp audits Canton Coin tokenomics (Daml smart contracts), not cryptographic implementation. CertiK audited USDCx (application-level deployment). OpenZeppelin analyzed Daml smart-contract security. Halborn discussed Canton's privacy architecture. None constitute an independent audit of the core protocol's quantum-critical cryptographic implementation.

Coverage basis: Exhaustive search of public audit reports, SV governance proposals, and security firm publications. No core cryptographic implementation audit identified.

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Under QRI v3.1 rules, absence of an independent audit for an otherwise verifiable quantum-critical claim (classical-only vulnerability is independently verifiable from public code and docs) does not create a Readiness & Risk Cap. The score of 0.00 reflects that no audit exists for this subfactor. This affects Confidence (capped at Medium) rather than applying additional score penalties beyond the subfactor score.

The OpenZeppelin Technical Risk Assessment noted in March 2026 that Canton had 'no public security audits for the client implementation.' This assessment remains accurate specifically for quantum-critical cryptographic implementation. Application-level audits (Quantstamp for tokenomics, CertiK for USDCx) do not fill this gap.

• https://github.com/global-synchronizer-foundation/cips/blob/main/cip-0057/cip-0057.md
• https://www.certik.com/blog/cip-56-redefining-token-standards-for-institutional-defi
• https://www.openzeppelin.com/news/smart-contract-security-for-institutional-finance-on-canton-an-entirely-different-problem

Claim: Canton Network core protocol is open-source (Apache 2.0 license) on GitHub. The classical cryptographic implementation is reproducible from public source code. The Quanton proposal commits to Apache 2.0 licensing for PQ verification libraries. The BOLTS QFlex pilot uses proprietary technology (SDFT, 30+ patents) and is not open-source.

Coverage basis: GitHub repository (digital-asset/canton) is public and active. Classical crypto code is verifiable. PQ code does not yet exist in the public repo.

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: score-reducing

Assurance: The open-source nature of the classical codebase is a positive assurance factor. The Quanton proposal's Apache 2.0 commitment is credible. The BOLTS QFlex proprietary model is noted as a concern for that integration path. Score of 0.50 reflects that PQ code is planned but does not exist in the open-source repo.

Digital Asset is the sole maintainer of the core client. No independent client implementation exists (single-client risk). The OpenZeppelin Technical Risk Assessment notes that 'a supply-chain compromise could affect 100% of validators simultaneously.'

• https://github.com/digital-asset/canton
• https://github.com/canton-foundation/canton-dev-fund/pull/222

Claim: Canton has a documented pluggable cryptographic architecture. Nodes can configure default and allowed signing/encryption schemes via configuration. Synchronizers impose minimum scheme constraints. The Quanton proposal explicitly extends `SigningKeySpec` and `SigningAlgorithmSpec` for PQ algorithms and describes synchronizer minimum-scheme negotiation. The topology transaction model allows independent key registration per participant.

Coverage basis: Official key management documentation, Quanton proposal, and FC 2026 paper describe agility mechanisms and upgrade paths. The architecture is designed for this but not yet exercised with PQ algorithms.

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: score-reducing

Assurance: The pluggable architecture and synchronizer minimum-scheme negotiation are well-designed for crypto-agility. The Quanton proposal provides a concrete integration path. However, the upgrade path has not been exercised with PQ algorithms and the KMS driver API for PQ keys is not yet specified.

The architecture's crypto-agility is a recurring positive theme across all documentation. The Quanton proposal's detailed description of integration touchpoints (JCE provider, KMS driver API, topology TX serialization, synchronizer negotiation) demonstrates serious engineering consideration.

• https://docs.canton.network/global-synchronizer/production-operations/key-management
• https://docs.canton.network/global-synchronizer/reference/crypto-schemes
• https://github.com/canton-foundation/canton-dev-fund/pull/222

Claim: The Quanton proposal discussion acknowledges stateful-signature schemes (LMS/XMSS) in the context of NCSC guidance and notes that ML-DSA, SLH-DSA, and FN-DSA are stateless. The proposal discusses thresholdization challenges: ML-DSA is the most tractable for MPC, SLH-DSA is hard to thresholdize due to WOTS+/Merkle internals, FN-DSA threshold variants are still research. HSM/KMS integration risks are acknowledged as out of scope for the initial milestone.

Coverage basis: Quanton proposal discussion thread and technical comments. No formal analysis document exists.

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: The Quanton proposal discussion thread is informal technical commentary, not a formal analysis. The acknowledgment of thresholdization challenges for institutional MPC custody is relevant and appropriate. Score of 0.25 reflects awareness but no formal analysis.

The proposal correctly identifies that Canton's institutional MPC custody users will need thresholdizable PQ schemes. The identification of ML-DSA as the most tractable candidate for threshold signing is well-founded. The deferral of HSM/KMS integration to a follow-up is a significant gap for institutional deployment.

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

Claim: The Quanton proposal includes plans for benchmarking against Canton's actual transaction processing model, including hash function optimization (SHAKE vs. Keccak-256) and KAT validation scoped to Canton's deployment configurations. No performance benchmarks have been conducted or published. No analysis of PQ signature size impact on topology transactions, sequencer messages, or archival growth exists.

Coverage basis: Quanton proposal describes planned benchmarking. No published performance data exists.

Implementation score: 0.25 · Evidence confidence: Low

Issue classification: assurance-only caveat · Score treatment: score-reducing

Assurance: Performance analysis is planned but not conducted. Under v3.1 rules, missing formal benchmarks should not reduce the QRI Score unless resource constraints prevent safe use of the PQ path (which does not yet exist). The score of 0.25 reflects that planning exists but no data is available.

PQ signature sizes for ML-DSA-87 (~4620 bytes) and SLH-DSA (~7856-29792 bytes) are substantially larger than Ed25519 (64 bytes). Canton's topology transactions include multiple signatures; the bandwidth and storage implications for a network processing 650K daily transactions are material and unquantified.

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