Case study · Distributed systems · 2022–2026
Zircuit
Proof orchestration and release engineering for an EVM-compatible ZK-rollup, from its first commits to public mainnet.
- Backend and distributed systems
- Releases and reliability
- Early-stage teams
- Blockchain infrastructure
- Company
- Zircuit
- Product
- EVM-compatible ZK-rollup
- Timeline
- Sep 2022 – Feb 2026
- My role
- Senior backend engineer
- Stack
- Go · NATS · Rust · Optimism Bedrock
- Outcome
- Public mainnet, Aug 2024
On this page
Architecture
Problem
Zircuit is an EVM-compatible ZK-rollup with AI-powered security at the sequencer. Every batch has to be proved, and if proving falls behind, state can’t advance and blocks can’t finalize. The proving pipeline had to keep up, survive prover upgrades, and never hold up the chain.
Constraints
- Proof jobs are long and expensive. A batch was proved every 5 to 6 hours, scaling to 8 to 10 provers under load.
- Upgrades meant draining an in-flight pipeline across staging, testing and production, with DevOps and external partners.
- Internal code had to stay private while the protocol code was published openly.
What I owned
I was among the first four engineers, from inception through public mainnet.
- Proof orchestration. Architected the pipeline: a NATS message bus, Go consumers running proof jobs concurrently, and a Rust prover as the worker.
- Prover migrations. Moved the proving stack from Halo2 to SP1, helped move onto a new orchestrator, and owned prover upgrades in production.
- Sequencer screening. Built detectors on the sequencer-level security interface, including the blocklist and allowlist that decide which transactions are admitted.
- Public release pipeline. Automated publishing of the open-source monorepo from the private tree, stripping internal code before each push.
- Release reliability. Drained the pipeline before each upgrade, resumed it after, and ran the rollback when one failed.
Approach
Keep proving off the critical path of chain progress. A durable message bus decouples batch production from proof generation, proof jobs run concurrently, and the prover pool scales with load.
Upgrades are treated as operations: drain the pipeline, upgrade, verify, resume, and keep a rollback ready.
Results
- Zircuit’s Mainnet Phase 1 went live on August 5, 2024.
- Publishing to the open-source monorepo became about 2.5× faster, with internal code stripped automatically.
- Proving scaled to 8 to 10 provers under load.
Zircuit has since moved its L2 to Conduit, and the public repositories are kept for legacy purposes.
Skills this shows
| If your role needs | Evidence in this project |
|---|---|
| Distributed systems | NATS-based orchestration of long-running proof jobs, scaled to 8–10 workers. |
| Release engineering | Drain, upgrade and resume rollouts across three environments, with rollback. |
| Production migrations | Moved the prover from Halo2 to SP1 in production. |
| Security-sensitive systems | Transaction-screening detectors at the sequencer. |
| Open-source operations | An automated public mirror of a private monorepo. |
What this means for your project
- Running long, expensive jobs that can’t fall behind? I design the queueing, concurrency and back-pressure so the slow part stays off your critical path.
- Upgrading critical infrastructure in production? I treat upgrades as operations, with drain, upgrade, verify, resume, and a rollback that has been rehearsed.
- Early team, no process yet? I’ve built release management and incident response from scratch while shipping features.
On the record
Zircuit’s own look back at the road from testnet to mainnet, and what comes next.
Zircuit’s announcement of its public mainnet launch.
Independent coverage of the mainnet launch.
The open-source monorepo, published by the release pipeline I built.
© 2026 Ali Farooq