Canton publishes a supported-cryptographic-schemes reference that separates key specifications from algorithm specifications, states which combinations each provider supports and which are verification-only or encryption-only, names the default for the JCE provider and the default for the AWS and GCP KMS providers separately, and gives signature and key encoding formats. It separately documents three signing key usages, Namespace for node identity and topology transactions, SequencerAuthentication for member-to-sequencer authentication and Protocol for synchronization-protocol messages. The protocol source and the wire-protocol enumerations carry the same roster with the post-quantum parameter set spelled out. That is an unusually complete and machine-checkable published inventory. Two deductions. The Ed25519 verification rule the implementation enforces is not published, neither cofactored nor cofactorless, and small-order point rejection is not addressed anywhere in the reference or the documentation. And the inventory is complete only on the signing side: no post-quantum encryption scheme or key-encapsulation mechanism exists to inventory, which is the half that carries Canton's confidentiality guarantee.

Every primitive carrying a live security guarantee is Shor-breakable. Signing is discrete-log on edwards25519, NIST P-256, NIST P-384 or secp256k1; asymmetric encryption is discrete-log on NIST P-256 through ECIES or integer factorization at RSA-2048 through RSA-OAEP-SHA-256. Three points earn credit. The key-specification roster contains no pairing-friendly curve, so the privacy architecture carries none of the Groth16-class or KZG-class pairing exposure, a structural property that reconstructs from the published reference rather than a claim. The post-quantum side of the classification is populated rather than empty, because the one post-quantum scheme present names an exact parameter set, ML-DSA-65, which fixes its family, its hardness assumptions and its NIST security category without inference. Against that, the symmetric margin is thin on both sides of the stack: AES-128-GCM is the only supported symmetric scheme and is not configurable, and the AES-128-CBC layer inside ECIES leaves roughly 64 bits of effective work under Grover, which is a weaker margin than an AES-256 construction would leave once the asymmetric layer falls. And no key-encapsulation mechanism exists at all, so the encryption half of the classification has no post-quantum entry to tag.

Production cryptography draws on two classical families and no production post-quantum family: elliptic-curve discrete log for Ed25519, ECDSA and ECIES, and integer factorization for RSA-OAEP-SHA-256 at RSA-2048. Both fall to Shor, so this is one quantum failure mode, not two. On the post-quantum side the only implemented scheme is lattice-based ML-DSA-65, and it is experimental and filtered out of every provider scheme set by a configuration flag that defaults to false. A second family is named but not implemented: SLH-DSA, a hash-based scheme, appears in Canton's own repository as a source comment marking it as future work alongside ML-DSA-65, and in the open development-fund proposal, which lists it with Falcon and is scoped to verification only. Credit here is for a hash-based scheme appearing in the chain's own source and in a public architectural document rather than nowhere at all. No code-based scheme appears anywhere, and Classic McEliece, BIKE and HQC are key-encapsulation mechanisms in any case and are not candidate signature families.

A NIST post-quantum security category is derivable for the one post-quantum scheme Canton implements, because Canton names the parameter set rather than the family: the signing key specification and the signing algorithm specification are both ML-DSA-65, cited in the source and in the wire-protocol enumeration to FIPS 204. ML-DSA-65 is NIST security category 3, which NIST IR 8547 in initial public draft records at 192 bits of security strength, against ML-DSA-44 at category 2 and 128 bits and ML-DSA-87 at category 5. That is a real claim a third party can check, and it is the level a conservative institutional deployment would pick. Three deductions hold the score below half. The scheme carrying the category is marked experimental in Canton's own source with the comment that it should not be used in production, and is excluded from every provider scheme set unless enableExperimental is set, which defaults to false, so the category describes code that no production node runs. No category exists on the encryption side at all, because no post-quantum encryption scheme or key-encapsulation mechanism is implemented. And on the classical side one strength is a live compliance problem: RSA-2048 provides roughly 112 bits of security strength, which NIST IR 8547 in initial public draft deprecates after 2030 rather than 2035, and Canton uses it for transaction-view encryption and as the default asymmetric encryption key specification under the AWS and GCP KMS providers, not for an ancillary function.

