o1js
The TypeScript SDK Mina developers actually write against. Circuits in a language they already know, proofs underneath.
It sits between product engineers and a proving stack that spans TypeScript, Rust, and WebAssembly. Circuits are authored in TypeScript. Proofs come out the other side.
Zero-knowledge application development was too far from the tools product teams already use. The cost of authoring circuits, integrating with the protocol, and shipping releases was too high for most engineers.
I co-architected o1js from its early stages, then took ownership of architecture, roadmap, delivery, hiring, and release strategy as team lead. I stay hands-on across the TypeScript API, proving pipeline, and the coordination work required to ship breaking changes without stranding the ecosystem.
Circuits are authored in TypeScript, compiled into a constraint system, and proved with a Kimchi backend. Browsers keep a WASM path. Node can use a native Rust prover through N-API. The SDK, protocol, and cryptography layers have to move together.
Choices that mattered
Replace a custom circuit language with TypeScript-native authoring so web engineers can stay in a familiar toolchain.
Keep the proving backend interchangeable so native Node performance can improve without changing circuit code.
Treat SDK releases as ecosystem events: protocol changes, cryptography changes, and developer migration have to be planned as one delivery.
What came of it
o1js through v1 and v2, including a coordinated migration across protocol, cryptography, and SDK layers.
Native prover path for Node: same circuit API, faster proving, larger circuits, no circuit rewrites.
MESA hardfork work that expanded on-chain zkApp state capacity by 4x.
Hiring, leveling, and mentorship loops for a four-person engineering team.
Monthly npm downloads moved from 4K to 15K while the team stayed small.
Public repository around 600 GitHub stars.
SDK now supports larger constraint systems on Node without changing authoring APIs.