Smart-Contract PQC Audit

ECDSA-locked smart contracts have a Q-Day half-life. Find yours.

Specialised audit for EVM, Solana, and Move-based smart contracts that depend on classical signatures. Identifies harvest-exposed addresses, recommends migration paths (account abstraction, ZK-of-knowledge proofs, hybrid signature verification on-chain), and ships a signed audit certificate that's verifiable on the QorTrace public registry.

Engagement

3–6weeks

Day-one staffing

Seniorled

Final artefact

Signedcert

Verifier surface

On chain

Audit depth

AST + runtime

Output artefact

Signed cert

ECDSA-locked contracts have a Q-Day half-life.

Every ECDSA signature you've published on-chain is harvested forever. Once a CRQC arrives, every key with reused-nonce risk, every dormant address that signed once, every bridge with a known signer set — becomes recoverable. The migration path on EVM isn't simple, and the wrong choice locks you in.

NIST FIPS 203

ML-KEM (Kyber) · key encapsulation

The lattice-based key-exchange standard NIST finalised in August 2024. Replaces ECDH on every TLS 1.3 handshake, every IPsec tunnel, every messaging-app key wrap. We integrate the FIPS-203 module ML-KEM-768 by default (Level 3 security · ~256-bit classical · quantum-resistant).

REQUIRES: OpenSSL 3.x or BoringSSL with oqs-provider · TLS endpoint owner-of-record · 90-day rotation runbook
PROTECTS: Harvest-Now-Decrypt-Later: every byte your customers send today, recorded by an adversary today, decrypted in 2034 once Shor's-capable hardware exists

NIST FIPS 204

ML-DSA (Dilithium) · digital signature

The lattice-based signature standard. Replaces RSA-PSS and ECDSA on code-signing, document-signing, and TLS server authentication. We deploy ML-DSA-65 (Level 3) for transitional dual-signing alongside the classical algorithm during the migration window — never replace, always co-sign first.

REQUIRES: Sigstore / Cosign or in-house signer · code-signing CI/CD · 365-day key rotation
PROTECTS: Forged software updates, forged firmware, forged TLS server certs — every place a quantum-attacker would impersonate your build pipeline

POLICY · CNSA 2.0

NSA Commercial National Security Algorithm Suite v2

The U.S. federal mandate: PQC primitives operational across National Security Systems by 2030, exclusive by 2035. Defines the exact KEM (ML-KEM-1024) and signature (ML-DSA-87) profile used at NSS-grade and the migration-pace expected from contractors. Every Cryptographic Migration Certificate we issue carries an explicit CNSA 2.0 attestation block.

REQUIRES: FIPS-140-3 validated module (or FIPS-203/204 module-pending) · auditable inventory · documented sunset plan
PROTECTS: Federal contract eligibility post-2030 · DoD / IC supplier status · DORA + EO 14028 alignment

BRIDGE · HYBRID

X25519 + ML-KEM · hybrid key exchange

The transitional posture every serious PQC rollout uses: combine a battle-tested classical primitive (X25519, the Curve25519 ECDH variant — or X448 at higher security level) with the post-quantum KEM in a single key-derivation step. If either side breaks, the other still holds. Browsers shipped this in 2024 (Chrome “X25519MLKEM768” group); we operationalise it for your endpoints.

REQUIRES: TLS 1.3 stack · OpenSSL 3.2+ or BoringSSL · negotiation telemetry to confirm hybrid-group adoption
PROTECTS: Day-1 deployment risk: a flaw in either ML-KEM or X25519 alone does not break your traffic — only a flaw in BOTH simultaneously could

TOOLING

oqs-provider · OpenSSL provider

The Open Quantum Safe project’s OpenSSL 3.x provider that exposes ML-KEM, ML-DSA, SLH-DSA, and the hybrid groups as first-class crypto algorithms inside any application that already speaks OpenSSL. We do not maintain a private fork — we ship upstream patches and point your CI at a reproducible build with a pinned commit.

REQUIRES: OpenSSL 3.2+ · CMake 3.18+ · liboqs build chain · application-side config update
PROTECTS: Vendor-lock-in to a single PQC library · drift between staging and production crypto behaviour

TOOLING · CORE

liboqs · post-quantum primitive library

The C library underneath everything else — implementations of every PQC candidate that ever entered NIST’s evaluation, including the four standardised winners (ML-KEM, ML-DSA, SLH-DSA, FN-DSA). Audited, side-channel-aware, and the de-facto reference for open-source PQC. We pin the version, we record the commit hash, and the hash makes it onto your migration certificate.

REQUIRES: C99 toolchain · OpenSSL or mbedTLS for symmetric primitives
PROTECTS: Implementation-bug exposure: a verified-pinned build is the difference between ‘we ran ML-KEM’ and ‘we ran a known-bad ML-KEM’

RUNTIME

OpenSSL 3.x · with PQC providers loaded

The version line that gives us providers (modular crypto), proper FIPS module isolation, and the runtime negotiation hooks needed to ship hybrid TLS without a fork. We standardise every engagement on OpenSSL 3.2+ and surface the version on the certificate so auditors don't need to grep your container builds.

REQUIRES: Operating system upgrade if pinned to OpenSSL 1.x (RHEL 7, Ubuntu 18.04 etc.) · runtime config rebuild
PROTECTS: PQC drift across services — one binary on 3.2 negotiating hybrid, another on 1.1 silently falling back to classical-only

KMS

AWS KMS · GCP KMS · Azure Key Vault · Thales / Entrust HSM

Where your most sensitive keys actually live. Every cloud KMS now exposes ML-KEM and ML-DSA key types (AWS “ML_KEM_768”, GCP “PQ_SIGN_ML_DSA_65”, Azure “ML-KEM”), and on-premise HSMs from Thales and Entrust ship FIPS-203/204 firmware lines. We map your existing key inventory, design the wrap-and-rotate path, and ship the runbook your SRE team executes — without you ever exposing key material outside the boundary.

REQUIRES: Cloud account audit access · HSM administrator credential · IAM separation between operator and rotator
PROTECTS: Cross-region replication, backup/restore, and disaster-recovery flows breaking silently when a primary key migrates and a secondary doesn’t

Before you book the call.

Which chains do you cover?

EVM (Ethereum, all L2s, Polygon, BNB, Arbitrum, Base, Optimism, Linea, Scroll, zkSync, etc.), Solana, Move (Aptos, Sui), Cosmos SDK, Near. Bitcoin/Stacks on request.

Do you produce a public certificate?

Yes — every audit produces a verifiable certificate at qortrace.com/verify/<id>, signed by our methodology key. Embeddable as SVG, downloadable as PDF, includes the full finding manifest hash.

What's the difference between this and a security audit?

A traditional audit finds reentrancy, oracle manipulation, integer overflow. Ours finds harvest-exposure, ECDSA-lock-in, and quantum-vulnerable signing patterns. We are usually run AFTER a traditional audit, not instead of one.

How do you handle dormant / cold addresses?

We flag every address that has ever revealed a public key (i.e. signed at least once). Dormant cold-storage addresses are re-classified as harvest-exposed because their pubkey is permanent.

Smart-Contract PQC Audit

Every engagement ends with a registry-verifiable certificate.

ECDSA-locked contracts have a Q-Day half-life.

Signed deliverables. No handwave.

Address-level harvest exposure score

Migration path: AA + hybrid sigverify

Cryptographic remediation checklist

Public Audit Certificate (SVG + PDF)

Your dormant ECDSA addresses are not safe. Here’s why.

What we’re actually shipping into your stack.