There is a number in Microsoft's capacity plan that does more analytical work than any token whitepaper published this cycle: 38 gigawatts, targeted by 2032, against roughly 12 gigawatts today. Tripling in seven years. Trailing-year capital expenditure sits at $145 billion, and the analyst consensus expects that line to keep climbing through the decade.
The roadmap is more interesting for what it excludes. It counts self-built and leased facilities. It does not count compute rented from the so-called new cloud service providers. CoreWeave is the named example. That omission is not an accounting footnote. It is a disclosure about where the marginal megawatt is expected to originate: the hyperscaler's own balance sheet, not a counterparty's.
For anyone building decentralized compute markets, verifiable inference layers, or DePIN-style GPU networks, that excluded column is the most load-bearing datapoint in the release. It marks the edge of a moat that is not made of capital. It is made of queue positions, transformer order books, and power purchase agreements signed two years before the first GPU rack is bolted down.
The code doesn't read press releases. Neither, apparently, does the interconnection queue.
The Physics Ledger
The reporting around Microsoft's expansion has been framed as a supply-response story: capacity was constrained, Microsoft restricted new cloud subscriptions in key U.S. and European regions, some customers walked to competitors, earlier construction pauses left compute tight, and now the company says it is accelerating builds. That framing is not wrong. It is incomplete in a way that matters for anyone modelling compute markets.
Start with what a gigawatt actually is. One gigawatt of continuous load is roughly 8,760 gigawatt-hours per year, adequate for something on the order of 700,000 to 800,000 average homes. Microsoft's stated endpoint is 38 of those. The current base is approximately 12. The delta is not a procurement problem. It is an infrastructure problem with four separate chokepoints, and only one of them involves silicon.
A modern AI campus has a hard ceiling determined by whichever of four constraints binds first: nameplate power, interconnect capacity, transformer delivery, and generator delivery. Silicon is a purchase order. The other three are queues.
I model these as a min() function, because that is what they are:
site: columbus_oh_phase_3
nameplate_mw: 480
pue_target: 1.18
rack_density_kw: 92 # liquid-cooled, GB-class rack
interconnect_queue: PJM # position secured 2027-Q3
step_up_transformers: 6 # 84-week lead time, quoted 2026-02
prime_movers: 4 # gas turbines, delivery window 2029-H2
effective_mw: min(nameplate_mw, interconnect, transformers, prime_movers)That last line is the whole business. Every operator in the market runs the same function with different numbers. The ones who win are not the ones with the largest nameplate. They are the ones whose minimum is highest, and whose minimums were locked in earliest.
Transformer lead times are the least discussed and most binding input. Large power transformers and generator step-up units that once quoted in 12 to 20 weeks now commonly quote in 80 to 120 weeks, with some rated units further out. Interconnection queues in the major U.S. markets run into multi-year territory. Gas turbine order books at the primary OEMs are effectively sold out through the late 2020s. This is public information, and it is the reason a hyperscaler roadmap extending to 2032 exists at all: you cannot announce a 2030 capability in 2029.
The roadmap is not a forecast. It is a reservation list.
That distinction determines how to read the CoreWeave exclusion. A neocloud rents capacity to a hyperscaler on contract terms that are commercially convenient but strategically optional. When the buyer's own builds come online, the rented layer is the first to be repriced. Capacity is a queue position before it is a product. Microsoft counting 38 GW of owned and leased facilities, and separately accounting for third-party rental, tells you which side of that repricing it intends to be on.
What the Neocloud Actually Sells
The neocloud business model is simple to describe and uncomfortable to audit. It buys GPUs on debt, collateralized by the GPUs themselves. It signs multi-year capacity contracts with creditworthy buyers. It services floating-rate debt with contracted revenue. On paper the spread is attractive because the buyer's credit is better than the borrower's cost of funds.
The structure is a maturity and duration mismatch dressed as a service business. Revenue is fixed-price and multi-year. Debt is floating. Collateral depreciates on a technology curve, not an accounting curve. The contract is the asset. If the contract is repriced or not renewed, the collateral is worth a fraction of the loan balance within two quarters.
I have run this shape before. In 2022 I pulled apart the Mercurial Finance leverage mechanism to understand how aggressive lending parameters produced insolvency, and the causal chain was not exotic. Risk parameters were set to a regime that had not been stress-tested, the collateral was reflexive because the protocol's own token sat inside it, and the first margin call triggered a liquidity drain that no parameter could absorb. The lesson generalized past DeFi: if your revenue is contractual and your liabilities are mark-to-market, you are short optionality, and optionality is what the counterparty is buying.
The Microsoft roadmap makes the optionality explicit. The buyer has a build option. The seller does not have a substitute buyer at the same price, because the substitute buyers are the same short list of hyperscalers running the same build programs. A capacity contract with a company that has announced a 38 GW self-build program is not an annuity. It is a call option granted to the counterparty, financed at a floating rate.
None of this says neoclouds fail. It says their equity is a leveraged position in hyperscaler build delays. That position pays extremely well while delays persist. It is worth nothing the moment they do not.
The Miners Who Own the Queue
The more interesting arbitrage sits one layer down, with the Bitcoin miners who spent the last cycle accumulating exactly the asset the AI build-out needs: energized sites with interconnection positions.
Post-halving miner economics are unforgiving. Block subsidies were cut, and the marginal operator's revenue per megawatt is now a fraction of what the same megawatt can earn hosting inference. The conversion math is not subtle:
# coarse per-MW revenue, illustrative shape only
btc_rev_per_mw_yr = hashrate_per_mw * block_reward_value * blocks_per_yr
ai_rev_per_mw_yr = racks_per_mw * contract_rate_per_rack_hr * 8760 * utilization# observed reality: btc_rev_per_mw_yr compresses every halving, # ai_rev_per_mw_yr is contractually fixed for 3-6 years ratio = ai_rev_per_mw_yr / btc_rev_per_mw_yr ```
The ratio explains the migration. It also explains why the migration is a concentration trade, not a diversification trade. A miner who converts a site from hashing to hosting has traded a volatile, permissionless, globally liquid revenue stream for a fixed-price contract with a small number of buyers. The buyer has a build option. The site has a queue position, which is valuable โ but a queue position has exactly one monetization path, and the number of parties capable of paying for it is countable on one hand.
This is the same structural short I keep finding. Every constraint in a system eventually becomes someone's pricing power, and the question is always which side of the constraint you are standing on. The miner standing on the queue owns something scarce. The miner who signed a fifteen-year below-market contract to finance the conversion has sold that scarcity forward at a discount to a buyer who understood it better.
The hash rate concentration thesis compounds here. Post-halving, only operators with the lowest power costs or a conversion path survive. Consolidation into a handful of pools was already the trend; the AI hosting bid accelerates it by giving large site operators a capital source that small operators cannot access. Decentralization of hash power becomes a formal property rather than a real one โ the ledger stays distributed while the production of blocks concentrates in three or four industrial operators whose marginal revenue now depends more on AI contracts than on Bitcoin.
Verifiable Inference and the Determinism Problem
Now the part that actually concerns on-chain compute, and the part I have hands-on experience with.
In 2026 I worked with a distributed AI research group to design a verifiable inference oracle. The premise was straightforward: commit to a model, commit to an input, execute off-chain, produce a proof that the output corresponds to the committed computation, verify on-chain without exposing weights. We ran ten thousand inferences on a private Ethereum testnet at 99.9% accuracy against a reference implementation.
The engineering surprised me in one direction and confirmed a prior in another. The surprise was that the verifier contract was cheap. The confirmation was that determinism, not arithmetic, is the hard part.
A model does not produce the same output twice unless you force it to. The same weights, the same input, three legitimate execution paths:
torch.backends.cuda.matmul.allow_tf32 = True # path A
torch.backends.cuda.matmul.allow_tf32 = False # path B
# path C: identical config to B, different cuBLAS build
# with a different split-k reduction heuristic# greedy decoding, 70B-class model, identical prompt # A vs B: single token divergence at position 412 of 2048 # B vs C: single token divergence at position 1187 of 2048 ```
A single token flips. Downstream, that flip propagates. Any verifier that compares outputs byte-for-byte will reject honest provers. Any verifier that tolerates divergence has to define a tolerance, and a tolerance is a security parameter masquerading as a rounding decision.
The response space has three shapes.
Deterministic execution. Pin the kernel version, pin the precision mode, pin the reduction order, quantize aggressively enough that the arithmetic is exact. This works. It also constrains the model, costs throughput, and requires every prover and every verifier to run a frozen software stack. That is a governance surface, not a technical one โ whoever controls the pinned kernel controls the truth.
Zero-knowledge proofs of inference. Elegant, and brutally expensive. The overhead for proving a transformer forward pass sits in the range of several thousand times the cost of executing it, depending on the scheme and the quantization. Folding schemes and proof aggregation have compressed this materially, and GPU-accelerated provers compress it further, but the ratio is still the dominant cost term by an order of magnitude. The bottleneck is not the verifier. It is the prover's power bill.
Optimistic inference with a challenge window. Publish a claim, post a bond, allow a dispute. The security model shifts from cryptographic soundness to economic soundness with a liveness assumption. This is the shape most teams converge on, because it is the only one that clears the cost bar today.
interface IInferenceOracle {
struct Claim {
bytes32 inputCommitment;
bytes32 modelCommitment; // weights + kernel version + precision mode
bytes32 outputCommitment;
address prover;
uint64 submittedAt;
uint64 challengeWindow; // seconds
uint256 bond;
}function submit(Claim calldata c) external payable returns (bytes32 claimId); function challenge(bytes32 claimId, bytes calldata counterProof) external; function finalize(bytes32 claimId) external; } ```
Read that struct carefully, because the security lives in the fields nobody puts in the marketing. modelCommitment has to bind the kernel version and the precision mode, or two honest provers will produce different outputs for the same committed model. challengeWindow has to be long enough for an independent verifier to re-execute โ which, for a large model, is minutes to hours of GPU time, and that sets a hard floor on the window. bond has to exceed the profit from lying, which requires knowing what the output is worth to the liar, which is an economic question that smart contract engineers routinely skip.
The bond is the security parameter. Not the proof.
The Data Availability Problem Nobody Prices
Weights are large. A 70B-parameter model in FP16 is roughly 140 gigabytes before optimizer state, before tokenizer, before the inference server's own footprint. Committing to that on-chain is a hash. Making that commitment meaningful requires the weights to be retrievable by anyone who wants to challenge, which means data availability at a scale that no public chain currently prices.
You can route it through an external DA layer. You can use erasure-coded availability sampling. You can require challengers to fetch weights from a permissioned mirror and accept that the permissioning is the trust assumption. All three are defensible. None of them are free, and none of them are in the fee model of any inference token I have examined.
There is a second unprcied cost. Inference is stochastic at the sampling layer even when the arithmetic is deterministic. Temperature, top-p, top-k, and seed handling all affect output. A verifier that does not bind the sampling configuration is verifying a distribution, not a computation. I have seen production oracle designs where the sampling parameters were passed as calldata and never committed โ which means a prover could re-sample until the output matched whatever was convenient, and no verifier would catch it.
That is not a theoretical hole. It is a live one, and it is invisible in audit reports because it is a specification gap, not a code defect.
The code doesn't fail here. The specification does.
Where the Capital Actually Is
Return to the roadmap and the capital line. A $145 billion trailing-year capex figure with consensus growth implies a multi-year commitment to owned infrastructure that dwarfs the aggregate market capitalization of every decentralized compute network combined.
That gap is not a valuation anomaly to be arbitraged. It is a statement about what the buyers want. Hyperscaler customers are buying latency guarantees, contractual uptime, compliance posture, and a support phone number. Decentralized compute networks sell lower unit cost and censorship resistance. Those are real properties. They are not the properties the paying customer's procurement process scores.
What decentralized networks actually have is a cost basis that excludes power contracts, because they rent spare capacity rather than owning the interconnect. That is an advantage in a soft market and a fatal weakness in a tight one. The moment capacity is scarce โ which is precisely the condition Microsoft's roadmap exists to address โ the spare capacity disappears, because the owner monetizes it directly at contract rates. The decentralized market's supply is procyclical. It expands when nobody needs it and vanishes when everybody does.
I saw the same reflexivity in the cToken models I reverse-engineered during 2020. The interest rate curves looked responsive. In simulation they were, because the simulation assumed supply was elastic within a block. Real supply was not elastic, and the curve's responsiveness was an artifact of a parameter choice that had no relationship to how lenders actually behave. Arbitrary curves produce arbitrary liquidation cascades. Compute markets have the same property: a spot market that only exists when spot supply is abundant is not a market, it is a residual.
On-chain compute tokens have consequently become a levered proxy for hyperscaler capex, correlated to accelerator demand and rate expectations, and only loosely coupled to their own utilization. The depreciation mismatch is the tell. AI accelerators have an effective competitive life closer to three years at the workloads that matter, because the performance-per-watt envelope moves that fast. Token models that assume five- or six-year service lives are understating cost by roughly half, and the understatement lands directly in the earnings line.
The Contrarian Read: The 38 GW Number Is Bearish for Decentralized Compute
The consensus interpretation is that massive AI infrastructure demand validates the decentralized compute thesis by proving the market is enormous. That reading is backwards, and the reason is structural rather than sentimental.
Vertical integration plus power scarcity produces a moat that cannot be crossed with cheaper GPUs. The scarce asset is not the accelerator. It is the energized site with a secured interconnect, a delivered transformer, and a firm generation contract. Those are acquired through relationships, long-dated capital, and queue positions โ none of which are composable, and none of which can be permissionlessly replicated. A decentralized network competes on the one input that is not scarce.
The specific blind spot the market is carrying is the belief that the neocloud and miner-conversion layer is the bridge between the two worlds. It is not a bridge. It is a buffer that exists because the buyer chose not to build fast enough, and it will be repriced the moment the buyer's own builds clear their queues. Treating CoreWeave's exclusion from the roadmap as a footnote is the analytical equivalent of ignoring a disclosed related-party transaction because it appears under a subheading.
The second blind spot is verifiability itself. The on-chain inference narrative assumes demand for trustless verification of model outputs. That demand is currently near zero among the buyers with budgets. Enterprises running inference today accept the provider's word because they have a contract and a legal remedy. Verifiability is not a feature you can sell to someone who is not buying it. The customers who genuinely need it โ adversarial multi-party systems, autonomous agents transacting with each other, on-chain protocols that must act on off-chain model output โ are small, technically demanding, and currently poor.
That does not mean the work is worthless. It means the timeline is longer than the token charts imply, and the projects that survive it will be the ones whose cost structure does not depend on a demand that has not arrived.
What to Watch
The datapoints that will resolve this are not in the earnings calls. They are in the queue filings and the equipment order books.
Watch the interconnection queue positions that get converted from Bitcoin hashing to firm AI load, because each conversion permanently removes flexible load from the grid and shrinks the residual supply that decentralized markets rent. Watch large-power transformer lead times, because they set the real completion date of every announced campus regardless of what the roadmap says. Watch the depreciation schedules that neoclouds and converted miners disclose, because the gap between the stated life and the effective three-year competitive life is where the next round of impairments originates. And watch whether any inference oracle ships a specification that binds its sampling parameters, because that omission is the one that will not appear in a post-mortem until after it has been exploited.
The 38 gigawatts are real. The question worth asking is what the number looks like from the other side of the meter โ when the last excluded column is finally priced, and everyone discovers they were short the queue the whole time.