Real key hygiene is documented and it earns credit here. Signing keys are scoped by usage into Namespace, SequencerAuthentication and Protocol, so a compromise of one usage does not carry to another. Keys can be held in an external key-management service, with the root key administratively isolated. The experimental post-quantum scheme is handled with visible discipline: it is marked experimental in the source with the stated reason that more confidence is needed in the scheme and its implementation, the configuration field that enables experimental schemes is documented as not for production use and defaults to false, and the filter that removes experimental schemes from the usable set is in the shared scheme-construction path rather than in one provider. Deductions are substantial. No formal verification of the cryptographic layer is published. No independent audit of the signing or view-encryption stack is published. The Ed25519 verification rule is not stated, so a third party cannot tell whether the cofactored or cofactorless rule applies or whether small-order points are rejected, and that distinction decides real malleability behaviour. Session signing keys are a narrower mitigation than they first appear: they are usable only when an external key-management service is deployed and the documentation states they are disabled by default, so the bound they place on long-term key use applies to a configured subset of deployments and to protocol messages only, never to sequencer client authentication. Constant-time behaviour of the deployed implementations is not independently verified here; the underlying libraries' own claims are the basis, and the post-quantum path delegates to a general-purpose provider's ML-DSA implementation. A reviewer on the open development-fund proposal raises the implementation question from the other direction, asking why custom cryptographic implementations would be written rather than established libraries used.

Every key that authorizes anything on Canton is exposed from creation in the sense of the address-type rule: node identity keys, party keys, sequencer authentication keys and protocol keys are published as raw public keys in topology transactions, not hidden behind a hash that a spend later reveals. A Canton development-fund reviewer states the same thing directly about the root, that the public key remains in the topology state. There is no mitigated-until-spend class on this network. The public key is available to an adversary before the first command is ever submitted, so a CRQC recovers the Ed25519 scalar or the ECDSA private key from topology state alone. The credit is for one real and limited mitigation: Canton is permissioned, topology state replicates to admitted participants rather than to an open peer-to-peer network, so obtaining the key material requires participant access or captured traffic rather than a public block explorer. That narrows who can harvest; it does nothing to the cryptography. No public source quantifies the value authorized by exposed keys on Canton, and none is inferred here.

Canton has no dormant-output analogue, and the structure is worse rather than better for it. A namespace identifier is the hash of its root key, which looks like hashed-pubkey protection, but the namespace is established and extended by namespace delegations and topology transactions signed under that root key, and those publish the public key. The hash therefore gives no standing protection, and a root key that has not signed for years is exactly as exposed as one signing now. Canton's own documentation states that the root namespace key cannot be rotated, so a long-dormant institutional root cannot be moved behind a stronger key the way an unspent output can be swept to a new address; operators mitigate by keeping the root offline, which protects the private key from theft and does nothing against recovery from the published public key. Credit is limited to the same permissioned-visibility point as 2a. No public source enumerates registered-but-inactive party keys on Canton.

Split by attacker time budget. Long-range, at-rest, 2 of 13: namespace delegations and topology transactions are signed artifacts that stay load-bearing for the life of the identity graph, the root key cannot be rotated, and no sunset date for Ed25519 or ECDSA is published, so a CRQC forging a root namespace signature could mint party and participant identities under an existing institutional namespace. A slow-clock CRQC suffices, because nothing is being raced. Short-range, on-spend, 5 of 12: the window factor earns most of the credit, since Canton has no public mempool that broadcasts a public key ahead of confirmation, submissions travel over authenticated channels to a sequencer, and ordering is deterministic with fast finality. The exposure-discipline factor earns nothing: single-use identities are the opposite of Canton's design, since party identities are long-lived and reused by construction, and no post-quantum-safe submission path is enabled in production. The window credit is largely notional and is stated as such, because the public key is already in topology state before any command is submitted, so an attacker never needs to race a confirmation window. Consensus-signature standing exposure is not scored here; Canton's consensus signing is scored at 4f, where it is not applicable.

