Celestia’s long-term success depends on preserving inexpensive, permissionless data availability while creating a stronger economic relationship between network usage and TIA. This proposal package introduces optional premium services, such as reserved capacity, service guarantees, and bonded data infrastructure, that require TIA commitments without raising barriers for ordinary users. The goal is to improve validator sustainability, reduce long-term reliance on inflation, and ensure that growth in Celestia’s economic importance is reflected in the security and value of the network itself.

Celestia Sustainable Blob Economy Governance Package

Executive summary

This package proposes a staged redesign of Celestia’s network economics around five principles:

1. Permissionless blobspace should remain inexpensive.

2. Higher-value guarantees should require TIA commitments.

3. Network fees should create direct value accrual for TIA.

4. Revenue should progressively replace inflation as the source of validator compensation.

5. Community funds should prioritize durable integrations and infrastructure rather than temporary subsidized activity.

At present, TIA is used to pay for blobspace, secure Celestia through proof-of-stake, participate in governance, and optionally bootstrap rollup economies. Celestia currently uses a standard gas-price-prioritized mempool without a protocol-enforced EIP-1559-style minimum fee.

This package does not attempt to make ordinary data expensive. It introduces additional economic demand through reserved capacity, refundable TIA bonds, fee burning, and bonded services.

---

Proposal 1: Sustainable Blob Economy Development Program

Proposal type

• Forum RFC establishing the program’s objectives

• Followed by an on-chain community-pool spend

• No consensus change in this proposal

Title

Fund the Celestia Sustainable Blob Economy Development and Audit Program

Abstract

This proposal funds the research, economic modeling, protocol development, testing, and independent security review required to implement:

1. A protocol-enforced blob base fee

2. Partial fee burning

3. Reserved blob-capacity contracts backed by TIA

4. A TIA-bonded data-services framework

5. A revenue-responsive validator security budget

The program would be conducted publicly, with milestone-based funding and all deliverables released under open-source licenses.

Motivation

Celestia is designed to make data availability abundant and inexpensive. This is valuable to rollups but creates a tension between network adoption and token-value capture. Extremely inexpensive data can support substantial technical activity without producing proportionate fee demand for TIA.

The objective is not to raise the cost of ordinary blobspace indiscriminately. It is to create premium, economically valuable services that require persistent TIA commitments while preserving a low-cost permissionless tier.

Celestia’s community pool currently receives 2% of block rewards and can fund ecosystem initiatives through governance.

Scope of work

The funded team must deliver:

Workstream A: Economic simulation

Models must evaluate:

• Blob-demand growth under multiple adoption scenarios

• Fee revenue under low, moderate, and high utilization

• Effects of different fee-burn percentages

• TIA locked under capacity-reservation scenarios

• Validator revenue under different issuance schedules

• Bonding-ratio sensitivity to reduced staking issuance

• Effects on small versus large blob submitters

• Potential customer migration to competing DA systems

• Manipulation and denial-of-service scenarios

All models and source data must be publicly reproducible.

Workstream B: Protocol specifications

The team must prepare separate CIPs for:

• Blob base fee and fee distribution

• Capacity reservations

• Bonded data services

• Revenue-responsive issuance

Each CIP must include implementation details, test cases, migration behavior, security considerations, and proposed governance parameters.

Workstream C: Reference implementations

Reference implementations must be developed for:

• celestia-app

• Relevant Celestia node interfaces

• Fee-estimation tools

• Rollup submission clients

• Capacity-account management

• Public dashboards and analytics

Workstream D: Testing and audits

The program must include:

• Unit and integration testing

• Economic attack simulation

• Mocha testnet deployment

• At least two independent security reviews

• Public bug bounty

• Load testing at different block-utilization levels

• Rollback and emergency-disable testing

Budget

Authorize a maximum budget equivalent to $1.5 million, paid in TIA through a publicly disclosed milestone escrow.

Suggested allocation:

• 15%: research and economic simulation

• 40%: protocol engineering

• 15%: rollup integrations and developer tooling

• 20%: audits and bug bounty

• 10%: program administration and contingency

The final proposal must specify:

• Exact TIA amount

• Recipient multisignature address

• Multisignature members

• Conversion methodology

