Best practices for conditional ZK proof verification in Solidity (threshold-based)

[aletheiamanifesto-pixel]

Hi 👋

I'm working on a system where ZK proofs generated by Noir circuits are verified on-chain, but only when a transaction exceeds a certain threshold (think regulatory compliance — above X amount, a proof is required; below, it's not).

The current approach:

if (amount >= THRESHOLD && address(verifier) != address(0)) {
bytes32[] memory publicInputs = new bytes32;
publicInputs[0] = bytes32(uint256(uint160(msg.sender)));
publicInputs[1] = bytes32(amount);
require(verifier.verifyProof(proof, publicInputs), "Invalid ZK proof");
}

My questions:

Public input encoding: Is casting msg.sender to uint256 → bytes32 the canonical way to pass addresses as public inputs to a Noir-generated verifier? I couldn't find explicit guidance in the docs.
Proof reuse prevention: I'm hashing the proof bytes with keccak256(proof) and storing it in a mapping. Is there a better pattern for replay protection with Noir proofs specifically?
Gas considerations: For the generated UltraPlonk verifier from nargo codegen-verifier, what's the typical gas cost range on mainnet for a 2-public-input circuit? Should I consider batching proofs?

Any pointers to real-world examples of threshold-based conditional verification would be super helpful. Thanks!

[critesjosh]

Hello!

1. Yes, plassing as bytes32 is the way to go.
2. To prevent proof reuse, there is not a standardized way to do this and your approach would work. I think it would be cheaper to add a nonce as a public input to the circuit that gets stored in the contract, which would act as a nullifier. Each nonce should only be able to be used once.
3. I would only consider batching if the transaction volume is high. It would add a lot of latency to the the transactions. A current verifcation is on the order of 1-2M gas i believe

[aletheiamanifesto-pixel]

Thanks so much @critesjosh — this is incredibly helpful!

I've implemented your suggestions:

1. bytes32 for proof passing — confirmed and working ✅

2. Nonce-based nullifier — I'm adding a nonce as a public input to my Noir circuits, stored on-chain in a mapping(bytes32 => bool) in my verifier contract. Each nonce can only be used once, which prevents proof replay at much lower gas cost than my original approach.

3. Skipping batching for now — agreed, at my current volume the added latency isn't worth it. I'll revisit if transaction volume grows.

For context, I'm building AEGIS Protocol — a MiCA-compliant EUR-backed stablecoin with ZK privacy using Noir. The system uses three Noir circuits:

balance_proof — proves balance ≥ threshold without revealing the exact amount
transfer_proof — proves a valid transfer with sufficient funds
compliance_proof — proves KYC verification without revealing identity
The on-chain side includes a NoirVerifier.sol (UltraPlonk), an ERC-20 stablecoin with transferWithProof(), and Zcash-style viewing keys for selective disclosure to regulators.

I'd love to get your thoughts on a couple of follow-up questions if you have time:

For the nullifier nonce — should I hash it with the sender address before storing, or is a plain incrementing nonce sufficient?
Any recommendations on structuring the Noir circuit for the compliance proof, where I need to prove KYC status without revealing the user's identity to the verifier?

Really appreciate

[critesjosh]

I think hashing with the sender address makes sense, so there isn't any risk of being front run by other people interacting.

For kyc, are you looking to use existing kyc providers? It'd probably be worth checking out this zktls project (its for aztec, but could be adapted for Noir). https://hashcloak.com/blog/primus-noir-zktls-tutorial