Why I started Zera Labs

This is the post I keep wanting to skip. It’s the founding letter — the one where I’m supposed to explain, in clean prose, why a perfectly happy senior IC with a security-research side hustle decided to incorporate a thing and put his name on the door. I have started writing it five times. The other four versions all went a little too hard on the grand cryptographic destiny of the human race angle, which is not the kind of post I’d respect if I read it in someone else’s feed.

So here is the version that survived: three things became true at roughly the same time, in the same year, and sitting at the intersection of those three things felt much more like a ship date than a thesis. That’s the whole pitch. The rest of this letter is just walking the three legs of the tripod.

Leg one: ZK got fast enough to be boring

I have been reading zk papers for, depending on how you count, six or seven years. The thing about zk papers is that the math doesn’t get faster — the math has been there since Goldwasser and Micali’s 1985 paper. What gets faster is the engineering. Better proving systems (Groth16 → PLONK → Halo2 → STARKs → folding schemes). Better hashes inside circuits (Pedersen → Poseidon → Reinforced Concrete). Better hardware (CPU SIMD → GPUs → FPGAs → the inevitable ASIC). Better libraries (snarkJS → arkworks → halo2 → Lurk → Risc Zero).

In 2018, you could prove a non-trivial program in a circuit and submit it to Ethereum, but you needed a research lab and a friend at a hardware accelerator company. In 2024, you could prove a non-trivial program in a circuit on a laptop in a few seconds and submit it to a chain that didn’t price proof verification like a war crime.

In 2026, the prover is fast enough that a wallet can do it on the user’s machine for a normal interactive payment without the user noticing. That last sentence is the entire reason ZK leaves the lab.

The bar for “leaves the lab” is ruthless. It isn’t “research demo at Devcon.” It’s: a non-technical user, on their existing laptop, opens a wallet, clicks Send, waits less than a coffee sip, and a Groth16 proof has gone over the wire to settle the transaction. Until that is true, ZK lives in conferences and academic papers. Once that is true, ZK eats a chunk of the financial system.

That is the point we are at right now. I built zera-sdk and the Zera Wallet v3 to be the first products to ship after that line was crossed. Not after the line will be crossed, after some round, after some grant. After. It already happened. We are mostly waiting for the rest of the industry to notice.

Leg two: Solana stopped being a gas-fee story

I came up at ConsenSys. I love the EVM the way you love a complicated relative — deeply, suspiciously, with a lot of patience. But the EVM was not designed for a world in which a privacy-preserving deposit costs you a single-digit number of cents and a transfer costs less. The EVM was designed for a world in which compute is precious and you charge by the opcode.

Solana is the opposite design point. Compute is cheap, throughput is high, parallelism is the default, and — critically — Light Protocol’s compressed-token primitive lets you push almost the entire account state of a token into an off-chain Merkle tree. The savings are not marginal. They are something like 5000× per token. I spent a weekend porting a notional AMM to Solana for the first time and the gas numbers came out so low I assumed I had a math error. I did not. The chain is just that much cheaper.

I wrote about the implications in ZeraSwap: An AMM for Compressed Tokens. The short version: when the per-account-state cost of a token drops by three and a half orders of magnitude, every assumption you had about the granularity of tokenisation has to be re-examined. You can have one token per medical record. One token per receipt. One token per proof. The cost of “putting it on chain” stops being a budgeting decision and starts being a naming decision.

ZK is the privacy half. Compressed tokens are the bandwidth half. If you have both, you have the substrate I would have wanted for the cryptocurrency we should have built.

Leg three: AI agents need verifiable money

This is the leg that tipped me from “interesting hobby” to “I’m doing this full-time.” It’s also the leg the most people get wrong, so I want to walk it carefully.

If you have not played with the Model Context Protocol yet, the elevator version is: an AI agent (Claude, Cursor, Cline, your custom thing) connects to a server that exposes tools the agent can call. The server might be a calendar. The server might be a database. The server might be — and here is where it gets interesting — a wallet.