• Payment schedule

• Return address for unused funds

Disbursement

Funding should be released in four tranches:

1. 10% at initiation

2. 25% after publication of specifications and models

3. 40% after functioning Mocha implementations

4. 25% after audits, remediation, and final reports

A three-of-five or stronger publicly identified multisignature should control the funds. No single contractor should unilaterally control the escrow.

Reporting requirements

The program must publish monthly:

• Funds spent

• Engineering progress

• Simulation results

• Open technical risks

• Testnet metrics

• Changes to scope

• Contractor and vendor payments

Success conditions

This proposal is complete when:

• All four implementation CIPs have been published

• Reference implementations operate on Mocha

• At least three independent rollup teams have tested capacity reservations

• Two independent audits have been completed

• Economic models and dashboards are public

• Final activation parameters have been recommended

Vote interpretation

A “Yes” vote supports funding design and implementation work. It does not automatically activate any new economic mechanism on Mainnet Beta.

---

Proposal 2: Protocol Blob Base Fee and Fee Burn

Proposal type

Standards Track Core CIP requiring a coordinated network upgrade.

Title

Introduce a Protocol-Enforced Blob Base Fee and TIA Fee Burn

Abstract

This proposal introduces a protocol-enforced minimum base fee for PayForBlobs transactions. The fee would adjust according to blobspace utilization and would be divided among burning, validators, and the community pool.

Users could continue to pay priority fees for faster inclusion. Priority fees would be paid entirely to validators.

Motivation

Celestia currently relies on locally configured validator fee thresholds and a standard gas-price-prioritized mempool. There is no protocol-enforced minimum fee equivalent to Ethereum’s EIP-1559 mechanism.

The proposed base fee would:

• Prevent blobspace from being persistently priced below a protocol-defined minimum

• Allow fees to respond predictably to utilization

• Create direct TIA value accrual through burning

• Provide a growing non-inflationary source of validator compensation

• Improve fee estimation for rollup operators

Specification

1. Separate blob base fee

Every MsgPayForBlobs transaction must pay:

• A protocol blob base fee determined by blob size

• Any ordinary execution cost

• An optional priority fee

The blob base fee should be calculated according to the number of shares consumed rather than transaction count.

2. Utilization target

The base fee should target 50% of effective blob capacity.

This is a utilization target, not a hard capacity limitation. Blob usage above 50% remains permitted, but causes the base fee to rise.

3. Adjustment mechanism

The base fee should adjust according to an exponential or bounded proportional controller.

Recommended initial constraints:

• Maximum upward adjustment per block: 6.25%

• Maximum downward adjustment per block: 6.25%

• Minimum base-fee floor: determined after Mocha testing

• Utilization smoothing: 120-block exponential moving average

• Fee calculation based only on blobspace consumption

The smoothing period is intended to reduce sharp fee oscillations caused by individual large submissions.

4. Fee distribution

Recommended initial distribution of the blob base fee:

• 50% permanently burned

• 40% paid to validators

• 10% deposited into the community pool

Recommended distribution of priority fees:

• 100% paid to validators

Governance may later modify the distribution percentages within software-defined safety ranges.

5. Small-submitter protection

To avoid disproportionately affecting experimental and low-volume users:

• The first 64 KiB submitted by an account within a rolling period may receive a limited fee credit.

• Credits must be nontransferable.

• Credits must not permit unlimited account-splitting.

• Total credits must be capped at no more than 1% of target network capacity.

• The community pool may fund the credits, but burned fees must not be reissued.

This feature may be omitted if testing shows that it creates excessive Sybil risk.

6. Emergency control

The upgrade should include a narrowly scoped emergency mechanism permitting validators to freeze base-fee adjustments while preserving the last valid fee.

The emergency mechanism must not permit arbitrary fee confiscation or redistribution.

Initial activation conditions

Mainnet activation should occur only after:

• At least 60 days of continuous Mocha operation

• Successful load testing above 75% utilization

• Two independent audits

• No unresolved critical vulnerabilities

• Public confirmation that major submission clients support the fee estimator

Security considerations

Potential risks include:

• Fee manipulation through artificial blob submission

• Oscillating utilization

• Excessively rapid fee increases

