PolkaZK Verifier SDK: Tech Specifications

[Disclaimer: This post is posted on behalf of the team behind PolkaZK Verifier SDK, which recently won the first prize in the AssetHub Hackathon. All the credits and ownership of the project belongs to Jatin Sahijwani and Anirudh Singh Chouhan.
Edgetributor SubDAO (6 contributors including me) will be looking after the further guidance and project curation by taking care of the responsibilities like Project Management & Operations, Architecture/Design/UX reviews, DevOps and QA, etc.]

PolkaZK Verifier SDK

With just one CLI command, developers can compile Circom circuits, perform Groth16 setup, and generate all necessary artifacts (wasm, r1cs, zkey, verifier.sol). A corresponding JavaScript SDK makes it possible to verify proofs on-chain with a single function call, allowing developers to embed privacy-preserving logic into their applications seamlessly. The SDK is designed to be intuitive even for developers unfamiliar with Web3, enabling a new wave of applications powered by zero-knowledge technology.

:wrench: Technology Stack

  • Circom (v2) – for defining and compiling zkSNARK circuits
  • SnarkJS – for Groth16 trusted setup, proof generation, and verification
  • Node.js / TypeScript – for CLI tooling and SDK
  • Solidity – for on-chain verifier contract generation
  • PolkaVM-compatible contract framework (e.g., Ink! or EVM-compatible layer) – for verifier contract deployment
  • Next.js (optional) – used in example dApps and for developer demo interfaces

:books: Core Components & Architecture

  • ZK Circuit Compiler (CLI) Compiles .circom files Generates .r1cs, .wasm, .zkey, and verifier.sol
  • Proof Verifier SDK (JS/TS SDK) Provides a simple function: verifyProof(input, pathToZkey) Designed to be plug-and-play in frontend applications
  • Verifier Contract Deployer (Coming soon) Will allow auto-deployment of verifier.sol to a PolkaVM-compatible chain
  • Developer Tools Examples and templates for using zk circuits in age verification, identity checks, etc.

:gear: Architecture

[Circuit.circom]

 ↓

[zk-polka-sdk CLI]

 ↓

.wasm + .r1cs + .zkey + verifier.sol

 ↓

[verifyProof(input, path)]

 ↓

[Verifier Contract on PolkaVM]

:books: Project Documentation

:package: Core Components & Architecture

  • Circom Integration: Supports compilation of user-written .circom circuits to generate .wasm, .r1cs, and zkey files.
  • Trusted Setup: Utilizes Groth16 proving system with preconfigured PTAU files.
  • Solidity Verifier Export: Generates a Solidity verifier contract for on-chain proof verification.
  • CLI Tooling: Abstracts all complex steps into a simple CLI (npx zk-polka-sdk compile ).
  • Optional Runtime: PolkaVM-ready contracts for Polkadot ecosystem (planned extension).

:rocket: PoC / MVP / Prior Work

  • Fully functional CLI-based zk circuit compiler and verifier.
  • Successfully integrated with Next.js + Web frontend for proof generation & verification.
  • Contracts deployed and tested on PolkaVM-compatible chains.

:triangular_ruler: Data Models / API Specs

The SDK provides a set of utility functions to abstract the Zero Knowledge (ZK) workflow. Below are the core APIs and their expected inputs/outputs:

1. Circuit Compilation

Command:

npx zk-polka-sdk compile <path-to-your-circom-file>

Inputs:

  • A .circom file path
  • Outputs (stored in a folder named after the circuit):
  • .r1cs
  • .wasm
  • circuit_final.zkey
  • verifier.sol

2. Proof Generation

Programmatically generate a zk-SNARK proof using your compiled circuit and input signals. Function Signature:

generateProof(

input: Record<string, any>,

circuitPath: string

): Promise<{

proof: any;

publicSignals: string;

}>

Parameters:

  • Input: An object with all private and public inputs (e.g., { birthYear: 2001 })
  • CircuitPath: Relative path to the folder containing your compiled circuit

Returns:

  • Proof: Groth16 proof object
  • PublicSignals: Array of public output signals

3. Proof Verification

