On this page
A community-run summary of what is happening across the Neptune Cash ecosystem.
In brief
- Proving is several times faster. neptune-core v0.19.0 brings Triton VM 9, up to 6.7 times faster on a 96-core machine, and desktop wallet 4.4.0 proves transactions 1.6 to 1.8 times faster. The Android wallet cannot send.
- Development turns to succinctness and smart contracts. Succinctness needs a hard fork after all, and is still expected this year. The first smart-contract work aims to let miners sell their time-locked coins. The fork has no activation height yet.
- Lentern launched on 5 October, offering GPU mining without a pool balance: a miner who finds a block is paid straight to their own address.
- A Triton VM flaw, already fixed by the September fork, is now disclosed. The advisory, published on 5 October once the fix was in force, reports that a check of every affected case found no way to create coins with it, so the lustration counter will not be reset (explained below).
Releases
neptune-core v0.19.0 (1 October) is the release that Thorkil Værge, one of Neptune’s two founders, says leaves “most of the fire-fighting” behind. It fixes networking vulnerabilities that let a peer stall or crash a node, and refuses connections from nodes older than v0.17.0.
It also changes what a node checks. A node syncing from scratch now checks the blocks from before the September fork against a checkpoint built into the release, instead of verifying their proofs, which let the old proof system be dropped. It no longer opens connections over the older peer-to-peer protocol, which has no encryption, though it still accepts them from older nodes. Upgraded nodes talk over libp2p, which since v0.17.1 prefers a hybrid post-quantum key exchange.
The biggest change is speed. Triton VM 9.0.0 keeps the same proof format, so v0.17 and v0.18 nodes accept its proofs. On a 96-core workstation, the largest proof composers build today fell from over 100 seconds to under 15. Ordinary machines gain less, but the change also lets a proof of that size succeed on a 64 GB Linux machine without special configuration.
Security
The 24 September fork carried a fix for a critical flaw in Triton VM, the virtual machine whose proofs Neptune’s consensus rules check. The advisory explains that up to version 7.0.0, a prover could produce a valid proof naming one program when it had actually run that program with its opening instructions skipped. The fix shipped in Triton VM 8.0.0 in August; the advisory followed once the fork had put it into force.
For Neptune, it reports that every shortened form of the consensus programs the flaw allowed, 24,165 in all, was checked before the fix was deployed, and “no path to inflation was found.” For the standard lock script, it puts the chance that a given user’s coins could have been spent without their key at about 2⁻¹²⁴, which is effectively zero.
A forum post by Thorkil the same day explains why the lustration counter was not reset. A precautionary reset was rejected: it would set a precedent that every hard fork or Triton VM update needs one, and it reveals the value of every old output that moves. The stated rule is to reset only if a false proof can actually be made for a consensus program.
Development
Succinctness needs a hard fork after all. The 14 September update scoped it as a soft fork. The 28 September update says it “cannot be achieved via a soft fork,” and Thorkil’s post of 5 October explains why: the witness data carried by transaction inputs is too big and too complex for Triton VM to handle. Thorkil still expects succinctness this year.
What succinctness changes. Succinctness would let a node decide which chain is canonical from a single block, cutting sync time from hours to under a second. Such a light node could not mine, though. Thorkil’s table of node types sets out what each kind keeps and can do, with today’s sizes:
| Node | Keeps | Finds the canonical chain | Can mine | Serves old blocks |
|---|---|---|---|---|
| Light | The latest block only | Yes | No | No |
| Mutator set | Neptune’s record of coins created and spent, about 60 MB | Yes | Yes | No |
| Full archive | Every block, about 60 GB, or 2 GB without proofs | Yes | Yes | Yes |
The speed-up comes just as composers get more to do. Building a block proposal takes the fastest composer about 40 seconds today, and with succinctness that is expected to rise to about 120, since each block will need at least four proofs of today’s largest size and three smaller ones.
Blocks should fit more inputs. An input is a coin that a transaction spends. Today, the data each input carries hits practical limits well before the formal cap of 16,000 inputs per block. The 5 October update says the planned fork will remove part of that data, called chunk dictionaries, targeting 5,000 to 10,000 inputs per block. It also records the decision to let coinbase transactions, the ones that pay the miner, take inputs.
Coinbase inputs are about time-locked coins. Consensus locks half of every block subsidy for three years. A draft pull request that Alan Szepieniec, Neptune’s other founder, opened on 5 October would let a miner sell that locked half inside the block itself. A buyer posts a standing order offering spendable coins for future ones, and the miner’s coinbase transaction fills it, so the miner is paid in spendable coins straight away. It runs as a plugin beside the node, and so far works only on a local test network.
Wallets
Desktop wallet v4.4.0 (5 October) proves transactions 1.6 to 1.8 times faster. If a new block arrives while a send is being proved, it now submits the finished proof instead of starting over. That needs a node on v0.18 or later, which accepts transactions built up to three blocks behind the tip. The wallet’s default remote node already runs the latest release, so users who keep the default setting get this without doing anything.
The Android wallet cannot send. Two weeks after the fork there is no new build: the fix merged on 23 September is unreleased, and the Play Store listing has not changed since June. It is a community project, not a core-team one, and its status was the question asked most often in the Telegram group. To send meanwhile, restore your seed phrase in the desktop wallet.
Consolidate in smaller steps. On 1 October a transaction merging 67 inputs sat unmined in the mempool. A wallet submits a bundle of smaller proofs, which a well-equipped node must merge into a single proof before a block can include it, and that cost grows with the number of inputs. For this one, a core developer put it at about 410 GiB of RAM, even on the memory-saving path. The advice in the Telegram group was to split large consolidations into several smaller transactions.
Mining
Lentern offers mining without a pool balance. Neptune splits mining into two jobs: composers assemble each block and prove it valid, and guessers search for the winning number with GPUs. Launched on 5 October, Lentern does the composing while GPU miners guess on its block templates under their own receiving address. A miner who finds a block is paid the guesser’s share, time-locked half included, straight to that address by the protocol. Lentern keeps the composer’s share, 8 to 64 of the 128 NPT according to its site. The catch is variance: a pool pays out steadily for partial work, while here a miner is paid only for the blocks they find. The client is NVIDIA-only, and the operators are not named.
Project and community
The founders point contributors to the community. In the Telegram group on 9 October, a core developer said the neptune.cash website’s code is public and welcomes pull requests, but “you will probably get faster responses if you collaborate with community members than with the founders.” The founders’ own time is going to succinctness and to smart contracts.
Machine-checked proofs were proposed. On 9 October an outside contributor opened a proposal and two pull requests with proofs for parts of Neptune written in Lean 4, a language for machine-checked mathematics, among them that the mutator set’s spending rule prevents double spends. Each claim is pinned by hash to the code it describes, so it is flagged as stale when that code changes. None of it had been reviewed at the time of writing.
Impersonators were reported in the Telegram group again. Be wary of anyone who messages you first, even if they appear to be from the team, and never share a seed phrase.
Elsewhere
AI mathematics became this period’s security debate. On 7 October, a day after OpenAI released a batch of AI-generated mathematics results, Justin Drake of the Ethereum Foundation wrote that it is now reasonable to “brace for the possibility that ECDSA breaks before qday.” In other words, the signatures Bitcoin and Ethereum use could fall to new mathematics before any quantum computer arrives. Drake called on the industry to “calmly begin planning” for “bunker mode”, recommending a controlled migration of funds to fresh addresses.
Vitalik Buterin called lattice-based cryptography, including the new post-quantum signature standard ML-DSA, the “core new area of risk”, adding: “For privacy protocols, strongly favor not putting encrypted notes onchain.” Cryptographers including Coinbase’s Yehuda Lindell replied that there is “no evidence whatsoever” of a break in such long-standing assumptions, and no deployed scheme was broken in this period.
For Neptune, consensus, proofs and spending rest on hashes, the posture Drake argues for. The exceptions are payment notices, the encrypted messages that tell a wallet it has been paid. Generation addresses encrypt them with lattice-based cryptography, the pattern Buterin cautions against, and EC hybrid addresses with the elliptic curve behind Bitcoin’s ECDSA. If either were broken, past payment details could be exposed, but nobody could spend or create coins.
Zano rolled back a month, not a day. Zano is another privacy coin, whose chain also issues private tokens such as its fUSD stablecoin. A flaw in its Gateway Addresses, a feature added in August and covered in Bulletin #5, let an attacker create coins from nothing. To undo it, Zano first proposed rewinding about 24 hours, but in the end discarded about a month of history, legitimate transactions included. Zano says about 36.9 million ZANO were minted this way, the first batch unnoticed for nearly a month, and that the coins “functioned as authentic ZANO and could be spent normally.”
Monero’s next upgrade needs another inflation fix. At Monero’s research meeting on 7 October, a developer reviewing the code for FCMP++, the upcoming upgrade that hides each spent coin among every output on the chain, reported that an earlier fix for a “detectable inflation issue” was insufficient. The code runs only on a test network so far, not on Monero’s main chain.
Explainer: the lustration counter
A privacy chain hides amounts, so how would anyone know if a soundness bug had let someone create coins from nothing?
Neptune’s answer is the lustration counter. When it is reset with a hard fork, it is set to the total supply that should exist: the premine plus every block subsidy so far. From then on, spending an output created before that fork reveals its amount, and the counter is reduced by it. Newer outputs move privately as usual.
If every old coin is genuine, the counter never runs out. If the supply had been inflated, moving the extra coins would use it up, and once it reaches zero, old outputs not yet moved become unspendable. Forged coins cannot hide: they can only move within the bounds of the valid supply.
The price is privacy, because the value of every old output becomes public when it moves. So the counter is reset only when a flaw could actually have been used to inflate. It was last reset at hardfork gamma, on 18 June 2026.
Worth doing
- Upgrade. Node operators and miners: neptune-core v0.19.0, for its networking fixes. Desktop wallet users: v4.4.0, for faster sends.
Corrections and additions welcome. Discussion in the Neptune Bulletin thread on the forum.