On Data Availability Pricing

Research
1

A topic across the data availability space right now is the discussion of pricing, DA by many is considered a commodity whose pricing should be marginal. Due to platform lock-in DA being relatively loose, pricing is a double edged sword. Too expensive, people switch; too cheap, and the protocol generates no revenues.

In this post I propose a new pricing model comprised of 3 layers:

  1. A fixed annual fee per DA account (DAA)
  2. Volume-tiered pricing per DAA
  3. Chain wide congestion multiplier

The goals are to increase protocol revenues, maintain predictability, keep high volume rollups on Celestia with affordable marginal costs and create a sustainable long term economic foundation for Celestia.

Motivation

Since Matcha, the Celestia throughput has increased drastically, however annual protocol revenue remains relatively low. Even though the revenues of the system as a whole remain low, high volume rollups could end up being priced out. For example if Bullet were to require 5mb/s they’d pay roughly $3m per year in DA fees. The current system itself cannot generate meaningful revenue without raising per byte fees drastically, luckily other DAs are priced significantly higher, as of writing Celestia blobs are priced at $0.03 per MB whereas Eth is priced at $0.06.

Specification

Data Availability Account

A DAA is a new abstraction above namespaces. In order to post data a DAA must be registered. A DAA may own multiple namespaces however:

  1. Fixed fee (F) applies per DAA
  2. Volume Tiers apply per DAA
  3. Throughput is aggregated across all namespaces under the DAA

Volume-Tiered Pricing

Each DAA receives a tier assignment based on its 30-day rolling average throughput:
Tier 30-Day Throughput Marginal Price Discount vs Base
T0 < 0.05 MB/s c₀ (full price) 0%
T1 0.05–0.5 MB/s 0.70 × c₀ 30%
T2 0.5–3 MB/s 0.45 × c₀ 55%
T3 > 3 MB/s 0.30 × c₀ 70%

*discounts and throughput are examples

Congestion Multiplier

A chain-wide multiplier applied to all DAAs based on overall DA utilization.

Let:

  • u = utilization (ratio of current throughput to max throughput)
  • M(u) = multiplier applied to all tiers

Proposed Multiplier Curve

  • u < 40%:
    • M=0.9M
  • 40% ≤ u ≤ 80%:
    • Linear growth: M(u) = 0.9 + 1.0(u−0.40)
  • u > 80%:
    • Superlinear congestion pricing:
      • M(u) = 1.3 + 2.5(u−0.80)^2

Final Fee Formula

For any blob posted by DAA i:

Fee_i=F_i+(ct(i)×M(u)×blob_size_bytes)

Where:

  • Fi​ = annual DAA lease fee
  • ct(i) = tier price for that DAA
  • M(u) = global congestion multiplier

Revenue

This section presents a sample revenue model using illustrative values:

  • Base per-byte price: c₀ = $0.012 / MB
  • Namespace fixed fee: F = $10,000 / year
  • 400 total DAAs (small + medium + large)
Segment Count Avg Throughput Tier Effective Cost/MB Annual Usage Per DAA Fee Per DAA Segment Revenue
Small 200 0.01 MB/s T0 $0.012 315 GB ~$13,800 ~$2.76M
Medium 150 0.3 MB/s T1 $0.0084 9.46 TB ~$89,000 ~$13.3M
Large 50 4 MB/s T3 $0.0036 126 TB ~$467,000 ~$23.35M

At this usage, uncongested revenue would be roughly $39.4 million, and congested revenue roughly $59.1 million. This is 3 - 5× higher than Celestia’s maximum possible revenue under the current linear pricing model and it stays compatible with high-volume rollups, who now pay less per MB than they would do today.

Currently Celestia has about between 10-20 small chains posting, 8 medium chains and around 2 large chains. So we can assume around 30 DAAs.

Segment Count Avg Throughput Tier Fee Per DAA Segment Revenue
Small 20 0.005 MB/s T0 ~$11,892 ~$237,840
Medium 8 0.05 MB/s T1 ~$23,247 ~$185,976
Large 2 0.03 MB/s T3 ~$89,464 ~$178,928

Assuming these numbers we see Celestia’s revenue go towards $602,744 annualized at current usage.

