Every authorization that moves value, mints currency, or releases a model is signed with the module-lattice signature standardized by NIST. There is no legacy elliptic-curve fallback quietly authorizing sovereign transactions behind the post-quantum label.
The signature scheme is fixed to FIPS 204 so that owners can point to a normative specification rather than a vendor's cryptographic claim.
Signatures follow ML-DSA as standardized in FIPS 204, the module-lattice digital signature algorithm derived from CRYSTALS-Dilithium. The parameter set is the one a national auditor can independently name and verify against the published document.
The 65 parameter set targets NIST security category 3, the middle of the three standardized strengths. It is chosen deliberately over the lightest set so that signing keys guarding currency issuance carry a security margin, not the minimum viable configuration.
Security rests on the hardness of Module Learning-With-Errors and Module Short-Integer-Solution problems, which have no known efficient attack on classical or quantum computers. This is a structurally different foundation from the discrete-log and factoring problems that Shor's algorithm breaks.
Signing supports both the deterministic and hedged variants defined in the standard. Deployments default to hedged signing so that a single faulty random-number source cannot leak a private key through repeated signatures.
The same post-quantum primitive authorizes every stage, so there is no weak classical link between an authorized instruction and its execution.
Each entry appended to the tamper-evident hash-chained ledger carries an ML-DSA-65 signature over its contents and its predecessor's hash. The signature binds who authorized the entry to the exact position it occupies in the chain.
Atomic DvP requires both legs to be signed before the settlement commits. The asset transfer and the payment leg are each signed by their respective owners, and the atomic operation refuses to complete if either signature fails verification.
Central-bank issuance, key generation, and custody transitions are gated by signatures from the holders of the controlling keys. Because the CBDC is non-custodial, these operations prove that the sovereign — not the operator — authorized the change.
Foundation and specialized model weights are released and versioned under signed attestations. A signed manifest lets an owner confirm that the weights loaded in-nation are the exact artifact that was trained and approved.
A signature is only as sovereign as the key that produced it, so the private key lifecycle is designed around owner control.
The private half of every signing key is generated and retained by the state or institution that owns the function. The infrastructure verifies signatures and never requires possession of the signing key to operate.
Signing keys are designed to be generated and held in hardware security modules so that the private key never exists in extractable form. The lattice key structure of ML-DSA is accommodated by the HSM's key storage rather than exported to software.
High-consequence actions can require signatures from a quorum of distinct key holders rather than a single key. This distributes authority across officials so that no individual credential can unilaterally issue currency or move reserves.
Keys can be rotated on a schedule or after personnel change, and prior signatures remain verifiable against the keys that were valid when they were made. Rotation replaces future signing authority without invalidating the historical chain.
Anyone holding the public keys can confirm the integrity of the record without trusting the party that produced it.
Because the scheme is a public standard, an auditor or supervisor can re-verify every signature in the ledger with their own FIPS 204 implementation. Trust in the platform reduces to trust in a published algorithm and a set of public keys.
Verifying a signature also verifies its position, because the signed payload includes the previous entry's hash. A tampered or reordered history fails signature verification, not just a separate integrity check.
Long stretches of ledger can be verified in bulk, letting a reviewer confirm an entire epoch of settlement in a single pass. This makes full-history audit tractable rather than a theoretical possibility.
Verification requires only the public keys and the signed artifacts, so an auditor can confirm signatures in an air-gapped environment. Assurance does not depend on live access to the operator's systems.
ML-DSA-65 is not confined to application-layer transactions; it authenticates the components those transactions run on.
At protocol boundaries where a hybrid posture is prudent, an ML-DSA-65 signature is carried alongside a classical one so that a break in either scheme alone does not forge the authorization. The post-quantum signature is always present, never aspirational.
Signatures extend to firmware and boot artifacts in the data-center and CBDC hardware so that only owner-approved code executes. The same primitive that authorizes a transfer also attests the machine that processes it.
Software and model artifacts ship with signed manifests, letting operators confirm provenance before deployment inside the residency boundary. A component with a missing or invalid signature is rejected rather than trusted by default.
Signatures are bound to the transport session that carried them, so a captured authorization cannot be replayed onto a different channel or context. Authorization is tied to where and when it was actually made.