This is Canton's sharpest exposure and it is the one its users are least able to accept. Each transaction view is encrypted to its recipients with ECIES-HKDF-HMAC-SHA-256-AES-128-CBC over NIST P-256 or RSA-OAEP-SHA-256 at RSA-2048, and those ciphertexts are what sequencers order and what participants retain. Both schemes fall to Shor, so an adversary who records traffic or holds a stored view today reads it once a CRQC exists, with no cooperation from Canton and no detectable event at the time of harvest. The AES-128-CBC layer inside the ECIES construction leaves roughly 64 bits of effective symmetric margin under Grover once the asymmetric layer is gone. Digital Asset's published position acknowledges this risk class directly and ties mitigation to TLS post-quantum support it states is not yet available in libraries, browsers, server software or certificate-authority issuance. A Canton development-fund reviewer separately states in the public proposal thread that hybrid encryption key exchange including X-Wing is under evaluation, and pushes back on the proposal's own sequencing argument by stating that breaking the key-sharing layer puts stored data at risk just as much as the signing layer does. The credit is for that public acknowledgement at two levels and for a scheme registry that could carry a post-quantum encryption scheme if one were written. Nothing hybrid is deployed, the encryption algorithm set in the protocol source holds only the two classical entries, and no ML-KEM under FIPS 203 appears anywhere, which is why Gate 1a-KEM fails.

Anonymity. Canton's need-to-know visibility is architectural rather than a retention promise, and it is the strongest property on this card. Canton's published privacy model states that participants see only those parts of a transaction they are entitled to, and that for the other parts they see neither transaction payload nor metadata such as involved participants or parties. The same document states that each view is encrypted to its respective recipients and that the synchronizer sees none of it, only encrypted messages and confirmation results. There is no global ledger view to analyse, so the graph-reconstruction attacks that apply to a pseudonymous public ledger have no corresponding surface, and the operator-visibility boundary the structural impossibility requirement asks for is stated in Canton's own documentation rather than in marketing material. Deductions: synchronizer sequencers still handle the encrypted envelopes and the routing metadata needed for ordering, so a sequencer operator observes a node-level communication and timing pattern even without reading contents, and no public source quantifies what party-level graph could be reconstructed from that; and the published model does not state what a colluding quorum of sequencers and mediators could reconstruct together.

Anonymity, composite. Provider concentration, 5 of 8: Canton has no third-party remote-procedure-call market of the kind that concentrates a public chain's traffic through a handful of hosted endpoints, because each institution runs its own participant node and connects to a synchronizer directly, so the originating-traffic concentration this factor measures is structurally low. The deduction is that concentration has not disappeared, it has moved: the Global Synchronizer is a single logical ordering service run by a vetted Super Validator set whose membership is decided by governance vote. Broadcast observability and independent entry points, 5 of 7: there is no public mempool, submissions travel over authenticated channels rather than open gossip, and multiple sequencers give more than one entry point. Metadata retention policy, 0 of 5: no published retention policy for operator-side metadata such as participant addresses, connection timing or client fingerprints is in the public record, and the rubric scores an undeclared policy at zero rather than assuming a benign one.

Anonymity. No public source documents a canonical cross-chain bridge for Canton with observable source-to-destination bookkeeping, and Canton's published ecosystem guide names wallet, exchange and custody providers rather than bridge operators, so the passive-observer correlation surface this sub-score measures is small on the evidence available. That is where the credit comes from. The deduction is for the path that does exist and is undocumented: assets reach and leave Canton through named institutional custodians and exchanges, and no public source describes the correlation properties of those flows, whether a deposit into a Canton party identity is linkable to an external chain address held by the same custodian, or what either side retains. A surface nobody has described is not a surface that has been shown to be safe.

Confidentiality, and the place where Canton's privacy claim meets its quantum exposure. The confidentiality of every transaction view rests on ECIES-HKDF-HMAC-SHA-256-AES-128-CBC over NIST P-256 and RSA-OAEP-SHA-256 at RSA-2048, both Shor-breakable, so every historical encrypted view retained by a participant or captured from sequencer traffic becomes readable once a CRQC exists. Retroactive de-anonymization here is not a side channel, it is the primary reading of the ledger. Payload shelf life compounds it: Canton is a ledger of record for regulated financial contracts, whose retention follows long financial recordkeeping horizons rather than a pruning window, so the ciphertext an attacker harvests in 2026 is still meaningful when it is decrypted. Against the band ladder for post-quantum payload encryption, Canton sits at the bottom: no hybrid post-quantum view encryption is deployed on mainnet, none is on a testnet, none is announced with a date, and no re-encryption or rotation of historical views is proposed. The published three-step plan puts post-quantum encryption schemes at its first step with no date attached, and the encryption algorithm set in the protocol source contains no post-quantum entry, unlike the signing set. Credit is for one genuine architectural choice, that the published key-specification roster contains no pairing-friendly curve, so Canton's privacy carries no additional Shor surface from a pairing-based proof system, and for the explicit public acknowledgement of the harvest-and-decrypt risk class by both Digital Asset and a Canton development-fund reviewer.

