Supply Auditability in Neptune: A Quantum-Safe Solution
The Problem
Neptune has experienced two network restarts due to vulnerabilities that allowed undetectable minting. This isn’t coincidence — it reveals a fundamental architectural gap.
The core issue: There is no cryptographic mechanism to verify that total_supply == expected_supply.
When a bug allows invalid proofs that create tokens from nothing, the damage is invisible. We cannot determine how much was minted or by whom. For a monetary system, this is unacceptable.
Why Neptune Can’t Audit Supply Today
Neptune uses Tip5 hashing for value commitments. This provides genuine quantum resistance — a valuable property that Zcash and Monero lack.
However, Tip5 is not homomorphic:
H(a) + H(b) ≠ H(a + b)
Zcash uses Pedersen commitments which ARE homomorphic:
Commit(v1) · Commit(v2) = Commit(v1 + v2)
This allows Zcash to verify sum(all_commitments) == expected_supply without revealing individual amounts.
Neptune’s choice:
┌─────────────────────────────────────────────────────────┐
│ │
│ QUANTUM-SAFE NOT QUANTUM-SAFE │
│ ──────────── ───────────────── │
│ │
│ Tip5 (hash-based) vs Pedersen (EC-based) │
│ NOT homomorphic Homomorphic │
│ Can't audit supply CAN audit supply │
│ │
│ Neptune ──────► ◄── Zcash │
│ │
└─────────────────────────────────────────────────────────┘
The question: can we get BOTH quantum-safety AND supply auditability?
The Solution: Separate Audit Layer with LWE Encryption
Key Insight
We don’t need homomorphism for every cryptographic operation. We only need the ability to verify the TOTAL sum.
This suggests a two-layer architecture:
| Layer |
Purpose |
Cryptography |
Quantum-Safe |
| Privacy |
Hide amounts, prove conservation |
Tip5 + STARKs |
 |
| Audit |
Verify total supply |
LWE encryption |
|
Why LWE (Learning With Errors)?
LWE-based encryption is:
-
Quantum-resistant (lattice-based, NIST post-quantum candidate)
-
Additively homomorphic: Enc(a) ⊕ Enc(b) = Enc(a + b)
-
Compact: ~256 bytes per ciphertext
-
No trusted setup required
Unlike full lattice commitment schemes (which need range proofs and reach 2-10 KB per value), LWE encryption is lightweight because:
-
Range proofs already exist in the STARK layer
-
We only need semantic security, not binding
-
Verification is pure addition, not proof verification
Architecture
╔═══════════════════════════════════════════════════════════════════╗
║ UTXO STRUCTURE ║
╠═══════════════════════════════════════════════════════════════════╣
║ ║
║ PRIVACY LAYER (existing, unchanged): ║
║ ├── owner_commitment: Tip5(pubkey || blinding) ║
║ ├── value_commitment: Tip5(value || blinding) ║
║ └── STARK proof: sum(inputs) = sum(outputs) + fee ║
║ ║
║ AUDIT LAYER (new): ║
║ └── value_audit: LWE_Encrypt(value) ║
║ Size: ~256 bytes ║
║ Key derivation: seed = Hash(audit_pubkey || utxo_id) ║
║ ║
╚═══════════════════════════════════════════════════════════════════╝
How It Works
Setup (one-time):
Generate audit_pubkey via verifiable random generation
NO PRIVATE KEY EXISTS - this is crucial
The pubkey is only used to derive deterministic encryption parameters
Transaction creation:
User creates TX with:
├── [existing] STARK proof: balance conservation
└── [new] STARK proof: value_audit is correctly computed
The user knows their values, proves encryption correctness in ZK
No one else learns the values
Global state tracking:
supply_audit_accumulator:
├── Initialized: LWE_Enc(0)
├── Each coinbase: accumulator += LWE_Enc(coinbase_amount)
└── Each fee burn: accumulator -= LWE_Enc(fee)
Audit verification (anyone, anytime):
left = Σ(all_utxo.value_audit) // homomorphic sum of all UTXOs
right = supply_audit_accumulator // expected encrypted supply
assert(left == right)
If they match: supply is correct
If they differ: inflation bug detected
Why No Private Key?
This is the elegant part. LWE encryption:
ciphertext = A·s + e + encode(message)
where:
A = public matrix (derived from audit_pubkey)
s = secret vector (derived deterministically: Hash(audit_pubkey, utxo_id))
e = small noise
For verification, we don’t decrypt. We check equality:
Σ(ciphertext_utxo) should equal Σ(ciphertext_expected)
Both sides are computed the same way. If supply is conserved, they match. If there’s inflation, they differ. No decryption needed.
Handling Noise Accumulation
LWE has additive noise that grows with operations. After ~100,000 additions, noise could cause false mismatches.
Solution: Periodic noise refresh
Every N blocks (e.g., 50,000):
1. Compute fresh_accumulator with minimal noise
2. Publish STARK proof:
"old_accumulator and fresh_accumulator encrypt the same value"
This is provable WITHOUT knowing the value:
- Show that (old - fresh) encrypts zero
- Zero-encryption is verifiable in ZK
3. Network adopts fresh_accumulator as new baseline
This can be done by anyone — it’s a permissionless protocol maintenance task.
Properties
| Property |
Status |
| Privacy preserved |
LWE is semantically secure |
| Quantum-safe |
Lattice-based |
| No trusted setup |
No private key exists |
| Trustless audit |
Anyone can verify anytime |
| Permissionless refresh |
Anyone can reset noise |
Overhead Analysis
Per UTXO:
-
Additional storage: ~256 bytes
-
Current UTXO size: ~500-800 bytes
-
Overhead: ~30-50% increase
Per transaction:
Global verification:
-
O(n) LWE additions where n = UTXO count
-
For 1M UTXOs: completes in seconds
-
Can be parallelized trivially
Comparison with alternatives:
| Approach |
Size per UTXO |
Quantum-Safe |
Trustless |
| Pedersen commitments |
~32 bytes |
 |
|
| Full lattice commitments + range proofs |
~2-10 KB |
|
|
| LWE audit layer |
~256 bytes |
|
|
The LWE approach is 10-40x smaller than full lattice schemes because we leverage the existing STARK proofs for range validation.
Open Questions for Discussion
-
Parameter selection: What LWE dimension provides adequate security margin? NIST recommends n=1024 for 128-bit post-quantum security.
-
Noise budget: How many operations before mandatory refresh? Need concrete analysis based on chosen parameters.
-
Retroactive audit: Can we compute audit ciphertexts for existing UTXOs, or only for new ones post-fork?
-
Incentives: Should noise refresh be incentivized? It’s cheap but someone needs to do it.
-
Failure mode: If audit detects mismatch, what’s the recovery procedure? Halt? Fork?
Conclusion
Neptune’s quantum-safety is genuinely valuable — it’s one of very few production blockchains with this property. But the current inability to audit supply makes the monetary policy unverifiable.
The LWE audit layer provides:
-
Quantum-safe supply verification
-
Minimal overhead (~256 bytes/UTXO)
-
No trusted setup
-
Permissionless verification
This preserves Neptune’s core value proposition while closing the auditability gap. The cryptographic tools exist and are well-understood. The question is whether the community prioritizes this enough to implement it.
Two network restarts suggest we should.