Neptune Cash versus pinned Quantus: evidence for design comparison

Date: 2026-09-12. Research only. No live transfers, accounts, wallet restores, new proofs or full test suites were run. Current source, packaged dependencies, primary published reports and existing local Trisha receipts were inspected. Source-derived costs and cryptanalytic bounds are explicitly distinguished from measured results. Downloaded sources and scratch metadata were kept in /tmp/mudra-optimality-20260912; pinned source links below are the persistent evidence.

Revisions and release boundary

The GUI therefore must not be credited with all v0.17 transaction-chaining functionality. Core's new Delta rules activate at mainnet height55,000 / testnet0 height5,400, rather than merely because the binary is installed. Live activation height was not queried. Release, Core lockfile, GUI lockfile, fork gates.

Five-axis comparison

Quantus basis: /Users/master/cyber/mudra/audit/{quantus-identity-privacy.md,quantus-wallet-evidence.md,quantus-wormhole-evidence.md}. These pin apps e843b06…, chain 662ef6d…/release f1176ce…, circuits main e77ba5c…/chain-used b224e6d…, CLI b98083b…. Quantus was not re-audited in this task.

Authorization and proof pipeline

The standard lock script reads a secret witness, hashes it, checks the committed lock digest, and consumes five public-input field elements. The calling proof-generation code supplies the transaction kernel MAST hash, including its outputs, fee and state commitment. Consequently this is a proof of authorization for a particular kernel, not a public bare preimage or a reusable claim detached from the message. Binding also depends on the STARK transcript/verification being sound. Generation addresses use this standard hash lock; arbitrary custom lock scripts may impose other policies. Standard hash lock, public input construction, per-lock proving, recursive claim input, Generation binding.

Traditional ProofCollection contains 4 + L + T proofs: four structural checks, L lock-script proofs, T type-script proofs. Raise recursively converts this into one SingleProof; Merge and Update preserve that outer form. Only a SingleProof-backed transaction is block-eligible. Delta adds LinkProof::Forge, which inlines structural checks while recursively verifying lock/type proofs, plus chaining and conversion branches. This is an implementation improvement, not zero proving cost. The current GUI explicitly selects TxProvingCapability::ProofCollection; upstream upgrading work is still required to make it mineable. Count, pipeline and Forge, GUI proof mode.

The GUI abandons a proof collection at subproof boundaries if a new block makes its state stale; one in-progress proof cannot be interrupted. This is another reason that a proof microbenchmark is not transaction completion latency. Proving guard.

Hash, seed and notification cryptography

Tip5 uses Goldilocks, state16, rate10, capacity6, five rounds; its digest is five field elements encoded as40 bytes. Triton8 defaults to security_level160, explicitly described as conjectured. These parameters do not establish160-bit quantum security of the entire wallet. Tip5 implementation, digest, STARK definition, default, Tip5 paper.

The wallet master secret is three Goldilocks elements, about192 bits, serialized as24 bytes /18 BIP39 words. This entropy is an independent ceiling: given a checkable public derived address, generic quantum search over that seed space is about2^96 oracle queries. This is a theoretical query-count observation, not a practical demonstrated attack or a wall-clock estimate. Hashing the seed to a320-bit digest cannot add secret entropy. Actual phrase conversion, derivation.

Default GUI receive mode is Generation, not EC hybrid: the address page initially selects Generation and the wallet's default address derives Generation index0. Generation notification encryption uses twenty-first's own lattice KEM plus AES-256-GCM; the packaged KEM uses64-coefficient ring elements and module rank4, with SHAKE256/SHA3-256 derivations. It is not an ML-KEM implementation or evidence of FIPS203 conformance. This task did not locate a current independent evaluation of this precise KEM sufficient to assign it a production security category. Default UI, default address, Generation encryption, KEM structure, encapsulation/decapsulation.

EC-hybrid is an optional shorter address mode. Its implementation uses secp256k1 ECDH-related material and a separate hash-lock secret; the code and UI warn that a quantum attacker knowing the address can reveal its announced payment history, without thereby receiving the separate spending preimage. Symmetric addresses are secret-bearing and are not for arbitrary third parties. GUI change currently reuses symmetric index0, with an explicit privacy TODO. Do not generalize the EC warning to every Generation-address payment. EC warning, EC implementation, UI warning, change key.

Privacy: stronger confidentiality, remaining observable data

Neptune's public transaction kernel has input removal records, output commitments, announcements, fee, coinbase, timestamp, mutator-set hash and merge status. Ordinary output amounts and lock policies reside in the committed UTXO payload. This is materially more confidentiality than Quantus's public deposit and exit amounts. It is not complete metadata invisibility: input/output counts and times remain observable, and encrypted announcements expose their format and receiver identifier. Reusing an address repeats a recognizable identifier; the source explicitly acknowledges this. Lustration rules can require affected old coins' values to be disclosed to bound inflation after soundness failures. Kernel fields/lustration, public notification header and reuse warning.

