Background
Hardfork-delta, which was activated at block height 55,000 on September 24, 2026, came with a new, backwards-incompatible version of Triton VM. This new version includes a fix for a vulnerability in Triton VM’s proof system, detailed [here]( Program-hashing sponge capacity unconstrained in Hash Table initial row allows forged program attestation · Advisory · TritonVM/triton-vm · GitHub ) .
What is the lustration counter?
The lustration counter is a public counter, initialized to the total expected supply (premine + block subsidies). When it is reset with a hard fork, any transaction spending a UTXO created before that fork must pass through the lustration barrier:
- The amount of coins passing through the barrier is publicly revealed.
- The counter is decremented by the revealed amount.
- Once the counter reaches zero, the barrier closes, and any UTXOs that have not migrated become unspendable.
This forces any coins created through an exploit into the light: they can only be moved within the bounds of the valid total supply. For more details, see the v0.6.0 announcement.
Why the lustration counter was not reset again
Despite this vulnerability, the lustration counter was not reset with the activation of hardfork-delta.
The lustration counter exists to give users a guarantee that past vulnerabilities have not been exploited to inflate the money supply beyond its intended amount. So why wasn’t it used here?
- Although the vulnerability in Triton VM was critical, it was not found to be exploitable in any of
neptune-core’s consensus-critical programs. - In other words, the programs that ensure the correct evolution of the monetary supply on the Neptune blockchain could not be exploited through this Triton VM vulnerability.
Shouldn’t we reset it anyway, just to be sure?
We considered resetting the counter as a defense-in-depth precaution, and decided against it:
- Precedent: We don’t want to establish that every hard fork or Triton VM update must come with a reset of the lustration counter.
- Privacy cost: Forcing all UTXOs through the lustration barrier is bad for privacy, since the value of every UTXO passing the barrier is revealed.
For these reasons, we believe the burden of proof lies on the other side: Only if a false proof for any consensus program can be made with either Triton VM proof version 7 or proof version 8, should the lustration counter be reset.
What does the integrity of the monetary supply rest on?
The lustration counter was last reset with the activation of hardfork-gamma, when Triton VM proof version 7 was taken into use. Since then, the integrity of Neptune’s monetary supply rests on two assumptions:
- No false proof can feasibly be made for the consensus-defining programs using Triton VM proof version 7 (blocks between hardfork-gamma and hardfork-delta).
- No false proof can feasibly be made for the consensus-defining programs using Triton VM proof version 8 (blocks from hardfork-delta onward).
A stronger claim for proof version 8
The monetary integrity of Neptune rests only on the assumptions stated above. For proof version 8, however, we believe a much stronger proposition holds:
- No false claim about any Triton VM execution can be proven with its proof system, at a security level of more than 150 bits.
In other words, the soundness of proof version 8 does not depend on the particulars of neptune-core’s consensus programs; it holds for arbitrary Triton VM programs. Something that will be needed for Neptune to function as a proper smart contract platform.