# Lustration counter: To reset or not to reset, that is the question **URL:** \ **Category:** General\ **Created:** [October 5, 2026, 1:11pm UTC](https://talk.neptune.cash/t/lustration-counter-to-reset-or-not-to-reset-that-is-the-question/405 "2026-10-05T13:11:49Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![sword-smith](https://talk.neptune.cash/user_avatar/talk.neptune.cash/sword-smith/32/20_2.png) [@sword-smith](https://talk.neptune.cash/u/sword-smith)\ **Post date:** [October 5, 2026, 1:11pm UTC](https://talk.neptune.cash/t/lustration-counter-to-reset-or-not-to-reset-that-is-the-question/405/1 "2026-10-05T13:11:49Z")
### 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](https://github.com/TritonVM/triton-vm/security/advisories/GHSA-6649-f4rh-52g9) ) . ### 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](https://neptune.cash/articles/version-0.6.0). ### 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: 1. 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). 2. 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. ---
**Author:** ![sword-smith](https://talk.neptune.cash/user_avatar/talk.neptune.cash/sword-smith/32/20_2.png) [@sword-smith](https://talk.neptune.cash/u/sword-smith)\ **Post date:** [October 5, 2026, 1:20pm UTC](https://talk.neptune.cash/t/lustration-counter-to-reset-or-not-to-reset-that-is-the-question/405/2 "2026-10-05T13:20:33Z")
### Note: proof version vs. Triton VM version The _proof version_ is separate from Triton VM’s semantic version number. The mapping is as follows: | Triton VM version | Proof version | | --- | --- | | v7.0.0 | 7 | | v8.0.0 | 8 | | v9.0.0 | 8 | Triton VM v9.0.0 (used in the latest release of `neptune-core`) is therefore just a faster implementation of the same proof system used in Triton VM v8.0.0. Everything said above about proof version 8 applies equally to proofs produced by Triton VM v8.0.0 and v9.0.0.