Anonymity. Canton specifies no mix mechanism. There is no cryptographic shuffle, no cMix-class information-theoretic mixing, no commit-reveal or batch-ordering scheme claimed as an unlinkability mechanism, no independent mix nodes, no cover traffic and no precomputation. Canton's hiding comes from need-to-know addressing, which is scored at 3a and is not re-credited here. The rubric requires a named mechanism with a cited specification and Canton names none, so the score sits just above zero to record the one incidental effect, that sequencers order envelopes whose contents are already encrypted, which no Canton document claims as an unlinkability property and which is not treated as one here.

Canton's cryptography is registry-driven at protocol level, and the registry already holds a post-quantum entry rather than only classical ones. The JCE provider's supported signing set contains Ed25519, ECDSA-SHA-256, ECDSA-SHA-384 and ML-DSA-65; the wire protocol carries ML-DSA-65 as its own key-specification and algorithm-specification enumeration value; the signature-format mapping, the key-format conversions and the key-management-service driver conversion all handle it; and a Canton development-fund reviewer states that the protocol semantics already allow classical and post-quantum keys to coexist on one synchronizer, because the signing algorithm is chosen by the signer and published in the topology transaction for the verification key, while the encryption algorithm is chosen by the recipient's topology. That is protocol-level agility demonstrated in code, not described in prose. Three things hold it below full credit. ML-DSA-65 is experimental and excluded from every provider's usable set unless a default-false flag is set, so no scheme change has been executed in production. The external-party key specifications exposed at the Ledger API do not yet include it, which Canton's own source records as outstanding work. And the encryption side has no agility to demonstrate at all, because no post-quantum encryption scheme has been written.

Canton's key-rotation position splits sharply at the namespace root, and the card scores both halves rather than the worse one. Below the root, rotation is a deployed, documented protocol primitive: NamespaceDelegation, OwnerToKeyMapping and PartyToKeyMapping topology transactions, signed by an authorized namespace key, register a new key for an intermediate namespace key, a party key, a protocol signing key, a sequencer-authentication key or an encryption key, with no change to the namespace and no change to party identifiers, and the same machinery already used for classical key rotation extends to a post-quantum key once the algorithm specification is enabled. Session signing keys add a second, narrower rotation primitive for protocol messages where an external key-management service is deployed, though they are disabled by default. At the root, Canton's key-management documentation states plainly that the root namespace key cannot be rotated, because the namespace is the hash of that key, so a scheme change at the root means a new namespace with new parties and participants and contracts transferred across. There is no account-abstraction layer and no deployed client-layer migration path. The Ed25519 seed-rebind floor does not apply: Canton accounts do not uniformly commit to a single RFC 8032 Ed25519 seed, since ECDSA over NIST P-256, NIST P-384 and secp256k1 are supported alternatives, long-term keys are commonly held in a key-management service with no seed in the holder's hands, and multi-party-computation custodians sample shares through distributed key generation with no seed at all. The post-quantum rebind bonus is zero: the construction cited in the development-fund thread for binding a new post-quantum verification key to an existing account rests on a preprint whose content is not independently confirmed, the proposal is unmerged, and the same thread records that the construction does not cover the ECDSA and no-seed cases that make up most of the key population.

Canton Improvement Proposals have thresholds published in a governance charter, not in social posts: CIP-0000, type Process, approved 2025-03-03, states that a CIP reaches Proposed only with support from at least two Super Validators, that approval requires a two-thirds majority vote in favour cast by designated representatives of the Super Validator rights owners, and that a CIP requiring on-chain adoption reaches Final only when a two-thirds majority of Super Validators implement it on-chain. CIP-0051, type Governance, status Final, adds the on-chain vote mechanics: expiry-based auto-rejection when fewer than two-thirds of Super Validators vote, early rejection on a two-thirds reject majority, and immediate effectivity on two-thirds accept. The process has produced a dated, binding outcome: CIP-0096, type Tokenomics, created 2025-12-07 and approved 2025-12-31, specifies four staged on-chain Super Validator votes stepping the validator liveness reward cap from 570 to 3.33, then 2.50, then 0.60, then to zero on 30 April, rolled through DevNet, then TestNet, then MainNet. That is coordination with published thresholds, a recorded approval date and a stated effectivity schedule, which is what this sub-score measures. Two deductions. The production record is short, since the Global Synchronizer went live on 2024-07-01. And the evidenced change is protocol economics rather than cryptography, so it demonstrates the mechanism without demonstrating it on the hardest class of change; no CIP covering cryptographic migration has reached Proposed.

