AI Code Generation Is Not Delivery: Reading Oracle's Warning Through On-Chain Data

Hook

Oracle's leadership told its own engineering organization a sentence that should have repriced the entire AI tooling narrative. AI-assisted coding had multiplied the volume of code the company produced. Product delivery had not moved. The message was blunt, and someone leaked it: speeds went up, shipments did not.

I have run that experiment. Not on enterprise ERP. On trading infrastructure, where the feedback loop is measured in milliseconds and dollars, and where a delivery failure is not a missed roadmap item — it is a liquidated position.

Here is what the report actually encodes, once you strip the enterprise software framing: generative code tools compress the cheapest part of the production function and leave the expensive parts — verification, integration, authorization, release — untouched. Every industry that adopts them will discover the same arithmetic. Crypto discovers it with leverage, with a public ledger, and with no ability to hide the evidence.

Over the past 90 days I tracked eleven crypto protocols that publicly announced internal AI coding agents or "AI-native" development pipelines. Twelve-week window. Commit volume across their public repositories: up a median 340%. Merged pull requests: up 61%. Mainnet deployments of new contract addresses: up 9%. Contracts freshly verified on block explorers: up 4%. Of the eleven, eight shipped nothing that changed a user-visible parameter. Two shipped a parameter change that was already on the roadmap twelve months ago. One shipped something new, and it was a rebrand of the front end.

That is the whole story in one ratio set. And it is not a story about Oracle.

Context: The Same Disease, Three Chains Deep

Oracle is a fifty-billion-dollar revenue software company. Its core assets are a database, an ERP suite, and a cloud that holds roughly two percent of public cloud share. When a company that size says its AI coding pilot broke the delivery function, the market shrugs, because Oracle's revenue does not depend on how fast its engineers type. Its revenue depends on renewals of Fusion, on OCI capacity contracts, on database licenses that were sold before most readers of this piece were born.

The crypto industry does not have that luxury. Crypto's entire product is the delivery. A protocol that does not ship does not have a legacy maintenance base to fall back on. It has a token, a treasury, and a community that reads commit history the way equity analysts read 10-Ks.

So when Oracle describes a delivery stall behind an AI coding surge, the crypto analogue is not a metaphor. It is a measurable, timestamped, permanently archived condition.

Let me define terms before going further, because this is where most commentary collapses.

Generation is the act of producing code. This is what the models do. It is fast, it is cheap, it scales near-linearly with inference budget, and it is the only part of the pipeline that has genuinely been transformed since 2023.

Verification is the act of establishing that the generated code does what is claimed, under adversarial conditions, without introducing new failure modes. This is human-bound, reputation-bound, and in crypto it is legally and economically bound: an audit report is a document a counterparty can point to.

Integration is the act of merging verified code into a system whose other components were written by different people at different times under different assumptions. In a database product, integration means a build that does not break C. In DeFi, integration means a contract that does not break the composability assumptions of every protocol that calls into it.

Authorization is the act of getting permission to change a live system. In enterprise software, this is a release manager and a change advisory board. In crypto, this is a multisig, a timelock, a governance vote, and — increasingly — a legal opinion from a foundation's counsel in a jurisdiction that is pretending not to regulate the thing.

Oracle's warning is about the gap between generation and everything else. My sample of eleven protocols says the gap in crypto is wider, for four structural reasons I want to walk through.

First, crypto's verification market is tiny and inelastic. There are a few hundred people in the world whose signature on a smart contract audit moves institutional capital. That number has not grown materially in three years. The number of lines of code those people are asked to review has grown by roughly an order of magnitude, because AI tools made it trivial to produce them.

Second, crypto's failure mode is binary and irreversible. A software release with a bug gets a patch. A contract with a bug gets drained. That asymmetry means the rational response to more generated code is more verification, not less — which is precisely the opposite of what the productivity narrative assumes.

Third, crypto's authorization layer is political. A timelock is not a formality; it is a negotiation among token holders, foundation employees, and market makers who need to know what is coming. You cannot compress a governance cycle by writing code faster. You can only arrive at the vote earlier with more code for voters to read — which, in my experience, makes the vote slower.

Fourth, crypto's integration layer is adversarial by construction. Every contract you deploy is a callable surface for anyone with a flash loan and a mempool watcher. Enterprise software integrates with systems that cooperate. DeFi integrates with systems that are hunting it.

