Noxvault: hash-based vaults for a post-quantum Solana

Noxvault — Hash-based vaults for a post-quantum Solana

Whitepaper · draft v0.1 · 10 October 2026

Abstract

Noxvault is a Solana vault whose funds move only with hash-based one-time signatures, so a quantum computer that breaks ed25519 cannot touch them. One fixed vault address serves 256 actions through a Merkle tree of WOTS+ keys, and the vault's rules — co-signers, a recovery key, a testament, a whitelist with delays, schedules and capped session budgets — are fixed in its address forever. An Escape Hatch extends protection to ordinary wallets: when an on-chain quantum canary trips, linked wallets are evacuated into their vaults. $NOX is the protocol's access and priority token: features unlock by $NOX held inside the vault itself, and holders stand first in line at Q-Day.

  • Security that does not depend on elliptic curves. Only SHA-256 stands between an attacker and a vault's funds; Grover's algorithm gives a square-root speedup, not a break.
  • A vault people can actually live with. A fixed address, gasless withdrawals, staking, schedules and a Phantom budget for daily use, for SOL and every SPL or Token-2022 token.
  • Protection beyond the vault. The Escape Hatch, the canary and a timestamped wallet registry are, to our knowledge, not offered by any other Solana project.

The problem

Every Solana account that has ever signed a transaction has its ed25519 public key on-chain, and a large enough quantum computer running Shor's algorithm can derive the private key from it. Nobody knows when such a machine will exist; the day it does is called Q-Day. From that day, any balance guarded only by an ed25519 signature can be taken by whoever runs the machine first.

Three properties make this urgent for Solana in particular:

  • Public keys are addresses. On Solana the address is the public key itself, so every funded wallet is exposed from its first deposit, not only after it spends.
  • Migration is a race. When Q-Day is near, honest users and attackers will try to move the same funds at the same time; moving early, under keys that do not rely on elliptic curves, is the only reliable defence.
  • Hash functions hold. The best known quantum attack on SHA-256, Grover's algorithm, only halves its effective security, which is why NIST standardised a hash-based signature scheme (SLH-DSA, formerly SPHINCS+) for post-quantum use.

Noxvault does not try to change Solana's signature scheme. It gives users a place on today's Solana where funds move only under hash-based signatures, plus a way out for what is still in ordinary wallets.

Prior art

Hash-based vaults exist, but each solves one piece and leaves daily use, recovery and ordinary wallets open; Noxvault combines them.

ProjectApproachWhat it leaves open
Solana Winternitz VaultWOTS one-time keys, Keccak-256A new address for every transaction; no recovery, rules or tokens
Anchor Wallet / PQ1 (Ethereum)Lamport / SPHINCS+ smart accountsNot on Solana
Quip (Bitcoin)Quantum-resistant layer 2Not on Solana
Project Eleven Yellowpages (Bitcoin)Registry linking old addresses to PQ keysA registry, not a vault; not on Solana

What Noxvault adds: one fixed address for 256 actions, tweaked WOTS+ with full 32-byte chains, rules committed in the address, an inheritance path that needs no keys, gasless use, and protection for ordinary wallets through the Escape Hatch, canary and registry.

Design

256 one-time keys merge into one root that opens the vault
256 one-time keys merge into one root that opens the vault

A vault is a program-derived address whose seed is the hash of its rules and of the Merkle roots of its key trees, so the address itself commits to who may act and how.

  1. 24-word phrase — stays in your browser.
  2. 256 one-time keys — WOTS+ leaves of a Merkle tree.
  3. Fixed vault address — hash of the tree roots and the rules.
  4. Sign one action — one key, one message, ever.
  5. Verify on-chain — chains, leaf and root, usually in 2 transactions.
  6. Approve, then execute — when the vault's rules are met.

One-time keys. Each key is a WOTS+ signature over SHA-256 with w = 256: 34 chains of 255 steps, every hash call tweaked by a per-tree seed and its exact position, so attacks on many keys at once gain nothing. A message digest picks one position per chain; two checksum chains stop anyone from pushing chains further to forge another message.