In 2025 a lot of teams glued LLMs to wallets and discovered, predictably, that the result was funny but not safe. Funny because LLMs are very confident; not safe because wallets, being unverified pieces of state, can be lied to in ways the model has no way to verify. The result was a small wave of “agent steals the demo wallet’s testnet ETH” videos that everyone enjoyed and then forgot about.

The fix isn’t smaller models or more guardrails. The fix is verifiable cryptographic state. If the agent asks the server “do I have the right to spend this note?”, the server should be able to produce a proof that the agent can verify locally, with the same trust model the chain itself uses. Not a screenshot. Not an oracle. A Groth16 proof that the agent’s runtime checks against the same verifying key the chain holds.

This is the reason @zera-labs/mcp-server exists, and it’s the reason it shipped on the first day of the SDK rather than as a v2 feature. If agents are going to interact with money — and the rate at which the next generation of agentic products is being shipped tells me they are — they need the same cryptographic verifiability that human users now expect from a wallet. The MCP layer is the agent’s wallet. The SDK below it is the cryptographic verifiability. The chain underneath is the settlement.

You don’t have to believe the agent thesis is going to be huge. You only have to believe it isn’t going to be zero. The MCP server is, on the day this letter ships, less than 500 lines of code. If the bet is wrong, I lose 500 lines of code. If it’s right, the SDK ships into a market that is roughly 100× larger than the human-wallet market.

Why a company instead of more posts

People who have read me for a while know I do most of my thinking out loud, in writing, on this blog. There’s an obvious version of all the above that’s just more posts about it. Why a whole company.

Two reasons.

First: the surface area is larger than one person. The SDK alone is a Rust crate, a Neon binding, a TypeScript SDK, a prover, an MCP server, three transaction builders, a Surfpool devnet, a 144-test Vitest suite, and a documentation surface. The wallet is its own product. The AMM is its own product. The medical demo is its own product. The design system is its own product. I cannot ship that on weekends. Nobody can.

Second: the work is more credible inside a company. When the SDK lands an audit, that audit lands on Zera Labs, not on “some guy with a blog.” When the first integration partner asks who’s accountable if the prover regresses, the answer is “Zera Labs,” not “I’ll get to it Tuesday.” When a customer asks for a SOC 2, the answer is “we’re working on it” instead of laughter. The legal and operational scaffolding is part of the product.

I want to be clear about what I’m not claiming. I’m not claiming the team is huge. (TODO: Dax confirm — keep this hedged until the team page is public.) I’m not claiming we’ve raised a round. I’m not claiming we have customers I can name. I am claiming we have a working SDK, a working wallet, a working AMM, a working medical demo, a working devnet, and a Design System we use across the company. The rest is sequencing.

The animating principle

Every company has one sentence that explains what it is willing to be embarrassed about and what it is willing to be loud about. The one I keep coming back to for Zera Labs is:

We build cryptographic infrastructure that is fast enough, cheap enough, and verifiable enough to leave the laboratory. Everything else is taste.

“Fast enough” is the ZK leg. “Cheap enough” is the Solana / compressed-token leg. “Verifiable enough” is the agentic leg. “Everything else is taste” means the design system, the documentation, the tone of the blog, the choice of dependencies, the way we write commit messages, the way we run incident response. None of those things are in the trade-off space. They are the part where the company has to be the company.

If any of the three legs of the tripod were missing, this would be a research lab or a side project. All three are present. The thing to do, then, is to ship.

Where to next

If you want the technical receipts:

• Building the Zera SDK: Day One — the 14-minute session that put the foundation in.
• 144 Tests and a Surfpool Devnet — the bridge from “the code exists” to “you can use it.”
• ZeraSwap: An AMM for Compressed Tokens — the bandwidth half.
• Zera Wallet v3 — the user-facing half.
• ZK-FHIR — the proof we can do this for things other than money.

If you want the personal receipts: Nuclear reactors taught me to ship software and What running a Bitcoin mine taught me about cloud margins are the two prior chapters. This one is chapter three.

If you want to use the work — [email protected]. The calendar’s here.

That’s the founding letter. Now I have to go ship the next thing.