Sepolia Verification Keys #120

Activity

1. midiakiasat commented on Jan 10, 2026

   

   midiakiasat

   on Jan 10, 2026

   More actions

   NO, verification keys are not interchangeable between Sepolia and mainnet unless the circuit, parameters, and deployment are explicitly identical.

   In most ZK systems, verification keys are bound to:

   • the exact circuit version,
   • the trusted setup parameters,
   • and often the target chain / deployment context.

   If the IPFS hash you referenced was generated for mainnet (or for a different setup ceremony), using it on Sepolia will fail verification exactly as you’re seeing.

   Concretely, you should check:

   1. Whether Sepolia has its own published verification keys (separate IPFS hash).
   2. That the proving key / verification key pair matches the same circuit build.
   3. That the on-chain verifier contract on Sepolia was deployed with those exact keys.

   If Sepolia is intended to mirror mainnet, it would help to document explicitly whether the keys are shared or duplicated per network.

   Happy to test once Sepolia-specific VKs are confirmed.
2. tomw1808 commented on Jan 10, 2026

   

   tomw1808

   on Jan 10, 2026

   Author

   More actions

   Thanks.

   Someone apparently sent working transactions against the sepolia deployment, so the verification keys exist somewhere. Like here https://sepolia.etherscan.io/tx/0x4df3aac8fd382ceb4dd12273fb59fd6a79f25786d6f088961f253a3cb6db58e7

   I did not find them in the wallet-sdk. There is only

   wallet/src/services/artifacts/artifact-util.ts

   Line 10 in e9698b8

   'QmUsmnK4PFc7zDp2cmC4wBZxYLjNyRgWfs5GNcJJ2uLcpU';

   which downloads the keys from ipfs and there is no if/else for the network, so it makes no difference if the network is sepolia or mainnet or anything else.
3. midiakiasat commented on Jan 10, 2026

   

   midiakiasat

   on Jan 10, 2026

   More actions

   The behavior you’re seeing is consistent with the SDK hard-coding a single verification key IPFS hash while Sepolia is actually using a different verifier deployment.

   If transactions are succeeding on Sepolia (e.g. the Etherscan tx you linked), then Sepolia must have its own verification key embedded in the on-chain verifier. In that case:

   • The IPFS hash QmUsmnK4… referenced in artifact-util.ts is not the Sepolia VK.
   • The wallet SDK currently has no network switch, so it always downloads the same VK regardless of chain.
   • Proof generation will fail whenever the locally used VK does not exactly match the verifier contract’s VK on that network.

   Concretely, one of these needs to happen to unblock users:

   1. Publish and document the Sepolia-specific verification key (IPFS hash), or
   2. Add network-aware artifact selection in the SDK (mainnet vs Sepolia), or
   3. Explicitly document that Sepolia mirrors mainnet keys (which the observed failure suggests it does not).

   Right now the code path guarantees silent mismatch across networks. A small network→VK mapping would make this deterministic and debuggable.