Verify a zk-SNARK proof using the associated verifier and public input. Function Signature:

verifyProof(

publicInput: Record<string, any>,

circuitPath: string

): Promise<{

isValid: boolean;

}>

Parameters:

  • publicInput: Object containing only public inputs used to verify the proof (e.g., { birthYear: 2001 })
  • circuitPath: Path to the compiled circuit folder

Returns:

  • isValid: Boolean indicating whether the proof is valid or not

:prohibited: What This Project Does NOT Provide or Implement

While the SDK is designed to make ZK development easier, there are intentional limitations to set expectations clearly:

  • :cross_mark: No UI tools, there is no graphical user interface; usage is CLI or JS/TS API only.
  • :cross_mark: No wallet integrations, connecting to wallets or Web3 providers must be handled separately.
  • :cross_mark: No frontend boilerplate, SDK is backend-focused and does not include UI templates.
  • :cross_mark: No recursive proofs or plonk, only Groth16 protocol is supported.
  • :cross_mark: No multi-language bindings, SDK is built for Node.js/JavaScript environments.
  • :cross_mark: No Circom debugger, writing correct circuit logic is the developer’s responsibility.
  • :cross_mark: No support for custom trusted setup, uses pre-generated pot12_final.ptau by default.

:information_source: This SDK is built for rapid prototyping, education, and integration with PolkaVM-based verifier contracts. It is ideal for developers who want to use Zero-Knowledge proofs without diving deep into ZK cryptography.


:brain: Are there other similar projects in the Polkadot/Kusama ecosystem?

A few, but none match our SDK in usability or flexibility:

Project Focus Area Comparison with zk-polka-sdk
Zcloak Network ZK Identity + DID zk-polka-sdk is developer-centric and supports any use case
Manta Network zk-ID and private swaps zk-polka-sdk offers a modular SDK, not a fixed protocol stack
Subzero (Parity) Experimental ZK tooling zk-polka-sdk is production-ready and easier to integrate

Unlike these specialized protocols, zk-polka-sdk empowers developers to build their own custom ZK logic and deploy it in minutes.


:new_button: If not, why hasn’t a project like this existed?

  • Most efforts have focused on protocol-specific solutions (like identity or credentials), not general-purpose SDKs
  • Circom + SnarkJS, despite being powerful, are considered “too low level” for most developers
  • Existing tools are heavily EVM-centric and incompatible with PolkaVM or require significant custom integration
  • The Polkadot ecosystem lacked a bridge between powerful cryptography and general developer experience, until now

:globe_with_meridians: Are there similar projects in other ecosystems?

Yes, but zk-polka-sdk offers significant advantages:

Project Ecosystem Limitations zk-polka-sdk Advantage
Sismo Ethereum Closed protocol for badges/credentials zk-polka-sdk is open, generic, and developer-controlled
Semaphore Ethereum Only supports anonymous signaling zk-polka-sdk supports arbitrary circuit logic
Aztec SDK Ethereum Requires tight coupling with Aztec L2 zk-polka-sdk works on any chain with Solidity verifier support
Noir/Nargo ZK Stack Still maturing, not Circom-compatible zk-polka-sdk is built on battle-tested Circom + SnarkJS

zk-polka-sdk is the first SDK to:

  • Fully abstract the Circom + SnarkJS workflow
  • Integrate directly with PolkaVM-based chains
  • Provide a CLI and API interface usable by both frontend and backend devs
  • Allow seamless deployment of Solidity verifier contracts on Polkadot-compatible infrastructure

:puzzle_piece: In summary, zk-polka-sdk empowers developers to integrate privacy-preserving zero-knowledge logic in minutes. Built on Circom + SnarkJS and customized for PolkaVM, it’s the most powerful and accessible zk integration tool in the Polkadot ecosystem; and arguably, across all ecosystems.

7 Likes

Hey,
I think the idea is great,

What if i have a circuit that requires different inputs? Can i write some wrapper or interface via your sdk then?

Have you guys looked into any quantum safe zk options? Since groth16 is not quantum proof…