It is important to note that the fixed fee may be priced too high, numbers are hypothetical.

6 Likes
2

Hi, I very much appreciate all the hard work that must have gone into this. Great job planning all this out. I’m writing because although I love the proposed tier system and other features, I think the $10,000 per namespace is prohibitive to network growth; it’s too early to charge entry fees like this. I believe this because of the following logic:

1. Celestia’s business model depends on network effects

2. Celestia hasn’t yet built substantial, real network effects

3. Celestia will only truly achieve network effects once lazybridging goes live and many more chains join the ecosystem

With the above in mind, I believe charging $10,000 for each namespace creates a disincentive for joining the Celestia ecosystem. Charging any substantial entry amount for new projects before network effects are in place may result in harm to the project, stunting its growth. So although I do like the other aspects of the above proposal, which correctly attempts to reduce fees for massive DA consumers like Bullet, I’m thinking something like the $10,000 fee per namespace should only be implemented after lazybridging and many more projects join the ecosystem. This would ensure real value capture.

Also, the concept of network effects is a bit complicated, so I’m just leaving this link here so we avoid any disagreement due to different definitions: https://online.hbs.edu/blog/post/what-are-network-effects

Thanks for reading!

3

As mentioned in the post, numbers are hypothetical. Additionally assuming that Celestia’s business model relies on network effects is completely untrue. Network effects currently do not add any implicit value to the network as lazy briding etc are not yet a thing.

4

Hi, I think we’re having a miscommunication, your response indicates that I wasn’t understood. I’ll try to repeat in a different way:

1. If network effects are absent, the only competitive advantage for a DA layer is low cost, and a competition of low fees will eventually yield a race-to-the-bottom commodity.

2. We should all agree that we don’t want this low-fee situation. This would yield less revenues overall for the protocol (compared to a version of the protocol with network effects). And this would eventually lead to lower token price/FDV if expected protocol revenues are lower. This is why I said Celestia’s business model relies on network effects.

3. So if Celestia starts to charge the $10k fee now (or any other substantially large fee) this will inhibit growth and the accrual of network effects.

4. Therefore, Celestia should wait until lazybridging is live (I never said it was live already, I said we should wait until it is live), and many chains join the ecosystem. This way network effects accrue.

5. If Celestia is unable to accrue network effects, we’re back at step 1 and the goal is simply to charge the lowest amount among all competitors.

This is such an important discussion, please take the time to read through my logic. Thanks!

Edit: Regarding #1, I should have written “primary competitive advantage” instead of “only competitive advantage.” Of course, different alt-DA can provide variability in aspects of service, but they will primarily compete via price (if network effects are absent).

5

Amazing proposal Dean!

I want to propose a different angle. Instead of starting from current market rates and then applying discounts, we can invert the model and start from user commitment.

Many industries work this way. Hotels offer cheaper prepaid, non-refundable rates. AWS gives the best pricing to customers who reserve capacity for a year or more. The idea is simple: you get a better deal if you give up flexibility and make demand predictable for the operator.

Applied to DA, this becomes an upfront commitment model. Users select a commitment tier first, for example:

• Tier 1: 12-month upfront, non-refundable, highest effective discount

• Tier 2: 6-month upfront, pricing: T1+50%

• Tier 3: 3-month upfront, pricing: T1+75%

Here T1 is actually the most committed one. Users get the best deal only if they lock in for the full year and give up flexibility. Shorter commitments cost more because they introduce more uncertainty for validators and protocol.

This model keeps blob fees unchanged. The discount applies only to the reservation itself, not to the per-blob fee. Validators still earn fees normally as blobs land, while the system benefits from more predictable demand and the deflationary effect of unused prepaid quota expiring. I.e. burn.

It is a straightforward way to let users buy cost stability by committing upfront, instead of trying to derive discounts directly from current market rate.

6

Other industries usually do this because of rate of cancellations + the ability to do something with those deposits. As a network we don’t really run the first risk even if we do a bandwith level fee and point number 2 doesn’t really add much of a benefit to network participants eg validators. What you’re now doing is getting into the world of gas futures essentially. The question there becomes how to price the up front costs.

7