The GUI's claim that Generation addresses may be reused without harming on-chain privacy is too broad relative to that explicit notification metadata. This was checked against its actual packaged0.15.0 dependency, not inferred from0.17 alone: the same flag+receiver_identifier encoding and warning exist at GUI dependency revision. This observation does not claim plaintext amounts can be read without decryption.

The lightweight wallet downloads all relevant stripped blocks by height ranges, avoiding the normal-path address-list disclosure found in Quantus's app. Spending-witness recovery sends absolute Bloom-filter index sets; the server returns authentication paths for the plausible AOCL interval, and the wallet privately selects its actual leaf. Thus the exact input leaf is hidden among candidates, but a fuzzy creation range, grouping/timing/IP and the index sets themselves are visible. Special incoming-randomness recovery also has a find_utxo_origin RPC that sends the exact addition commitment; the broad marketing phrase “never reveals inputs” needs this workflow qualification. Block range requests, witness request, candidate response, special origin query.

Seed restore and incremental wallet state

The18-word seed reproduces the key families, including internal change keys. It does not reproduce a counterparty's arbitrary sender randomness. Default on-chain encrypted notifications supply the UTXO payload and randomness during historical scanning. If a payment used off-chain notification, retain/import its payload or the corresponding incoming_randomness.dat recovery data; seed alone is not a universal backup of those receipts. A sender retaining the off-chain payload could resend it. Certain legacy mining rewards have special reconstruction rules. Notification modes/default, scan documentation, GUI randomness import.

Core scan mode defaults to25 future keys and genesis-onward blocks. GUI also defaults to25 and start height0; for every key family it scans all known keys plus that look-ahead. A successful, actually-present output bumps the counter. This is a moving key window, not guaranteed recovery of arbitrarily distant indices or out-of-order use. Funds to an address beyond the current window can be missed; increasing the range and rescanning is necessary. Current core supports explicit historical rescan-announced/rescan-expected commands, so old documentation implying only directory deletion can trigger rescanning is incomplete. Core defaults, GUI defaults, key ranges, scan and bump, current rescan tools.

The desktop wallet fetches batches of100 blocks, persists a wallet tip and transactions, and processes only subsequent blocks during ordinary warm sync. At the tip it waits60 seconds when the next block is absent; retries use shorter delays. It scans announcements locally and checks current unspent UTXOs against each block's removal-index sets. Under a conservative source model, cold network work grows with stripped chain history, not merely the wallet's own transactions; local work includes announcement matching over known/look-ahead keys and UTXO spend matching. Warm work is proportional to newly processed history, with per-block work growing with keys and current unspent UTXOs. Neither restore time nor update cost is constant. Batch size, incremental loop/cadence, spent matching.

Reorgs are explicitly handled: find a common ancestor, transactionally delete receipts confirmed after it, clear later spent flags, reset tip and replay. Unlike Quantus's180-block permanent-cache heuristic, this model has explicit reversal. However, the GUI asks the server which ancestor is canonical, and its stripped block structure contains a kernel/hash without the block proof. The inspected sync path does not independently establish full consensus validity or proof of completeness. Server privacy and server trustlessness are different properties. Fork search, rollback, stripped block.

Mutator-set witness costs: avoid attributing optional work to the default node

A membership witness contains sender randomness, receiver preimage, AOCL authentication path/index and the relevant Bloom-filter chunks. Membership changes as global additions/removals arrive. The optional eager-maintenance path batches updates, but it still traverses maintained wallet witnesses for each addition/removal; there is O(U·(A+R)) bookkeeping in that code before authentication-path/hash factors, for U maintained witnesses and a block with A additions/R removals. This is not O(1) wallet upkeep. Witness fields and append update, wallet per-addition loop, per-removal loop.

But current archival core defaults to zero stored membership proofs per UTXO, derives them from archival state on demand, and has a separate no-maintenance update path. The GUI likewise requests fresh selected-input witnesses when spending instead of eagerly downloading an authentication path for every held coin on every block. Recovery response work grows with the number of plausible AOCL candidates and affected chunks: the server loops over that candidate interval and builds paths, with at most45 selected Bloom indices before deduplication. Default0, archival rationale, two update paths, actual archival dispatch, response construction, parameters.

Measured evidence versus estimates

