Skip to content
Proofsure

Proofsure

Insurance without exposure

Created on 23rd August 2026

•

Proofsure

Proofsure

Insurance without exposure

The problem Proofsure solves

Health insurance has a trust problem that costs people their privacy, their money, and their time.

Today's system forces an impossible trade-off, i.e., to get coverage at all, you must surrender your raw medical records to insurers, data that then sits in centralized databases vulnerable to breaches, and can be used to price against you. Then, when you actually need care, claims crawl through weeks of manual adjudication, where legitimate claims get rejected behind non-transparent processes no patient can audit. The entire industry runs on the mistreated assumption that someone must see your private data in order to trust you.

ProofSure removes that assumption entirely by replacing trust with cryptographic proof.

On the underwriting side, the pricing model runs locally in the client's browser via ONNX runtime, user's sensitive health inputs never leave the device, and are never persisted anywhere. A zero-knowledge ML proof (EZKL) then demonstrates to the insurer that the premium was computed honestly using their exact approved model, bound on-chain by its hash so neither side can cheat ensuring patients don't fake inputs and insurers don't secretly swap pricing models.

On the claims side, hospitals sign itemized invoices with EdDSA keys authorized on-chain, and a Groth16 circuit proves five facts simultaneously: the hospital is authorized, the treatment is covered, the expense sum is correct, the deductible/co-pay formula was applied honestly, and the payout respects coverage bounds. Zero medical details touch the chain.

Finally, settlement is automatic because, the smart contract verifies the proof, enforces nullifier-based replay protection so no invoice can ever be claimed twice, converts INR to ETH through a price oracle, and pays out instantly.

The result is that no medical data breaches because there's no central trove of medical data; no opaque rejections because verification is mathematical; no waiting weeks for payouts. Payouts now happen in seconds.

Challenges we ran into

Technical/integration challenges

Reconciling two independently-designed pieces. Person A's real ZK circuit used a different public-input structure than the contract originally assumed, 5 values instead of 4, hospitals identified by BabyJubJub public keys instead of Ethereum addresses, payouts in paise instead of wei. HealthInsurancePolicy.sol had to be substantially rewritten to match, while preserving a backward-compatible legacy path for the old test suite.
Bridging an off-chain currency to on-chain value. The circuit proves amounts in Indian paise (integer math, no oracle dependency inside the proof itself), but settlement happens in ETH. Solved with a Chainlink price feed doing the paise→wei conversion after verification, so the proof never depends on live price data.
A soundness gap in the circuit itself. The deductible, co-pay, and coverage-limit values used inside the ZK proof are private circuit inputs, the contract has no public signal to check them against the policy's actual on-chain terms. This means a proof could currently be built against fabricated deductible/coverage numbers and still verify. Not yet fixed, needs either exposing those values publicly or committing to them cryptographically.
A front-running vulnerability in the legacy settlement contract. ClaimPayoutChainlink.sol's settleClaim let any caller name an arbitrary beneficiary address, meaning a public proof sitting in the mempool could be front-run by someone else redirecting the payout to themselves. Turned out to be dead code (not called from anywhere in the deployed path), but was a real design flaw caught during review.
Constructor signature drift breaking the test suite. Adding the Chainlink price feed changed HealthInsurancePolicy's constructor from one argument to two, and the existing test fixture wasn't updated, all 13 tests failed at the deploy step until the fixture was fixed.
Non-ceremony trusted setups on both ZK pipelines. Both the claim circuit's Groth16 zkey and the premium pipeline's KZG SRS were generated locally rather than via a real multi-party ceremony, a known, disclosed limitation rather than a "real" trust-minimization guarantee.

Team/scoping challenge

Correctly framing what problem is actually being solved. The initial instinct, that ZK proofs prevent an insurer from secretly overcharging on premiums, turned out to be legally redundant (contract law already covers that). The real, sharper insight (from Aditya) was that the actual value is on the claims side, removing an insurer's discretion to deny a legitimate claim. That reframing changed the whole pitch.
Tracking what's actually built vs. designed-but-missing. At one point the premium/underwriting side looked completely unbuilt, no model, no proof pipeline, nothing. A later delivery (the EZKL FastAPI backend) closed that gap.

Tracks Applied (2)

Private AI on Ethereum

ProofSure's premium underwriting pipeline uses AI in a privacy-preserving way that satisfies both paths this track allow...Read More

Overall

Beyond the AI component, ProofSure's core claims-settlement system is built entirely on zero-knowledge proofs deployed a...Read More

Discussion

Builders also viewed

See more projects on Devfolio