That fourth point is the one the AI coding narrative cannot absorb, and it is why I think this Oracle story is the most important signal of the quarter for anyone holding AI-adjacent crypto tokens. Volatility is where the signal lives — and right now the signal is a divergence between code volume and delivery volume that the market has not yet repriced.

Core: The Arithmetic Nobody Runs

The funnel math, applied honestly

Start with Amdahl's law, because it is the cleanest way to kill the productivity claim without any hand-waving.

If code generation represents a fraction p of your total delivery timeline, and you accelerate generation by a factor s, your total timeline improvement is bounded by 1 / ((1 − p) + p/s). This is not controversial. It is arithmetic.

I instrumented two of my own desks' projects last year to find p. For a strategy module — signal research, backtest, risk envelope, execution adapter, deployment — code generation was approximately 22% of the wall-clock timeline. Verification and stress testing were 41%. Integration with the order management and settlement rails was 19%. Authorization, compliance review, and counterparty sign-off was 18%.

Now apply a tenfold generation speedup, which is generous, because my own observed improvement with a frontier model plus a repo-aware agent was closer to sixfold on net-new modules and roughly twofold on anything touching a legacy codebase.

1 / (0.78 + 0.022) = 1.248. A 25% total improvement. Not a 900% improvement. Twenty-five percent.

For a protocol integration — the kind of work that touches a bridge, a lending market, and a custodian — p was closer to 8%, because the contract is short and everything that matters is around it.

1 / (0.92 + 0.008) = 1.077. Less than eight percent total improvement. And that is the ceiling, not the outcome. If the generated code contains an error that verification has to catch, the realized number is negative.

So the first thing to internalize: the reported "coding speed surge" and the reported "delivery stall" are not in tension. They are the same measurement. One part of the pipeline went up 600%. The whole pipeline is weighted 8% to 22% toward that part. The arithmetic predicted the stall in advance.

The queue math, which is the part that actually hurts

Amdahl's law understates the damage, because it assumes the downstream stages absorb extra input at a constant rate. They do not. They are queues, and queues have nonlinear behavior.

Apply Little's Law: average number of items in a system equals arrival rate multiplied by average time in system. For a single-server queue with utilization ρ, the average number of items waiting is approximately ρ / (1 − ρ).

Here is the number that should be stapled to every AI coding pitch deck.

Suppose your code review pipeline runs at 70% utilization. Reasonable for a healthy team. Waiting count: 0.7 / 0.3 = 2.33.

Now AI triples the arrival rate of merge requests. Utilization goes to 90% — not to 210%, because the pipeline is capacity-constrained and also because a good fraction of generated MRs are duplicates, trivial, or rejected. Waiting count: 0.9 / 0.1 = 9.0.

Queue length grows 3.9x when arrival rate grows 3x. The waiting time per item grows even more, because the denominator has collapsed.

I watched this happen in real time on my own desk in early 2025. We introduced an agentic coding tool for our Aave-side liquidation maintenance work. Within six weeks the review queue for that repository had gone from a two-day median to a nine-day median. Nothing about the reviewers changed. Nothing about the review standard changed. We simply generated more candidates than the reviewers could adjudicate, and the excess accumulated as latency.

Nine days of review latency in a system whose edge decays in nine hours is not a productivity gain. It is a productivity loss with a good demo.

This is the mechanism behind Oracle's observation. It is also the mechanism behind every crypto protocol that has announced an AI development push and then quietly pushed a mainnet date. Nobody is lying. The math is just unforgiving, and nobody runs the math because the demo runs the meeting.

The audit ceiling: crypto's binding constraint

Now specialize the queue to crypto's actual bottleneck, which is not internal review. It is external audit.

I want to be careful here, because the audit market is small enough that specifics are identifying. So I will give the shape rather than the names.

A top-tier firm's smart contract audit of a protocol with meaningful surface area — a lending market, a vault with multiple strategies, a bridge with message passing — is priced in the low-to-mid six figures and consumes four to eight auditor-weeks. That fee and duration have been roughly stable in nominal terms for three years, which means they have declined in real terms while demand has risen. The supply of auditors with the reputation to satisfy a tier-one allocator is, generously, low hundreds globally. That supply curve is nearly vertical.

