A community-run summary of what is happening across the Neptune Cash ecosystem.
📌 In brief
- Transaction chaining is benchmarking 30% cheaper than the single-proof method. Machines with under 64 GB of RAM carry on using the proof-collection method.
- Four wallet fixes are merged; none are yet in a build you can download. The last wallet release was v4.2.0 on 5 August.
- The claim redemption programme is closed. 84% of the 2,727,680 NPT fund was redeemed, and 277,454 NPT now has no decided destination.
📦 Releases
Triton VM v8.0.0 (24 August) is a hardening release for the proof system Neptune is built on.
Triton VM is what decides whether a Neptune transaction is valid, so work on its robustness carries further than most. v8 strengthens it in two places. A node handed a deliberately malformed proof now rejects it cleanly instead of crashing. And the rules that check hashing and program execution were tightened, one of three changes flagged as breaking. A third strand puts Triton VM’s zero-knowledge property on firmer footing: the quotient table is now randomized, which gives an explicit proof of zero-knowledge where previously there was none.
Because the proof format changed, v7 and v8 proofs are not interchangeable, so adopting v8 means a hard fork.
🔗 Transaction chaining
Transaction chaining took most of the development effort this period. Both developers worked on the pipeline across both weekly updates, though the week after 24 August turns to shipping Triton VM v8 and reviewing wallet pull requests. The work is happening in PR #964.
What chaining changes: a transaction can currently only spend inputs that are already confirmed, which caps interactions with a given smart contract at one per block. Chaining lets an output be spent before its parent transaction confirms.
Benchmarking confirmed that producing transactions through the chaining pipeline is 30% cheaper than the single-proof method. It does not replace the other route: the proof-collection method “remains essential for devices with under 64 GB of RAM,” and that is how most laptops create and broadcast a transaction today. The saving comes from the merged step skipping a recursive proof verification it previously performed, checking the same logic directly instead. That is heavy work, but it is not work an ordinary sender does on their own machine: it is the step they rely on someone else to perform. So the 30% goes to whoever runs that step, not to the laptop on your desk.
Integration spans four areas: peer-to-peer sharing, mempool handling, transaction initiation, and upgrader compatibility. When it lands it will ship behind an explicit flag, with the default deferred to a later version.
👛 Wallets
Four fixes are merged; none are yet in a build you can download. No wallet release since v4.2.0 on 5 August.
- #88: password change is now atomic (25 Aug). Changing your wallet password is now a single all-or-nothing operation, so an interruption partway through cannot leave the wallet in an inconsistent state.
- #85: QR codes for generation addresses (22 Aug), encoded as uppercased bech32m so a ~3,500-character address fits QR alphanumeric mode.
- #86: inline recipient validation (25 Aug): addresses are checked as you type, not at send time, and the detected key type is shown.
- #87: first-run onboarding is retryable (25 Aug) instead of bricking on a failed attempt.
Still open: #80, the fix for the reorg bug reported in Bulletin #2, where coins stay marked spent after a rollback and disappear from your balance.
📝 Proposals and governance
Governance became a real topic this period.
The 24 August update establishes “an unofficial policy setting a 2,000-block preparation window (approximately 2 weeks) prior to hard forks”. That is your guaranteed upgrade notice before a consensus break, and it matters given the v8 fork ahead. The same update adds that “to address concerns around formal governance, a new NIP will be drafted to outline procedures for community members expressing disagreement with proposed hard forks.”
The payment URI standard also moved. The scheme prefix is now settled as neptunecash:, agreed by community vote in the development Telegram channel. The specification is published as NIP-002, currently marked Draft.
🧭 Project and community
The claim redemption programme is closed. On 18 August the core team announced the end of the process that let holders on the pre-relaunch chain redeem their coins. Of a fund of 2,727,680 NPT, 84% was redeemed, leaving 447,787.13504 NPT unclaimed, of which 277,454.08504 NPT has no decided destination: “We have not decided yet what is going to happen with that.” The stated reason for closing is that claims made after the Triton VM vulnerability was discovered cannot be trusted. Hosting for the redemption verification files will also be discontinued.
Visibility was the recurring theme in the group this period. “Group seems very quiet,” one member wrote on 22 August. Another the next day: “we could use an X community for people to freely post and make content; we’re too isolated… lots of people don’t know we exist.” A third, on the 25th: “we could end up with great technology that most of the market simply doesn’t know about.”
🌍 Elsewhere
Another privacy coin found an inflation bug in its own cryptography. Firo disclosed on 13 August that under specific conditions an attacker could forge Spark coins, in what it calls “a supply-integrity (inflation) issue” that “originated in the Spark cryptography paper and was missed by both cryptography audits.” A researcher minted about 200 FIRO on mainnet to demonstrate it; Firo reports no other evidence of inflation, and says keys and wallets were never at risk. Users must upgrade to v0.14.17.2, and Spark spends are limited to a single input until a hard fork.
That is Zcash’s Orchard circuit and Neptune’s own Triton VM constraint work, both in June, and now Firo’s Spark: three privacy chains in three months, each with a gap in the proving machinery rather than an ordinary bug, and each hard to spot precisely because the supply is shielded. Firo says both of its audits missed it. Three in three months is the strongest case yet that expert review alone is not enough, and that the underlying maths needs to be checked by machine.
A supply-chain attack hit the wider Rust ecosystem. On 20 August the Rust Security Response Team disclosed that an upstream crate maintainer, unconnected to Neptune, had their crates.io credentials compromised. Three widely used crates were briefly republished carrying a malicious dependency whose build script downloaded and ran an implant during cargo build. The bad arrayref 0.3.10 was live for 86 minutes. Neptune’s lockfile pins arrayref 0.3.9 and does not reference the other affected crates, so the project was not exposed. But anyone who ran cargo update inside that window would have executed attacker code.
💡 Explainer: what succinctness would change
Succinctness is the missing piece of Neptune’s core design, and the reason it keeps coming up.
Today, joining the network means replaying its whole history: you download every block and verify it, and the longer the chain runs the worse that gets. That is why running a full node is a serious commitment and why light wallets have to trust somebody.
Under succinctness, every block carries a proof that its predecessor was valid, which, recursively, means it carries a proof that the entire chain behind it was valid. A new node downloads one block, checks one proof, and is synced. Not “synced enough to trust a server,” but synced with the same certainty as a node that replayed the chain’s entire history.
Succinctness is scheduled to follow transaction chaining, and can ship as a soft fork.
✅ Worth doing
- Node operators: a Triton VM v8 hard fork is coming, with a stated notice of 2,000 blocks, roughly two weeks. Watch the forum, and the GitHub releases page.
Corrections and additions welcome. Discussion in the Neptune Bulletin thread on the forum.