A community-run summary of what is happening across the Neptune Cash ecosystem.
📌 In brief
- Three neptune-core releases in two weeks. v0.15.0 came out of the audit findings, and v0.16.0 reworked how nodes sync.
- The wallet can now watch an address without being able to spend from it. v4.2.0 adds viewing-key import, a lock that engages automatically after 15 minutes, and sends that survive a block landing mid-proof.
- A payment URI standard is on the table, and it is still waiting for comments. NIP-002 would let a link or a QR code open a wallet with the address and amount already set. Three design questions are open.
- Transaction chaining is the near-term focus, with succinctness queued behind it. The TASM code is written, a security review comes next, and activating it will need a hard fork.
📦 Releases
neptune-core v0.15.0 (30 July) is a security release out of the audit findings. The wallet now checks that a lock script really is yours and really is satisfiable before recording a UTXO, closing a hole where you could be made to credit yourself coins you cannot spend.
v0.15.1 (31 July) is a one-day follow-up: sync-loop fixes so a peer feeding you a bad block during catch-up can’t wedge the process, plus new neptune-cli commands to check whether a specific payment has actually landed in the mutator set.
v0.16.0 (7 August) is about syncing. Nodes catching up can now request cryptographically authenticated blocks rather than relying on what a peer provides, and a node that is itself still syncing can serve those onward. Mutator-set removal-record maintenance went from O(N²) to O(N), the operation that dominates catching up after downtime.
neptune-wallet-app v4.2.0 (5 August) is about watching and locking. Importing a viewing key (nview… or nechvk…) lets the wallet monitor incoming payments from a machine that holds no spending key, and adding the receiver preimage gives a true balance. The wallet can now be locked manually, and it also locks itself after 15 minutes by default, which is on after upgrading. Sends also survive a block landing mid-proof: a proof in flight when a block arrives is rebuilt against the new tip instead of failing, and once broadcast a transaction is no longer re-proven every block, since keeping it valid is the node’s responsibility.
📝 Proposals
The payment URI scheme RFC is now a formal proposal, NIP-002. It defines payment links, QR codes and deep-linking using the scheme string neptunecash:. The payoff is practical: an invoice, a donation page or a shop could offer a link or a QR code that opens your wallet with the amount already set alongside the address, and because the format is a standard rather than one wallet’s convention, every wallet and payment tool can support it the same way.
The proposal carries three open questions for reviewers: the scheme name, QR-code capacity against Neptune’s address length, and how amounts are denominated. It has zero replies on the forum and no comments on the PR since 4 August. If you want to influence how Neptune payment links work, now is the time.
Separately, the block-time thread, opened just after Bulletin #1, has produced a concrete idea: Thorkil suggested letting transactions sync against the n last blocks rather than only the current tip, so proofs relating to slightly older blocks aren’t rejected, calling it “not impossible, but challenging.” That is the real constraint on shorter block times, and it is now written down instead of scrolling past in a chat window.
🧭 Direction
What transaction chaining would change. Today an output has to be confirmed in a block before it can be spent again, so a run of payments advances one block at a time. Chaining lets the unconfirmed outputs of one transaction be spent as the inputs of the next. For anyone paying in sequence, a merchant settling a series of payments or a wallet spending its own change, that is the difference between waiting for a block at each step and not waiting at all.
Transaction chaining is the near-term roadmap, and succinctness is behind it. The 10 August dev update has Alan finishing the TASM code with most unit tests, leaving end-to-end integration, and Thorkil reviewing and integrating it into transaction processing. A security review comes next, to find vulnerabilities and other problems before the implementation goes live.
An earlier audit raised a soundness question about Triton VM, which the team assesses as “a theoretical soundness concern for Triton VM when analyzed in isolation” posing “no risk of funds theft or token inflation within the current Neptune Cash system architecture.” A fix is not yet released.
📖 Coverage
This site published a Technology page on 11 August, a plain-terms explanation of how Neptune keeps payments private and proves them valid, covering the mutator set, address formats, lock and type scripts, Triton VM, zk-STARKs and Tip5. It is written for newcomers, and assumes no prior knowledge of the cryptography involved.
🌍 Elsewhere
A machine-checked proof about zk-STARKs landed on 3 August: Isabelle/STARK: A Formalization of zk-STARK in Isabelle/HOL (arXiv 2608.01965). Isabelle is a proof assistant, software in which each step of a mathematical argument is stated precisely enough that a machine can check it follows. HOL stands for higher-order logic, a form of logic that can quantify over functions and predicates rather than only over values. The work carries a staged soundness theorem with an explicit probability bound, plus a model that can be executed. Neptune’s entire security argument reduces to “the STARK is sound,” which is what makes machine-checked work on these protocols worth watching.
IBM and the University of Chicago claimed verified quantum advantage on 70 logical qubits on 30 July. Worth knowing what it isn’t: an independent fact-check on 1 August concluded these papers “provide no technical basis for revising CRQC or Q-Day estimates, or for changing an organization’s PQC migration plan.” Breaking RSA-2048 needs roughly 1,400 simultaneously active logical qubits under fault tolerance, a different regime. Neptune’s case is better served by being accurate about quantum timelines than by amplifying them.
✅ Worth doing
- Upgrade to neptune-core v0.16.0 and wallet v4.2.0.
- Comment on NIP-002. Three open design questions, zero responses so far.
- Anyone with Rust and STARK experience: transaction chaining goes to security review next, before the implementation goes live. That is the highest-leverage code in the project right now and extra eyes are worth more before the hard fork than after. Introduce yourself on talk.neptune.cash.
Corrections and additions welcome. Discussion in the Neptune Bulletin thread on the forum.