• Historical upstream measurement, May2025, Triton0.48.0 on Threadripper7995wx: padded height2^20 took46.52s and approx58.4GiB;2^21 took99.17s and107.8GiB. This is a disclosed prover configuration and an obsolete VM version, not current0.17 wallet performance. The accompanying168.47s block-composition figure is the author's sum/estimate, not an end-to-end wallet measurement. Primary benchmark post.
• Existing local real-proof receipt, Trisha's Neptune0.15.1 node gate on2026-09-12: five component proofs, then a1,155,385-cycle SingleProof padded to2^21; reported full SingleProof proving+verification575.958s, peak RSS23,307,108,352 bytes, with4 threads and TVM_LDE_TRACE=no_cache. Actual isolated-node mempool acceptance was tested. This is one custom-lock fixture, not representative phone performance, not mined confirmation, and not v0.17. Source evidence: /Users/master/cyber/trisha/audit/neptune-local-node-validation.md and its linked receipt; not rerun here.
• Current executable benchmark fixtures exist for110-block wallet rescans and wallet tip updates. Checked-in TASM benchmark JSON reports VM cycles/table heights, not seconds. No current-release reproducible cold-wallet restore timing was found in this bounded review. Rescan fixture, cycle-only JSON.
• Official product statement, March31,2026: the lightweight wallet downloads up to1GB of initial block data, recommends2GB disk, and is supported on Windows/Linux/macOS while described as unsuitable for mobile. That figure is a dated product estimate, not a measured present chain size. Desktop release4.2.1 exists; its inspected release assets target Linux, macOS and Windows, with no Android/iOS package. No native mobile release was established here. Official launch/limitations, current GUI release.

What published security work establishes

1. Hridam Basu2024 report: published25-page Triton audit scoped to0.42.1/d2c6fc7, covering AIR/ISA/VM. It reported no cryptographic soundness error; it explicitly excluded constraint builder/circuit, tests, benchmarks and TASM code. It does not certify today's Triton8, the lattice KEM or the whole wallet. Report, pages1–6.
2. July2025 inflation bug and actual August relaunch: the developers discovered the bug on July4 and disclosed it July5. A zero-input/zero-output transaction could omit the native-currency type-script check, and fee merging enabled concealed inflation. The fix made that check mandatory. The official August7 retrospective confirms a new-genesis mainnet relaunch on August5,2025, with a redemption process for holdings at old height21,310. Exploitation was not established. Initial disclosure, actual relaunch and cause.
3. January2026 soundness incident, revised recovery plan: OtterSec reported a Triton soundness bug allowing false proofs and possible undetectable inflation. The January disclosure initially announced reboot/redemption, but that was superseded: the February3 v0.6.0 announcement explicitly chose rollback to height23,400 while preserving earlier ledger history and requiring the patched proof system from23,401. The maintainers' April22 retrospective dates the actual rollback/resumption to February4, and describes the subsequent lustration-barrier policy for old UTXOs. Distinguish the original plan from the shipped recovery. These are historical failures; exploitation and a remaining break in the current patched version are not established here. Initial disclosure/plan, v0.6.0 chosen recovery, retrospective confirming execution.
4. June2026 further incident: core's current Gamma rules explicitly cite recursive-verifier and Triton sponge/under-constrained-trace fixes and restart lustration. The linked June audit archive describes itself as multi-pass output run with Opus4.8, pinned to old Neptunef0fb02a4, Triton5f24556b and tasm41df5997/v3.0.0. Its summary identifies a recursive Fiat–Shamir absorb-length binding break; it says the primitive PoC passed while an end-to-end mint PoC was pending. Do not rebrand this as independent professional certification of the full current stack. Official discussion and archive link, current rule-set explanation.
5. Keyper Labs2025 wallet review: dated October28, scoped to former VxBlocks2.0.1/054e972…, focuses on key safekeeping and expressly says it is not an audit/certification and did not focus on privacy. Its severe findings are historical; Neptune's March2026 article says critical and most high findings were fixed while work remained. This task did not redo that review or certify every fix. Published review, maintainer response.

These are meaningful security-work artifacts and useful failure lessons. They neither prove that Neptune currently has an exploitable break nor establish that one universal cryptographic optimum has been achieved.

Reproduction and local artifacts

Commands executed included:

git clone --depth 1 https://github.com/Neptune-Crypto/neptune-core.git neptune-main
git clone --depth 1 --branch v0.17.0 https://github.com/Neptune-Crypto/neptune-core.git neptune-release
git clone --depth 1 https://github.com/Neptune-Crypto/neptune-wallet-app.git neptune-wallet
git -C neptune-release ls-remote origin refs/heads/master refs/tags/v0.17.0
# Parsed both Cargo.lock files with Python tomllib; inspected rg/nl source excerpts.
pdftotext neptune-keyper-wallet-review.pdf neptune-keyper-wallet-review.txt

Latest release metadata is preserved in neptune-release-metadata.json and neptune-wallet-release-metadata.json. Downloaded dependencies were SHA256-checked against their lockfiles before safe tar extraction:

• twenty-first1.1.0: 2f2127e955aea73cc584e429c544f4a5997128fd5e4021c852cb63f309bf51ea
• Triton VM8.0.0: 0ffb3ccf17d8feee26164a027aaf5d318aeee655592dc744bfdda0863a207d39
• Neptune-wallet0.15.0: 2565599154c3379c7669218d189c62e42f6a0c7427596d0e398f2d9cc554630c

neptune-june-audit.zip, its extracted neptune-june-audit-summary.md, and neptune-keyper-wallet-review.{pdf,txt} are in that temporary directory, not committed here. Production repositories were preserved during inspection. No current runtime-performance or live-restore success is claimed.