Block 55,000 was mined at 11:38 UTC on 24 September 2026, and with it hardfork delta went live on Neptune Cash mainnet. Its headline change is transaction chaining. Bulletin #4 previewed the fork in detail; this post covers what is now live.
In short
- Your coins are safe. To send, update to Neptune Wallet 4.3.0 or later. If you run a node, use Neptune Core 0.18.0.
- New in the rules: a payment can now spend coins that haven’t been confirmed yet, by being combined with the payment that creates them.
- Nothing to try yet: no wallet or command-line tool can make a chained payment so far. Sending works as before.
- Also in the fork: Triton VM version 8 with soundness fixes, a fix for an attack that could freeze coins, and optional expiry times for transactions.
Why chaining matters
Until this fork, a Neptune transaction could only spend coins that were already in a block. If Alice paid Bob, Bob had to wait for that payment to be mined before passing any of it on. Blocks come roughly every ten minutes.
For one payment, that’s a short wait. For an app that handles many payments in a row, it’s a ceiling. An on-chain exchange on Neptune would keep its current state in a coin that every trade spends and replaces, so it could handle only one trade per block, as the design post for chaining pointed out. That’s about six trades an hour.
The cause is privacy. A Neptune transaction never points at the coin it spends. It proves the coin is somewhere in the chain’s record of coins, without revealing which one. A coin that hasn’t been mined isn’t in that record yet, so there was nothing to prove against.
How chaining works
With chaining, Bob can pay Carol straight away. His payment can’t prove its coin is in the chain’s record, so it carries an IOU in its place: a promise that names the coin from Alice’s payment, which hasn’t been mined yet. No block accepts a payment with an unsettled IOU, so Bob’s node combines the two payments into one transaction. The IOU cancels out against the coin Alice’s payment creates, and that coin, which only passed through Bob, never has to be written to the chain at all.
If Alice’s payment never goes through, Bob’s can’t either, so nobody can pass on coins they never received.
Allowing this needed a new version of the proof that every block transaction carries, which changes what every node checks. Together with the Triton VM upgrade below, that’s why delta is a hard fork: nodes that don’t upgrade can’t follow the chain.
Also in the fork
- Triton VM v8. Triton VM is the engine that produces and checks Neptune’s proofs. Version 8 fixes flaws, found in a review, that could have let a proof misstate which program it ran. It also strengthens the guarantee that proofs reveal nothing, and rejects malformed proofs instead of crashing. Its proofs aren’t compatible with version 7’s, which is why wallets needed an update.
- A fix for coin freezing. An attacker could deliberately overfill part of the chain’s record of spent coins, which could make coins that depend on that part unspendable. Delta enlarges the format so this no longer works.
- Optional expiry. A transaction can now carry an expiry time, after which no block may include it. It’s meant for exchanges and other automated senders. It’s opt-in, and for now only developers using neptune-core’s Rust libraries can set it.
What isn’t there yet
Chaining is in the rules, but no app offers it yet. Neither the wallet nor the command-line tools can make a chained payment. Developers can already build one with neptune-core’s Rust libraries, and nodes pass chained transactions along. The core team kept app integration out of the fork release to keep it focused, and says DeFi features will live in separate apps built on top of the node.
It’s also demanding for now. A chained payment does its heavy proving on the sender’s own machine. On the developers’ benchmark workstation, with 123 GB of RAM, that took more than 15 minutes: longer than the ten or so minutes between blocks. If Alice’s payment is mined first, Bob’s chained send stops, and he can pay Carol the ordinary way.
What you need to do
- Desktop wallet: update to Neptune Wallet 4.3.0 or later to send. Older versions still sync and receive, but can’t send. The wallet uses a hosted server by default, so you don’t need Neptune Core unless you point it at your own server.
- Node, miner or your own wallet server: run Neptune Core 0.18.0, the latest. Anything older than 0.17.0 rejects the new blocks and falls off the chain, and 0.17.1 added security fixes. See the core team’s upgrade notice.
- Payment stuck from before the fork? A payment still pending when block 55,000 arrived was built under the old rules and can never be mined now. Remove it from your wallet’s pending list and send it again. You won’t pay twice.
- Community Android wallet: it’s built outside the core team and needs its own update for Triton VM v8. Check with its developer before sending.
What’s next
The core team has turned to succinctness, which would let a new node sync by checking a single proof instead of replaying the whole chain. It’s now planned as a soft fork, meaning nodes that don’t upgrade can still follow the chain. Work has also started on a DeFi module for swapping NPT with user-created tokens. For background on the fork and the features after it, co-founder Alan Szepieniec discusses both in a late-August video.
Questions are welcome on the Neptune Forum and Telegram.