Quantum Shield White Paper

Version 0.1 | 3 October 2026 | Pilot specification

Executive summary

Quantum Shield is a proposed company-first security visibility and post-quantum readiness service for organizations managing blockchain accounts. Its initial software release inventories Ethereum and Base addresses, records evidence from public blockchain data, preserves assessment history and identifies changes in monitored account state. Individual users can explore the scanner without a paid subscription, subject to the private pilot's sign-in and access controls.

The commercial opportunity is to help teams answer practical questions: which addresses belong to us, what account mechanisms do they use, what changed, what evidence supports each finding, and what needs specialist review? The product does not claim to make a wallet quantum-proof, prevent theft, detect a quantum computer, certify compliance or replace an independent smart-contract audit.

This document distinguishes implemented pilot behavior from proposed commercial capabilities. It is not a token offering, investment prospectus or audited cryptographic design. Payments are intentionally deferred at the founder's request.

Problem and intended customers

Treasury operators and wallet teams often maintain account lists, owner responsibilities, reports and monitoring in separate places. A credible product can reduce this operational friction while building a structured inventory for future cryptographic migration. The initial customer hypothesis is small and midsize Web3 treasury teams, wallet developers and protocol operators with an identifiable security owner. It must be validated through customer interviews and paid pilot interest.

The buyer receives an organized evidence trail and a review workflow. The individual user receives understandable findings without surrendering keys. A company should pay for recurring workflow value, not for a frightening label or an unsupported probability of loss.

Cryptographic foundation

NIST finalized ML-KEM for key encapsulation and ML-DSA and SLH-DSA for digital signatures in 2024. These standards address different tasks; a key-encapsulation algorithm is not a substitute for blockchain transaction signatures. Using a standardized algorithm in one application component does not automatically secure a blockchain's consensus, account recovery, signing software or infrastructure. [1]

Ethereum's post-quantum documentation describes migration work spanning account signatures and other network mechanisms. The product should track those developments without presenting proposed milestones as guaranteed delivery dates. No Quantum Shield launch date depends on predicting when a cryptographically relevant quantum computer will exist. [2]

Account abstraction enables programmable account policies. It does not itself establish post-quantum safety. Ethereum's EIP-7702 also means an account with delegated code requires more careful classification than simply calling every nonempty code result a conventional contract. The pilot identifies a standard delegation marker but does not validate the delegated policy. [3][4]

Product architecture

A browser sends an authenticated request to the application API. The API checks identity, workspace membership, role and usage limits before contacting a configured blockchain RPC provider. The result is stored with its methodology version, observation time and block reference. The frontend presents findings and limitations together; saved reports can be downloaded as JSON or printed to PDF.

Production storage uses a platform database. Company ownership is enforced on the server for every protected resource. Read and write API keys are workspace-scoped and revocable. The local Node.js server uses SQLite for development, with the same application logic as the hosted Worker. The hosted pilot relies on ChatGPT sign-in and the existing private Site boundary; it is not yet a public customer identity service.

Assessment methodology

The first methodology, qs-evidence-1, makes six RPC calls per assessment: verify chain identity, read the latest block, and inspect code, nonce and native balance at that block, followed by a block-hash consistency check. A mismatched or unavailable provider results in an error, not a fabricated report. Historical evidence is not inferred from missing data.

Three findings are recorded: account classification, nonce activity and a post-quantum readiness review requirement. The report distinguishes contract accounts, delegated accounts and addresses that may be externally owned or unused. A nonzero nonce is treated as an activity signal, not proof that a specific public key has been recovered. Public-key exposure and signing policy remain unknown in this version.

No Q-score or percent-secure value is calculated. The prototype's earlier numerical scores remain illustrative only in clearly labeled design previews. The live application does not reuse them. Future scoring requires documented factors, a labeled reference corpus, expert review, false-positive analysis and versioned change control. It must represent a defined exposure category rather than the probability of theft.

Every report records the chain, address, block number and hash, observation time, account type, native balance, evidence, recommendations and coverage limits. Latest-block observations can be affected by chain reorganizations. The pilot checks that the block hash is unchanged during the assessment but does not provide finalized historical indexing or cross-network attribution.

Monitoring and alerts

A watchlist stores a baseline fingerprint of account type, nonce and native balance. Later checks compare that state and create an in-app change alert when it differs. A balance change is not inherently malicious; the alert explicitly asks the operator to review it. This avoids mislabeling ordinary activity as a detected attack.

