Brave Browser
ZK proofs as a browser-native primitive.
Brave already ships privacy-first defaults, a multi-chain wallet across Solana and EVM, and prior ZK research around login and age verification. zkRune fits as a browser-native ZK primitive: Brave Wallet proves balance, NFT, or membership claims without exposing addresses, and a 'Zero-Knowledge Browsing' mode delivers proofs to verification prompts instead of personal data.
Three layers of integration
Each layer is shippable independently. The first layer already works — Brave Wallet implements the Solana wallet adapter zkRune consumes, so the existing balance-proof primitive runs against a Brave Wallet without any code change on either side. The next two layers are the actual proposal.
Already works through the wallet adapter
Connect Brave Wallet to zkRune's existing balance-proof template and prove an SPL token balance ≥ X without exposing the address. No Brave-side integration required — it works because Brave Wallet ships the standard adapter.
Try it todayNative Prove action inside Brave Wallet
Each token row exposes a one-click Prove button. The SDK reads the wallet provider already in scope, runs the circuit locally, and returns a shareable proof URL. Same primitive for NFT ownership and membership proofs.
Zero-Knowledge Browsing autopilot
Brave detects verification prompts on the open web — age gates, KYC checkpoints, eligibility forms. Instead of asking the user for raw data, the browser delivers a zkRune proof. Same primitive across the consumer web.
Why a browser-native ZK primitive?
The privacy story has been one-sided for fifteen years: block trackers, block ads, block fingerprinting. Verification prompts — age, balance, license, jurisdiction — still demand raw data because the browser has nothing better to offer. zkRune is the missing response.
What the browser does today
- Block, but never substitute. Brave already blocks third-party trackers and fingerprinting. Forms still demand raw data — there is no positive primitive to hand back.
- Wallet exposes the address by default. A balance check leaks the entire on-chain history of the wallet. There is no native way to prove a threshold without revealing the source.
- Extensions are the workaround. Reclaim, zkPass, and others ship as third-party extensions. Privacy-conscious users install them; the long tail does not.
- Age and jurisdiction prompts route to ID upload. Centralized KYC vendors get the data. Operator gets the liability. User gets the friction.
With zkRune as a native primitive
- Positive answer, not just refusal. When a site asks for a fact, the browser hands back a proof of the fact — not the underlying data, and not nothing.
- Wallet UX without address leakage. Prove a token balance threshold, NFT ownership, or membership without disclosing the address. The wallet stays private by default.
- Default for everyone, not just opt-in users. Built into the browser path means the long tail is covered — not only the 5% who installed an extension.
- On-chain audit trail by design. Every match leaves a cryptographic record on Solana, Sui, or Base. Operators get a regulator-shaped log without retaining PII.
Architecture — Layer 2 in detail
Layer 1 is already live. Layer 3 is the long-horizon vision. This diagram zooms into Layer 2 — the native Prove action inside Brave Wallet — because that is the concrete proposal that lands first.
Wallet UI surfaces a Prove action
Each token row in Brave Wallet exposes a Prove button. zkRune SDK consumes the wallet provider already in scope — no new key plumbing.
Circuit runs locally against wallet state
Balance proof, NFT ownership, or membership proof — pick the circuit, set the threshold, snarkjs runs in the wallet process.
On-chain verifier check
Solana verifier 9apA…X7ad, Base verifier 0xa03A…9E849EA, or Sui verifier 0x2783…d4c5 — same proof, picked by chain context.
Shareable proof artifact
Proof URL plus on-chain attestation hash. Paste anywhere — websites verify against the on-chain record without contacting Brave.
Integration sketch
// Inside Brave Wallet UI — token row "Prove balance" action
import { zkRune } from "@brave/zkrune";
const proof = await zkRune.proveBalance({
token: selectedToken.mint, // e.g. "SPL:51mxznNW..." or "native:SOL"
threshold: 1000, // in token units, never the actual balance
// wallet provider already in scope inside Brave Wallet
});
// proof.shareableUrl → paste anywhere; the verifier is on-chain
// proof.proofHash → 0x... collision-resistant identifier
// proof.publicSignals → [mint, threshold, attested] — never the balanceWhy Brave specifically
Privacy posture is genuine
Defaults already block trackers, ads, and fingerprinting. ZK proofs extend the same product DNA upward — the missing positive primitive after fifteen years of refusal.
Multi-chain wallet, multi-chain verifiers
Brave Wallet handles Solana and EVM. zkRune's on-chain verifiers live on Solana, Base, and Sui. Zero new plumbing — the wallet adapter is already shared.
Prior ZK posture, no native ZK primitive yet
Brave shipped zkSENSE for ad fraud, partnered on Sui zkLogin, and explored age verification. The interest is documented; the user-facing primitive is not yet built.
Build this with the Brave team
This is a community-built reference design, not an official partnership. Layer 1 is shippable today. Layer 2 is a 6–12 week engineering scope on the Brave Wallet UI. If you are on the Brave team — or building toward a browser-native ZK primitive elsewhere — let's talk.