• Validator attempts to circumvent fee rules

• Spam designed to increase competitors’ costs

• Disproportionate impact on small developers

The protocol must calculate and enforce the base fee deterministically so validators cannot selectively waive it.

Evaluation metrics

Governance should monitor:

• Effective price per MiB

• Average and peak utilization

• Percentage of blocks above target utilization

• TIA burned

• Validator fee income

• Community-pool fee income

• Number and concentration of blob submitters

• Failed or delayed PFB submissions

Vote interpretation

A “Yes” through coordinated upgrade adoption supports implementing the fee mechanism. Final numerical activation values should be published before the upgrade is scheduled.

---

Proposal 3: Reserved Blob Capacity Backed by TIA

Proposal type

Standards Track Core CIP requiring a coordinated network upgrade.

Title

Introduce TIA-Bonded Blob Capacity Reservations

Abstract

This proposal creates an optional system through which rollups and other recurring users may reserve predictable blob-submission capacity by:

1. Locking a refundable TIA bond

2. Prepaying a recurring reservation fee in TIA

3. Committing to a fixed reservation term

The permissionless open market remains available without a bond or reservation.

Motivation

Large rollups generally value predictability, guaranteed access, and operational certainty. A system that charges them only the same minimal spot fee as occasional users does not capture the value of those guarantees.

Capacity reservations create persistent TIA demand without making basic blobspace expensive.

Specification

1. Open-access tier

The existing permissionless submission system remains available.

Open-access users:

• Do not lock TIA

• Pay the prevailing base fee and optional priority fee

• Receive no guaranteed quota

• Continue to compete for ordinary inclusion

2. Reservation terms

Initial supported terms:

• 30 days

• 90 days

• 180 days

• 365 days

Reservations may be denominated as:

• Maximum bytes per block

• Maximum bytes per rolling epoch

• Percentage of target blob capacity

3. TIA bond

Every reservation requires a refundable TIA bond.

The bond should be calculated according to:

• Reserved capacity

• Reservation duration

• Historical base fees

• Reservation concentration

• Payment risk

The bond must be large enough to create meaningful TIA commitment and cover unpaid contractual obligations, but it should not function as a punitive entrance fee.

The initial formula should be:

Required bond = greater of 90 days of projected reservation fees or the governance-defined minimum bond for the capacity tier.

4. Reservation fee

Reservation holders pay a nonrefundable recurring fee in TIA whether or not all reserved capacity is used.

Recommended discounts relative to purchasing comparable expected capacity at spot rates:

• 30 days: no discount

• 90 days: up to 5%

• 180 days: up to 10%

• 365 days: up to 15%

Discounts must be calculated using a trailing utilization and base-fee reference rather than a single market observation.

5. Fee distribution

Capacity-reservation fees should be distributed:

• 50% burned

• 40% to validators

• 10% to the community pool

Any bond forfeited because of unpaid obligations should follow the same distribution.

Refunded principal is not treated as protocol revenue.

6. Reserved inclusion lane

A reservation account may submit authenticated blob transactions into a reserved lane.

The protocol must prioritize these transactions up to the account’s quota when:

• Transactions are submitted before the block-construction cutoff

• The account is current on payments

• The transaction complies with protocol limits

Reserved capacity not used by the cutoff must automatically return to the open-access pool. Capacity should never remain empty solely because a reservation holder did not submit data.

7. Anti-concentration limits

During the pilot:

• Total reservations may not exceed 20% of target blob capacity

• A single entity may not reserve more than 5%

• Affiliated accounts must be aggregated

• Governance may reduce reservation limits if concentration becomes excessive

After a successful 180-day pilot, total reserved capacity may increase to 35%, subject to a separate parameter proposal.

8. Transferability

Reservations should not initially be transferable.

Allowing secondary trading before the system has matured could encourage capacity speculation and hoarding. Transferability may be reconsidered after one year of operating history.

9. Settlement and withdrawal

At expiration:

• Unpaid fees are deducted from the bond

• Any remaining bond enters a 21-day settlement period

• The remaining principal is then returned

• Fraudulent or duplicated claims may delay release through a predefined dispute process

Pilot requirements

The pilot must include at least:

• Three independent rollup operators