Manual checks work through the dashboard. Automatic checks require a deployed and verified scheduler. The code includes a bounded job runner, database leases, next-check times and failure retry times. Email delivery, reliable message outboxes, transaction-indexed alerts and provider failover belong to the next engineering phase.

Service portfolio

Quantum Scanner is the implemented entry point for bounded account assessments. The company workspace adds ownership, reports, watchlists and team roles. The developer SDK exposes these functions to a company's server-side integration.

Risk Engine currently means deterministic evidence rules, not predictive artificial intelligence. Threat Monitor currently means account-state change monitoring, not exploit prevention or mempool protection. Migration advisory is a proposed expert-led service requiring qualified staff and a defined statement of work. Quantum Vault is research-only; no custody, signing contract or automatic migration implementation is included.

Revenue model

The recommended business model combines company subscriptions, paid readiness assessments and later API plans. Basic individual checks can remain free within a defined usage allowance. Company plans should charge for workspaces, monitored addresses, history, team features, reporting and support. Consulting must have a separate scope, delivery timetable and specialist cost model.

Suggested validation prices, not published offers: a Team plan at US$149 per month, a Growth plan at US$499 per month, enterprise arrangements by quotation, and a scoped readiness engagement starting around US$1,500. These figures are hypotheses to test with buyers and may be too low for high-touch support or licensed data. No payment checkout is active.

An illustrative scenario with 20 Team customers and five Growth customers produces US$5,475 in monthly subscription revenue. If variable delivery costs were 25%, contribution before fixed costs would be US$4,106.25. At US$6,000 of monthly fixed costs, that scenario would still lose US$1,893.75 before tax and other omitted expenses. This is arithmetic, not a revenue forecast. Consulting receipts should not be counted as recurring subscription revenue.

Differentiation and validation

Established onchain security vendors already offer substantial monitoring capabilities. Hypernative, for example, markets account, transaction and protocol monitoring. Quantum Shield should not claim those capabilities merely because the frontend has a similar visual presentation. [5]

A plausible initial distinction is transparent, evidence-linked readiness reporting combined with a focused company workflow. Validate it with 10 to 15 buyer interviews, three design partners and a narrowly scoped paid pilot. Measure time saved preparing reports, repeated weekly use, accepted pricing, cost per monitored address and willingness to renew. Stop or narrow the offering if customers do not value the findings.

Security and data governance

The pilot never requests private keys, seed phrases, wallet signatures or transfers. It uses parameterized SQL, server-side role checks, same-origin browser mutation checks, API-key hashing and bounded usage. Provider credentials stay on the server. Public addresses are sent to the chosen RPC operator; company labels and workspace relationships remain private application data.

These controls do not constitute an independent security audit. Before a public commercial launch, complete external review, backup and restore testing, incident response procedures, retention and deletion controls, privacy documentation and jurisdiction-specific legal review. The operating country and legal entity are not yet specified, so this paper makes no licensing or regulatory conclusion.

Roadmap and release gates

Phase 1 is the current private pilot: account snapshots, evidence reports, company workspaces, manual watch checks and SDK access. Its gate is successful permission tests, real provider checks and a usable end-to-end workflow.

Phase 2 adds production identity, automated scheduling, transactional email, paginated history, retention controls, provider observability and recovery testing. Its gate is reliable unattended operation and an independent security review.

Phase 3 adds billing, contracts, support commitments and validated company pricing after the founder approves payment integration. Phase 4 adds a full-history indexer, network-specific exposure evidence and supported contract policies, based on measured customer demand. Phase 5 explores audited post-quantum account protection in test environments. No mainnet vault release should precede cryptographic and smart-contract review.

Sources

[1] NIST, First finalized post-quantum standards: https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards

[2] Ethereum, Post-quantum cryptography: https://ethereum.org/roadmap/security/quantum-resistance/

[3] Ethereum, Account abstraction: https://ethereum.org/roadmap/account-abstraction/

[4] EIP-7702, Set Code for EOAs: https://eips.ethereum.org/EIPS/eip-7702

[5] Hypernative, Product overview: https://www.hypernative.io/

[6] PublicNode Ethereum endpoint: https://ethereum.publicnode.com/

[7] PublicNode Base endpoint: https://base.publicnode.com/

Sources checked on 3 October 2026. External roadmaps, prices and provider availability can change. Product recommendations and commercial scenarios in this document are proposals, not claims made by these sources.