What running a Bitcoin mine taught me about cloud margins

A short stint at Foundry Digital running ASIC fleets, immersion vs. air, the depreciation curve, and the brutal arithmetic of difficulty adjustments — and why I never stopped thinking like an operator after I went back to writing software.

TODO: Dax confirm dates, exact title, and any specifics he wants to swap in. Where I couldn’t pin a public source down I left a TODO. Don’t fill any of these in with vibes.

After the Navy and before I went all-in on writing software for a living, I spent a chapter at Foundry Digital on the operations side of industrial Bitcoin mining. I won’t pretend it was a long chapter. It was long enough to permanently change how I think about every cloud bill I have ever paid.

This post is about what mining at scale teaches you that no amount of staring at AWS Cost Explorer ever will.

The setup

A modern Bitcoin mining facility is, structurally, a data center with one workload. Walls of ASICs in racks. Power coming in by the megawatt. Heat going out by every method physics allows. A network that exists only to push pool work and pull telemetry, because nobody is serving HTTP responses out of a hashboard.

The two things that matter, in order: the cost of the electron that arrives at the chip, and the cost of removing the heat afterward. Everything else — uptime, firmware, network design, even the hardware itself — orbits those two numbers.

The exact site I worked, the exact rig count, the exact MW of nameplate capacity — TODO: Dax confirm specifics. The lessons below are what I took with me. They generalised.

Lesson 1: the unit economics are knowable to four decimal places

Mining is the rare infrastructure business where a junior operator can compute the unit economics on a napkin. It goes like this:

A given ASIC has a hashrate (TH/s) and a power draw (W).
Network difficulty determines, statistically, how much BTC a given amount of hashrate is going to produce per unit time.
The market determines the dollar value of that BTC.
Your power contract determines what an electron costs you.
The depreciation curve on the box determines how much you owe yourself per day for owning the box.
Subtract.

That’s it. Five inputs. The whole industry runs on a spreadsheet you can re-derive from first principles. Compare and contrast: SaaS gross margin, where the inputs are “how much your AWS bill secretly was last quarter” and “what the CFO claims the COGS allocation is.”

The first time I ran the math on a single rig, end-to-end, I felt a kind of clarity I have not felt about a software business since. This is what ‘good unit economics’ actually looks like, and most products you have ever shipped do not have them.

Lesson 2: difficulty is gravity

Every two weeks (more or less) the Bitcoin network adjusts difficulty to retarget block time at ten minutes. If hashrate has gone up — because someone stood up a new fleet, because someone got a better firmware tune, because a competitor finished a build-out — your share of the reward goes down. Mechanically. Without you doing anything wrong.

What this means in practice: the unit economics from the last paragraph have a built-in headwind that compounds. You are running on a treadmill that speeds up automatically. The only ways to win are (a) get cheaper power, (b) get more efficient chips, or (c) shorter holding period than your competition. There is no fourth option.

I think about this every time I see a SaaS company that thinks its margin is stable because the AWS price list hasn’t changed. The AWS price list isn’t your difficulty adjustment. Your competition is your difficulty adjustment. Every quarter someone smaller and hungrier ships a thing that makes your incremental customer slightly less willing to pay what your incremental customer paid two years ago. You have a difficulty adjustment. You’re just not pricing it in.

Lesson 3: heat is the actual problem

If you’ve never been in a room with several thousand ASICs in it: it’s loud and it is the precise temperature your air conditioning lets it be, and not one degree cooler. The boxes do not care if the room is hot. The boxes care if the junction temperature on the chip exceeds spec, at which point the firmware downclocks and your hashrate drops, or worse, fails the chip outright.

The two ways out are air and immersion. Air is what you think it is — fans, baffles, careful airflow design, an HVAC plant you respect. Immersion is dunking the boards in dielectric fluid that pulls the heat off twenty times more efficiently, at the cost of all the operational complications you’d expect from running electronics in a bath.

I will not pretend I made the architectural calls on which sites went air vs. immersion (TODO: Dax confirm role specifics). What I will say is that being adjacent to the decision for the first time was the moment I understood that infrastructure is not a software problem with hardware as an implementation detail. It is a thermodynamics problem with a software top layer. The data centers you and I run our cloud workloads on are exactly the same problem, just with someone else holding the bag for the cooling.

When I read a cloud provider’s pricing page, I now read it through the heat. This region is more expensive because the heat is more expensive to remove. That is not a metaphor. That is the literal reason.

Lesson 4: ASICs depreciate faster than you respect

A new generation of ASICs comes out roughly every 12–18 months. Each generation is meaningfully more efficient (J/TH) than the last. The economics of the previous generation under current difficulty are, accordingly, worse than they were the day you bought it. Worse the day after that. Worse next quarter.

The right way to model an ASIC is not as an asset. It is as a slow-burning fuse. You bought a thing that produces revenue, and the revenue declines on a schedule that is not entirely under your control. The question is not “is this rig profitable today.” The question is “is this rig going to pay back its capex before the depreciation curve crosses the operating cost.”

Most cloud infrastructure quietly works the same way. The instance type you bought your reservation on is going to be deprecated. The CPU generation you pinned is going to underperform the new one. The vendor lock-in you picked up to save engineering hours is a slow-burning fuse with a duration measured in CTO turnover. Plan for it.

If I have one piece of cloud-architecture advice I credit Foundry for, it’s this: the day you sign a multi-year reservation is the day you should put a calendar reminder in for “how do I get out of this contract” eighteen months hence. Mining taught me. The treadmill always speeds up.

Lesson 5: the operator is the hero

In a mining facility, the operations team is not a cost center the engineering team tolerates. They are the team. The site is profitable because of them. Your firmware tune, your network design, your chip generation — none of it matters if the on-call doesn’t catch a transformer fault before it takes the substation down for six hours.

I have carried this view into every software org since. A platform engineer is not “supporting” the product engineers — they are the multiplier on every product engineer. A site reliability engineer is not “fixing problems” — they are creating the conditions under which problems are recoverable. The mining-site mental model is: the operator is the hero of the story, the engineer is the supporting cast. Most software cultures invert that. Most software cultures are wrong about it.

What it means now

I think about all of this almost every day at Zera Labs. When we set up the Surfpool devnet on a Latitude box — a single physical machine that mirrors mainnet for our entire dev team — I priced the math the way you price a mining site. Power-equivalent (the box’s monthly cost) vs. throughput (devs unblocked) vs. depreciation (how long until we want to replace this with the next generation). Three numbers. No vibes. The same five-input spreadsheet, just with hashrate replaced by “developer hours saved per RPC call.”

Then I went back to writing software. But I never stopped thinking like an operator.

If your engineering org has never had a person on it who has been in a room with several megawatts of compute they were personally responsible for, hire one. They will be quieter than your loudest senior engineer and they will save you a small fortune.

Footnotes for Dax

TODO: confirm exact role title at Foundry — the framing above intentionally hedges between “operations” and “engineering” because the public record doesn’t pin it.
TODO: confirm dates. The post is generic enough to survive any month.
TODO: confirm whether to name a specific site. I left it abstract.
TODO: confirm rig count / MW if you want to add one specific number to ground the story. The post works without it.