The question is whether Canton can ship classical and post-quantum together without replacing the scheme, architecturally rather than by announcement. Half of the answer is real and now demonstrated in code: the registry carries ML-DSA-65 alongside three classical schemes, the wire format and the key-management-service driver conversion handle it, and a Canton development-fund reviewer confirms that classical and post-quantum keys can coexist on one synchronizer with each signer choosing its own algorithm. The other half is missing entirely, and it is the half the gate tests. Nothing composes the two. There is no 2-of-2 construction requiring both a classical and a post-quantum signature to verify over the same message, no 1-of-2 construction with a commitment to both public keys, no combiner specification, no canonicalization or domain-separation construction, and no security reduction of any strength. Per-signer coexistence is a choice between schemes, which is scheme substitution, and substitution is the baseline Gate 1a-Sig disqualifies. The open development-fund proposal does not close this: it is scoped to in-protocol verification of ML-DSA, SLH-DSA and Falcon and explicitly excludes signing infrastructure and key-management changes, so even if merged it would add verifiers rather than a hybrid signing path. On the encryption side there is not even coexistence to credit, only a reviewer's statement that hybrid key exchange including X-Wing is under evaluation.

Full credit by the documented default for stateless-only schemes, which is a real score rather than a non-applicable one. Canton deploys no stateful hash-based signature scheme: no XMSS or XMSS^MT per RFC 8391, approved for federal use through NIST SP 800-208, and no LMS or HSS per RFC 8554 appears in the published scheme reference, the protocol source, the wire-protocol enumerations or the development-fund proposal. The one post-quantum scheme implemented, ML-DSA-65 per FIPS 204, is stateless, and the schemes named in the proposal, SLH-DSA per FIPS 205 and Falcon per the round-3 submission, are stateless too. No one-time-key index space needs tracking, no backup-restoration procedure can rewind signing state, and no multi-device coordination problem arises. The Stage 5 prerequisite that would require a 90-day operational record of state management without a state-reuse incident does not arise for this chain.

Not applicable, and this entry is not scored. Canton's consensus signing uses non-aggregating schemes: the published roster of supported signing algorithms contains Ed25519, ECDSA-SHA-256, ECDSA-SHA-384 and ML-DSA-65, the key-specification roster contains no pairing-friendly curve and no BLS12-381, and neither the reference nor the protocol source contains a BLS signature scheme, a threshold construction or a multi-signature aggregation; sequencer and mediator authentication signs per signer rather than into an aggregate. This sub-score exists for chains whose consensus depends on Shor-vulnerable aggregation or threshold primitives, where a declared post-quantum aggregation path must be evidenced; a chain with no aggregation has no such path to declare. It leaves both the numerator and the denominator, so Dimension 4 scores out of 80 rather than 100. Consensus-key standing exposure is not lost by this: the exposure of sequencer authentication and protocol keys is scored at 2a and 2b, where those keys are published in topology state.

Zero percent. No post-quantum signature or encryption scheme is live in Canton's production signing or encryption path, and the chain's own artifacts establish it rather than a third party's characterisation: ML-DSA-65 is marked experimental in the protocol source with the comment that it should not be used in production, it is filtered out of every provider's usable scheme set unless the configuration field enableExperimental is set, that field defaults to false and is documented as not for production environments, and no post-quantum encryption algorithm exists in the encryption scheme set at all. Digital Asset's published position, in a post dated 2026-08-26, describes ML-DSA signing as available behind an experimental flag and places implementation of post-quantum signing and encryption schemes at step one of a three-step plan. The open development-fund proposal is unmerged and scoped to verification. No public source states any percentage of Canton mainnet transaction traffic using the experimental scheme. The only quantitative statement available is that several partners have begun testing with ML-DSA, unnamed and unquantified, which is not mainnet traffic. Migration Stage derives from this sub-score.

