The underwriting question

I set out to underwrite a paired position in AR and AO. The thesis was that AO turns Arweave's permanent message history into live computation, and that growing AO activity would therefore show up as measurable storage demand for Arweave.

I could not substantiate it. Not because the thesis is wrong, but because the metrics everyone cites — messages, processes, protocol fees — do not measure what they are assumed to measure. This is a report on why, and on what would have to be measured instead.

Three claims I made early in the work did not survive contact with the data. I retract them below.

One issuer, not a thousand applications

On 25 July, the network counters recorded 2,305 new processes against 679 messages in the same rolling window. The obvious reading is mass deployment followed by abandonment. I queried the block range directly to check.

Two case-sensitive tag schemas over blocks 1,965,241–1,965,907 returned 7,054 unique IDs with no overlap between them and no unresolved pagination. Of those, 2,152 were process creations.

FIGURE 01

The spike has one author

DENOMINATOR / 2,152 PROCESSES · SEPARATE CLASSIFICATIONS
name-token@1.02,078 / 2,152 96.56%
One creating owner2,084 / 2,152 96.84%
2,078 of 2,152 processes ran name-token@1.0 (96.56%); 2,084 were created by a single owner address (96.84%). These are separate classifications of the same sample, not additive groups. Source: author-collected arweave.net GraphQL queries in the original study.

These are permaweb name tokens, not applications. The Initial-Owner field spans 416 distinct addresses, but the creating owner is one. Read together with Arweave's published consolidation of legacy naming systems, a bulk issuance or migration event is the more plausible explanation than a thousand product launches.

Low message counts do not indicate a dead process here; they indicate that message count is the wrong instrument for this object class.

A name token can be resolved thousands of times without ever producing a state-changing message. Process creation is not an application count, and the ratio of messages to new processes mixes populations that should not be divided by one another.

Message activity is not ecosystem breadth

The same record-level window contained 1,147 messages and 43 distinct recipients. There were 154 messages with no recipient tag.

FIGURE 02

One process received 58.2% of messages

DENOMINATOR / 1,147 MESSAGES · INCLUDING UNTAGGED
Recipient #1667 / 1,147 58.2%
Recipient #2108 / 1,147 9.4%
Recipient #334 / 1,147 3.0%
Recipient #429 / 1,147 2.5%
Recipient #525 / 1,147 2.2%
Recipient #621 / 1,147 1.8%
Other attributed recipients109 / 1,147 9.5%
No recipient tag154 / 1,147 13.4%
The top three recipients accounted for 70.5% of all 1,147 messages. The denominator includes the 154 untagged messages; attributed groups total 993. Dominant actions — PlaceDecorations, Move, WaterMultiple and PlantSeeds — were consistent with a game-like application, not evidence of diversified demand. Source: the original study's record-level queries.

This does not mean the activity is fake. It means that, in this window, aggregate message counts describe the behaviour of one or two applications and cannot be read as a measure of ecosystem breadth.

The fee lives in the bundle

The economic link from AO to Arweave is the one that matters for a paired position, and it is the hardest to trace. AO DataItems are written to Arweave inside ANS-104 bundles. The individual item carries no fee; the parent bundle transaction pays the L1 cost.

I downloaded one parent bundle, parsed its header, and reconciled every child against the index.

FIGURE 03

7,092 serialized bytes. Six bytes of body data.

ONE PARENT BUNDLE / 7,092 SERIALIZED BYTES
One shared header and five DataItems
  • Shared header352 B
  • DataItem 1ao.N.11,250 B
  • DataItem 2ao.TN.11,156 B
  • DataItem 3ao.N.11,545 B
  • DataItem 4ao.N.11,244 B
  • DataItem 5ao.N.11,545 B
Combined body data
6 bytes
Parent L1 fee · one sample
0.003450644064 AR
One bundle, five DataItems: three Messages and two Assignments, comprising four ao.N.1 items and one ao.TN.1 item. 7,092 = 352 + 1,250 + 1,156 + 1,545 + 1,244 + 1,545. All five child IDs matched the index and their parent links. The parent fee is the single-sample L1 cost, not customer revenue. Source: original study, Figure 3; arweave.net/raw and GraphQL.

First, fee attribution is technically possible. Allocating the parent fee by serialized bytes is a defensible convention. But it is a convention, not a protocol field: it distributes the shared 352-byte header proportionally, it is not a marginal cost, and it cannot be multiplied across the network from one conveniently chosen bundle.

Second, and more important, the combined body data across all five items is six bytes. Almost the entire 7,092 bytes is signatures, tags and framing. A model estimating AO's storage footprint from payload size would understate this sample by orders of magnitude.

The L1 fee payer is a known address. Whether the end customer reimbursed it is not known. ANS-104 explicitly permits a third party to pay for a DataItem it did not sign, and the AO bundler documentation cited in the original study describes a subsidy path.

Both of these can be true at once: real AR cost was incurred on L1, and no end customer paid for it.

A subsidy does not erase the transaction, but it changes the forecast for how durable that demand is.