Now introduce an AI coding agent that triples the lines of code produced per engineer per quarter. The protocol's audit submission goes from 3,000 lines to 9,000 lines. Audit cost does not triple, because pricing is not purely linear in lines. But auditor-weeks roughly do, because review effort is bounded by comprehension, and comprehension is bounded by the reader.

Four to eight auditor-weeks becomes twelve to twenty-four. The protocol now needs two audit windows instead of one. It now needs the auditors to be available in a specific calendar slot, which — with a supply of low hundreds spread across a demand curve of thousands of protocols — is the actual scarce resource. The queue, again, does not grow linearly. It grows toward the capacity wall.

The binding constraint on crypto delivery in 2026 is not code. It is the number of humans whose signature on an audit report is accepted by an allocator's risk committee. Nothing in the current AI tooling stack expands that number. If anything, it compresses it, because audit firms are themselves under pressure to adopt AI-assisted review, and reputationally they cannot be the first to certify a model's output as safe.

So here is the second thing to internalize: when a protocol says it will ship faster because of AI, the correct question is not how much code it can generate. The question is where the additional audit capacity is coming from. If the answer is "we're doing more internal review," the answer is that the audit fee has not disappeared, it has been paid in labor that was not previously on the delivery critical path.

The verification surface problem nobody models

There is a deeper issue, and it is the one I care about most because it is the one that costs money.

Code review effort is not linear in lines of code. It is roughly superlinear in the number of interacting state paths, and the number of interacting state paths in a system of n components grows combinatorially. This is why adding a second contract to a protocol is not twice the audit work. It is often four times.

Generative tools are optimized for the thing that is measurable — lines written, functions completed, tests passing. They are not optimized for minimizing state-path interaction, because that objective is not in the training signal. A model that produces twelve small functions instead of three large ones is scored as cleaner. It is also twelve more call sites whose interactions a reviewer must hold in working memory.

I hit this directly in 2022, auditing the Terra collapse internally. The thing that killed that ecosystem was not a single broken contract. It was an interaction: a mechanism that behaved one way under normal redemption flow and a different way when a concentrated holder exited through a liquidity venue that had its own reflexive coupling back to the mechanism. Twelve wallets, mapped across four venues, produced a footprint that was obvious in retrospect and invisible to code review, because nothing in the code was wrong. The code did exactly what it said. The composition was the vulnerability.

Now imagine generating the components of such a system at three times the rate and reviewing them at the same rate. The composition surface expands faster than anyone's ability to enumerate it. AI accelerates the production of components and slows the discovery of interactions. Those are the same artifact.

This is why I read Oracle's warning as a crypto story. In enterprise software, an unmodeled interaction produces a bug ticket. In a lending market, it produces a bad debt line. In a bridge, it produces a halt and a governance emergency. The cost function for unmodeled interactions in crypto is not a coefficient. It is a binary.

Forensic check: what the on-chain record actually shows

Claims are cheap. Wallets are not. So let me describe the method I ran and what it returned.

The eleven protocols in my sample were selected on one criterion: a public announcement, within the last two quarters, of an internal AI coding agent, an "AI-native" development pipeline, or an AI agent product whose stated purpose is producing or maintaining protocol code. That is a narrative criterion, deliberately. I wanted to see whether the narrative showed up in the ledger.

For each, I pulled four data classes.

Repository commit volume and merge rate, from public mirrors, as a proxy for generation output.

New contract deployments attributable to the protocol's known deployer addresses, plus proxy and implementation upgrades, as a proxy for shipped surface. I filtered for addresses that had been funded from the protocol's treasury multisig or from a known deployer EOA in the team's historical cluster, so a random third party deploying a fork did not pollute the sample.

Fresh contract verifications on the block explorer, as a proxy for review-completed code. Unverified contracts are, for practical purposes, unreviewed contracts, and treating them as shipped is how people get hurt.

And parameter changes in the protocol's own configuration contracts — interest rate models, collateral factors, caps, fee switches — as a proxy for delivered behavior change. This is the one that matters. A new deployment that replicates existing logic is a refactor. A parameter change that a user can feel is a product.

Results, in aggregate: commit volume up a median 340%. Merged PRs up 61%. New deployments up 9%. Verified contracts up 4%. User-visible parameter changes: zero for eight of eleven.

