zkRune
Visual ZK proof builder - Privacy that works
Created on 2nd December 2025
•
zkRune
Visual ZK proof builder - Privacy that works
The problem zkRune solves
The Privacy Paradox Problem
Most zero-knowledge platforms claim to provide privacy, yet require server-side proof generation - your sensitive data gets transmitted to their servers, violating the core principle of privacy.
The Three-Part Problem We Solve:
1- Privacy Tools That Don't Respect Privacy
Existing ZK platforms require you to send private inputs to their servers
Your secrets (passwords, balances, credentials) leave your device
You must trust the platform operator not to log or misuse your data
This defeats the entire purpose of zero-knowledge proofs
2- Massive Learning Curve
Building ZK applications on Zcash requires deep cryptography expertise
Months to learn Circom, snarkjs, Groth16 mathematics
Only cryptography PhDs can build privacy-preserving apps
This limits ecosystem growth to a handful of experts
3- Slow Development Cycles
Teams spend 3-6 months just learning the tech stack
Another 2-3 months building their first working circuit
Circuit compilation, trusted setup, verification key generation - all manual
Total time: 6-12 months from idea to production
Our Solution: zkRune
1- True Client-Side Privacy
All cryptographic operations happen in the user's browser. Private inputs never leave the device. No server calls, no data transmission, no trust required.
Use case: A DeFi app can prove you have >$10,000 balance without revealing your 2- Zero Learning Curve
Visual drag-drop circuit builder. Non-cryptographers can understand and build zero-knowledge proofs in 5 minutes.
Use case: A frontend developer with zero crypto knowledge can add age verification to their app without learning advanced mathematics.
3- Hours, Not Months
13 production-ready templates. Copy-paste working circuits. npm install zkrune-sdk and ship.
Use case: A startup can add privacy features to their MVP in an afternoon instead of hiring a ZK expert for 6 months.
Real-World Applications
🗳️ Governance & Voting
Problem: On-chain voting exposes your vote publicly
Solution: Prove you're eligible to vote without revealing your choice
Impact: True secret ballots on blockchain
💰 DeFi & Finance
Problem: Proving creditworthiness means sharing your bank statements
Solution: Prove you have minimum balance without revealing exact amount
Impact: Privacy-preserving loans and credit
🎫 Identity & Access
Problem: Age verification requires showing full ID (name, address, photo)
Solution: Prove you're over 18 without revealing birthdate or identity
Impact: Anonymous age-restricted services
🖼️ NFT & Gaming
Problem: Proving NFT ownership reveals your entire wallet
Solution: Prove you own a specific collection NFT without revealing which one
Impact: Private membership proofs for DAOs and communities
🔐 Authentication
Problem: Password recovery leaks your email/phone
Solution: Prove you know the password hash without revealing the password
Impact: Zero-knowledge authentication systems
Making Privacy Accessible
Before zkRune:
❌ Send data to servers (privacy risk)
❌ Hire a cryptography PhD ($200k+/year)
❌ 6-12 months development time
❌ Limited to experts only
After zkRune:
✅ 100% client-side (true privacy)
✅ Visual builder (no expertise needed)
✅ Hours to production (templates ready)
✅ Accessible to all developers
The Bigger Impact
Zcash's Groth16 has secured billions of dollars in shielded transactions since 2016. It's battle-tested, production-proven cryptography.
By making this technology accessible, we enable:
More developers → More privacy apps → Stronger ecosystem
Faster innovation → Privacy becomes standard, not luxury
Wider adoption → Privacy for everyone, not just crypto natives
zkRune democratizes privacy technology. Just like how Figma made design accessible to everyone, zkRune makes zero-knowledge proofs accessible to every developer.
Challenges I ran into
The Three Major Challenges (And How I Solved Them)
🔴 Challenge #1: The Viewing Key Security Disaster
The Problem:
Early in development, I implemented shielded balance checking with viewing keys sent via GET request URL parameters:
// WRONG - Security vulnerability!fetch(
/api/balance?address=zs1...&viewingKey=zxviews...
)Why This Was Catastrophic:
Viewing keys appeared in browser history (unencrypted)
Server logs captured viewing keys (permanent record)
Network monitoring could intercept keys (MITM attack)
This defeated the entire purpose of privacy
The Solution:
Rewrote the entire endpoint to use POST requests with body encryption:
// CORRECT - Secure implementationfetch('/api/zcash-balance-shielded', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ address, viewingKey }) // Never in URL!})
Key Learning: Security-first architecture isn't optional in privacy tech. One careless API call can destroy months of cryptographic work.
Challenge #2: Client-Side ZK Proof Generation (The "Impossible" Feature)
The Problem:
Industry standard is server-side proof generation. Generating Groth16 proofs in-browser seemed impossible:
snarkjs is 2.5MB+ (slow initial load)
WASM circuits are 200KB-500KB each
Proving keys are 3-5MB per circuit
Browser memory limits (~2GB)
Total: 50MB+ assets for all 13 circuits
The "Expert" Advice:
Everyone said: "Just use a server, client-side is impractical."
My Response:
"If I use a server, I'm just another privacy theater platform."
The Solution:
Built a progressive loading system with aggressive caching:
Lazy Loading: Only load circuit files when user selects a template
const { proof } = await snarkjs.groth16.fullProve( inputs, new Uint8Array(wasmBuffer), // Loaded on-demand new Uint8Array(zkeyBuffer) // Cached in service worker)
Service Worker Caching (PWA):
// Cache circuit files for 365 days{ urlPattern: /^https?.*.(wasm|zkey)$/i, handler: 'CacheFirst', expiration: { maxAgeSeconds: 365 * 24 * 60 * 60 }}
Result:
First load: 3-5 seconds
Cached: <1 second
Zero server calls, true privacy maintained ✅
Key Learning: "Impossible" usually means "no one bothered to optimize it properly."
Challenge #3: The Trusted Setup Transparency Dilemma
The Problem:
Groth16 requires a trusted setup (generating .zkey proving keys). Options:
Single-party setup (fast): I generate keys alone
⚠️ I could theoretically forge proofs (if I keep "toxic waste")
⚠️ Users must trust me
Multi-party ceremony (secure): 20+ people contribute randomness
✅ Trustless (only one needs to delete their secret)
❌ Takes 4-6 weeks to coordinate
❌ Impossible during 8-day hackathon
The Dilemma:
Do I ship a working demo with trust assumptions, or miss the hackathon for perfect security?
The Solution:
Radical transparency - document everything in README:
⚠️ Security Note (Hackathon Demo)
Current Setup:
Single-party trusted setup (timestamp-based entropy)
What This Means:
- ✅ Proofs are mathematically valid
- ⚠️ Key generator could theoretically forge proofs
- 🔒 Production requires multi-party ceremony
Production Path:
MPC ceremony with 10+ contributors (timeline: 4-6 weeks)
he Response:
Community appreciated honesty over false claims. Several members already volunteered for the ceremony.
Key Learning: In crypto/privacy, transparency about limitations builds more trust than hiding them.
Tracks Applied (2)
Privacy Infrastructure & Developer Tools
Electric Coin Company
Privacy Infrastructure & Developer Tools
Zcash Community Grants
Technologies used
Cheer Project
Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.