• One high-throughput and one low-throughput customer

• Public utilization dashboards

• Published uptime and inclusion performance

• Comparison with equivalent open-market costs

• No exclusive commercial agreements

Success criteria

The pilot is successful if:

• Reserved transactions receive their specified inclusion priority

• Unused capacity reliably returns to the open market

• Open-access users do not experience material artificial exclusion

• At least 75% of pilot customers renew

• The system produces measurable TIA locking without materially reducing blob use

Vote interpretation

A “Yes” supports deploying the reservation module with the stated pilot limitations. It does not authorize unlimited reservations or removal of the open-access tier.

---

Proposal 4: TIA-Bonded Data Services Network

Proposal type

• Community-pool development proposal

• Followed by a Standards Track CIP for any required base-layer interfaces

• Service execution should occur outside the Celestia consensus state machine wherever practical

Title

Create a TIA-Bonded Marketplace for Historical Data and Interoperability Services

Abstract

This proposal funds and establishes a service marketplace where operators post TIA bonds and receive TIA payments for providing objectively measurable services related to Celestia.

The initial service categories would be:

1. Historical blob storage and retrieval

2. Namespace-specific archival services

3. Blobstream relaying and attestation delivery

4. Proof delivery and availability monitoring

Celestia distinguishes real-time data availability from long-term historical data storage. Historical storage can therefore support a distinct service market rather than being treated as an unlimited obligation of consensus nodes.

Motivation

Celestia’s economic system should capture value from more than initial data publication. Rollups may also require:

• Long-term retrieval

• Redundant archival providers

• Relaying of attestations

• Monitoring

• Proof delivery

• Service-level guarantees

These services can create recurring TIA-denominated demand and bonded collateral without adding unnecessary execution complexity to Celestia’s base layer.

Specification

1. Minimal base-layer footprint

The Celestia base layer should provide only the interfaces necessary for:

• Identifying namespaces and data commitments

• Verifying relevant proofs

• Escrowing or identifying TIA bonds

• Receiving finalized slashing or settlement messages

Service agreements, indexing, customer interfaces, and complex dispute processing should operate on a Celestia-secured rollup or another auditable execution environment.

2. Provider bonds

Every provider must lock TIA according to:

• Contract value

• Service duration

• Data volume

• Number of customers

• Required availability level

A provider’s total active obligations may not exceed a governance-defined multiple of its bond.

Recommended initial collateralization:

• Minimum bond: 150% of outstanding service payments

• Maximum obligations: five times posted bond

• Withdrawal delay: 30 days after final service obligation

3. Customer payments

Customers must pay service fees in TIA or through a mechanism that automatically acquires TIA at settlement.

Direct stablecoin payments that bypass TIA demand should not qualify as canonical protocol-supported contracts.

4. Service proofs

Contracts must use objective evidence wherever possible, including:

• Challenge-response retrieval proofs

• Signed delivery receipts

• Timestamped proof submissions

• Multiple independent monitors

• Data-commitment verification

• Quorum-confirmed service failures

Subjective governance adjudication should be used only when objective verification is impossible.

5. Slashing

A provider may be penalized for:

• Failure to return contracted data

• Invalid proof submission

• Equivocation

• Falsified service attestations

• Persistent failure to meet contracted availability

• Refusal to complete paid relay obligations

Recommended penalty distribution:

• 50% to affected customers

• 25% burned

• 15% to successful challengers

• 10% to the community pool

Penalties should be capped according to the severity and economic value of the failure.

6. Initial service scope

The initial deployment should support only:

• Historical blob storage

• Namespace-specific retrieval

• Blobstream relay monitoring

Cross-rollup sequencing and generalized messaging should not be added until the simpler services demonstrate reliable settlement and slashing.

7. Community-pool support

The community pool may subsidize:

• Open-source software

• Audits

• Initial provider onboarding

• Public-good archival coverage

• Monitoring infrastructure

It should not subsidize ordinary customer fees indefinitely.

Pilot limits

For the first 12 months:

• No provider may control more than 25% of bonded capacity

• At least three independent providers must serve each subsidized public-good contract

• All service performance must be publicly visible

• Subsidies must decline according to a predetermined schedule

• All code and contract specifications must be open source