Many keys, one address. 256 keys are the leaves of a Merkle tree; a signature carries its leaf's authentication path, and the program rebuilds the root. The address stays the same for 256 actions, then a migration moves everything to a fresh vault.

Approve, then execute. A signature does not fit in one Solana transaction, so it is written to a buffer, verified chain by chain, and turned into an approval that burns its key. The action executes when the vault's rules are met: one approval for a simple vault, a threshold for a multi-signer vault, the recovery tree after inactivity.

One message per key. Clients refuse to sign with a key that ever published part of a signature for a different message, read from the vault's full on-chain history.

design // how a vault works
0124-word phrasestays in your browser02256 one-time keysWOTS+ Merkle leaves03fixed addresshash of roots + rules04sign one actionone key, one message05verify on-chainchains → leaf → root06approve / executewhen the rules are met
From a phrase to an executed action: every step after the first happens in public, none needs an ed25519 key.

Protocol features

Every feature below is enforced by the on-chain program, works for SOL and for SPL and Token-2022 tokens, and is covered by an end-to-end test on a local validator.

FeatureWhat it doesWho can trigger it
Multi-signer approvalsUp to 3 signer trees; an action executes once threshold of them approve the identical actionEach signer, one one-time key each
Recovery keyA separate tree held by someone else; may cancel anything at any time and act fully after the owner is inactive for a set period (default 180 days)The recovery holder
TestamentUp to 4 heirs with percentages; after a set inactivity (default 365 days) anyone can distribute SOL, tokens and stakes to themAnyone, once due
Whitelist, instant limit, delayUp to 4 trusted addresses pay out at once; others pay out at once up to a daily limit, above it after a delay (default 24 h) during which it can be cancelledOwner signs; anyone executes when due
SchedulesRecurring payments (amount, interval, count) from one signatureAnyone, only when due
Session budgetsAn ordinary wallet (e.g. Phantom) may spend up to a limit per period until a date, only to allowed destinationsThe session wallet
MigrationMoves all SOL and tokens to a new vault, e.g. when the 256 keys run lowOwner signs; anyone executes
Invoice addressesPer-payer deposit addresses that sweep into the vaultAnyone
StakingNative stake accounts owned by the vault: delegate, deactivate, collectOwner signs
Gasless relayerA relayer pays network fees and is repaid from the vault by a signed fee; it cannot change the actionThe relayer

A vault's rules are part of its address: changing any rule means a new vault, so nobody, including the owner, can quietly weaken them.

Escape Hatch, canary and registry

escape hatch // the fire exit
walleted25519, at riskarmedlink·delegate·txcanary tripsed25519 brokenpanicowner's alarmkeepers evacuateSentinel→Guardian→Freeyour vaulthash keys onlythen by $NOX held
Armed once while ed25519 is safe; fired by the canary or by the owner; executed by keepers, highest $NOX tier first, into the wallet's own vault.

An ordinary wallet cracks; its funds stream into the vault
An ordinary wallet cracks; its funds stream into the vault

The Escape Hatch protects what is still in an ordinary wallet: it is armed while ed25519 is safe, and fires the moment it is not.

Arming. The wallet signs, once: a link to its vault (also a timestamped registry entry proving ownership), a token delegate that can only move tokens into that vault, and a durable-nonce transaction that moves all its SOL into the vault. That transaction never expires and is stored on-chain; anyone may broadcast it, and it can only ever move the wallet's SOL into the wallet's own vault.

The canary. A bounty sits on an ed25519 address found by hashing to the curve (6S396A19…j7w9), so no one knows its private key. If the bounty ever moves, ed25519 is broken in practice; anyone can then trip the canary on-chain.

The quantum canary: a bounty no one can move unless ed25519 breaks
The quantum canary: a bounty no one can move unless ed25519 breaks

Evacuation. Keepers watch the canary and every link. On a trip, or when a user presses panic, they broadcast the stored SOL escapes and move delegated tokens, in order of $NOX tier.

Honest limits. An attacker who breaks one wallet's key can move it directly, so this is a race the defender usually but not always wins. The canary is a public alarm, not a guarantee: whoever first breaks ed25519 might leave it alone. Funds belong in the vault; the Escape Hatch is the fire exit for what is not there yet.

