From sailor to CEO in three acts

This blog has accumulated, at this point, several long-form posts covering individual chapters of how I got from a Navy reactor compartment to running Zera Labs. The Navy origin post. The Foundry post. The founding letter. The CEO-still-shipping post.

This is the shorter post that exists because people who don’t read the long posts still ask the question. How did the Navy guy end up building a ZK SDK? The version that fits on LinkedIn. Three acts. One arc.

I’ll keep it under two thousand words.

Act one: the watch

I came up as a Nuclear Electronics Technician in the US Navy. The Navy nuclear pipeline is — there is no nice way to say this — an unreasonable amount of school. You go through a screening that washes out most of the people who applied. Then you go through Nuclear Power School, which is twenty-six weeks of physics, reactor theory, thermo, fluids, and mathematics at a pace that is calibrated to break you exactly enough to find out whether you bend back. Then you go through prototype, where you actually run a real reactor, in a real plant, for thousands of hours of supervised watchstanding. Then you go to a hull, which is when the actual job starts.

Along the way you are taught — not as a soft skill, but as a hard skill — that the panel does not lie, the procedure is the contract, and the most dangerous person on the watchstation is the one who decides the indications are probably fine.

I got out with a stack of qualifications, a security clearance whose paperwork I am still slightly anxious about, and a bone-deep instinct for how safety-critical engineering is actually done. That instinct does not show up on a resume. You only see it when the system is on fire, and even then you only see it as the absence of panic.

If you want the long version: Nuclear reactors taught me to ship software.

Act two: the chips and the code

Out of the Navy, I took an unexpected detour through industrial Bitcoin mining at Foundry Digital. (TODO: Dax confirm length of stint and exact role title — keeping the short version short here.) ASICs in racks. Megawatts of power. Heat going out by every method physics allows. The unit economics live on a five-input spreadsheet, and the spreadsheet does not lie either.

The thing nobody tells you about working in mining operations is that it is the closest thing the modern economy has to a reactor compartment. The discipline transfers exactly. The watchstanding is the same. The brutal physical immediacy of a ten-thousand-amp electrical bus is a familiar object to a former reactor electronics tech. So I did a chapter, learned what I needed to learn about the depreciation curve and the cost of an electron, and moved on.

If you want the long version: What running a Bitcoin mine taught me about cloud margins.

After Foundry I went where most former-military, vaguely-technical thirty-somethings end up: into software. PMG first (TODO: Dax confirm). Then USAA (TODO: Dax confirm). Then ConsenSys, which is where the Web3 part of the story started — open-source work across the product surface, mentoring junior engineers, and starting to speak publicly at Permissionless and EthGlobal on developer experience and supply-chain risk.

The supply-chain risk thread is the one that became the Rusty Pipes series on this blog — a research thread on Rust binaries injected into npm packages, which is the kind of attack that is funny on a slide and very much not funny in a customer’s CI. The series is the longest-running thing I’ve written and the thing I am most consistently invited to talk about. It also lined up, in a way I did not plan, with the technical posture I’d later need at Zera Labs: the moment your dependency surface is non-trivial, the registry becomes your threat model, not your library.

In act two I learned to ship software the way the modern industry ships it. Continuous deployment. Cloud-native everything. PR review culture, sometimes good, sometimes bad. I learned what a senior IC actually does, then I learned what a staff engineer actually does, then I started to notice that the ceiling was not where the interesting problems were.

Act three: the company

The third act starts with three things being true at the same time, in the same year. ZK got fast enough to be boring. Solana got cheap enough to make tokenisation a naming decision instead of a budgeting decision. AI agents stopped being demos and started being tools that needed to interact with money. Sitting at the intersection of those three things, I incorporated Zera Labs.

The technical surface — visible in github.com/Dax911 — is the zera-sdk (Solana-native ZK SDK with a Rust core), zera-wallet-demo (Tauri 2 with Groth16 in WASM), z_trade (zeraswap — first compressed-token AMM on Solana), zera_med_demo (a ZK-FHIR gateway because someone asked us to prove it works for things other than crypto bros), and a public Zera Design System we use across the product. Plus an MCP server for AI agents to call any of it. We are small (TODO: Dax confirm headcount when comfortable disclosing), the work is technically dense, and the schedule is short.

If you want the long version: Why I started Zera Labs. If you want the inside-the-week version: Being CEO and still shipping code.

What the arc actually is

Looking at the three acts side by side, the arc is not “Navy guy gets into crypto.” That is the LinkedIn-recruiter version. The actual arc is something narrower:

Each chapter forced me to take seriously the gap between the system is correct and I have correctly observed that the system is correct.

In the Navy that gap is closed by watchstanding, two-person verification, and casualty drills. In mining it is closed by telemetry, redundant temperature sensors, and on-call. In software at scale (PMG → USAA → ConsenSys) it is closed by tests, code review, and post-mortems. In ZK it is closed by a Groth16 proof — a piece of math that is the closure of the gap. The whole story, condensed, is that I kept moving up the stack of “ways to know that the system is correct,” and each step gave me a little more leverage than the last.

The reactor watchstander’s tools are slow, expensive, and limited to a single plant. The miner’s tools are faster and parallel, but only over a single workload. The senior IC’s tools are general-purpose but soft — they assume an honest reviewer. The cryptographic tools at the end of the arc are general-purpose, fast, and don’t assume an honest reviewer. They are, in a real sense, what every prior chapter was reaching for.

If I had to pin the arc to one sentence I’d say: I have spent fifteen years getting better at proving that systems are doing what they claim to be doing, and the most productive place to do that work, today, is at a company whose entire surface is about producing those proofs.

What I’d tell my younger selves

Three notes to three different versions of me — because I find this is the most useful summary for people whose careers are a few chapters earlier than mine.

To the kid in the reactor compartment: the discipline you are absorbing is the most valuable thing you are going to learn, and you will not realise this until you have been out for five years. Don’t lose the watchstanding habits. Don’t soften the procedure-in-hand instinct. Find a civilian career where they still apply.

To the operator at the mining site: pay attention to the unit economics. The five-input spreadsheet is a model that generalises beyond mining. Carry it with you. Whatever business you eventually find yourself in, you will be able to think about it more clearly than the people around you because you have seen what real unit economics actually look like.

To the senior IC at ConsenSys: the Rusty Pipes work is the start of a research thread, not the end of one. Don’t drop it after the first post. The supply-chain question is going to be one of the defining infrastructure problems of the next decade, and you are early.

To present me: don’t get cocky.

And to the reader

That’s how I got here. The interesting question, though, is not how I got here. It is where everyone else is going.

If you came up the same way — Navy, military, technical — and you are thinking about the civilian transition, my email is at the bottom of every page. Reach out. The civilian-tech industry will tell you a lot of things about your discipline, almost none of them flattering, almost none of them correct. The reactor instincts are a superpower in a software org that has lost them. Bring them with you.

If you are a senior IC who is wondering whether to keep going up the staff ladder or jump sideways into a founder seat, I hope the CEO-still-shipping post is useful. The math is not as bad as the canon makes it sound.

If you are at the third act yourself, building cryptographic infrastructure or anything adjacent, I want to know. The ecosystem is small enough that we should know each other.

And if you are at the very beginning — looking at a screening package, or a Navy recruiter, or a dev bootcamp acceptance, or a first software job — pick the chapter that gives you the deepest forcing function. Pick the chapter that demands the most discipline up front. The discipline is the thing that compounds. The technology is the thing that changes.

That’s the LinkedIn version. The longer versions are linked above. Thanks for reading.