Quantum Vault - An audited reference implementation for account abstraction

Post-quantum readiness must be achieved at all layers of the stack. We’ve worked with protocols on post-quantum testnets and hybrid signing models, deployed yellowpages as an attestation service for Bitcoin migration, proposed and optimized PQC algorithms, and proved BIP32 HD Wallets can work in a post-quantum world.  

Today, we are releasing our latest contribution to the open-source blockchain community: two repositories on GitHub under Project Eleven. Libqc is a TypeScript SDK for ERC-4337 account abstraction with parallel Bitcoin support, and quantum-vault is a browser-extension vault built on libqc. Both are MIT-licensed and have been audited by Cure53. They are reference implementations; not production wallets.

The vault model

quantum-vault is not a general-purpose wallet. There is no on-demand send. An address either holds its full balance or is fully emptied to a fresh address in a single all-or-nothing sweep, after which it is marked as "quantum vulnerable". A future quantum computer can break an ECDSA private key from its public key, but only once that public key is visible onchain. The public key only becomes visible when the address signs a transaction, so an address that has only ever received funds is safe. The vault model keeps addresses in that state for as long as the user holds the balance, and accepts the exposure only at the moment the entire balance is moved, at which point the balance is zero so the exposed key protects nothing.

The repos are the best source of truth, but a few parts are worth touching on here: how keys are derived, how they are held in memory, and how the signature scheme they sign with can be swapped.

Custom BIP-85 derivation

Both EVM and Bitcoin keys come from the same 24-word mnemonic via BIP-85, which derives independent child keys along the path m/83696968'/<app>'/<index>'. The application number base is 4860, taken from the first four hex digits of sha256("PROJECTELEVEN"); EVM keys are at 4861 and Bitcoin keys at 4862. A user who imports the same mnemonic into another wallet will derive a different set of keys and a different set of addresses, so an address that quantum-vault has marked “quantum vulnerable” cannot be accidentally re-funded through a parallel wallet that does not know about this public key exposure. Recovery back into quantum-vault preserves the exposure identification. Address derivation runs entirely off network, so vault recovery does not require a connection to any RPC provider, and property tests using fast-check cover determinism, length, and collision resistance across the index and application-number space.

Memory handling in JavaScript

Importantly, classical attacks on key material are still far more likely today than quantum ones, and a vault is only as good as its handling of its secrets. JavaScript makes this hard as it gives no direct control over memory, the garbage collector and JIT may copy or spill buffers, and any conversion of secret bytes to a string puts them in a heap that cannot be reliably wiped. Most of what a vault can do about this is best-effort. libqc verifies the effort with a test layer that takes heap snapshots after sensitive operations and asserts the secrets are gone. The scanner calls v8.getHeapSnapshot(), which forces a full GC, then streams the snapshot through pattern matchers for the raw, decimal, and hex encodings of a target byte sequence. Canary tests inject known patterns into key-derivation routines and assert the post-run snapshot contains zero hits, on both success and failure paths. quantum-vault does the equivalent end-to-end, with Playwright using Chrome DevTools’ HeapProfiler against a full vault flow.

Validators and crypto agility

A Kernel account is an ERC-4337 smart contract account: the address is a contract onchain rather than a key pair, and the contract delegates signature checking to a separate validator contract whose address it stores. The signature scheme the account accepts is the validator it points at, which means a future migration from ECDSA to a post-quantum scheme is a validator swap and the address stays the same. libqc reads rootValidator() from the deployed account and parses the response back to a known validator type. The only type supported today is secp256k1, but adding PQ schemes such as ML-DSA or SLH-DSA is straightforward. Validator types are an enumerated allowlist in the SDK, so an account configured against a validator the SDK does not recognise will not be loaded.

The vault model

quantum-vault is not a general-purpose wallet. There is no on-demand send. An address either holds its full balance or is fully emptied to a fresh address in a single all-or-nothing sweep, after which it is marked as "quantum vulnerable". A future quantum computer can break an ECDSA private key from its public key, but only once that public key is visible onchain. The public key only becomes visible when the address signs a transaction, so an address that has only ever received funds is safe. The vault model keeps addresses in that state for as long as the user holds the balance, and accepts the exposure only at the moment the entire balance is moved, at which point the balance is zero so the exposed key protects nothing.

The repos are the best source of truth, but a few parts are worth touching on here: how keys are derived, how they are held in memory, and how the signature scheme they sign with can be swapped.

Custom BIP-85 derivation

Both EVM and Bitcoin keys come from the same 24-word mnemonic via BIP-85, which derives independent child keys along the path m/83696968'/<app>'/<index>'. The application number base is 4860, taken from the first four hex digits of sha256("PROJECTELEVEN"); EVM keys are at 4861 and Bitcoin keys at 4862. A user who imports the same mnemonic into another wallet will derive a different set of keys and a different set of addresses, so an address that quantum-vault has marked “quantum vulnerable” cannot be accidentally re-funded through a parallel wallet that does not know about this public key exposure. Recovery back into quantum-vault preserves the exposure identification. Address derivation runs entirely off network, so vault recovery does not require a connection to any RPC provider, and property tests using fast-check cover determinism, length, and collision resistance across the index and application-number space.

Memory handling in JavaScript

Importantly, classical attacks on key material are still far more likely today than quantum ones, and a vault is only as good as its handling of its secrets. JavaScript makes this hard as it gives no direct control over memory, the garbage collector and JIT may copy or spill buffers, and any conversion of secret bytes to a string puts them in a heap that cannot be reliably wiped. Most of what a vault can do about this is best-effort. libqc verifies the effort with a test layer that takes heap snapshots after sensitive operations and asserts the secrets are gone. The scanner calls v8.getHeapSnapshot(), which forces a full GC, then streams the snapshot through pattern matchers for the raw, decimal, and hex encodings of a target byte sequence. Canary tests inject known patterns into key-derivation routines and assert the post-run snapshot contains zero hits, on both success and failure paths. quantum-vault does the equivalent end-to-end, with Playwright using Chrome DevTools’ HeapProfiler against a full vault flow.

Validators and crypto agility

A Kernel account is an ERC-4337 smart contract account: the address is a contract onchain rather than a key pair, and the contract delegates signature checking to a separate validator contract whose address it stores. The signature scheme the account accepts is the validator it points at, which means a future migration from ECDSA to a post-quantum scheme is a validator swap and the address stays the same. libqc reads rootValidator() from the deployed account and parses the response back to a known validator type. The only type supported today is secp256k1, but adding PQ schemes such as ML-DSA or SLH-DSA is straightforward. Validator types are an enumerated allowlist in the SDK, so an account configured against a validator the SDK does not recognise will not be loaded.

Repos

The repos can be found on our Github; github.com/p-11/libqc and github.com/p-11/quantum-vault. Issues and pull requests welcome.