A community-run summary of what is happening across the Neptune Cash ecosystem.
📌 In brief
- Hardfork delta is live. Block 55,000 was mined at 11:38 UTC on 24 September, and with it transaction chaining and Triton VM v8 are now part of Neptune’s consensus rules.
- Old software needs an upgrade. Nodes older than v0.17.0 cannot follow the chain past block 55,000, and v0.18.0 is current. Desktop wallets older than v4.3.0 can still sync and receive, but cannot send.
- Succinctness is next. The core team’s focus has moved to letting a new node verify the whole chain from a single proof.
🍴 The fork
Before block 55,000 a transaction could only spend coins that were already in a block. Now it can spend an output created by another transaction that has not been mined yet. For a payment that is a convenience. For the smart contracts planned for Neptune it is a requirement, because without it each contract could only be used once per block. For comparison, Monero’s consensus rules require an output to be ten blocks old before it can be spent.
Chaining is now in the consensus rules, but the application side comes later: the 31 August dev update says application integration was left out of the 0.17 release to keep it focused.
📦 Releases
Three node releases shipped in the two weeks before the fork.
neptune-core v0.17.0 (11 September), covered in Bulletin #4, carries the fork itself. One change not covered there: the fork choice rule is now stable. When two valid blocks arrive at the same height, a node keeps the first one it saw instead of flickering between them.
v0.17.1 (15 September) is a security release for the peer-to-peer layer. Most of it closes ways a misbehaving peer could stall or confuse a node, prompted by reports from an outside researcher. It also adds something easy to miss: connections over the node’s libp2p networking layer now prefer TLS 1.3 with a hybrid X25519 plus ML-KEM-768 key exchange (commit 3dd77d54). Traffic between two upgraded nodes on that layer stays confidential even against someone recording it today to decrypt with a quantum computer later. The explainer below sets out what that does and does not cover.
v0.18.0 (23 September) fixes a problem that surfaced the same day in libp2p’s relay component, which helps nodes behind home routers reach each other. A bug in that upstream code could crash part of the networking layer and leave nodes running in a degraded state. The release catches those crashes, and if the networking layer still fails, the node now exits instead of limping on. A new --disable-relay-server flag stops your node relaying for others, while still letting it use relays itself.
The same release carries a change wallet users will feel. Before it, a transaction whose proof was built against a block that was no longer the latest was refused, and the wallet had to prove it again from scratch. Now a transaction up to three blocks behind is accepted, as long as none of its inputs has been spent in the meantime, so a new block arriving mid-proof no longer means starting over. It puts into practice an idea raised in the forum’s block-time thread in July and covered in Bulletin #2. v0.18.0 also adds a SECURITY.md setting out how to report vulnerabilities privately.
👛 Wallets
Desktop wallet v4.3.0 (21 September) is the version needed to send after the fork.
The Android wallet cannot send after the fork until it is updated. It is a community project, maintained outside the core team. A core developer contributed the update for the fork, PR #27, which was merged on 23 September. Among other things it caps the size of the proofs the phone builds, so that proving fits in about 5 GB of memory. Until an updated build is available, anyone who needs to send can restore their seed phrase in the desktop wallet or neptune-core. As a core developer put it: “All your funds are safe if you know your seed phrase.”
Beware impersonators. A group member reported on 15 September being messaged privately by someone posing as a core developer, offering reassurance about the mobile wallet. The core developers do not message people first. Nobody legitimate will ask for your seed phrase.
🛠 Development
Succinctness is now the core focus. It would let a new node check the whole chain by verifying a single proof, instead of replaying its history, as Bulletin #3’s explainer set out. The 14 September dev update says it has been scoped as a soft fork, so nodes that do not upgrade would keep following the chain. Future changes to Triton VM itself will still need hard forks.
The 21 September update describes the first obstacle. When a transaction spends a coin, it carries a record that marks the coin as spent in the mutator set, the structure Neptune uses to track spent coins privately. Part of that record is stored in a compact, “packed” form. Unpacking it inside a proof costs about 15,000 rows of Triton VM execution, a measure of proving work, for each input, and over 1.5 million for a transaction with 100 inputs. Costs like that decide whether proving the whole chain is practical. Changing the mutator set’s layout was ruled out because it would need a hard fork, so the options being evaluated are to drop packing entirely or to pack only digests (hashes).
DeFi will live outside the core. Design work has begun on standing swap orders and user-defined tokens, which would allow atomic swaps between NPT and custom tokens. The 21 September update records the decision to build this, and the wallet logic that goes with it, as a separate application on top of the node rather than inside neptune-core.
🌍 Elsewhere
Zano found a flaw in how its assets are issued. On 25 September Zano announced a vulnerability in its public Gateway Addresses, a feature added in its 26 August hard fork, that “affects asset issuance, including fUSD,” its stablecoin. A network upgrade is coming, and Zano says ordinary users need only install it. Transaction privacy, spend keys and wallets are unaffected, and a technical write-up will follow the upgrade. It is the second privacy chain in six weeks to report a supply-related bug, after Firo in August, and this one sits in a feature only a month old.
A gap in a Monero security proof was repaired on paper. On 22 September MAGIC Grants published a report on a gap in the security proof for Bulletproofs+ aggregate range proofs, which Monero uses to show that hidden amounts are valid. An earlier audit had spotted the problem but did not write out the repair. The report says the Monero network is not vulnerable, and the researchers intend to produce a combined paper that includes formal verification. The code was fine; what was missing was the written argument that it is.
A proposal for shielded payments on Bitcoin, without changing Bitcoin. Shielded Bitcoin, published on 24 September, puts encrypted notes and nullifiers into ordinary Bitcoin transactions and relies on off-chain indexers to check the proofs and ignore invalid ones. It needs a trusted setup, does not address quantum security, and leaves moving BTC in and out as future work. Bitcoin itself never checks those proofs, and that is the contrast with a chain like Neptune, which enforces privacy in its own consensus rules.
💡 Explainer: post-quantum, layer by layer
“Post-quantum” gets used as though it were one property. It is several, and Neptune has them to different degrees.
Consensus is the part that decides who owns what. Lock scripts, the STARK proofs that every transaction and block carries, and the Tip5-based proof of work all rest on hash functions, with no elliptic curves involved. A quantum computer that breaks elliptic curves gains nothing here. This has been true since launch.
Payment notifications tell a recipient which coins are theirs, and stay on the chain for good. Neptune’s standard generation addresses encrypt them with a lattice-based scheme designed to resist quantum computers. The nech address type uses an elliptic curve instead, and its own code documentation warns that someone with a quantum computer who knows such an address could see its transaction history. They still could not spend from it, because spending is locked by a hash.
Transport is how nodes talk to each other, and Neptune nodes currently run two networking stacks side by side. The older one sends messages without encryption. The newer libp2p stack used classical encryption, which someone recording traffic today could break once a large quantum computer exists. For a privacy coin that matters, because which node relayed a transaction first is metadata. Since v0.17.1, two upgraded nodes talking over libp2p agree on a hybrid key exchange that includes ML-KEM, closing that gap for those connections. Connections over the older stack remain unencrypted.
Peer identity is still classical: nodes identify themselves with Ed25519 keys. Impersonating a peer would not let anyone forge a block or spend a coin, because every node checks every proof itself.
✅ Worth doing
- Node operators: run v0.18.0, and make sure your node is restarted automatically if it exits.
- Desktop wallet users: update to v4.3.0 to send.
- Miners: confirm with your pool that it is running v0.17.0 or later.
- Security researchers: neptune-core now has a SECURITY.md for private disclosure. This period’s peer-to-peer fixes started with an outside report.
Corrections and additions welcome. Discussion in the Neptune Bulletin thread on the forum.