The problem VitaPod solves

The Problem

Patients will share health data for research — until they learn who receives it. Only 18% trust pharmaceutical companies "a lot" (65% say pharma "only wants money" — CISCRP 2023, n=12,017), and among people who had already enrolled in a trial, 31% were still concerned about their data being stolen (NEJM/Mello 2018). That distrust is earned: recent breaches include Novo Nordisk (~11,500 participants' biomarkers, June 2026), DM Clinical Research (1.67M recruitment records on an unprotected database), Cencora (1.4M individuals across Novartis/Bayer/AbbVie trials), and 23andMe (6.9M users, data marketed to target ethnic groups). Health data can't be reset like a password — a breach is permanent.

On top of that, screening itself is brutal: patients travel an average of 67 miles one-way (135 for rare disease), spend 2-4 hours at the site handing over a complete medical history, and 20-80% fail anyway depending on indication. ~40% of NCI network trials fail to complete accrual and fewer than 2% of eligible cancer patients ever enroll in a trial at all.

The Solution

VitaPod lets a patient cryptographically prove they meet clinical-trial eligibility criteria (age, HbA1c, eGFR thresholds) without ever revealing the underlying biomarker values to the sponsor. Instead of handing over their medical history, they generate a zero-knowledge proof, locally, on their own device. The sponsor receives one bit — eligible or not — plus a wallet address and two cryptographic digests. Nothing else.

Prior Art: the idea exists on paper — a working implementation didn't

Zero-knowledge proofs for healthcare privacy are not a new idea. TeleZK-L2 proposes a scalable zk-SNARK framework for telehealth; TeleZK-FL extends this to zero-knowledge federated learning for remote patient monitoring; zkFL-Health combines blockchain with zero-knowledge federated learning for medical AI; CoSMeTIC presents zero-knowledge Merkle trees for clinical research, demonstrated on Huntington's and HIV-1 case studies. All four exist as academic papers, with no shipped, runnable code. Commercially, Solve.Care's Care.Trials (launched 2023) claims to be "the first healthcare network to use ZKPs" for patient-to-trial matching — but its documented ZK usage is for identity verification, not zkML proving a computation over biomarker data. EZKL's own documentation and examples contain no healthcare use case at all. We searched specifically for an open-source implementation combining EZKL, ONNX, a generated Solidity verifier, and an on-chain registry for clinical eligibility, and found no runnable example anywhere. VitaPod isn't a new idea — it's the first reference implementation that proves the idea actually works end to end, on a real chain.

Technical Architecture (three stages, strict data isolation)

1. Browser (local only). A React/Vite frontend parses the JSON health record with a Zod schema — the single source of truth — and evaluates the eligibility policy locally, in memory, for an instant preview. No network calls, no persistence.
2. Local proof pipeline. Inside a pinned Docker container, the identical policy is encoded as an ONNX computational graph (age >= 18, 5.7 <= HbA1c < 8.5, eGFR >= 60, all normalized to fixed-point integers) and EZKL (v23.0.5) compiles and proves it as a Halo2 zk-SNARK — a real cryptographic proof of correct computation, not a hash comparison or a simulation.
3. Blockchain. A generated Solidity verifier plus a TrialProofRegistry contract verify the proof on-chain and enforce replay protection (one accepted proof per wallet per policy), emitting only ProofAccepted(wallet, policyDigest, proofDigest). No age, HbA1c, or eGFR value ever appears in the proof, the calldata, or the event logs — verified by an automated privacy-scan test on the bundle, not just an assertion. A separate guard test scans the intake component's source for fetch/axios/XMLHttpRequest/localStorage/etc. and fails the build if any appear, so "no upload" is enforced, not just claimed.

Measured performance: 5.665s one-time setup, 2.050s to generate a proof, 0.027s to verify it.

Deployed and independently verified on a public chain, not just localhost

The registry and verifier are deployed on HashKey Chain Testnet (chain 133) — confirmed via raw RPC/API calls rather than trusting the deploy script's own output: deployed bytecode matches the compiled artifacts at both addresses, registry.verifier() resolves correctly, registry.policyDigest() matches the expected hash, and a real committed proof bundle was simulated against submit() and returned accepted at 648,593 gas — the actual zk-SNARK verification logic runs correctly on a public chain. Both contracts are also fully source-verified on the block explorer, with the verified source independently re-hashed to match the committed repository files byte-for-byte. Mainnet was deliberately not touched.

Market

AI-based patient matching is a $641.6M market (2024) growing to $2.4B by 2030 (24.8% CAGR — Global Industry Analysts, Jan 2025); the broader clinical-trial recruitment market is $11.8B (2025) heading to $26.2B by 2035 (Roots Analysis). Sponsors already pay for privacy infrastructure: Datavant's tokenization is deployed across 270+ trials and 2,000+ hospitals, including the top 30 pharma brands, and carries a $7B valuation — but tokenization still requires a trusted intermediary to hold the linkage keys. A zero-knowledge proof needs nobody to hold anything.

Five buyer segments are already primed for exactly this: CROs (IQVIA, Medpace), who directly bear screen-failure costs ($800–$2,500 per failed screen — Tufts CSDD); patient-matching platforms (Trialbee, Antidote), for whom privacy is a differentiator — notably, Deep 6 AI, a pure NLP-matching competitor with no privacy layer, raised $55M+ and was acquired by Tempus AI for just $17.4M in March 2025, evidence that matching alone isn't a durable moat; decentralized-trial vendors (Medable, Science 37, Curebase), whose entire business model depends on trust for remote enrollment; rare-disease programs (RARE-X, Global Genes), trying to reach patients who won't share data at all; and DeSci organizations (VitaDAO — ~$56M treasury, Molecule), who need exactly this kind of privacy-preserving proof-of-contribution substrate for their IP-NFT funding mechanisms.

Note for investors: we've since done deeper due diligence on market sizing, competitive positioning, and go-to-market sequencing beyond what's summarized here. Reach out to the contributors below if you'd like to see it.

Project Potential — Roadmap

The 4-biomarker threshold shown in the demo is deliberately the simplest possible case, not the ceiling — the same EZKL/ONNX pipeline that proves it today compiles arbitrarily complex models the same way (EZKL has demonstrated proofs over 18-million-parameter networks), and swapping in a richer model is a model-export change, not an architecture change. That makes VitaPod less a clinical-trials-only tool and more a general privacy primitive: cryptographic proof of any deterministic computation over private data, without trust requirements — infrastructure other Decentralized Science projects needing "prove this happened, without revealing the private input" could build on directly. Each phase below is additive on the same architecture that's already shipped and deployed — none of it requires a rewrite:

• Phase 1 (today, shipped): Prove eligibility for a threshold policy — built, deployed to HashKey Chain Testnet, and independently verified.
• Phase 2 — Authenticated inputs: Today's proof shows the computation ran correctly, not that the input came from a real lab. Phase 2 adds provenance via zkTLS, signed lab results, or FHIR provenance to close that specific, explicitly-acknowledged gap.
• Phase 3 — Scientific bounties: A sponsor posts eligibility criteria on-chain with a reward attached; a patient's proof auto-claims it the moment it verifies — no manual review loop, no intermediary.
• Phase 4 — Proof-of-contribution: Proofs generated across enrollment, milestones, and completion accumulate into a portable, privacy-preserving track record that can unlock real benefits — drug-access discounts, priority trial access, travel/time compensation, aggregated personal health insights, or patient advisory-board seats. Sponsors and DAOs choose the reward structure; VitaPod stays the neutral, verifiable substrate underneath — not the reward mechanism itself, so it composes with existing DeSci IP-NFT frameworks (Molecule, VitaDAO) rather than competing with them.

Tech Stack

Zero-Knowledge Proofs, zkML, EZKL, Halo2, ONNX, Solidity, Hardhat, React, Vite, viem/wagmi, Docker, HashKey Chain (EVM L2), Python, Zod, TypeScript

Contributors

• Diana Chang — AI Engineer, Project Lead (PharmD, MS Health IT) — LinkedIn
• Mehdi-Loup Nasom — Blockchain/Web3 Developer (ENSC Ingénieur en Cognitique) — LinkedIn
• Mariana Uchoa — Scientific Advisor (PhD Neuroscience, former clinical trial operations) — LinkedIn

GitHub: github.com/dyrtyData/VitaPod

Challenges we ran into

Browser/WASM proof generation: a real upstream dead end, not a skill issue

Our core flow proves eligibility via a CLI-in-a-Docker-container pipeline (pinned EZKL v23.0.5, aarch64, ONNX 1.19.1). As a stretch goal, we tried moving proof generation itself into the browser via a Web Worker using @ezkljs/engine, for a much better UX than shelling out to a container.

It turned out to be structurally impossible with our pinned toolchain, not just hard. The last version of @ezkljs/engine ever published to npm is 22.0.1 (April 2025) — there is no v23-line release — and the EZKL v23.0.5 GitHub release ships CLI binaries only; inspecting the zkonduit/ezkl source at that tag confirmed the wasm-bindgen JS bindings that existed in earlier versions were removed upstream, leaving only Python bindings.

We didn't just assume this was fatal — we tested it. Running engine 22.0.1's wasm build inside our container against our actual v23.0.5 prover artifacts, every validation step passed (settings, input, SRS, verification key, proving key) and verify() on our real CLI-generated proof returned true. But compiledCircuitValidation() and genWitness() both threw Internal error: Failed to deserialize compiled circuit: io error, reproduced twice across independent artifact regenerations — a binary serialization format break between EZKL v22 and v23. Since proving requires the compiled circuit, in-browser proof generation was a dead end with this pairing, even though in-browser verification of our CLI-generated proofs would have worked fine.

We considered three ways around it: downgrading the whole toolchain to the matched EZKL/engine v22.0.1 pair (rejected — would force rewriting the already-committed, tested Halo2Verifier.sol and destabilize the working demo this close to submission); hand-building a wasm engine from the v23 source ourselves (rejected — not a checksum-pinned official artifact, and realistically a multi-day effort); and switching the entire stack to Circom + snarkjs, which is technically superior for this specific tiny 4-comparison circuit (KB-scale proving keys instead of EZKL's ~157MB pk.key, sub-second proving, no COOP/COEP/SharedArrayBuffer requirements) — we explicitly discussed this and declined it too, because it would abandon the "real ML model compiled via ONNX" story that is the actual point of the project, in exchange for a hand-written circuit, and meant a 1-2 day rewrite of the prover, verifier, and registry adapter we didn't have time for.

Given our own project rule — never simulate success — we recorded the failure honestly and stopped rather than ship a worker that could only ever fail. Zero feature code was written for it; the stretch branch stayed empty and unmerged. VitaPod ships the fully working, rehearsed CLI-to-chain flow, with browser-native proving documented as a known, deliberately out-of-scope limitation rather than something we quietly dropped.