Post-quantum code is merged in Canton's open-source protocol with an exact parameter set, and that is a real score well above the floor. The signing key specification and the signing algorithm specification are both pure ML-DSA-65, each cited in the source to FIPS 204; the wire protocol carries SIGNING_KEY_SPEC_ML_DSA_65 and SIGNING_ALGORITHM_SPEC_ML_DSA_65 as first-class enumeration values; the implementation binds to the provider's ml_dsa_65 parameter specification, which that provider distinguishes from its pre-hash sibling ml_dsa_65_with_sha512, so the pure FIPS 204 variant is the one wired in; signatures are DER-encoded and the declared signature size is 3,309 bytes; the key-management-service driver conversion, the key-format conversions and the JCE provider's sign and verify paths all handle it; and a dedicated post-quantum integration test exists in the repository. Four deductions bring it to the middle of the band. The scheme is marked experimental with the stated reason that more confidence is needed in the scheme and its implementation, and the rubric deducts code that is not production-active. It is excluded from every provider's usable scheme set by a flag that defaults to false and is documented as not for production. The external-party key specifications exposed at the Ledger API do not include it, which the source itself records as outstanding work alongside SLH-DSA. And there is no post-quantum encryption or key-encapsulation code of any kind, so half the exposure has no implementation to credit.

Zero, and a real zero rather than a non-applicable entry, because Canton has key-holding infrastructure operators whose keys could have been migrated. Super Validators operate the Global Synchronizer's sequencer and mediator infrastructure and hold Namespace, SequencerAuthentication and Protocol keys, and the topology-transaction machinery that would register a new key for those usages already exists and is documented. No public source names a single Super Validator, participant node or party using a post-quantum key for any of those usages, and no percentage of the validator set with post-quantum keys is published or derivable. Partner testing of the experimental signing scheme is not validator key adoption and is scored at 5b, not re-credited here.

Voided by the rule that this sub-score scores zero when mainnet post-quantum traffic is zero. That rule is the operative one here, and it applies because 5a is 0. Independently of it, the published record would not carry full credit either: the three-step plan published on 2026-08-26 is directional rather than dated, covering implementation of post-quantum signing and encryption schemes, partner enablement across wallet, multi-party-computation, exchange and software-development-kit providers, and migration of parties off elliptic-curve and RSA schemes, with a stated intent to implement over the next six to twelve months and further partner engagement expected toward year-end 2026. A rolling six-to-twelve month horizon is not three named, dated, publicly verifiable milestones, and none of it is protocol-enforced in the way full credit requires. No CIP covering cryptographic migration has reached Proposed, so no milestone is bound to the governance mechanism that binds Canton's other dated changes. No published prior post-quantum milestone exists against which a hit or slip ratio could be computed. This sub-score at zero triggers the Milestone-Discipline Cap on Migration Stage.

Two communications in the trailing twelve months name a construction, and mainnet bytes signed under either are zero, so the announced-to-shipped ratio has no finite value and the deduction band above 1.5 applies, taking 10 points from the 15 available. The two differ in character and both are stated here. Digital Asset's own position page, in a post dated 2026-08-26, names ML-DSA and in the same document states the signing path is behind an experimental flag, so it claims no deployment and opens no gap between promise and delivery; it is counted because it is a first-party primitive claim, not because it oversells. A vendor press release of 2025-12-10 announces a quantum-resilience pilot on Canton built on a proprietary Structured Data Folding with Transmutations construction, paired with a headline figure for real-world assets on the network. That construction is not ML-KEM per FIPS 203, not ML-DSA per FIPS 204, not SLH-DSA per FIPS 205, and not Falcon per the round-3 submission; no independent cryptanalysis of it is published; and Digital Asset's own executive quoted in the release frames the collaboration as something to explore rather than something shipped. That is the gap this sub-score measures. The narrative-only characterisation above a ratio of 5.0 is not applied, because it reads a finite ratio against nonzero shipped volume and because a merged, parameter-set-exact post-quantum signing implementation does exist, which is credited at 5b and not re-credited here.

The per-signature multiplier is published and exact, which lifts this above the undisclosed floor. Canton's protocol source declares an approximate signature size on every signing algorithm specification: 64 bytes for Ed25519, 96 bytes for ECDSA-SHA-384, and 3,309 bytes for ML-DSA-65, which matches the FIPS 204 signature size for that parameter set. A post-quantum signature therefore costs about 51.7 times the current default, from Canton's own constants rather than from an estimate. Everything else this sub-score asks for is absent. No per-block or per-transaction signature-data figure is published under any post-quantum configuration. No signature aggregation, proof-based batching or data-availability offloading is described for a post-quantum path, and the consensus signing schemes do not aggregate. No recalibration of transaction weight or of the synchronizer traffic fee is published, which matters here because Canton meters and charges synchronizer traffic by volume, so a 51.7-fold signature expansion lands directly on participants' traffic cost and no published analysis addresses it. And no per-quarter rate of party migration to post-quantum-safe keys is reported, since that migration has not started.