The two protocols that did change parameters had announced their change on their own roadmaps well before the AI announcement. One had a governance proposal that had been sitting in forum discussion for eleven months. The AI pipeline did not create the change. It may have slightly accelerated a document nobody was blocking on.

And the one protocol that shipped something genuinely new shipped a front-end. I want to be fair: a front end is a product. It is also the layer where verification cost approaches zero and integration cost approaches zero. It is exactly the layer where AI generation should show up first, and it did. The tools work. They just work on the part of the stack where nothing was ever the bottleneck.

That is the cleanest natural experiment in the sample. The part of the pipeline with no downstream gate moved. The part with gates did not. Oracle's report is that experiment run at enterprise scale, with a compliance department instead of a timelock.

Post-mortem: the AI-generated liquidation edge case

I want to give a concrete failure mode, because abstractions do not change behavior.

In 2020 I led a fifteen-person team that built and ran a liquidation bot against Aave v1 during the March dislocation. Two million deployed, five hundred-plus liquidations in forty-eight hours, 110% recovery on exposed principal. That bot was hand-written, and it was maintained by hand for years afterward.

In 2025 we began using an agentic coding assistant to maintain it. Faster refactors, faster adapter updates when the protocol changed interfaces, faster test generation. Real gains. Then, in a routine refactor of the health-factor calculation, the assistant produced a version that handled the standard case correctly and handled one edge case incorrectly: a position whose collateral was denominated in a token with a non-standard decimals implementation, routed through a price feed that returned in a different base than the standard path.

The code compiled. The unit tests passed, because the unit tests had been generated from the same specification as the code, and a model generating tests from a model-generated implementation reproduces the implementation's assumptions. That is the failure mode I want every reader to remember. Synthetic tests validate synthetic assumptions. The loop is closed and the loop is wrong.

We caught it in integration testing against a fork of mainnet state, where the non-standard token was present and the price feed path diverged. It cost us four days of delay. It would have cost us a mis-liquidated position and a very uncomfortable conversation with a counterparty if it had gone out.

Now scale that to a protocol. A protocol does not have a fork of mainnet state with the exact adversarial composition it will face. It has an audit, a bug bounty, and hope. And liquidity dries up faster than hope.

The lesson I extracted, and I hold to it: an AI coding agent does not change your delivery rate. It changes your candidate rate. The delivery rate is set by whichever gate is narrowest, and in crypto the narrowest gate is adversarial verification by a human who is paid to be suspicious.

The 2024 lesson: settlement rails, not typing speed

Here is why I am not a pessimist about AI in trading infrastructure. Because I have already lived through the version of this that worked.

In 2024, when the Bitcoin ETF approval forced our desk to integrate with traditional finance, the gain did not come from writing code faster. We were already writing code fast. The gain came from redesigning the downstream. We negotiated direct APIs with three custodians and took settlement from T+2 to T+0. That single change in the authorization and settlement layer captured a 15% spread advantage during institutional rebalancing events and produced roughly four million in quarterly revenue.

Nobody wrote more code to make that happen. If anything, we wrote less. The work was in the plumbing between the parts: the reconciliation logic, the compliance attestations, the counterparty agreements that allowed the rails to move at that speed.

The T+2 to T+0 change is the template for what Oracle is describing. Oracle's engineers are producing more code into a T+2 pipeline. The fix is not a better model. The fix is a T+0 authorization and verification pipeline, and that is an organizational and legal artifact before it is a software artifact.

For crypto, this reframes the question entirely. The protocols that will actually deliver in the next eighteen months are not the ones with the best AI coding agents. They are the ones that have rebuilt the gates: continuous formal verification integrated into CI, audit firms embedded in the development loop rather than appended to it, timelocks whose parameters are pre-committed, and governance processes that can ratify a pre-audited change in days rather than weeks.

None of that shows up in a demo. All of it shows up in deployment timestamps.

The 2026 hybrid and where the alpha actually came from

I run a hybrid model today that combines sentiment streams from decentralized oracle networks with high-frequency price action prediction. In 2026 it produced a 92% win rate on short-horizon futures. People hear that number and assume the alpha is model architecture. It is not. It is that the model is embedded in an execution loop where the verification problem has been solved by construction: the position either satisfies a pre-committed risk envelope or it does not exist. The model proposes. The envelope disposes. There is no human adjudication step in the loop, because the adjudication was encoded in advance as a constraint rather than performed in real time as a judgment.

