Launching a new category for developer infrastructure
Summary
RISC Zero's flagship product was a zkVM, software that lets developers generate a cryptographic receipt showing that code ran correctly. I led the category definition, positioning, brand, and launch for its first production-ready release, making the product understandable and useful before the market had a name for it. The launch helped establish a category that drew roughly 25 competing teams, and I later helped RISC Zero focus on the strongest use case and make the case for continued leadership through performance.
- The 1.0 launch gave the market a clear name and story for a new category of developer infrastructure
- Roughly 25 competing teams entered the category after launch, showing that RISC Zero had opened a market others wanted to pursue
- Following demand from Layer 2 networks gave RISC Zero a focused product story, and company-tracked deployments later represented more than $12B in economic value
Starting before the market had a name for it
When RISC Zero prepared its first production-ready release, the product worked but developers had no familiar category for it. People could see code produce a cryptographic proof, yet they still needed a simple way to understand why that mattered and what they could build with it.
RISC Zero's flagship product was a zkVM, software that let developers run familiar code and generate a cryptographic receipt proving the result was correct. It made zero-knowledge proofs accessible to any developer.
For the 1.0 launch, I led the work around category definition, positioning, brand, and launch. The message had to make the product easy to grasp, explain why this category deserved to exist, and show developers what they could build right away.
Giving developers a language for the product
A zkVM could easily sound like one more piece of cryptographic alphabet soup, especially to developers encountering zero-knowledge proofs for the first time. I had to make the product understandable without flattening what made it interesting.
I built the positioning and messaging around what had changed technically, who could now build with it, and what they could create immediately. We gave people a simple way to understand the product: provable computation could become part of normal software development.
That language helped developers compare implementations, gave partners a way to explain where a zkVM fit into their stack, and meant the market could build knowledge around a category instead of relearning the technology from scratch every time RISC Zero appeared.
Earning credibility for an unfamiliar product
A new category becomes easier to trust when people beyond its creator are willing to spend time, engineering resources, and money on it. I built the 1.0 launch around respected technical teams and examples that showed the product was ready for serious work.
Every credible team that evaluated the product, built with it, or supported the launch made the next developer's decision feel less speculative. Their participation showed that zkVMs were more than an interesting idea from one company.
We needed RISC Zero to feel like the company developers could trust, while making zkVMs feel like a market worth joining. The category name gave people a shared way to talk about the product, and third-party participation made that story more believable.
Showing what developers could build now
When a new developer category is introduced, it is tempting to talk mostly about the future it could unlock. I wanted the 1.0 launch to answer a more immediate question: what could a developer build with this today?
Our 1.0 communication made production readiness central to the story. Teams could use familiar programming languages, build applications around verifiable computation, and ship with a real release without becoming cryptography specialists first.
I led the positioning, messaging, brand, launch strategy, and social rollout around that promise. Developers could see a new technical idea and a clear reason to start using it immediately.
When competitors confirmed the category had landed
After 1.0, we counted roughly 25 teams developing zkVMs of their own. They had accepted the same product frame and were committing engineering talent and capital to compete inside it.
The conversation had shifted from whether a general-purpose zkVM should exist to which zkVM developers should choose. That was an exciting sign that the category had taken hold, and it also changed the work in front of us.
We had helped establish the language, but every new entrant could now use it. To stay ahead, we needed to notice where demand was moving and make the next product story more specific before the rest of the category caught up.
Following market pull into Layer 2 infrastructure
We launched 1.0 with a wide view of what developers might build because the most valuable use case was still emerging. I kept close to the feedback and adoption patterns that followed the launch.
One use case started showing up more clearly: Layer 2 networks. These networks process transactions separately from Ethereum before settling the final result on Ethereum, which helps make applications faster and less expensive. Many used a security model that could leave withdrawals in a seven-day challenge period while disputes were checked. Zero-knowledge proofs offered a way to bring that wait down to hours.
That demand led to OP Kailua, a product that helped Layer 2 networks use RISC Zero's proof system without changing the underlying chain. It let us move from a broad category story to a more specific position around helping Layer 2 teams settle their networks faster.
BOB and Eclipse were early integrations. MegaETH later documented plans to use the RISC Zero zkVM and follow OP Kailua's hybrid architecture, showing how quickly the product had found a concrete place in the market.
Defending leadership as the category matured
By the time we launched version 2, more companies had built their own zkVMs. Developers increasingly wanted to know who could generate proofs fast enough for products that needed a quick turnaround, and the category was becoming a performance race.
We positioned R0VM 2.0 as ‘the zkVM built for the real-time era’ and used the latest benchmarks as evidence. The message connected the performance improvements to a broader shift in the market: real-time proving was becoming a meaningful decision criterion for developers.
The creative system made that position visible. The launch film used a race car to communicate speed before a viewer encountered a single benchmark, while the surrounding communication connected performance to the applications developers could build next.
The first launch made the category understandable; version 2 used the market's new performance expectations to make the case for RISC Zero's continued lead.
What I learned from creating a category
Launching 1.0 taught me that category creation asks marketing to do several jobs at once. You have to give people language they can remember, show why the product belongs in their world, and bring in credible teams who can make an unfamiliar idea feel less risky.
Once the category started catching on, the work changed. We had to listen for where customers were finding the strongest use cases and watch for the criteria competitors were beginning to compete on. Layer 2 demand and the move toward real-time performance both became the next product stories because the market was already moving in those directions.
During the period, RISC Zero tracked deployments representing more than $12B in economic value. That growth started with making a difficult technical idea clear enough for the market to adopt, extend, and eventually compete around.