Security model

A vault is as strong as SHA-256 and the program's code; nothing in it depends on elliptic curves, but the code is not yet independently audited.

Assumptions. SHA-256 is preimage- and second-preimage-resistant (about 128-bit security against a quantum attacker using Grover's algorithm); the Solana runtime executes the program as written; the user keeps their 24 words secret and signs each one-time key only once.

Protected: funds inside a vault, against a quantum computer and against anyone holding the owner's ordinary wallet keys.

Not protected:

  • funds left in ordinary wallets, except what the Escape Hatch moves in time;
  • a stolen phrase: whoever has the 24 words controls the vault, within its rules (whitelist, delay, limits and the recovery key are the mitigation);
  • browser compromise at the moment of signing;
  • the program's upgrade authority, an ed25519 key, until it is burned at mainnet launch.

One message per key, enforced from the chain. Before any signature, the client reads the vault's full transaction history and refuses to sign if that one-time key ever published part of a signature for a different message, from any device or payer, in any failed or cancelled attempt. Signing is deterministic, so retrying the same message reveals nothing new.

One tree, one vault. A key tree is used in exactly one vault, because the signed message names the vault.

Status: devnet only. Unaudited. 25 end-to-end program tests, plus an internal review that found and fixed one critical client issue before launch.

$NOX utility

$NOX unlocks features and priority by the amount held inside a vault, checked by the program on-chain: holding it means locking it behind hash-based keys, where it is itself quantum-safe.

Tier$NOX held in the vaultUnlocks
Free0Vault, withdrawals, staking, whitelist and delay, recovery key, Escape Hatch, standard relayer fee
GuardianThreshold G (set by protocol parameters)Free tier, plus testament, schedules, session budgets, waived vault-creation fee
SentinelThreshold S (set by protocol parameters)Guardian tier, plus multi-signer vaults, free relayer, keeper every minute

Safety never depends on the tier: recovery keys, the whitelist, delays and the Escape Hatch are free for everyone. A feature that was enabled stays executable even if the vault's $NOX later drops, so heirs and co-signers are never locked out.

Q-Day priority. When the canary trips, keepers evacuate linked wallets in order of tier, then of $NOX held. Transactions land in the order they are sent, so the front of the queue matters most in the first blocks after a break.

Fees. The protocol charges a small SOL fee on vault creation and relayed actions, paid to the treasury. Guardian and Sentinel waive the creation fee; Sentinel also relays free.

Governance. $NOX holders set the protocol parameters: tier thresholds, fees, the default validator for vault staking and treasury spending (see Governance and treasury).

Tokenomics

$NOX launches as a fair launch on pump.fun on 13 October 2026 at 20:00 CEST: no presale, no private round. The contract address is published only on www.nox-vault.com and @noxvaultHQ. The decisions that remain open are listed below with a recommendation for each.

Principles:

  • Utility before speculation. $NOX is bought to use the protocol (tiers, priority, fee waivers, governance), not as a claim on profits.
  • Locked by use. Tier balances sit inside vaults, so active users hold rather than trade.
  • No hidden supply. Mint and freeze authority are revoked at launch; every allocation is a public, time-locked account.
DecisionOptionsRecommendation
Launch methodFair launch (bonding curve) or presaleDecided: fair launch on pump.fun, no presale
Total supplyFixed at launchDecided: 1,000,000,000 $NOX, fixed; mint and freeze authority revoked by pump.fun
Team and treasury allocationNone, or a vested shareIf any: a small share in a public vesting account, 12-month cliff
Tier thresholds G and SAbsolute amountsSet as a share of supply at launch, adjustable by governance
Protocol feesSOL creation fee and relay fee0.01 SOL creation, relay at cost plus a margin; both to treasury
Treasury useCanary bounty, audits, keeper and relayer costs, developmentIn that order; buybacks only after legal review

Governance and treasury

The vault logic becomes immutable at mainnet; only a small set of protocol parameters stays adjustable, first by the team and then by $NOX governance.

  • Immutable: signature verification, approvals, vault rules, testament, Escape Hatch and canary logic. The program's upgrade authority is burned once the audited version is deployed.
  • Adjustable parameters: the $NOX mint, tier thresholds G and S, the creation and relay fees, the treasury address. They live in one protocol account; until governance launches, a multisig of the team controls it, and every change is public on-chain.
  • Governance: $NOX holders vote on parameter changes and treasury spending through a standard Solana governance program (SPL Governance / Realms), with $NOX held in vaults counting as voting power.
  • Treasury: receives protocol fees in SOL. Its first uses are the canary bounty (a larger bounty is a louder, more credible alarm), independent audits, and the running costs of the public relayer and keeper.

Roadmap

roadmap // gates, not dates
✓Builddone02Devnetnow03Auditnext04Mainnetafter the audit gate05Governancethen
Each phase starts only when the previous one's exit condition is met and published.

Noxvault is on devnet today; mainnet follows an independent audit, and governance follows mainnet.

PhaseStatusWhat it contains
BuildDoneProtocol v1 to v3, 25 program tests
DevnetNowPublic testing, test $NOX tiers
AuditNextExternal review, bug bounty
MainnetAfter the audit gate: report public, findings fixedUpgrade authority burned, $NOX tiers live
GovernanceThenParameters and treasury by vote

No dates are committed until the audit is scheduled. Each phase starts only when the previous one's exit condition is met, published on-chain or in the repository.

Risks

The largest risk today is unaudited code; the largest long-term risk is that the threat Noxvault guards against arrives late, or differently than expected.

RiskWhat could happenMitigation
Smart-contract bugFunds locked or lostIndependent audit before mainnet, bug bounty, small limits at launch
Lost phraseVault unrecoverableRecovery key, testament, Shamir and encrypted backups
Stolen phraseFunds moved within the vault's rulesWhitelist, delays, instant limit, recovery key can cancel
Browser compromisePhrase read while signingOffline signing on an air-gapped device
Escape Hatch raceAn attacker who breaks a wallet key moves its funds firstKeep most funds in the vault; canary priority
Quantum timelineQ-Day is decades away or never comesNoxvault is useful today as a rules-based vault; it is a precaution, not a prediction
Upgrade authorityAn ed25519 key could change the program until burnedBurned at mainnet after audit
InfrastructureRelayer, keeper or RPC unavailableAll are optional and replaceable: anyone can run them
Market$NOX price falls; tiers become cheap or expensiveThresholds adjustable by governance
RegulatoryToken or service treated as regulatedLegal review, MiCA white paper before any public offer in the EU

Appendix: parameters, costs, addresses

ItemValue
HashSHA-256, 32-byte chain values
Winternitz parameterw = 256, 34 chains (32 message + 2 checksum)
Keys per vault256 per signer tree (height 8), 16 for the recovery tree (height 4)
Signature1,088 B + 32 B seed + 256 B authentication path
On-chain verificationabout 180 compute units per hash, 4,000 to 5,000 hashes per signature on average
Transactions per actionusually 2; worst case 3
Key tree buildabout 3 s in Node, longer in a browser; once per vault, public part cached
Vault state rentabout 0.003 SOL, paid once
Program (devnet)8iDqwPFRxr2rHiuieVhGL4jdTT7XPE5qPAReS6VzTPw4
Quantum canary6S396A19NFHWdABtBP17tjfFCZA9LJuuvuPK7hWzj7w9, the first i = 0 with SHA256("noxvault/canary/v1" ‖ u32le(i)) on the ed25519 curve
Test $NOX (devnet)tNOX 9BGzxXGPpoQnFisTDGmEmaxy1hbzmd2yXSmivsfgbLA5; Guardian 10,000, Sentinel 100,000
Websitehttps://www.nox-vault.com
Xhttps://x.com/noxvaultHQ

Glossary: WOTS+ — Winternitz one-time signature with per-hash tweaks; Merkle tree — a hash tree whose root commits to all its leaves; leaf — one one-time key; approval — a verified signature recorded on-chain; keeper — anyone who runs permissionless follow-up instructions; relayer — anyone who pays network fees for a signed action; Q-Day — the day ed25519 can be broken in practice.

Sources