AUDIT  ·  QORTRACE LABS

EIP-7702 / AA PQC Audit

The first PQC audit for the modern Account-Abstraction stack — UserOps, validators, session keys, paymasters, recovery.

Specialised audit for ERC-4337 / ERC-7579 / EIP-7702 Account Abstraction wallets and the modular validator stack that ships on top. We score every cryptographic surface in the AA pipeline — UserOp signatures, validator-module slots, session keys, paymaster sponsorship signatures, EIP-7702 delegations + their revocation paths, and social-recovery guardian schemes — for post-quantum readiness. Deliverable: a signed AA Posture Certificate verifiable on the public QorTrace registry.

See all services
Engagement
1–3weeks
Day-one staffing
Seniorled
Final artefact
Signedcert
SIGNED · VERIFIABLE

Every engagement ends with a registry-verifiable certificate.

Cryptographic Migration Certificate · signed PDF, embeddable SVG, hash on the QorTrace public registry.

See a sample
THE PROBLEM

Account Abstraction's signature stack dies on Q-Day.

ERC-4337 UserOps, ERC-7579 validator modules, session keys, paymaster sigs, EIP-7702 delegations — every signature in the modern AA pipeline is ECDSA. Your existing security audit signed off on the logic and never looked at the cryptography. We do nothing else. We score the full AA stack — including the revoke-downgrade trap that bites every 7702 wallet — against NIST FIPS 204, ERC-7579, and the draft AA-PQC migration spec.

WHAT YOU’LL RECEIVE

Signed deliverables. No handwave.

Every engagement ships against this fixed manifest. No scope-creep invoices, no surprise “phase 2” line-items. If we change the scope, we re-sign first.

01

UserOp + validator scheme review

We score whether your IAccount / IValidator can swap to an ML-DSA verifier without a balance-migrating redeploy. Hard-coded `immutable` signers are flagged Critical.

02

Session-key HNDL exposure analysis

Every ephemeral session key signed today is harvestable. We classify your session-key issuance, lifetime, and rotation policy + write the ML-DSA migration plan.

03

EIP-7702 delegation threat model

We trace every revoke / clear / expire path. If revocation falls back to bare ECDSA, that's a Critical finding — we write the fix.

04

Paymaster sponsorship-signature audit

Verifying paymaster signatures are a forgery jackpot. We audit your paymaster's signature scheme + recommend the PQ migration path.

05

ERC-7579 PQ validator slot reservation

Documented slot-naming convention (`pq.validator.v1`) so wallets + UX can detect PQ-ready accounts at install time.

06

Social-recovery / guardian PQ-readiness

Guardian signatures, Shamir splits, WebAuthn passkeys — all classical today. We score your recovery scheme + map the PQ upgrade.

07

AA Posture Score (0–100) + signed certificate

Deterministic, methodology-citable. SVG + PDF certificate verifiable on qortrace.com/verify/<id>. Embeddable badge for your docs.

THE STACK WE WORK IN

What we’re actually shipping into your stack.

The post-quantum migration is not a slide — it’s a specific set of standards, libraries, and key-management primitives. Below is what we touch on every engagement, why it exists, and what it protects you against.

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
FREQUENTLY ASKED

Before you book the call.

Which AA stacks do you support?
Every production AA stack on Ethereum + L2s: ERC-4337 (v0.6, v0.7), ERC-7579 modular accounts, ERC-6900 modular accounts, Safe + Safe Modules, Coinbase Smart Wallet, Privy, Dynamic, Rhinestone, Biconomy, ZeroDev, Stackup, Pimlico, Permissionless.js, ModuleKit. If it implements IAccount or IModule, we audit it.
EIP-7702 specifically — what do you cover?
The delegation lifecycle end-to-end: `set_code` authorization, the delegated contract's verification flow, revoke / clear / expire paths (this is where the bugs live — see CVE-class downgrade attacks), and the re-delegation path to a PQ contract. We also audit the 7702-aware wallet UX flow if you ship one.
Do you audit our session-key SDK or our smart contract?
Both. Session-key bugs are a 50/50 split between contract and SDK; auditing only one half misses the harvest-now risk. We accept your Solidity / Vyper / Move + your TypeScript / Rust SDK in the same engagement.
What's the turnaround?
Standard: 1–2 weeks. Deep Dive: 3 weeks. Both include a 30-minute walkthrough with the auditor and one round of remediation review at no charge.
Do I need a Hybrid Signature audit too?
If your validator already ships a hybrid ML-DSA + ECDSA combiner, yes — these two audits are complementary. The AA audit scopes the wallet stack; the Hybrid Sig audit scopes the cryptographic combiner. Most teams need both. Bundle pricing available.

Ready to scope eip-7702 / aa pqc audit?

One business day to a senior engineer. Fixed-fee scoping memo within five business days. NDAs available on request.

Back to QorTrace Labs