TL;DR - Difference between T1/2/3 and the upfront quota model:

T1/2/3 is a throughput-based reservation (for example MB/s floors per 30 days window). The model I am describing is a quota-based reservation (for example “1 TB for 12 months”). Blob fees still drain the quota at spot rates, so there is no lock on future throughput or future prices. It simply gives users a predictable annual ceiling. Both abstractions match different budgeting mindsets and can coexist without interfering with each other.

I agree Celestia does not have cancellation risk in the same way, but prepaid deposits still create value in another form:

  • Burn of unused prepaid quota reduces circulating supply and creates revenue at the protocol layer
  • Validators benefit more from commitment signals than from deposits themselves, since predictable deal flow is easier to plan around than purely on-demand usage
  • Reservation value naturally accrues to the protocol, similar to how cloud providers capture value when customers reserve capacity even if they do not fully use it

Agreed. Validators do not need deposits directly, but they do benefit from long-term commitment.

  • Committed usage smooths aggregate demand and reduces operational variance for node operators
  • Burn improves economics, which indirectly strengthens validator rewards
  • Operators prefer predictable base load usage even if deposits themselves are not used

I think the model avoids futures completely because nothing about future blob prices is guaranteed or fixed.

  • Discounts apply only to the reservation, not to blob usage
  • Blob fees inside the prepaid quota are always paid at spot price, so no forward price is implied

A simple example: a rollup prepays for “1TB of DA for 12 months at a 30 percent discount” and this quota drains faster or slower depending on spot fees, without predicting future DA demand

From a DevOps and FinOps perspective, Tier 3 and prepaid commitments solve different budgeting problems.

  • Tier 3 suits teams who treat DA as throughput and are comfortable with block-level fee variance
  • Prepaid commitments suit teams who plan annually and want a fixed maximum spend regardless of throughput in X day windows they do practically
  • Like cloud budgeting: on-demand for flexibility and reserved blocks for predictable runway
8

From first principles, the minimum gas cost for a blob should cover the minimum operating cost it creates plus an estimated value, which we can think of as a premium.

These costs are denominated mainly by the user in $ terms.

Let’s assume we find a good $/MB value that we are happy with as a minimum.

If we have that good minimum value per MB we should figure out a way to reduce how TIA price volatility affects this value to the up and downside.

The simple solution would be to pay fees in stablecoins, and the other solution would be to use an enshrined TIA/USD price oracle (TWAP) that adjusts the cost so the $ value remains constant.

Congestion would create price discovery for the premium, but solving that price discovery is an adjacent problem to the minimum cost.

1 Like
9

I’ve been thinking about this proposal alongside what DoubleZero just did with Edge, and I think there’s a version of this that solves more of the problems raised in this thread if we shift the framing.

Even with volume discounts and a congestion multiplier, $/MB as the base unit keeps DA in commodity territory. Celestia blobs are $0.03/MB, Ethereum is $0.06/MB, and competitive pressure only pushes those numbers down. Fibre targets 1 Tb/s. If the game is “who offers the cheapest megabyte,” we can survive that race but we’re not going to win it.

Telecoms figured this out decades ago. Nobody buys bandwidth by the megabyte anymore. You buy a service tier with guaranteed performance, and the provider manages capacity behind the scenes.

DoubleZero Edge as a reference

DoubleZero’s Edge platform does something worth looking at here. Validators connected to DoubleZero don’t pay per-packet, they’re exempt from the 5% block reward fee. Revenue comes from subscription fees paid by traders who want guaranteed low-latency data delivery. They’re not selling cheaper packets. They’re selling deterministic performance. Different unit of account entirely.

What this looks like applied to DA

Instead of fixed fee + volume discount, three service tiers. Each bundles a throughput guarantee, an inclusion SLA, and a marginal rate.

Tier Access fee Throughput guarantee Inclusion SLA Marginal rate Target user
Open Free None (best effort) None Full spot price (c₀) New rollups, testnets, experiments
Pro Monthly subscription Up to X MB/s guaranteed Priority inclusion within N blocks 0.50 × c₀ Production rollups with steady usage
Enterprise Annual commitment Reserved capacity up to Y MB/s Guaranteed inclusion, latency SLA 0.25 × c₀ High-throughput rollups (Bullet-scale)

