Skip to main content

2026-07-02

· 7 min read
Kaan Kacar
Kaan Kacar
Developer Advocate

A Week About Privacy​

This week wasn't about AI — it was about your second-favorite subject: privacy. Per the Electric Capital developer report there are now more than 2,000 developers building on Stellar in a given week, and hopefully you're one of them.

Two reasons privacy was the theme. First, there was exactly one day left to submit to the Real World ZK hackathon on DoraHacks — the best possible time to be building with zero knowledge. Second, an hour before the call we published the developer preview of confidential tokens on Stellar, which pairs naturally with this week's guest. So the plan was: guest first, then a plain-English tour of confidential tokens.

Guest: Zarf — Private Token Distribution by Email​

Our guest was Zarf (zarf.to), a Turkish project that lets you distribute tokens to an email address rather than a wallet address. Recipients claim with a familiar "sign in with Google" button, and their browser quietly proves they own that email using a zero-knowledge proof — so the recipient's wallet is never linked to a person, and nothing on-chain says who received what. This was a special one for me personally: Yaman, one of the founders, is the first person I ever met in web3, at my first hackathon a bit over four years ago.

Yaman introduced Zarf alongside Dennis, who has spent three to four years in the ZK space (previously an exploration engineer at O1 Labs on the Mina protocol, and before that in web2 cyber security). The team builds things that are only possible with zero-knowledge proofs, and got excited about Stellar once the protocol gained native, cheap ZK-proof verification — with the heavy elliptic-curve math implemented as protocol-level precompiles, verifying a proof on Stellar became genuinely inexpensive.

The Problem​

When you send tokens on a blockchain, the recipient's wallet is always exposed. In token distributions and private sales, anyone can watch who claimed what — a strong signal for whales-watching and an easy way to get doxxed. Zarf's origin was a hackathon project at Devconnect in Buenos Aires: a proof-of-attendance tool that let you prove you'd attended an event via an email you received, then mint it as a POAP-style NFT. That grew into the more general idea of using an identity you already have — a Google account — for private, programmable token distributions.

How It Works​

The primitive underneath Zarf is ZK JWT — zero-knowledge proofs over the JSON Web Token that Google signs when you log in. When you sign in with Google, Google digitally signs your JWT; inside the circuit, Zarf verifies that signature against Google's published public keys, confirms the key really belongs to Google, and parses your email — all in zero knowledge. That proof then lets you claim from any wallet you like, and different claims can come from totally unlinked wallets (wallet A for one batch, wallet B for the next), even a single-use stealth address.

Dennis was careful to distinguish ZK JWT from ZK email: ZK email proves the signature of an email's sender, while ZK JWT is specifically for authentication and identity. They prefer ZK JWT because the UX is far better — no forwarding emails or uploading .eml files; you just open the page and log in with Google, and the proof is generated behind the scenes.

The best framing we landed on: Zarf is a privacy-focused version of the Stellar disbursement platform — instead of handing over a CSV of wallet addresses, you hand over emails, and people claim from whatever wallet they want, so nobody can track balances or link an identity to a wallet.

The Architecture​

A few implementation details worth capturing:

  • Proof system. Zarf uses Noir rather than Circom. Noir brings faster proof generation and, importantly, no per-circuit trusted setup ceremony (it relies on a universal setup instead).
  • Four contracts. A factory, a vesting contract, a verifier contract (invoked on every claim to check the proof), and a JWK registry that holds Google's public keys.
  • The Google key-rotation challenge. Google rotates the public keys that sign JWTs roughly every two weeks (not exactly, and not all at once). Zarf runs a Cloudflare worker that fetches the current keys and writes them on-chain so verification stays valid. This is the biggest open problem; the team is exploring more trustless approaches (e.g. zkTLS to prove the certificate URL directly) and even offering a shared Google-certificate registry as a public good for the whole ecosystem.
  • The privacy model. To break the email↔wallet link, Zarf parses your email from the JWT, generates a secret pin code, hashes the pin, hashes your email, and places the hashed identity in a Merkle tree. At claim time the circuit verifies the Google-signed JWT, derives your unique identifier, walks the Merkle proof to the root, and compares that root against the distributor's on-chain vesting contract. The pin prevents anyone who merely knows your email from brute-forcing to find you in the tree.

The Demo​

Yaman created a live token distribution on testnet — upload an email list, auto-build the Merkle tree, set a vesting schedule, deploy — then tried to claim. Proof generation and some caching got in the way and the claim didn't land cleanly on the call (it had worked in rehearsal). As I like to say: you're not really a builder if your demo works every time. It's a fine reminder of exactly why beta testers matter — better to get roasted in private than in front of 250 live viewers. Zarf is SCF cohort 42, heading to mainnet after its audit (likely within the week), and looking for beta testers via zarf.to and X (@zarf).

Confidential Tokens: The Other Half of Privacy​

After the guests left, I did a "so what?" walkthrough of the confidential token rails we previewed that day, built by OpenZeppelin — because Zarf and confidential tokens solve two different privacy problems and it's worth seeing the contrast:

  • Zarf hides identity. The email↔wallet link is never revealed. But once a claim lands, the recipient's wallet, the amount, and the claim event are all still public on-chain — fine in many cases, problematic in others.
  • Confidential tokens hide amounts. Instead of storing a plaintext balance, the token stores each balance as an encrypted commitment. Transfers move encrypted amounts and carry a zero-knowledge proof that the transfer is valid (the sender had enough, the amount is a positive integer, inputs equal outputs) without revealing any of the amounts. Only the holder — and optionally an auditor who holds a decryption key — can read the balance, which is how you'd add a compliance layer.

The mental model is a handful of methods: register, deposit, merge, transfer, withdraw. To participate at all you first register (a one-time zero-knowledge proof generated locally in the browser). You then deposit public tokens into your encrypted balance, merge received amounts so they become spendable, and transfer confidentially. Confidential tokens behave like SEP-41 tokens, so in theory they compose — but they're best at additive accounting (adding and subtracting amounts), and not the right tool for multiplication, price discovery, or deep public composability, where time-sensitive proof generation gets in the way. This is a confidential token, not a dark pool that hides the operation itself.

To make it concrete I vibe-coded a tiny confidential wallet for the meeting — two accounts, Alice and Bob — that walks through registering, depositing public XLM into an encrypted balance, merging, and then transferring confidentially so nobody can see how much moved. It reuses OpenZeppelin's confidential-token contract from the developer preview, so I was cutting corners, but it makes the flow tangible. The GitHub link is in the stream, and the real source of truth is the developer preview itself.

Closing​

With ~20 hours left on the Real World ZK hackathon deadline and a strong turnout of hackers, there was still time to ship something small and submit. Next week's guest is Hyperron. Thanks for watching — see you then.