Success criteria

• At least five independent providers

• At least three production rollups purchasing services

• Successful completion of public retrieval challenges

• No unresolved critical slashing disputes

• Recurring TIA-denominated service revenue

• Measurable TIA bonded beyond ordinary staking

Vote interpretation

A “Yes” supports development and a limited pilot. Expansion beyond the listed services requires a subsequent proposal.

---

Proposal 5: Revenue-Responsive Validator Security Budget

Proposal type

Standards Track Core CIP requiring a coordinated network upgrade.

Title

Transition Celestia from Fixed Inflation to a Revenue-Responsive Security Budget

Abstract

This proposal replaces Celestia’s eventual fixed inflation floor with an adaptive issuance system under which validator-directed network revenue offsets new issuance.

The mechanism would preserve a minimum security budget while allowing inflation to decline as the network generates sustainable fee revenue.

Celestia’s current inflation is approximately 2.5%, declining annually toward a 1.5% floor following CIP-0041.

Motivation

Permanent fixed inflation is useful during a network’s early years because it funds security before fee markets mature. It becomes less efficient when fees can pay an increasing share of validator compensation.

A mature network should not issue the same quantity of new tokens regardless of whether validator fee revenue is negligible or substantial.

Specification

1. Target security budget

The protocol should define an annualized target security budget equal to 1.5% of circulating TIA supply.

This is the total validator-directed compensation target from:

• New issuance

• Blob base-fee distributions

• Capacity-reservation revenue

• Canonical bonded-service protocol revenue

• Priority fees

Burned fees and community-pool revenue do not count toward validator compensation.

2. Revenue offset

New issuance should cover only the portion of the target security budget not supplied through validator-directed revenue.

Conceptually:

Gross issuance requirement = target security budget − qualifying validator revenue

The result is subject to the minimum and maximum rates below.

3. Issuance bounds

Recommended normal bounds:

• Minimum annual gross issuance: 0.50%

• Maximum annual gross issuance: 1.50%

Emergency maximum:

• 2.50% when predefined security conditions are triggered

4. Measurement period

Qualifying revenue should be calculated using:

• A 90-day exponential moving average

• A 365-day trailing reference

• Manipulation-resistant exclusions for self-funded abnormal activity

The 90-day measure provides responsiveness, while the longer reference reduces abrupt changes.

5. Rate-of-change limits

To protect validator economics:

• Issuance may decline by no more than 0.25 percentage points per quarter.

• Issuance may rise by no more than 0.25 percentage points per month under normal conditions.

• Emergency conditions may permit a faster increase up to the 2.50% ceiling.

6. Emergency security conditions

The emergency ceiling may activate if any two of the following persist for 14 days:

• Bonded ratio below 45%

• Fewer than 80 active validators

• Top 10 validators exceed a governance-defined concentration threshold

• Median validator revenue falls below the published minimum operating-cost benchmark

• Material deterioration in block production or participation

The emergency increase must automatically reverse when the conditions have remained resolved for 30 days.

7. Community-pool funding

The community pool should continue receiving its current issuance allocation during the initial transition.

Once fee-derived community-pool revenue exceeds the trailing value of the issuance allocation for 180 days, governance may reduce or eliminate the community-pool share of new issuance through a separate proposal.

8. Activation prerequisites

This mechanism must not activate until:

• The blob base-fee mechanism has operated for at least 12 months

• Capacity reservations have operated for at least six months

• Validator-directed fee revenue has funded at least 25% of the target security budget for six consecutive months

• Bonded ratio has remained above 55% for six months

• Independent economic and security audits are complete

9. Initial transition

At activation:

• The existing scheduled inflation rate becomes the initial ceiling.

• Issuance may decline only as the revenue-offset formula permits.

• The 0.50% minimum applies only after a one-year transition period.

• No immediate one-time reduction greater than 0.25 percentage points is permitted.

Security considerations

Primary risks include:

• Undercompensating validators

• Lower bonding participation

• Manipulated fee revenue

• Excessive complexity

• Procyclical issuance during market stress

• Revenue concentration among a small number of validators

The issuance formula must be deterministic, transparent, and observable through public dashboards.

Vote interpretation

