06 · ZK & Verification
Zero-Knowledge & Verification UX
Verification is a process, not a moment. Users feel that process as latency, status ambiguity, and unfamiliar failure modes.
By John Wright-Nyingifa · Product Designer building infrastructure for DeFi, DePIN, and autonomous agents.
Live Signal · March 2026
Real-time Ethereum proving achieved: 99.7% of blocks in <12 seconds (SP1 Hypercube). RISC Zero cut block proving from 35 minutes to 44 seconds. Browser ZK proofs at 600-800ms on consumer hardware. Mobile via Mopro with 40-100x GPU acceleration. Decentralized prover markets live (Succinct Network, RISC Zero Boundless). The performance problem is solved. The interface problem is wide open.
Zero-knowledge systems turn "trust me" into "verify this." But verification is a process, not a moment. Users feel that process as latency, status ambiguity, and unfamiliar failure modes.
Two years ago, proving a single Ethereum block took 35 minutes. Now it takes 12 seconds. Browser proofs run in 600ms. The cryptography performance problem is effectively solved. What isn't solved: every ZK-enabled product treats proof generation as an invisible implementation detail, and then wonders why users don't trust the outputs.
Mental Models
Prover: produces a proof that a statement is true (often offchain, computationally expensive). Verifier: checks the proof (often onchain, cheap). Provers do the heavy work. Verifiers do the cheap check.
Most systems generate proofs offchain because proving is expensive and prover throughput determines system capacity. Onchain verification happens because it makes correctness enforceable and anchors trust to the chain.
Many proofs compressed into one. Verification cost stays bounded as throughput increases. Mental model: "Proofs roll up into proofs."
To scale: multiple provers in parallel, prover markets (bidding for work), redundancy (two provers prove the same thing for reliability). Introduces queueing, variance in proving time, and failover paths.
Queues are normal. They should show: queue position (approximate), estimated proving time range, priority rules (if any). Not hidden behind a spinner.
PROVING PERFORMANCE (March 2026) Infrastructure ├─ SP1 Hypercube <12s per ETH block (99.7%) 16x RTX 5090 ├─ RISC Zero R0VM 2.0 44s per ETH block 5x cost reduction └─ Brevis Pico Prism <10s (96.8%) ETH Foundation RTP Client-Side ├─ Browser (M1-M3) 600-800ms Standard Chrome/Firefox ├─ Mopro (Mobile) 40-100x GPU acceleration Swift/Kotlin/React Native └─ StarkWare S-two Targeting instant Phones/browsers/laptops Proof Markets ├─ Succinct Network $PROVE token, decentralized provers └─ RISC Zero Boundless Open proof market
Verification Lifecycle
Five phases that most interfaces collapse into two (pending/done):
A batch/block is selected, the proving job is generated, the prover produces a proof. Users feel: "Submitted" but not yet "verified."
Multiple proofs aggregated via recursion into a single proof for many batches. Users feel: a delay that looks like "nothing is happening" unless surfaced clearly.
Proof sent onchain. Transaction competes for inclusion (fees, congestion). Users feel: another waiting stage, often gas-dependent.
Verifier contract checks the proof. State marked verified/final. Users feel: the moment the system becomes "trustless" for that batch.
Withdrawals enabled. Bridged messages executable. Risk flags removed. Users feel: "Now I can use my funds everywhere I need to."
VERIFICATION PIPELINE
○ Proving → ○ Bundling → ○ Submission → ○ Acceptance → ● Final
(offchain) (recursion) (onchain tx) (verifier OK) (usable)
minutes minutes minutes minutes product
guarantee
WHAT MOST UIs SHOW WHAT'S ACTUALLY HAPPENING
○ Pending → ● Done ○ → ○ → ○ → ○ → ● (five phases)Failure Cases
Each failure needs specific language, not generic errors.
Hardware failure, buggy circuit, bad witness, job timeout. Language: "Verification delayed" or "Proof generation failed and will retry." Not: "PLONK verifier timeout."
Too many batches, prover capacity exceeded. Language: "High demand: verification may take longer than usual."
Gas spike, transaction not included onchain. Language: "Waiting for onchain inclusion."
Invalid proof (serious), wrong parameters, circuit mismatch. Language: "Verification failed" with an incident link. Next action: "Funds remain safe, but finalization is paused" (only if true).
A good system defines: when a job is retried, when the user is notified, when the system enters degraded mode. All three must be explicit.
Gas Implications
Users don't need cryptography details. They need:
Network congestion can delay proof submission onchain. Users should know if the wait is gas-related or prover-related, as these have different resolutions.
Verification gas costs are usually system-level, not user-level. But if gas affects when withdrawals unlock, users need to see that connection.
If applicable, surface this as a choice: "Fast (30s, $0.02)" vs "Economy (5min, $0.008)." Proof markets make this tradeoff real.
UX Implications
Submitted: transaction accepted by execution layer. Verified: proof checked onchain. Finalized: withdrawals/messages enabled. Never collapse these into one "Confirmed."
Proving (minutes), Bundling (minutes), Onchain submission (minutes), Verified (minutes). Ranges feel more honest than exact countdowns.
Replace "Witness generation failed" with "Proof generation error." Replace "Circuit compilation mismatch" with "Verification configuration mismatch." Technical detail behind expandable panel.
"Your withdrawal becomes available after batch #123 is verified." "This bridge transfer completes when the proof is accepted." Make the mapping explicit.
Default: simple states + time ranges + action prompts. Expanded: batch ID, proof status, transaction hashes, explorer links.
UX Implications
→ Design for the speed spectrum. SP1 Hypercube at 12s is near-instant. Batched proofs save cost but add minutes. Show which mode and why.
→ Client-side proofs change the model. At 600ms, the proof runs faster than a page transition. No loading states. Instant results. Local computation feel.
→ Make the queue visible: position, estimated time, proof type. "Your proof is #47 in batch, ~3 minutes" beats a spinner.
→ Proof status needs new visual language: submitted, queued, proving, verified, finalized. Five states, not two.
Glossary
Proving correctness without revealing all details.
Generates a proof (expensive, often offchain).
Checks a proof (cheap, often onchain).
Proof that attests to many proofs, keeping verification cost bounded.
Backlog of proving/verification jobs. First-class UX concept, not hidden plumbing.