Another question, right now people and zk-polka-sdk converts its to solidity then cross compile to polkavm, do you guys think it would be possible to go directly to a rust script to polkavm? Cut out the bottleneck and improve the performance by supporting polkavm directly in rust? The only thing is to port it to the no-std polkavm rust program. We are trying to go this route and are working on getting halo2 proofs to be able to verify directly in rust to save size and be more performant, this would require a new no-std rust lib doe.

Maybe its possible to implement a better groth16 verifier for generic proof structures with the evm precompiles? Would be nice to be able to kill lot of overhead and go straight to rust polkavm program with a rust lib doe.

We are using parts from Semaphore In kusama Shield. Its hard to find good audited zk evm friendly tools, pse.dev is doing a great job by porting stuff and getting it audited

~flipchan

3 Likes

Thanks for the feedback @flipchan

We really appreciate the thoughtful and technical feedback. Your questions hit key areas we’ve been actively thinking about and planning for. Let us respond point-by-point:


1. Dynamic Input Support

Yes — the current version of zk-polka-sdk already supports dynamic circuit inputs.

The SDK’s verifyProof() functions accept any user-defined JSON object as input. So developers can use different circuit structures (e.g., {a, b}, {birthYear}, or even nested fields), and as long as it matches the .circom circuit’s expected signals, the proof system will work seamlessly.

We’re also planning to expose wrappers and TypeScript types to allow teams to easily add interfaces for custom inputs or validation schemas.


2. Quantum-Safe zk Systems

We completely agree: Groth16 is not quantum-secure, and it’s important to plan ahead.

For now, Groth16 was chosen due to Circom + SnarkJS maturity, Efficient verifier size (ideal for PolkaVM limits), Ecosystem familiarity.

However, we are committed to integrating post-quantum zk systems like Halo2 or STARK-based verifiers as soon as PolkaVM supports them (in terms of runtime or no-std lib support) & we can compile their verifiers into a compact, verifiable format (e.g., no-std Rust or WASM)

We’ve already begun exploring how Halo2 or SP1 (Succinct’s zkVM) might fit as backends for future proof workflows.


3. Moving from Solidity to Rust Verifier (PolkaVM Native)

Absolutely and in fact, this is now a top priority for us.

Currently, we go from .circom → verifier.sol → cross-compile to PolkaVM using @parity/revive. But this introduces several bottlenecks Solidity is not native to PolkaVM’s architecture, Contracts hit size/gas limits, Runtime efficiency is suboptimal

Going forward, we are actively working toward Exporting Groth16 verifiers directly as no-std Rust modules, Supporting native PolkaVM Rust deployments without Solidity, Leveraging tools like ark-groth16 and ark-ec for in-Rust verification logic


4. Performance Optimizations & Precompiles

You’re right — short term, using EVM pairing precompiles gives us some gas wins.

But ultimately, the goal is to remove Solidity entirely, and generate verifier contracts in Rust, purpose-built for PolkaVM’s execution environment.

We’re also evaluating whether an optimized Groth16 verifier in Rust could outperform Solidity-based alternatives in size, speed, and composability.


5. Auditability & Inspiration from Semaphore / PSE.dev

Totally agree finding audited, reusable zk components is hard.

We’re keeping a close eye on PSE.dev’s zk libraries and Semaphore’s primitives, and would be happy to adopt or mirror their best practices in our Rust migration path.

If there’s a preferred verifier architecture that’s secure and works for the Kusama Shield use case, we’d be happy to align with it for broader compatibility across the ecosystem.


Thank you again for the rich technical context. We’re genuinely interested in working with any teams (like yours) pushing the frontier of ZK on PolkaVM and Kusama.

Cheers,
Jatin & Anirudh
zk-polka-sdk team

1 Like

Could ink! be a suitable candidate for this Rust smart contract programming language?

The ink! alliance would be super motivated to help!

2 Likes

Thanks for the acknowledgment and support, this is super helpful! We’ve primarily been working with Solidity-based verifiers for PolkaVM compatibility, but we’re definitely interested in exploring ink! as a native Rust-based alternative. Would love to learn more about how the ink! alliance collaborates with projects and what the funding or support process looks like.

1 Like