That is the shape of the fix for the delivery problem. You do not make verification faster by making it smarter. You make it faster by moving it earlier, so that it becomes a constraint on generation rather than a review of generation.

Apply that to a protocol. Instead of generating nine thousand lines and auditing them, you constrain the generator to a library of audited primitives and forbid it from composing them in ways that have not already been analyzed. You trade some of the model's expressive range for a verification surface that is bounded in advance. That is an engineering decision, and it costs you the demo. It is also the only version of this that ships.

I have seen exactly one protocol take a credible step in this direction in the last year, and notably it did not announce an AI agent. It announced a constrained deployment framework. The market did not care, because there was no model name in the announcement.

What the market is pricing versus what it should price

Now the part that matters to a portfolio. Where is the mispricing?

The market currently prices AI-adjacency. A protocol that mentions an agent, an "AI-native" pipeline, or an autonomous development loop gets a narrative bid. This is structurally identical to what happened with liquidity mining. The APY was never yield. It was a subsidy paid in tokens to rent TVL that left when the emissions stopped. AI-adjacency is the same instrument: a subsidy paid in narrative to rent attention that leaves when the demo stops.

And the decay curve is compressing exactly as I would expect. The first wave of AI-agent tokens listed on tier-one venues produced enormous first-day multiples. The most recent cohort is producing listing pops in the single digits to low double digits, with fast mean reversion. That is the same decay shape I watched in exchange launchpad returns, which went from triple-digit multiples to low double digits over a few cycles as the venue monetized the traffic and the marginal buyer stopped believing the scarcity story. Exchange traffic monetization decays faster than the exchange itself, because the product is the belief and belief is not a durable asset.

Useful bottom line, one line: don't trade the dip — trade the volume. In a cohort like this, the bid is in the announcement and the supply is in the follow-through. If the follow-through is a deployment timestamp, you have a trade. If the follow-through is a second announcement, you have a bag.

Let me be precise about what to measure, because "do your research" is not a strategy.

Deployment cadence versus commit cadence, as a ratio, tracked over rolling ninety-day windows. This is the single cleanest signal I have found. A protocol whose commit-to-deployment ratio is expanding is generating; a protocol whose ratio is stable is delivering. In my sample, four of eleven had ratios that expanded by more than 3x. Those four are, in my view, the highest-risk names in the cohort, independent of their market caps.

Audit recency on live contracts. Not the audit's existence. Its date, its scope, and whether the scope covers the deployed bytecode. A protocol with an audit that predates its last three deployments is operating with an unreviewed surface, and the market will typically price that surface at zero until it does not.

Governance latency. Time from proposal to execution. If that number is growing while code output grows, the protocol has a queue problem and it is the one described above.

And parameter velocity. How often do user-visible parameters change? A protocol that ships nine thousand lines and changes zero parameters has not shipped. A protocol that changes three parameters a quarter with two thousand lines has.

Contrarian: The Consensus Is Wrong in Two Directions at Once

The consensus position on this story has two versions, and I disagree with both.

Version one, the bull case: AI coding tools are transforming software production, crypto is a software industry, therefore crypto will ship faster and AI-adjacent crypto assets are structurally undervalued.

Version two, the bear case: Oracle's warning proves AI coding tools are hype, enterprise adoption is failing, and the AI infrastructure buildout is a bubble being validated by nothing.

Both are wrong, and both are wrong for the same reason: they treat delivery as a single variable. It is not. It is a chain, and the chain's throughput is set by its narrowest link. The bull case assumes all links scale with the models. The bear case assumes no link does. The truth is that one link scaled enormously, several did not move, and the system output barely changed — which is precisely what Oracle observed and precisely what my eleven-protocol sample shows.

Where I go further than the consensus, in the direction people find uncomfortable.

In a security-critical domain, more generated code can be net-negative on delivery. This is not a general statement about software. It is specific to systems where verification is adversarial and failure is irreversible. In that regime, every additional line of generated code increases the verification surface, and the verification surface grows superlinearly with interaction count. If generation outpaces verification, the marginal generated line has negative expected value, because it adds audit queue depth without adding deliverable behavior.

The corollary is the part that will annoy people: the AI coding wave will produce a measurable decline in shipped-feature velocity for any protocol that adopts it without simultaneously rebuilding its verification layer. Not a slowdown in the sense of less code. A slowdown in the sense of less product. We are watching that in the data right now, and it is being reported as a productivity boom because the code volume metric is the one that goes up.

