To No Avail

A settlement layer can add data-publication capacity while a client still faces a choice about the arrangement through which its data becomes available and recognizable to settlement. Ethereum’s PeerDAS specification expands availability checking through sampling, and its blob schedule records additional capacity. Avail’s documented Nitro integration adds a different path: publication on Avail, a reference submitted to the settlement contract, a bridge commitment and payload recovery. Two separately resolved Nitro branch snapshots carry proof material while the inspected bridge entry point postpones Merkle-inclusion verification. Four local EVM tests on each snapshot distinguish that source check from the guide’s verified-inclusion design without identifying a deployed consuming rollup. The comparison then asks which publication, verification, settlement and retrieval requirements a client would have to replace. It establishes neither a durable external market nor its absorption by Ethereum; actual client substitution remains untested.

Avail’s current Nitro integration guide describes a sequencer posting batches to Avail, then submitting a reference to a settlement-layer inbox. In the guide’s design, the settlement path is intended to verify an inclusion proof against a bridged data-root commitment. An execution component later recovers the batch payload from Avail and replays the state transition (Avail Documentation n.d.-a). Increasing Ethereum’s blob capacity does not, by itself, replace those connections. A client considering migration must decide what its settlement contract will accept and how it will obtain the data it needs.

Native expansion can change the cost or scarcity of publication capacity. Its effect on an external provider depends on which parts of a client’s arrangement can be substituted, and at what cost. Verification, settlement recognition and retrieval can require changes even when both services publish bytes.

The guide describes inclusion verification that the inspected bridge entry point does not enforce in either integration snapshot. Comparing that path with Ethereum-native publication identifies what a client would have to replace. It leaves actual switching untested and makes no estimate of a provider’s market share, revenue, subsidy dependence or durable value.

EIP-4844 introduced blob-carrying transactions with commitments and a separate fee market. The EVM cannot directly read the full blob contents; it can access the associated versioned hashes. Availability checking and a contract’s use of a commitment are related parts of the system rather than a single operation (Buterin et al. 2022, “Specification” and “Rationale”).

PeerDAS changes how nodes check that blob data is available. EIP-7594 specifies an erasure-coded extension, cells arranged into columns, custody duties, gossip and sampling. A node obtains a subset of the data while checking against the relevant commitments. Its security argument concerns the probability that withholding can evade the sampling population under the stated assumptions (Ryan et al. 2024, “Specification” and “Security Considerations”). The mechanism supports a larger data-publication resource by distributing verification work.

The October mainnet configuration retains the Fulu activation epoch and two subsequent blob-schedule entries. The corresponding BPO records specify target/maxima of 10/15 and 14/21. EIP-8138 remains a draft with activation and parameter placeholders in the retrieved text (Ethereum Consensus Specifications n.d.; Ranjan 2026a, 2026b; Ranjan and Busa 2026). These are specifications and configuration entries. This refresh did not inventory deployed client binaries or independently replay fork activation.

More configured capacity changes the resource envelope. It does not alone determine the price a client pays over time, the assurance its settlement accepts or the cost of changing its software. Those outcomes depend on demand, fee dynamics, client configuration and the surrounding integration. A capacity observation can enter a substitution explanation without being that explanation’s conclusion.

This distinction also leaves room for successful native substitution. If a client’s binding problem is access to Ethereum-recognized publication capacity and the remaining arrangements already support the native path, additional capacity could make an external service less attractive. The relevant evidence would be the client’s options, costs and decisions. An argument that every external provider must vanish would require a defined population and evidence across the different arrangements it serves.

Avail’s pinned grid and light-client sources supply a different construction. The reviewed grid path builds commitments and proof material; the light-client path samples positions, checks proof material and records a confidence result. Those are implementation observations at named July revisions (Avail Core 2026; Avail Light 2026). They support discussion of the mechanism without certifying every current deployment or an entire application’s security.

The current VectorX guide then describes how an Avail data-root commitment reaches an EVM-compatible chain through a zero-knowledge proof bridge. A consuming contract can verify an inclusion proof against the committed root (Avail Documentation n.d.-b). The proof’s place in the system matters. Inclusion in a committed structure, the availability of its underlying data and the consuming system’s acceptance of that structure are connected propositions with different premises. Merely calling all three “data availability” would hide those premises.

The Nitro guide makes the connection visible in its batch path: the posted data, reference, bridge commitment, inbox and payload recovery each do particular work. It describes an integration design, not a census of deployed clients or paid use. The code-revision links named in the retrieved guide did not resolve through the attempted GitHub commit lookups. No verified deployment or source/build correspondence is inferred from the guide alone.

The guide’s verified-inclusion account needs an implementation-stage qualification. Two separately resolved Nitro integration branch snapshots contain a Avail bridge entry point that explicitly postpones Merkle-proof verification. For a version-two pointer it compares the declared payload hash with the supplied leaf, then returns false; its inbox caller raises an attestation error on true. Four local EVM tests on each snapshot confirm that unrelated roots pass this particular check while a mismatched leaf reverts. Other inbox guards still govern batch acceptance (Avail Project 2026a).

The node-side function named ValidateBlobProof makes the same distinction visible: it checks leaf equality and leaves inclusion verification to be added (Avail Project 2026b). This stage carries proof material without enforcing the guide’s entire root-verification path. Neither snapshot identifies a deployed rollup or the operation of another VectorX consumer. Publication capacity, a supplied proof and enforced settlement recognition can advance at different stages of an integration.

A move to Ethereum-native blobs would require examining how the consuming system handles the alternative path. The analyst must identify what accepts a data commitment, what verifies the relevant evidence and what retrieves the batch for execution or challenge. A system may already support both options; another may need software, configuration or contractual changes. The comparison is empirical and implementation-specific. Neither frictionless migration nor permanent lock-in follows from the existence of a bridge.

