Insight
By Quantum Stellar
Quantum-safe describes a security objective: resisting attacks that a sufficiently capable quantum computer could enable against certain cryptographic systems. For digital assets, the important question is which actions and credentials receive that protection. The answer depends on the algorithm, its implementation and the system using it. A useful explanation starts with the protected action, identifies the mechanism that authorizes it and makes the remaining assumptions visible. That is how a broad promise becomes a claim someone can assess. It also helps an issuer explain the value of a particular design without suggesting that every surrounding system has the same protection.
A quantum-safe claim should tell you what is protected, how it is protected and which evidence supports that conclusion.
Different cryptographic tools solve different problems. Digital signatures help establish that an authorized party approved an action. Key establishment helps parties agree on secrets for secure communication. These purposes are related to security but are not interchangeable. An asset design needs mechanisms suited to the actions it protects, together with a clear description of where those mechanisms are applied.
NIST has finalized post-quantum standards with distinct roles. FIPS 204 specifies ML-DSA and FIPS 205 specifies SLH-DSA, both for digital signatures. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism. Choosing an appropriate standard is one step in the work. The implementation must handle keys and inputs correctly, the authorization logic must enforce the intended policy, and the deployed system must match the configuration that was assessed. The name of a standardized algorithm does not establish that an entire product has been reviewed or certified. Evidence needs to follow the actual implementation and the specific claim being made. Review should cover the selected parameters, the software handling the signatures and the conditions under which authorization succeeds or fails. A standard supplies a defined cryptographic mechanism; the asset application supplies the rules that decide when that mechanism grants permission to act.
For an asset on Stellar, begin by separating the issuer, holder and network layers. The issuer may retain authority over creation or asset controls. A holder uses an account’s authorization rules to act. The network validates transactions according to its protocol. These layers connect, but they do not automatically share the same
cryptographic protection. A change to an issuer’s administrative mechanism does not rewrite every holder’s signing rules. A custom authorization policy in a contract account applies within its defined contract flow; it does not by itself replace network signatures. This distinction matters because the person reading a security statement may care about a different action from the one the implementation protects. Precise language helps connect the statement to the actual asset, account and operation under discussion. For example, an issuer might introduce a quantum-resistant approval process for one administrative action while holders continue using accounts with different authorization rules. That would be a claim about the specified issuer action. To describe holder protection, the design would also need to identify how those holders authorize transfers and which other powers can affect their balances.
Stellar’s Quantum Preparedness Plan describes work toward post-quantum capabilities across different parts of the ecosystem. A roadmap is useful context for design decisions, while the available capability must be checked against the relevant network version and supported tools. A proposal, an accepted specification and an activated feature represent different stages. Asset documentation should identify which stage it relies on and distinguish a planned integration from a deployed implementation. Useful evidence includes the target network, relevant protocol version, exact contract or account configuration and supported wallet flow. Those details make it possible to check that the intended mechanism is available and used where the claim says it is.
The same care applies to recovery and administration. If a conventional credential can replace the protected owner, or an administrator can change the authorization logic, that path affects the scope of the security claim. Assess the full set of powers that can reach the same outcome. Clear boundaries make ambitious security goals more useful: they show what has been established and what work remains. For an issuer, that clarity supports better design decisions. For a holder, it makes the relationship between a security promise and an actual account easier to understand.
Standards, implementation and deployment are separate layers of evidence. Learn more through NIST’s post-quantum cryptography program.