A “Yes” supports the adaptive mechanism only after all activation prerequisites have been met. It does not authorize an immediate reduction to the minimum issuance rate.

---

Proposal 6: Mainnet Activation, Parameter Limits, and Review Process

Proposal type

• Parameter-change proposal after the required modules are deployed

• Forum publication of final activation report

• Subsequent coordinated activation where parameters are not governance-changeable

Title

Activate the Sustainable Blob Economy Pilot with Bounded Parameters

Abstract

This proposal activates the previously deployed economic modules using conservative initial parameters and establishes an automatic review schedule.

Initial parameters

Blob base fee

• Target utilization: 50%

• Maximum adjustment per block: 6.25%

• Utilization smoothing: 120 blocks

• Base-fee burn: 50%

• Validator allocation: 40%

• Community-pool allocation: 10%

• Priority-fee validator allocation: 100%

Capacity reservations

• Maximum total reserved capacity: 20%

• Maximum per economic entity: 5%

• Minimum reservation term: 30 days

• Maximum reservation term: 365 days

• Maximum long-term discount: 15%

• Bond settlement delay: 21 days

• Transferability: disabled

Bonded services

• Minimum collateralization: 150% of outstanding customer payments

• Maximum obligations: five times provider bond

• Provider withdrawal delay: 30 days

• Maximum provider concentration: 25%

• Initial services: archival retrieval and Blobstream relay monitoring only

Adaptive issuance

Not activated under this proposal.

It remains disabled until the explicit conditions in Proposal 5 are satisfied and a separate activation report is published.

Automatic review schedule

A public review must occur:

• 90 days after activation

• 180 days after activation

• 365 days after activation

• Annually thereafter

Each review must report:

• Blob utilization

• Fee levels

• TIA burned

• TIA locked in reservations

• TIA bonded to service providers

• Validator revenue

• Community-pool revenue

• Submitter concentration

• Reservation concentration

• Customer retention

• Effects on open-access users

• Network reliability

• Comparison with competing DA pricing

Parameter-change limits

Until the first annual review:

• Burn percentage may change by no more than 10 percentage points per proposal.

• Reserved capacity may increase by no more than 10 percentage points.

• Per-entity reservation limits may not exceed 10%.

• Maximum reservation discount may not exceed 20%.

• New bonded-service categories require separate public review.

• Adaptive issuance may not be activated early.

Suspension conditions

Capacity reservations or bonded services may be suspended if:

• A critical vulnerability is discovered

• Reserved transactions systematically fail to receive contracted priority

• Open-access inclusion is materially impaired

• Reservation ownership cannot be reliably attributed

• Slashing mechanisms produce unresolved wrongful penalties

• A single entity circumvents concentration limits

Suspension should preserve customer balances and refundable bonds wherever technically possible.

Approval standard

The community should evaluate this package according to whether it:

• Preserves inexpensive permissionless blobspace

• Creates economically meaningful TIA demand

• Avoids arbitrary or coercive token utility

• Improves validator revenue sustainability

• Limits protocol complexity

• Protects small developers

• Reduces reliance on issuance over time

Final recommended sequence

1. Publish the Sustainable Blob Economy RFC.

2. Pass the development and audit community-pool proposal.

3. Complete simulations, implementations, and audits.

4. Adopt the blob base-fee CIP.

5. Adopt the capacity-reservation CIP.

6. Launch the bonded-services pilot.

7. Submit the bounded parameter-activation proposal.

8. Collect at least 12 months of operating data.

9. Consider activating the revenue-responsive security budget.

10. Expand capacity and service limits only through subsequent governance.

Overall rationale

This package does not depend on artificially increasing transaction fees or requiring every developer to hold a large quantity of TIA.

Instead, it divides Celestia’s service into two economic layers:

• Open blobspace: inexpensive, permissionless, and accessible

• Committed services: predictable capacity, historical retrieval, relaying, and service guarantees backed by locked and spent TIA

The result is a direct relationship between Celestia’s commercial importance and TIA’s economic role:

More economically important rollups produce more TIA-denominated fees, more TIA bonds, more TIA locked in capacity commitments, greater validator revenue, and less need for inflationary issuance.

That is a more durable value-capture model than relying solely on very low per-byte transaction fees.