“Open” is not free DA. Rollups still pay per-blob gas fees at spot rate for every byte, best effort inclusion at market price. That’s actually the most expensive per-MB option you can pick. The discounts kick in when you commit, because you’re giving the protocol predictable revenue in return.

The difference from the original proposal is that rollups choose their tier based on what they need going forward, rather than their trailing 30-day usage. Forward-looking instead of backward-looking.

Growth concern

I think the $10,000 per namespace is prohibitive to network growth; it’s too early to charge entry fees like this.

Agreed, and this is where the tier model helps. Open tier has no barrier to entry. Any rollup starts posting DA at spot rates today. Pro and Enterprise are opt-in upgrades, you move up when you actually need guaranteed performance, meaning you have real usage and real users. You’re paying for the service at that point, not paying for permission to exist.

More rollups posting data at the Open tier means more ecosystem activity, stronger case for lazybridging, and eventually the kind of network effects that justify premium pricing. Get them in the door first, charge for guarantees once they need them.

Commitment-based pricing fits here

Instead of starting from current market rates and then applying discounts, we can invert the model and start from user commitment.

The Enterprise tier is basically this. Annual commitment, upfront payment for a reserved capacity allocation. Unused capacity expires (burns). That smooths demand for validators and gives the protocol predictable revenue.

And it avoids the gas futures problem because the commitment is to a capacity allocation, not a future price. Blob fees within the allocation still settle at whatever the prevailing marginal rate is for the tier.

Congestion multiplier: only beyond guarantees

I’d keep the congestion multiplier from the original proposal but only apply it to usage beyond a rollup’s guaranteed allocation. Within allocation: marginal rate per tier, no multiplier. Beyond allocation: spot rate × M(u).

If a Pro rollup stays within its throughput guarantee, it pays a predictable discounted rate regardless of what’s happening chain-wide. Burst usage above the guarantee gets dynamic pricing. That separation is what makes the subscription worth paying for.

Revenue at current usage

Using the existing assumptions from the original post (20 small, 8 medium, 2 large chains):

Segment Count Tier Access fee Marginal revenue Total per DAA Segment revenue
Small 15 Open $0 ~$1,892 ~$1,892 ~$28,380
Small (upgraded) 5 Pro $2,500/mo ~$946 ~$31,446 ~$157,230
Medium 8 Pro $5,000/mo ~$6,624 ~$66,624 ~$532,992
Large 2 Enterprise $120,000/yr ~$22,366 ~$142,366 ~$284,732

Annualized that’s about ~$1,003,334. Roughly 66% higher than the $602,744 projected under the original model at current usage, and the Open tier still keeps the door open.

Implementation

Phase 1 is basically the status quo: Open tier only, everything at spot rates. Phase 2 introduces Pro with optional throughput guarantees and priority inclusion, which requires the DAA abstraction plus on-chain SLA enforcement. Phase 3 adds Enterprise with annual commitments once there are enough Pro rollups to show the demand is real. Phase 4 layers in the congestion multiplier, only beyond guaranteed allocations, only once utilization actually matters.

Open questions

How do you enforce throughput guarantees on-chain? Guaranteed inclusion within N blocks requires validator-level coordination. Might need to be baked into consensus rules or handled through a priority fee market within the tier. Not trivial.

On denomination:

If we have that good minimum value per MB we should figure out a way to reduce how TIA price volatility affects this value to the up and downside.

Subscription fees in USD (stablecoin or oracle-adjusted TIA) would give rollups the budget predictability that actually makes service tiers worth buying.

And what happens if guaranteed capacity goes underutilized chain-wide? If Pro/Enterprise rollups reserve more throughput than the chain uses, validators earn less in congestion fees. Subscription fees need to cover that gap. The guaranteed allocations become a floor on protocol revenue, which is probably fine, that’s the whole point of selling commitments.

TL;DR: price DA like infrastructure-as-a-service with performance tiers and guarantees instead of by the megabyte with discounts. DoubleZero Edge is already doing a version of this for network infrastructure. Per-byte fees still exist but they’re a metering mechanism inside a tier, not the main revenue source.

4 Likes