When Neptune launched in February of 2025, I expected that we would spend about one year making it a good and secure L1 for private and post-quantum transactions. Once that was done, we could turn to the exciting stuff: succinctness and novel smart contracts.
Now, almost 19 months after launch, I can see that that timeline was too optimistic. In hindsight, we have spent more time putting out fires than I would have liked to. We went through a (balance preserving) network reset, and later, two resets of the lustration barrier to uphold the guarantee that past soundness errors have not inflated the total monetary amounts.
With the newly released version 0.19.0 of neptune-core, I believe that most of the fire-fighting is behind us, and that we can now focus on the qualities that can make Neptune Cash truly stand apart from other blockchains: succinctness and an approach to smart contracts that unburdens the network from having to track program state.
Succinctness is one of the features I’m most excited about and where I will put my focus the next months. It means you can decide canonicity of a block by just downloading a single block. This will reduce the time required to synchronize to the network, from hours to less than a second, and it will allow Neptune to run trustlessly on smart phones and even smaller devices. On multiple occasions I have predicted that Neptune Cash will achieve succinctness this year, in 2026, and I continue to stand by that claim. Unfortunately, though, it seems like we are going to have to do a hard fork to implement succinctness. The reason for this is that the witness data of the transaction inputs are a) too big, and b) too computationally complex to handle in Neptune Cash’s zk-STARK VM [Triton VM](https://triton-vm.org/). Since succinctness is one of the core pillars of our vision of Neptune, we believe that this upcoming hardfork is worth the price.
Yes. Fully trustless in the sense that it can decide canonicity (which block builds on a chain of valid blocks and holds the most accumulated proof-of-work) without downloading any other blocks.
Tradeoffs? The composers will have to do more work. With succinctness we’re expecting them to have to do at least four proofs with padded height 2^{21} followed by three 2^{20} proofs. 2^{21} is the same complexity that building a coinbase requires. A 2^{21} proof currently takes 15 seconds on a Threadripper CPU. The fastest composer uses about 40 seconds today to build a block proposal. Expect that number to rise to about 120 seconds with succinctness.
Who will run full archival nodes, i.e. read all historical blocks? With succinctness there is no good reason to store historical block proofs. So those don’t have to be saved. But if you want to be able to serve old announcements and an index into those, then you have to know all blocks.
Capability
1. Light
2. Archival mutator set
3. Full archival
Stores
Latest block only
All mutator set data
All blocks, with or without proofs
Disk today
One block
~60 MB
~60 GB with proofs / 2 GB without
Determine block canonicity
Restore own membership proofs
Restore arbitrary membership proofs
Can compose
Can guess (PoW nonce search)
Historical announcements (encrypted UTXO data for the receiver)
UTXO index (instant address lookup of relevant block heights/hashes)
If a light wallet (that does not run its own node) wants to restore balance from an old seed, it needs to connect to a full archival node (proofs are not required)? So in that sense, it’s kind of must-have thing to keep some full archival nodes running?
On a related note, what about off-chain notifications? Is the plan to keep allowing off-chain sends at the protocol level? I’m mainly looking at this from a UX perspective: the sender randomness can’t be recovered from the receiver’s seed, even with a full archival node, so the receiver has to import the notification and back it up separately, since the seed alone won’t restore those funds.
If a light wallet (that does not run its own node) wants to restore balance from an old seed, it needs to connect to a full archival node (proofs are not required)?
Proofs are not required for that server. That is correct. The block Merkle Mountain Range (A collection of Merkle trees commmitting to all historical block hashes) will allow for succinct verification that the content of an old block, that this server serves, is authentic. In my view, this light node will, realistically, get this from an archival node serving all historical blocks, without their proofs. So with today’s block height of about 50,000 blocks, that’s around 2GB. As a fallback, the sender of the transaction can also store this data. In fact, that already happens today: The sender stores all spending information that is required for the receiver to rediscover their UTXOs, and restore their balance.
Is the plan to keep allowing off-chain sends at the protocol level?
Yes. We plan to keep allowing that. If someone wants to use an off-chain protocol to communicate receiver-information, they should be free to do so. On a personal note, I hope that this becomes practical, common, and secure in the future.
I understand that there are risks associated with this, namely that the information required to spend the UTXOs is somehow lost. But those are risks that will have to be mitigated through clever software engineering, on a higher abstraction level than the base layer.
In fact, I don’t even see a way to disallow off-chain notifications. Disallowing them would require every full node to decrypt the (on-chain) announcement to check if it matches the transaction output, the addition record. That would undermine the idea of a privacy-preserving blockchain.
The activation height is still in flux. But since this is a softfork, I think it can happen faster than if it was a hardfork. The miners can be expected to upgrade to the latest version faster than other users can.
So in my opinion, ten days notice would be reasonable.
You shouldn’t upgrade your main net node before this PR has been merged and a new release has been made.
Only if proofs are stored