The reconciliation that failed

I could not make the aggregate counters agree with the record-level queries, and I am reporting the gap rather than resolving it by assumption.

Same block range, different counts
MetricRecord-level queryCounter incrementGap
Messages1,147677+470
Processes2,1522,305−153

The 677 figure is the counter increment used in this reconciliation. The earlier 679 figure is the rolling-window counter reading reported in the process-spike section; the two observations are retained as reported in the original paper.

Both queries terminated with hasNextPage = false and no duplicate IDs. Completed pagination is not the same as reconciled data. Candidate explanations — counter definitions, index coverage, retroactive updates, tag mapping, or the documented possibility that DataItems change block-height association on bundler retry — were not narrowed to one.

This is a control that did not pass. Until the denominator is understood, no statistic resting on it should be published as a network-wide rate.

What I retract, and what remains unmeasured

  • The 1.6 billion legacy versus 171,743 mainnet message split cannot be used as an adoption argument. The token integration guide cited in the study uses MODE: 'legacy', and a recent sample contained an ao.TN.1 transfer addressed to the AO token process itself. Legacy is a message format, not a verdict on economic value.
  • The process spike is not evidence of abandonment.
  • A bundle's L1 fee is not proof of customer revenue.
The measurement boundary
MetricStatus after this study
Process creation, classified by device and ownerMeasured, within a defined index scope
Serialized bytes and parent-bundle feeMeasured on one sample
Active processes, 30–90 day retentionNot publishable — cohorts under-aged, execution paths incomplete
Fee-paying end customersNot measurable from the public data available to this study
AO service revenue, sustainable payment flowNot demonstrated
Valuation of AR or AONo basis from this work

I sampled twenty processes to test whether retention could be tracked, selected by hashing IDs before querying so the sample could not be chosen on outcome. The queries completed. I did not publish a retention rate, because a rate computed over an unreconciled denominator with incomplete execution coverage would be a number with no meaning.

Why I still hold both

None of this makes AR or AO uninvestable. It makes the paired thesis unmeasurable with the public data available to this study, which is a different statement.

My position rests on an architectural bet, not on the metrics above, and I would rather say so plainly than dress it in numbers that do not support it. The bet is that software with long-lived state needs a canonical history that outlives the operator who created it — that a process should be able to survive its front end, its company and its compute provider. Arweave stores that history; AO interprets it into live state. If that pairing matters, it will eventually show up as payments. At the study's cut-off, that link had not been demonstrated.

What would change my mind

  • A reconciled denominator. Counter definitions and record-level queries agreeing over a bounded range. Without it, every rate built on top is unverifiable.
  • One traceable payment chain. Customer → successful settlement → provider → L1 cost or tokens encumbered. One chain, fully traced, is worth more than another million rows from the same filter.
  • Retention measured on aged cohorts. Successful fee-bearing execution in a specified age window, with automation and configuration traffic separated out.
  • Evidence on who funds the bundler. If AO's storage footprint is subsidised, the demand is real but its durability is not established.

If those four resolve favourably, the paired thesis becomes underwritable. If the payment chain cannot be traced at all, the honest conclusion is that AO may succeed as software without materially repricing AR — and I would rather find that out from data than from price.

Method, scope and limits

Research cut-off: 15 September 2026 UTC. The aggregate snapshot was generated on 14 September at 00:00:21 UTC, at height 2,000,384, with 59 historical observations from 17 July. The 30 August observation was missing; the series is not 59 contiguous UTC days.

The record-level window covered blocks 1,965,241–1,965,907 inclusive, using two tag schemas and 7,054 unique IDs, with complete pagination. The bundle sample was parent tTDAMI7GjfmpQs8Ma-aEZBwyMxD4mpRBdIsareOJsOU at height 2,001,020. No wallet was connected, no transaction signed, no payment made, and the project team was not contacted.

  • Rolling counter fields use a 720-block window, not a UTC day, and must not be summed as disjoint days. The final snapshot's window covered 95,152 seconds.
  • Counter changes are provider-reported, not a reconciled chain census. Query completeness is completeness within the index at retrieval time, not proof that all protocol activity is indexed.
  • Fee allocation by serialized bytes is an illustrative convention. DataItem signatures, block proofs and snapshot commitments were not independently verified.
  • An earlier interrupted bulk download — 87,646 rows, 87,599 unique IDs, 58 of 164 planned files — was retained as audit evidence and was not used for any statistic here.
  • The original paper records preserved queries, raw responses, retrieval timestamps, calculations and SHA-256 checksums. Checksums detect post-packaging modification; they do not prove the indexer or the chain. The raw evidence archive is not attached to this web edition.

Source materials used in the original study include Arweave GraphQL and raw-bundle endpoints, the AO network metrics process snapshot, the ANS-104 specification, AO token mainnet integration and bundler/indexer FAQs, and AO posts on Permaweb Names, Open Service Markets, NASA, Decentralizing the Financial Layer and Bazar. The links below point to public protocol references; the empirical counts above remain the author's findings from the bounded study.