Canton publishes a guide to wallet, exchange and custody providers, so the vendor set is named and enumerable rather than unknown. It names BitGo, Blockdaemon, Copper, Dfns, Unit410, Taurus and Fireblocks for enterprise self-custody; BitGo, Blockdaemon, Hydra X, Zodia and Copper for enterprise cold custody; Bron, Console Wallet, Loop, Republic, Send, Zoro Wallet and Cantor8 for retail self-custody; Cypherock X1 as a hardware wallet; and Bybit, Gate, Kraken, KuCoin and MEXC as exchanges. That page contains no mention of post-quantum cryptography or quantum resistance, and none of the most significant vendors publishes a dated post-quantum roadmap for Canton; the Ledger Enterprise page for its Canton offering describes hardware-enforced threshold and multi-validator self-custody with no quantum content. The credit is raised slightly above a bare naming score by one structural point: several of these vendors are inside Canton's own governance rather than arm's length, with Dfns admitted as a Super Validator by CIP-0016, so a coordinated migration has a governance channel that an anonymous long tail would not provide. It is not credit for readiness, of which this tile records none.

No public source names a bridge operator or cross-chain messaging vendor for Canton, and Canton's own published ecosystem guide lists wallet, exchange and custody providers without naming one. No post-quantum roadmap is published for any cross-chain path into or out of Canton, whether operated by a bridge protocol or by the custodians and exchanges that move assets in practice. This entry is scored zero rather than left unscored, because assets do reach and leave Canton and the cryptography protecting those movements is somebody's responsibility; a surface that nobody has described is an undisclosed surface, not an absent one, and undisclosed must not score the same as architecturally impossible.

The custody and exchange set is named and institutionally heavy: Dfns for multi-party-computation key management, which is also a Super Validator admitted by CIP-0016; Zodia Custody, a bank-backed custodian that states it supports Canton Coin, operates validator infrastructure on Canton and is a member of the Canton Foundation, and which names Standard Chartered, Northern Trust, SBI Holdings, National Australia Bank and Emirates NBD as shareholders; Ledger Enterprise; and BitGo, Copper, Blockdaemon, Taurus, Fireblocks and Hydra X. None publishes a dated post-quantum roadmap for Canton, and the Zodia and Ledger Enterprise Canton pages contain no mention of post-quantum cryptography at all. Two points of credit beyond the naming. A custodian that is simultaneously a validator operator and a foundation member, and a key-management vendor that is simultaneously a Super Validator, are genuine coordination levers rather than arm's-length suppliers. And the post-quantum scheme actually present in Canton's software is ML-DSA-65, for which threshold multi-party-computation constructions are published, though they add rounds against classical signing, so the custody path is not foreclosed the way a mandate for SLH-DSA would foreclose it; SLH-DSA appears in Canton's public record only as future work in a source comment and inside a verification-scoped proposal, never as a custodial signing requirement.

Scored across the three components. Endpoint providers, 1 of 8: Canton has no hosted remote-procedure-call oligopoly, since institutions run their own participant nodes, which removes a concentration risk but also means no provider publishes a post-quantum roadmap that participants could inherit, and none does. Hardware-security-module and key-management-service algorithm support, 2 of 8: Canton supports key-management-service-backed key storage and documents the exact key purposes and algorithms it requires from AWS and GCP, which are ECC_NIST_P256 or ECC_NIST_P384 and RSA_2048 on AWS and EC_SIGN_P256_SHA256 or EC_SIGN_P384_SHA384 and RSA_DECRYPT_OAEP_2048_SHA256 on GCP, all classical. That places the post-quantum algorithm question squarely on those vendors, and no named hardware-security-module or key-management-service vendor publishes an algorithm roadmap covering ML-DSA-65 or any post-quantum signature for Canton's Namespace, SequencerAuthentication or Protocol usages. Credit here is for the driver interface and the key-management-service specification conversion already carrying the ML-DSA-65 case in code, so a vendor addition is mechanically possible without a protocol change. Trusted-execution attestation, 1 of 9: no published part of Canton's core path uses a trusted execution environment for block building, ordering or oracles, so the RSA-to-post-quantum attestation-chain transition has a smaller surface here than on chains that do, and no attestation roadmap is published either way.