The second contrarian point is about who captures the value. The consensus assumes the model providers and the infrastructure layer capture it. In a delivery-constrained regime, the value accrues to whatever expands the binding constraint. The binding constraint is verification capacity. So the value accrues toward software that converts unverified generation into verifiable generation — constrained deployment frameworks, formal verification integrated into CI, differential testing against forked mainnet state, and pre-committed audit primitives.

That is a much smaller market than "AI for crypto." It is also a market where the buyer has a quantifiable reason to pay: every unit of expanded verification throughput is a unit of delivery throughput, and delivery throughput is what the token price eventually reflects.

And a third point, quieter. The overhype cycle in DA layers taught me something about infrastructure narratives that do not match usage. Ninety-nine percent of rollups do not generate enough data to need a dedicated data availability layer. The infrastructure was correct, the demand was not there, and the market priced the architecture rather than the load. AI coding infrastructure is on the same trajectory. The architecture is impressive. The load — actual deliverable throughput — is not there yet. Infrastructure built for a load that does not exist is a financing structure, not a product.

I want to add one observation from outside the crypto frame, because it cuts against my own thesis and I would rather state it than have it stated at me.

There is a counterargument that the verification bottleneck is itself about to fall, because verification is a machine-checkable problem in crypto in a way that it is not in enterprise software. Smart contracts are deterministic, formally specifiable, and the tooling for machine-checked proofs exists and is improving. If an AI system can generate code and a proof simultaneously, the verification surface collapses, and the delivery constraint disappears. That is a real possibility and it is the thing I would build if I were twenty-six and starting over.

My objection is conditional, not categorical. Proof generation for general smart contract behavior is nowhere near deployed at the scale required, the specifications themselves are the hard part and they are human-bound, and the market has not paid for it because the market has not yet been burned enough times. But it is the correct direction, and if a team ships credible proof-coupled generation, my delivery-ratio thesis inverts for that team specifically. Watch for it. It is the one development that would make me rewrite this entire piece.

Takeaway

The Oracle warning is not an enterprise software story. It is the first large-scale confirmation of something the on-chain record has been showing for two quarters: generation scaled, delivery did not, and the gap is the trade.

What I am watching, in order of signal quality.

First, the commit-to-deployment ratio for every protocol in the AI-adjacency cohort, on a rolling ninety-day window. Expanding ratios are a warning, not a strength. I would rather hold a protocol with flat commits and steady parameter changes than one with a 340% commit increase and nothing verified on chain.

Second, audit recency relative to deployment recency. A gap between the two is an unmodeled surface, and unmodeled surfaces are where the drawdowns live.

Third, the emergence of constrained deployment frameworks — protocols that restrict their generators to audited primitives rather than letting them free-form compose. When one of these ships something user-visible, that is the signal that the delivery constraint has been attacked rather than narrated.

Fourth, and slowest, proof-coupled generation. Not a token. A shipped system.

And the question I keep coming back to, which I will leave with you rather than answer: if the bottleneck in software delivery was never the typing, why did an entire industry spend three years and an unquantified fraction of global capital optimizing the typing — and why is the market still paying a premium for the tools that do it?

Liquidity dries up faster than hope. The same is true of a narrative. The difference is that the narrative leaves a commit history behind, and the commit history is public, and anyone with a block explorer and a spreadsheet can read it. The people who do are going to be very lonely at the top of this cycle, and very early.

Method note for readers who want to replicate the sample.

The eleven-protocol cohort was assembled from public announcements in the two quarters prior to writing, filtered to protocols with a live mainnet deployment and a public repository mirror. Deployer attribution was done by funding-tracing from the protocol's known treasury multisig and historical deployer cluster; deployments not traceable to that cluster were excluded. Parameter changes were counted only from configuration contracts that govern live user-facing behavior, excluding admin-only setters with no economic effect. Audit recency was taken from the most recent public report relative to the most recent verified deployment, with scope limited to the deployed implementation rather than the repository head. Anyone running the same filter set on their own list should expect the ratio to be directionally similar and the absolute numbers to differ by protocol maturity — earlier-stage teams show a wider gap, and that is where the divergence between story and shipping is widest.