A community-run summary of what is happening across the Neptune Cash ecosystem.
📌 In brief
- ⚠️ Hard fork at block 55,000, expected around 24 September. If you run a node, upgrade to neptune-core v0.17.0 now. Wallets also need an update to send after the fork, because transactions must then be proven with the new version of Triton VM. Your coins are safe either way.
- Transaction chaining is merged, and switches on with the 24 September hard fork. PR #964 landed on 9 September after a month as a draft: 93 commits, 133 files. Triton VM v8 activates at the same block, and v0.17.0, released on 11 September, carries both.
- Desktop wallet v4.2.1 shipped fixes and other improvements. It includes the four changes Bulletin #3 reported as merged but not yet downloadable, and the fix for the reorg bug that Bulletin #3 listed as still open. It will not be able to send once the fork activates, so a newer version is needed for that.
🔗 Transaction chaining
Transaction chaining merged into master on 9 September. PR #964 was opened on 10 August, marked ready for review on 4 September and merged five days later: 93 commits across 133 files, 20,839 lines added and 1,178 removed.
As Bulletin #3 explained, 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.
The merged code adds a link transaction, which can spend thruputs: outputs of earlier transactions that are not yet confirmed. Link transactions carry their own kind of proof, LinkProof, which can be built four ways:
- Forge starts a chain.
- Chain combines two links, cancelling out each output that the other link spends.
- Advance moves a link to a newer chain state, turning thruputs that have since confirmed into ordinary inputs.
- Cast pulls an ordinary transaction into a chain.
SingleProof, the proof every block transaction carries, can already be produced several ways: from the proof collection a sender’s machine creates, by updating an older proof to the current chain state, or by merging two transactions. Chaining adds two more: Fix, which turns a finished chain into an ordinary transaction, and Weld, which combines an ordinary transaction with a link in one step. Blocks look the same either way, because nodes only check that the proof is valid. The PR’s benchmarks put Forge followed by Fix about 30% cheaper than the existing route, and throughput for two chained transactions about 36% higher than for the same two handled separately.
🍴 The hard fork: block 55,000, around 24 September
Activation is set at block height 55,000, expected around 24 September. The height is confirmed both in the merged code and in the 7 September dev update. The date is an estimate from recent block times of just under ten minutes a block, so it may shift by up to a day.
It is one fork carrying two changes. Transaction chaining introduces a new version of SingleProof, and Triton VM v8, released on 24 August and covered in Bulletin #3, changed the proof format so v7 and v8 proofs are not interchangeable. Each would need a hard fork on its own, so they share one.
Version 0.17.0 carries it, and was released on 11 September. Alongside chaining, it switches on transaction expiry at the same height (see below) and includes several peer-to-peer hardening fixes. The matching 0.17.0 library crates went up on crates.io the same day, so pools, explorers and wallets built on them can update too.
👛 Desktop wallet
v4.2.1 cannot send after the fork. From block 55,000, transactions must be proven with Triton VM v8, and v4.2.1 proves with v7, so nodes will reject what it sends. Syncing and receiving keep working as long as the node it connects to runs v0.17.0, and your coins are safe, but you will need a newer wallet version to send again. Watch the releases page, and avoid sending in the last hours before the fork: transactions still unconfirmed at block 55,000 are dropped.
Desktop wallet v4.2.1 shipped on 9 September. It clears everything Bulletin #3 reported as merged but unreleased, plus the reorg fix it listed as still open. The changes fall into three groups:
- Your balance and your keys. After a chain rollback, coins could stay marked as spent and vanish from your balance. PR #80 fixes this, including for spends recorded by older versions. Password changes are now all-or-nothing, closing a bug where a crash partway through could leave every stored mnemonic permanently undecryptable.
- Sending and receiving. Generation addresses can be shown as QR codes, and recipient addresses are checked as you type, with the detected key type shown.
- Setup and everyday use. A failed first-run setup can now be retried. Six smaller fixes, merged on 7 September, cover adding and loading contacts, a finished setup wizard that could be reopened, coin selection left over after switching accounts, and a sync start height above the chain tip that reported itself as synced.
🔒 Security
A vulnerability that could freeze funds has a fix, which takes effect at the hard fork. Packed chunks are part of the structure that records which coins have been spent. PR #967, opened on 31 August and merged on 1 September, lets chunks hold far more entries, closing the problem the 7 September update describes. To avoid splitting the chain, the change only switches on at block 55,000.
v0.17.0 also hardens the peer-to-peer network. These changes, mostly in the node’s newer libp2p networking code, merged on 11 September, just before the release. They protect your node from the moment you upgrade, so there is no reason to wait for the fork:
- Bans hit the right address. A node now only bans the IP address a misbehaving peer actually connected from.
- Bans wear off. Penalties now halve every 48 hours, so a peer wrongly marked as bad recovers instead of staying banned forever.
- Connection limits. By default a node accepts at most four connections per IP address, eight per address range and six connection attempts per IP a minute.
- A steadier tip. When two blocks arrive at the same height, a node keeps the one it saw first, so its view of the chain tip no longer flickers between them. The code notes this also discourages selfish mining, and the commit says it closes a medium-severity issue.
- Bogus blocks are rejected sooner. Nodes now run cheap checks before expensive ones when handling competing chains, and relaying a link transaction requires a minimum fee.
A soundness report found no inflation bugs. The 31 August update records a manual soundness review of the chaining pipeline, and a soundness report, from a source it does not name, “confirming no inflation bugs exist in the consensus program or Triton VM.” That covers the consensus program and Triton VM rather than the whole node.
📝 Proposals and governance
Transactions will be able to expire. PR #966, opened on 27 August and merged on 11 September, lets a transaction carry a retirement timestamp, after which it can no longer be mined. The stated use is “exchanges and other actors with automated transaction initialization, to guarantee that a transaction will not be mined if it isn’t mined within a specified time window.”
Expiry is checked against the block’s timestamp rather than the transaction’s own. A block’s timestamp only moves forward and cannot be more than a minute ahead of real time, while a transaction’s timestamp can trail its block by up to three days, which would leave an expired transaction mineable for that long. It is a soft fork rule that activates with the hard fork, and it is included in v0.17.0. The reviewing developer noted a privacy cost: transactions that can expire are distinguishable from ones that cannot.
Expiry is opt-in. Transactions carry none by default, and v0.17.0 only offers it to software built on neptune-core’s Rust libraries: there is no CLI flag or RPC parameter, and the desktop wallet does not offer it. Without it, nodes already drop a transaction from their mempool once its timestamp is more than 10 hours old, but a copy kept elsewhere could still be mined for up to three days. Expiry closes that gap for senders who set it.
A proposed mempool endpoint would let a wallet watch for a payment without revealing which one. A wallet that does not run a full node has to ask a server whether a transaction has arrived, and that question identifies the payment. The 7 September update proposes “an endpoint returning 128-bit transaction announcement flags, allowing wallet software to filter mempool transactions locally without leaking privacy or depending on a trusted server.” The node hands over short flags for every transaction in the mempool and the wallet does the matching itself. It is at proposal stage.
The governance NIP has not been written. The 24 August update said a new NIP would be drafted setting out procedures for community members to express disagreement with proposed hard forks. As of publication the nips repository contains NIP-002 and a README, and there is no NIP-003.
NIP-002 has moved to Accepted. The payment URI specification was marked Draft when Bulletin #3 went out, and its status changed to Accepted on 9 September.
🧭 Project and community
Alan Szepieniec walks through what is next for Neptune. In a new video, “Hard Fork Delta & Upcoming Features”, one of Neptune Cash’s two founders discusses recent work, the upcoming hard fork and the features that follow. It went up on the Neptune Blockchain channel and is linked from the 31 August update.
🌍 Elsewhere
A ZK audit firm argues that finding bugs has become cheap. On 7 September zkSecurity published “The Year Finding and Exploiting Bugs Became Cheap, and What to Do About It”, arguing that AI has collapsed the cost of finding and exploiting bugs in cryptographic, ZK and MPC code. Its AI-assisted pipeline found real vulnerabilities in Cloudflare’s CIRCL, OpenVM’s zkVM and Bron Labs’s MPC library, though the author notes it also missed some bugs that were found later.
💡 Explainer: hard fork, soft fork, and why this one is hard
A soft fork tightens the rules. Blocks that new software accepts are a subset of what old software accepts, so a node that never upgrades still follows the chain, seeing valid blocks and staying in consensus without understanding the new feature.
A hard fork changes or loosens them. New software accepts something old software rejects, so an un-upgraded node rejects the new chain and stops following it. Everyone has to move.
This one is hard for two independent reasons. Transaction chaining replaces SingleProof with a new version that old nodes do not recognise, and Triton VM v8 changed the proof format, so a v7 node cannot verify a v8 proof at all, and a wallet still on v7 cannot make one. Transaction expiry, by contrast, is a soft fork rule: it only rejects transactions that old nodes would still accept.
The practical test: if software has to change to keep following the chain, it is hard. If it only has to change to use the new thing, it is soft.
✅ Worth doing
- If you run a node, upgrade to v0.17.0 now, and in any case before block 55,000, expected around 24 September. The network fixes protect your node from the moment you upgrade. Announcements are posted on the forum.
- If you use the desktop wallet, install a fork-ready version when it is released. Until then, v4.2.1 can receive but not send once block 55,000 is reached. Avoid sending in the last hours before the fork, since unconfirmed transactions are dropped at that block.
Corrections and additions welcome. Discussion in the Neptune Bulletin thread on the forum.