Why Proofs?

An indexer scans the PIVX blockchain and builds a registry of names. But why should anyone trust it? What if it:

• Fabricates a registration that never happened on-chain?
• Charges the wrong fee?
• Registers a name twice?
• Tampers with the registry state?

ZK proofs eliminate these questions. Each proof is a cryptographic certificate that the registration was processed correctly. Anyone can verify the proof independently.

What Each Proof Verifies

The PIVX Prover uses SP1 - a RISC-V zero-knowledge virtual machine. For every transaction with domain, the prover performs the following checks inside the zkVM:

1. Name validity — 1-64 characters, lowercase alphanumeric and hyphens, in an allowed zone
2. Address validity — the target address is a PIVX Sapling shielded address on the right network, in the modern bech32 form
3. Ed25519 signature — the signature over the exact signed message is valid, and made by the key the operation requires
4. Operation invariants — ownership, price state and nonce ordering are consistent with the operation being performed
5. Replay protection — the nonce strictly exceeds the record's previous nonce
6. State transition — the Merkle proof reconstructs the old root, and the new root follows from applying exactly this change

If any check fails, the proof cannot be generated.

What the proof does not check

Being precise here matters more than sounding impressive:

• Payment is not verified inside the circuit. Whether a transaction paid the right fee, and whether a BUY actually transferred funds, is enforced by the registrar off-chain and is checkable by anyone replaying the chain with the published viewing key. Proving note ownership inside the zkVM would cost far more than the entire batch costs today, and it would buy a weaker guarantee than replication already provides — a circuit sees only a note commitment, while a replaying indexer sees the decrypted amount and the memo.
• The circuit does not prove the inputs were the real chain. It proves that given this batch, the transition follows the rules. That the batch is the true, complete, correctly-ordered command stream is established by replication — see Trust & Privacy.

This is why PiNS is fraud-evident rather than fraud-preventing: an incorrect batch cannot be proven at all, and a batch that did not come from the real chain is contradicted by every independent indexer.

Public Outputs

Each proof commits 3 values that are permanently bound to it:

Output	Description
old_root	Merkle tree root before this registration
new_root	Merkle tree root after this registration
end_block_height	The latest PIVX block of the registration batch

The end_block_height pins the proof to a specific PIVX block, like a checkpoint. Anyone can scan the chain up to that height with the published viewing key and confirm the memos and amounts match what the batch claimed.