The Global Synchronizer is operated by a vetted set of Super Validators running Byzantine fault-tolerant consensus, and the on-chain governance threshold is counted per Super Validator node rather than by token holding: CIP-0051, status Final, states that a vote request is auto-rejected if fewer than two thirds of the Super Validators vote, that two thirds of reject votes closes it early, and that an immediate-effectivity proposal takes effect on accept votes from two thirds of the Super Validator nodes. Governance is therefore not proportional to delegated Canton Coin, which removes the plutocratic capture risk this sub-score is built to measure. Three deductions. Super Validators are not uniform: the published governance record admits each one at a named weight, from 0.5 to 10, through a Governance CIP, and CIP-0000 states that a Governance CIP defines Super Validator rights owners and their weights, while no published process document states how those weights relate to vote counting, so a third party cannot rule out weighted influence from the record. Admission to the set requires a vote of the existing set, so the operator group is closed and self-selecting, which concentrates the ability to block a migration as much as the ability to drive one. And no public source states the current Super Validator count or any client-diversity figure for the participant, sequencer or mediator software, so neither a concentration coefficient nor a correlated-implementation-failure risk can be computed from the public record.

The Canton Improvement Proposal process is governed by a published charter with explicit thresholds and deadlines. CIP-0000, type Process, approved 2025-03-03, requires support from at least two Super Validators to reach Proposed, sets per-type deadlines for calling a vote of three months for Standards Track and one month for Governance, Tokenomics and Process, gives vote requests a ten-day completion deadline, requires a two-thirds majority in favour for Approved, and requires on-chain adoption by a two-thirds majority of Super Validators for Final. CIP-0051 tightened the on-chain vote mechanics in 2025-03. The process has produced a binding dated outcome: CIP-0096, approved 2025-12-31, scheduled four staged on-chain votes ending with the validator liveness reward cap set to zero on 30 April, rolled DevNet to TestNet to MainNet. A process with published thresholds, recorded approval dates and a staged effectivity schedule is the evidence this sub-score asks for. What is missing is the pressure half. Nothing in the public record shows Canton coordinating a change against a deadline it did not set itself, and the evidenced changes are economic and governance rather than cryptographic, so they do not demonstrate the network moving every participant onto new key material at once, which is what a post-quantum migration requires of it.

Canton Network is governed by the Canton Foundation, and Digital Asset publishes an official corporate position on post-quantum cryptography under its own name on the Canton forum, first posted 2025-04-14 and updated in a post dated 2026-08-26, which is more than an unattributed forum thread and carries a named three-step plan. A Canton development-fund reviewer also engages substantively and publicly on cryptographic migration questions in the proposal thread, including on namespace migration, store-now-decrypt-later sequencing and hybrid key exchange, so there is an identifiable technical voice inside the governance process. That is where the credit stops. No governance document names an owner for the post-quantum migration, no working group is chartered for it, no published mandate defines its scope or authority, and no Canton Improvement Proposal covering cryptographic migration has reached Proposed status, so the migration sits outside the one mechanism that binds Canton's participants to a dated change. A published corporate position and an engaged reviewer are statements of intent and competence; they are not a named lead with a mandate, and the distinction is what this sub-score measures.

No public source records Canton coordinating a cryptographic change while an attacker was actively threatening the network, and none records an emergency key rotation, an incident-driven scheme change or a forced upgrade under a live exploit. The production record begins on 2024-07-01 and the governance changes evidenced in it are protocol economics and Super Validator admissions. This sub-score has no partial band for a chain that has never faced the situation, and awarding credit for an untested capability would be scoring a claim rather than a precedent.

No canary or tripwire mechanism of any band exists. There is no monitored honeypot key, no rate-limited spending rule applied to classically-keyed identities, no cryptographic tripwire embedded in consensus with a published threshold, and no automated response such as pausing signing, switching to a hybrid path or alerting participants. No Canton-specific quantitative trigger is published either, meaning no defined capability threshold for a cryptographically relevant quantum computer, no date and no migration deadline. The closest public statement is an industry-wide estimate, not specific to Canton, that quantum computers large enough to break current cryptography are an estimated five to ten years away, published 2025-04-14, which is context rather than a tripwire.