QVAPT Assessment Methodology

We assess what is taking money today, and what will take it in 2030.

QVAPT (Quantum-VAPT) is Aurigraph DLT Corp's assessment platform for web/API, blockchain and DLT, smart contracts, wallets and custody, and post-quantum cryptography. Every engagement runs on NIST SP 800-115 (Planning → Discovery → Attack-in-lab → Reporting), closes on a deterministic score with no AI in the scoring path, and produces independently verifiable, hash-anchored results.

How an engagement runs

Scope says what we look at; this says how we operate on it. Every control below is enforced server-side by the platform, not left to operator discipline.

Authorization comes first

A target must sit inside the organisation's allowed-domains list before any test will launch, and adding a domain requires an explicit confirmation that you are authorised to test it. Active testing is confined to lab scope; production engagements are passive-only. Before a run starts, the target URL is verified to resolve and answer — and a URL resolving to a private, loopback or link-local address is refused outright, so the platform cannot be pointed at infrastructure that was never in scope.

Passive by default

A passive assessment is strictly read-only reconnaissance: TLS handshakes to observe offered protocol versions, negotiated cipher and certificate, and exactly one HTTP GET to read response security headers, banner disclosure and cookie flags. There is deliberately no active probing — no authentication-bypass attempts, no injection, no directory brute-forcing. An unreachable target is reported as a failed run, never as a clean one with zero findings.

Escalation is explicit and gated

Anything beyond passive runs as an agentic engagement at a declared autonomy level, with a human in the loop at each step up:

Approvals are held by your organisation's administrators, and an engagement pauses awaiting approval rather than proceeding on assumption.

Beyond web and chain

AI-agent assessment probes an LLM or agent endpoint against a twelve-threat catalogue (A1–A12 — direct and indirect prompt injection, role-swap, tool and signing authority abuse, data exfiltration), and reports a scorecard rather than a transcript to read. Mobile clients — native Android/iOS, Flutter and React Native — are analysed against the OWASP MASVS control groups. Both feed the same findings backlog, deterministic scoring and evidence chain as the rest of the engagement.

Six-module assessment scope

Scope is organised around the six failure classes that actually moved money in H1 2026, not a generic control checklist. Each module targets a distinct loss class and closes on a deterministic, on-ledger-anchored score. Module 1 (signer & key custody) is the MVP and ships in every engagement.

Quantum engine — twelve test cases (Q1–Q12)

The quantum-cryptography engine runs twelve cases and rolls them into one readiness grade. Five are critical — a FAIL on any caps the grade at F, because a broken root of trust cannot be graded readable.

Deterministic scoring

Every module ends in a score computed from countable inputs by a fixed rubric — no AI decides a grade or a gate, and the same inputs produce the same score on every run.

Asset grade. Every cryptographic asset in the CBOM is graded A (quantum-safe) / B (monitor) / F (Shor-broken) / X (already broken).

Readiness grade. The twelve quantum cases roll into one letter from the weighted pass ratio — A at 90% or above, B at 80%, C at 70%, D at 60%, F below that. Three ceilings then apply and the worst one wins: a FAIL on any of the five critical cases caps at F; a PARTIAL on a critical case caps at C; a FAIL on a non-critical case caps at D. A capped grade is always published with the case that caused it, so the cap is auditable rather than an unexplained downgrade.

Independently verifiable, hash-anchored results

A conventional pentest report asks you to trust the vendor. QVAPT results are evidence: each run captures a redacted transcript, signs its canonical digest with an Ed25519 key, and links it into an append-only hash chain. Published artifacts carry a hash-anchor manifest (per-file SHA-256 → Merkle root → signature → prior-root chaining) that anyone can verify against the platform's pinned public key (GET /api/attestation/pubkey) — without trusting QVAPT.

Verify this page yourself

The manifest covering everything published here is at /anchor-manifest.json. Three commands, no QVAPT tooling:

curl -sO https://qvapt.com/anchor-manifest.json
curl -sO https://qvapt.com/methodology.html
shasum -a 256 methodology.html

Compare that digest against the methodology.html entry in the manifest's artifacts list. If they match, the page you are reading is byte-for-byte the one we published. The merkleRoot is the root of all listed digests, and signature is an Ed25519 signature over the manifest's canonical digest — check it against the key at /api/attestation/pubkey, which is the same key that signs assessment evidence.

A mismatch on any single file changes the Merkle root, so a modified artifact cannot be presented as ours. prevRoot and chainedRoot exist so a re-issue references the previous root, making the sequence of publications auditable rather than a set of unrelated snapshots.

What this does and does not prove: it proves integrity and origin — that the bytes are the ones we signed. It is not a third-party audit of the content, and we do not claim it is.

See a real deliverable

A redacted sample scorecard is published ungated — no form, no call first. It shows a capped F grade with the rule that caused it, a 1,284-asset CBOM broken out by grade, the Q1–Q12 case table, and a Mode column marking every cryptographic assertion REAL or SIM. The Mode column is deliberately not removed to make the sample look stronger.