The broader external category also contains different constructions. The July review distinguishes Avail’s commitment and sampling path, Celestia’s extended-square and namespaced-Merkle path, and EigenDA’s dispersal, operator and retrieval arrangement (Avail Core 2026; Celestia Node Contributors 2026; EigenDA Contributors 2026). These historical source distinctions remain useful. They prevent the category’s shared vocabulary from substituting for a comparison of assurances, and they provide no ranking of the systems' actual performance or economics.

Avail’s Cosmos integration guide describes another arrangement. A relayer posts chain data, validators consult availability information through a light client, and vote extensions participate in accepting the result. The guide identifies configuration and asynchronous coordination duties (Avail Documentation n.d.-c). It describes a design intended for a Cosmos chain, without establishing how many chains use it or what they pay.

That example limits the population to which an Ethereum-capacity argument can apply. A client outside Ethereum settlement may have a different reason for choosing a publication and verification service. It may still compare Ethereum, and native expansion may still affect prices or available designs. The analyst must show that connection. The existence of such a documented design does not prove durable non-Ethereum demand, while its omission would make a universal absorption claim incomplete.

A useful study consequently begins with clients and their tasks. For an Ethereum-settled system, the relevant comparison might concern two ways to make a batch acceptable to its settlement and challenge machinery. For a sovereign chain, the comparison might concern how its validators establish availability. Different tasks can use related cryptography without forming one homogeneous market.

The former Avail RPC endpoint returned an authorization error. Two alternative endpoints listed in the current network documentation reported different native versions: OnFinality returned 2.4.0-2cbdea2df97, while PublicNode returned 2.3.4-82a9b31ea81. Both returned runtime specification version 56 and the same header and finalized-head fields. The release tag v2.4.0.0 resolves to the commit matching that native identifier, while its runtime source declares specification version 55 (Avail Queries 2026; Avail Node 2026).

The node’s advertised native version and its returned runtime version are therefore separate observations. They cannot supply an attestation that the current runtime equals the source bundled with that release. Reconstructing the difference would require the active runtime code and its relevant deployment or upgrade history. The responses do establish that the July node/runtime observation cannot silently serve as a current software description. They do not establish that all nodes use one executable or explain why the identifiers differ.

Use requires another kind of observation. In the preserved July L2BEAT record, Rooch Network leads Avail’s all-tracked-traffic population at 7.27 percent of bytes; Lens leads its scaling-project-only population at 94.16 percent. Both the population and its leading attributed poster differ. Neither population identifies paid commercial demand, independent clients or subsidy status (L2BEAT 2026, preserved July measurement, Avail entry).

The old throughput URL now redirects to an Ethereum blobs page. That response does not reproduce the earlier cross-provider population, so the refresh supplies no new all-provider utilization series. The historical example remains a bounded observation from a normalized record, not a current market statistic. A second dashboard observation, even if available, would not by itself identify client migration or a causal effect of a capacity change.

Posted bytes can reflect testing, internal activity, production use or subsidized use. Identifying the relevant demand requires attribution and payment records. Configured capacity is a denominator for an engineering ratio; it does not measure saleable capacity, realized revenue or willingness to pay.

The architectural comparison yields a testable question about a specified client: does native expansion change an option that was binding on its choice? An informative study would identify the client’s service requirements, feasible alternatives and decision period, then observe a change in posting, pricing, configuration or integration. A complete causal explanation must connect the changed option to the decision.

Several explanations can produce the same aggregate movement. A client may reduce external posting after moving to native blobs, after losing users, after changing batching or compression, or after a subsidy ends. A provider may post more bytes because of test traffic while commercial revenue falls. Those possibilities require different measurements and make aggregate byte growth an inadequate substitute for a client history.

Comparable prices should include effective posted bytes, token conversion, refunds, incentives and the relevant period. Integration costs should identify which software, verification, bridge and operating duties change. Security and recovery assumptions should be stated for the actual alternatives, without treating a name or a shared primitive as equivalence. Client identity and affiliation require attributable information rather than inference from an application ID.

A longitudinal panel with a comparison that addresses competing explanations could test displacement. Documentary decision histories and client interviews could explain adaptation and switching. A retrospective design can be informative when selection, definitions and analysis choices are disclosed; prospective commitments can strengthen an experiment or planned causal test. No single method is a prerequisite for describing a code path, and describing that path does not complete a demand study.

The two Nitro branch snapshots support an implementation-stage comparison, with four local EVM cases on each snapshot using Solidity 0.8.26. They do not recover the missing guide references or identify a deployed build. A deployment claim still requires the consuming rollup’s addresses, active implementations, configuration and a joined publication, proof, settlement and retrieval trace.

The earlier paper inferred that the settlement layer’s expansion would absorb the external category. It treated related cryptographic ingredients as interchangeable services and assumed that a native alternative would have negligible adoption friction. Those inferences outran the observations. The substitution argument is withdrawn as a finding, along with the category forecast, numerical cost-compression and cost-advantage claims, inferred affiliation/subsidy and roadmap-as-doubt claims.

The architectural comparison identifies conditions for substitution. Market displacement and current network-wide binary identity require their own evidence.

Native data-availability expansion changes an infrastructure option. Its effect on an external provider depends on the clients and arrangements that option can replace. The Avail integration designs show why the comparison includes settlement recognition, verification and retrieval alongside publication capacity. Following those connections would make a category-durability claim answerable to actual client choices, rather than treating an expanding protocol schedule as a market outcome.