o1js is the TypeScript framework used to build zkApps on the Mina protocol.
When I joined the team, Mina was preparing for the Berkeley hard fork, the network upgrade that would bring zkApps (effectively Mina's version of smart contracts) to mainnet for the first time.
The success of that launch depended heavily on the developer experience. If developers couldn’t confidently build and deploy production apps, the upgrade would fall flat.
The problem was that the SDK powering zkApp development — o1js — was still operating in a kind of perpetual beta. Breaking changes were common, some features were incomplete, and the security posture hadn’t yet been validated by a third‑party audit.
My mandate was simple: ship a true v1 developer platform alongside the hard fork so developers could confidently deploy zkApps to mainnet.
The Problem
Developers don’t deploy production software on unstable tooling.
At the time, o1js had three main gaps that stood in the way of a production release:
Feature gaps
There were several capabilities developers expected from a production zk framework that were either missing or incomplete.
Performance concerns
Proof generation and other core operations needed optimization to be viable for real-world applications.
Security guarantees
Before anyone could confidently deploy financial or identity applications using zk proofs, the framework needed a comprehensive third‑party security audit.
Without solving these issues, developers would hesitate to deploy zkApps to mainnet — which would undermine the entire purpose of the Berkeley upgrade.
My Role
I owned the end‑to‑end initiative of launching o1js v1.
That meant coordinating multiple workstreams that had to land together before the Berkeley hard fork:
identifying and prioritizing feature gaps
improving SDK performance
coordinating a full third‑party security audit
managing breaking change strategy for developers
preparing the developer ecosystem for a stable release
To understand what developers actually needed from a v1 release, I ran targeted outreach with the Mina developer community and gathered input from our internal engineering teams.
From there I worked closely with the SDK tech lead to assemble a long list of candidate improvements and prioritize them under tight timeline constraints.
Key Decisions
Ship stability first
One of the biggest tensions in the project was timing.
The Berkeley hard fork had a fixed timeline, and ideally the v1 SDK needed to launch alongside it.
However, some improvements that would require breaking changes could not realistically be completed in time.
Rather than delay the release, we took a staged approach:
release o1js v1 alongside the hard fork
deprecate APIs that would change in the future
introduce safe alternative endpoints
ship the breaking changes in a later major release
This allowed developers to start deploying zkApps immediately while giving them a clear upgrade path.
Security before launch
A core milestone for the release was a comprehensive security audit conducted by Veridise, a security firm specializing in zero‑knowledge systems.
The audit ran for several months and involved multiple security researchers reviewing the framework’s circuits, cryptographic primitives, and developer APIs.
The review uncovered a number of vulnerabilities across different severity levels.
Working closely with the SDK engineering team, we triaged the findings and prioritized fixes based on both severity and release timelines.
All critical and high‑severity issues were resolved prior to the v1 launch.
Some fixes required API changes, which we handled through a staged deprecation strategy so developers could migrate safely.
What We Built
o1js v1 represented the first production‑grade developer framework for building zkApps on Mina.
The release included:
resolution of major feature gaps identified by the developer community
performance improvements in core proving workflows
a fully audited security posture
a stable versioning strategy using semantic versioning
Perhaps most importantly, the release established a contract with developers: from that point forward the SDK would behave like a real platform rather than an experimental toolkit.
Results
The launch of o1js v1 coincided with the Berkeley hard fork and the introduction of zkApps to Mina mainnet.
Developers now had a stable, audited framework they could use to build and deploy applications with confidence.
The community response was overwhelmingly positive, and we began seeing a clear increase in projects preparing to deploy zkApps to mainnet.
More importantly, the release changed the perception of the tooling around Mina. Instead of an experimental developer environment, the ecosystem now had a credible production SDK.
Lessons
The biggest lesson from this project was how tightly coupled developer tooling and protocol adoption really are.
You can ship the most advanced protocol upgrade in the world, but if developers don’t trust the tooling, they won’t build on it.
Launching o1js v1 required balancing three forces at once:
shipping alongside a major network upgrade
maintaining developer stability
resolving real security issues uncovered during the audit
The staged deprecation strategy turned out to be critical. It allowed us to ship on time while still addressing deeper architectural issues in subsequent releases.
In short: shipping developer platforms requires the same discipline as shipping consumer products — stability, trust, and clear upgrade paths matter just as much as raw technical capability.
