broke_o_meter

Inspiration

I ran a LinkedIn poll asking which ZKP use case people found most exciting. Age verification, location proof, credit worthiness, proof of broke. All got roughly equal votes.

That last one stuck with me. "Proof of broke" was a joke option but it points to a real problem. A lot of financial systems, subsidy programs, and even informal arrangements need someone to prove they're below a certain income or balance threshold. And every time, the answer is: send your bank statement. Hand over your actual number to a stranger, a form, a company.

That's a terrible deal. You're sharing sensitive financial data to prove a yes/no fact. The number itself was never needed. Only the comparison was.

That's the gap Broke-O-Meter was built around.

What it does

You upload a screenshot of your bank balance. OCR runs entirely in your browser using Tesseract.js, extracts the number, and shows it only to you. You pick a threshold and a currency. The tool generates a cryptographic proof string. You share that string with whoever needs to verify. They paste it in and get back a verified BROKE or verified NOT BROKE. Your actual balance is never in the output string, never sent anywhere, never stored.

The full system is one HTML file. No server. No backend. No data leaves the browser.

The proof format is:

BOMPROOF:v3:T{threshold}:{commitShort}:{challengeShort}:{responseShort}:{validityHash}:{metaHash}

The balance feeds into a Pedersen commitment + Fiat-Shamir chain implemented with the Web Crypto API (SHA-256). The verifier re-derives expected hashes for both broke = true and broke = false and accepts whichever matches. They learn the result. They learn nothing else.

Currency conversion is also supported. Live rates are fetched from the fawazahmed0 exchange API and cached. If the fetch fails, it falls back gracefully and tells you.

How we built it

The OCR layer is Tesseract.js v5, loaded dynamically from CDN. The crypto layer is the browser's native Web Crypto API. The proof construction chains five SHA-256 hashes with strategically placed slices so the output is compact and portable but the original balance is irretrievable.

The privacy loop looks like this:

The bigger vision is the same architecture applied at scale with real zk-SNARKs. The system architecture below shows what that looks like when integrated with India's Account Aggregator framework, where the bank data is fetched encrypted directly from the FIP, a 288-byte Groth16 proof is generated on-device, and Paytm's backend sees only pass/fail:

![ZKP-Trust Protocol system architecture]

Broke-O-Meter is the honest demo version of that idea. It doesn't claim to be a full zk-SNARK circuit. The commitment-and-hash scheme is cryptographically sound for the specific claim it makes, but it doesn't provide the formal guarantees of Groth16 or PLONK. The README says this clearly.

Challenges we ran into

Getting Tesseract.js to reliably extract a number from a bank screenshot is harder than it sounds. Bank apps render balances in wildly different fonts, with currency symbols in unpredictable positions, commas, dots, spaces. The parsing had to be defensive enough to handle this without false extractions.

The currency conversion flow had a subtle edge case. The raw OCR amount and the working amount needed to be stored separately so switching currencies mid-session didn't corrupt the original reading. rawBalance and rawCurrency are frozen at OCR time. extractedBalance is always the working value in the currently selected currency and is the only thing that feeds into proof generation.

The proof format design required care. The balance can never appear in any segment, which means you can't include it directly, but you also can't just drop it: the hash chain has to be constructed so a verifier can independently verify the claim without ever seeing the input. Getting that right while keeping the format human-readable took a few iterations.

Accomplishments that we're proud of

The whole thing fits in one HTML file and works offline after first load. That felt like the right constraint for something built around the premise of "nothing leaves your browser."

The proof string is human-readable and portable. You can copy it into a WhatsApp message, paste it into any browser, and the verifier works without installing anything.

We tracked actual usage with GA4. The site had 29 users across India, the US, and the UK in the first month with an average engagement time of 1m 05s, 83 total views, and 357 tracked events including ocr_success, proof_generated, and proof_shared_whatsapp.

The spike in the views chart is from one Reddit post. That's how it always goes.

What we learned

People don't naturally trust "nothing is stored" claims. The single-file, no-server architecture is the proof, not the claim. When the entire app is 500 lines of HTML you can read yourself, the trust model becomes self-evident. That's more valuable than any privacy policy.

ZKP as a concept is genuinely hard to explain without a concrete, slightly absurd example. "Prove you're broke without showing your balance" landed much better than any technical description of commitment schemes.

The screenshot loophole is real and intentional to acknowledge. Screenshots can be edited. A real deployment needs Account Aggregator integration so the data comes directly from the bank source. The README says this. Being honest about scope is better than overselling what a demo can do.

What's next for Broke-O-Meter

The roadmap runs in three phases:

Year 1: Replace OCR with Account Aggregator integration. The balance is fetched encrypted from the FIP directly. No screenshot, no forgery. The proof is generated on-device and Paytm sees pass/fail only.

Year 1.5: Expand to B2B and government services. MSME health proofs, age verification, income proofs for subsidy eligibility. The same cryptographic primitive, applied to more claim types.

Year 2+: M2M and agentic payments. Autonomous IoT devices, EV chargers, smart meters, proving funds without exposing identity. The underlying protocol doesn't care whether the prover is a person or a device.

![Strategic roadmap and ROI: 75% reduction in KYC drop-off, 78% higher user adoption]