Wisk

Background verification has always felt outdated. An employer asks for your documents, a third-party agency collects them, and suddenly your most personal information your identity, your certificates, your government IDs is sitting in someone else’s database. It’s inefficient, it’s risky, and worst of all, it forces you to give up control of your own data.

We wanted to rethink this from the ground up. What if verification didn’t require handing over documents at all? What if you could prove the truth of your records without ever exposing them?

That’s exactly what we built.

Here’s how it works: when an employer wants to verify a candidate, they don’t call a middleman. Instead, they send a simple request by email. The candidate receives that request and uploads their Digilocker-issued certificate a government-signed PDF. Everything happens locally, right in the browser. The raw document never leaves the user’s device.

Our system uses WebAssembly with zk-pdf to parse the actual PDF bytes. It checks whether the requested details like a name or PAN number are present inside the document. At the same time, it validates the government’s digital signature embedded in the PDF, making sure the document hasn’t been edited or forged. If even a single byte is tampered with, the signature breaks and the verification fails.

Once everything checks out, we generate a zero-knowledge SNARK proof. This proof says, “Yes, this document is real. Yes, it’s signed by the Government of India. Yes, it contains the requested details.” And it does all of this without revealing the entire document. Only the facts the employer asked for are disclosed nothing more.

The proof is then emailed back to the employer. They can verify it instantly, with mathematical certainty. No agencies, no central databases, no trust required just pure cryptography. And since the proofs are standard SNARKs, anyone in the network can independently verify them too.

What makes this powerful is simplicity. For the employee, it’s just clicking a link in their inbox. For the employer, it’s receiving an email with a verified result. Underneath, though, it’s state-of-the-art cryptography ensuring privacy, authenticity, and tamper-proof verification.

No private data is stored anywhere. The entire codebase is open source, so anyone can audit how it works. And because it’s tied to Digilocker, only official government-signed certificates are accepted. Fake or edited PDFs are instantly rejected.

In short: we turned background verification into a trustless, privacy-preserving experience. No middlemen. No leaks. Just cryptographic truth, delivered seamlessly through email.

I built WISK on top of zk-pdf, a zero-knowledge proving framework purpose-built for PDFs. The goal was to keep sensitive documents fully private while still letting users prove individual fields (like Name, CGPA, or Institute) are authentic.

On the frontend, we used a Rust → WebAssembly module that runs entirely in the browser. This parses the raw PDF bytes, validates the /ByteRange signature, and extracts text handling tricky ToUnicode maps and CID fonts that show up in Indian DigiLocker PDFs. Doing this in WASM means the file never leaves the user’s device and ensures we feed deterministic, pre-processed inputs to the prover.

For proof generation, instead of writing circuits from scratch, we leveraged zk-pdf’s built-in ZK engine. It takes the pre-processed PDF data, runs signature verification and substring checks inside zero-knowledge, and produces a succinct proof. Only minimal public values (like “Name = Alice Kumar was signed by XYZ Institute” and a page hash) are revealed — the rest of the document stays private.

The orchestration layer uses a Next.js frontend and a lightweight Rust Axum backend. The backend acts as a prover service: it accepts proof requests, calls zk-pdf to generate proofs, and returns them as JSON. The frontend bundles multiple field proofs in parallel (Name, Institute, CGPA) into a single verification package that can be shared with employers. For extra auditability, we also wired this to an on-chain verifier contract, so the same proofs can be validated on Ethereum.

The hackiest part was building our own deterministic PDF parser in Rust. Off-the-shelf libraries weren’t zk-friendly, so we wrote a custom PKCS#7 validator and text extractor, ensuring both the WASM module and zk-pdf use the same normalization rules. Another challenge was parallel proof generation: we fire multiple proof requests at once and then merge them seamlessly into a single JSON response.

In short: Rust + WASM keeps the PDFs private, zk-pdf powers the ZK proofs, and Next.js delivers a smooth verification flow.