Celestia Sustainable Blob Economy Governance Package
Revised forum proposal integrating the Sovereign and Fibre amendments
Version 2.0 | September 22, 2026
Decision requested
I propose a staged program to develop paid capacity commitments and data services that strengthen Celestia’s economics while preserving inexpensive, permissionless data availability. The community should first approve the program’s direction and consider a separately itemized feasibility appropriation. Engineering, mainnet deployment, and changes to issuance would each require their own subsequent approval.
The program has an aggregate planning ceiling of $1.5 million equivalent. The first phase is capped at $225,000 equivalent. Those ceilings limit potential expenditure; they do not allocate tokens or commit funding to later phases. A spending proposal must identify its recipients, exact TIA amount, payment terms, and acceptance criteria before voting begins.
This revision consolidates the original forum package and its Sovereign acquisition addendum into six proposals. It corrects the existing fee baseline, defines the initial reservation product, ties bonds to contractual exposure, and separates candidate economic parameters from parameters authorized for deployment. [1]
Objectives and approval boundaries
The program should improve the reliability and commercial usefulness of Celestia services, establish measurable sources of protocol revenue, and determine whether those revenues can eventually replace part of issuance without weakening security. Success requires customers willing to pay, sustainable service delivery, and protection of the open market.
Token locking, fee denomination, burning, and reduced issuance must be reported separately. A refunded bond is not revenue. A payment in TIA does not establish a lasting increase in token demand. Growth in service-provider or corporate revenue contributes to the validator security budget only to the extent that an enforceable onchain mechanism actually transfers funds into that budget.
| Proposal | Decision covered | Required subsequent authorization |
|---|---|---|
| 1 Development program | Feasibility, procurement, engineering, and independent review | Separate appropriation for each funded phase |
| 2 Fees and accounting | Resource pricing, revenue classification, and fee allocation | Implementation CIP and exact activation parameters |
| 3 Capacity commitments | Optional paid inclusion priority with explicit liability | Audited implementation and a bounded mainnet pilot |
| 4 Bonded data services | Archival retrieval and relay monitoring | Service specifications and a bounded mainnet pilot |
| 5 Security budget | Research into revenue-responsive issuance | Separate monetary-policy CIP, upgrade, and activation approval |
| 6 Activation and review | Evidence, limits, monitoring, and emergency procedures | A module-specific activation manifest |
Forum support establishes direction. It does not execute a community-pool transfer, approve unspecified software, or constitute adoption of a formal CIP. Implementers must follow the applicable Celestia proposal and coordinated-upgrade processes.
Existing protocol and commercial baseline
Celestia already has a consensus-enforced global minimum gas price under CIP-6, which was included in Lemongrass. A dynamic, resource-specific blob base fee would extend that framework. Specifications must distinguish the existing minimum from the additional congestion controller considered here. [2, 3]
Fibre has its own publication and settlement architecture. Its specification distinguishes the settlement transaction fee from the data-availability payment deducted from escrow. Both flows must be included in accounting without counting the same transfer twice. The cited implementation and upgrade documents must be checked against the active network version before any activation proposal. [4, 5]
CIP-43 describes a fee-address mechanism for external contributions and is marked In Review in the cited specification. Integration must be conditional on its actual adoption. External contributions require a separate revenue category even when they enter the fee collector. [6]
Celestia’s documented minting calculation uses total supply. Its existing disinflation schedule remains the baseline until a separate change is approved. Existing rules also allow locked tokens to participate in staking. Economic comparisons must therefore use consistent supply and bonded-ratio definitions. [7, 8]
Celestia Labs’ acquisition of Sovereign Labs provides an additional integration route. Sovereign’s premium components have published commercial terms; community-funded functionality must be usable without requiring those components or their associated revenue share. Funding applications must identify the applicable licenses and dependencies. Ownership of an integration framework does not establish that every deployment will select Celestia. [10, 11]
Proposal 1 Development and feasibility program
Scope and funding stages
Fund work in three separately authorized phases. Each phase must have a named accountable lead, costed work packages, dated deliverables, a maintenance plan, and an independent acceptance process. The aggregate ceiling includes administration, integration, audits, remediation, and the support obligations contracted under the program.
| Phase | Maximum USD equivalent | Required result |
|---|---|---|
| A Feasibility and design | $225,000 | Reproducible economics, customer evidence, technical options, and a recommendation for each workstream |
| B Implementation and integration | $825,000 | Approved specifications, reference implementations, clients, and functioning testnet services |
| C Independent review and pilot preparation | $450,000 | Security and economic reviews, remediation, operational exercises, and activation documentation |
| Total | $1,500,000 | Aggregate ceiling across all phases |
Uncommitted funds for later phases remain unappropriated. Savings do not authorize new work automatically. Reallocating money between phase ceilings requires governance approval. If bids show that the scope cannot fit the ceiling, reduce scope or submit a separately justified funding amendment before committing additional funds.
Phase A requirements
The feasibility phase must publish a reproducible baseline using at least 90 days of available network data and a longer history where available. It must distinguish customer demand, sponsored activity, ordinary DA fees, Fibre payments, external contributions, staking rewards, and provider revenue. Publish data exclusions and uncertainty; do not infer economic ownership from addresses alone.
Economic models must compare the existing system with each proposed module independently and in combination. Model low utilization, burst demand, sustained congestion, customer departures, token-price shocks, and a simultaneous decline in fees and staking participation. Include validator costs, delegator rewards, software maintenance, customer refunds, provider replacement, and subsidy expenditure.
Obtain written feedback from at least three independent prospective customers, including different throughput profiles. Record their preferred service, expected volume, price tolerance, required guarantees, and objections. Publish aggregated findings and a verification method that protects confidential commercial information. Expressions of interest must be labeled as such; they are not bookings or revenue.
Phase A must also produce a costed implementation plan and a recommendation to proceed, narrow, or stop each workstream. A recommendation against implementation is an acceptable research outcome when supported by the evidence.
Conditions for further funding
Phase B requires independent acceptance of the feasibility work and a separate community-pool proposal. The application must show a credible path to customers paying the full delivered cost of the proposed service, or expressly identify a limited public-good function and the subsidy needed to provide it. It must compare the proposal with simpler changes using existing infrastructure.
Phase C requires working testnet implementations, stable audit scope, reproducible test results, and named independent reviewers. Consensus changes require two independent security reviews covering the relevant implementation and interfaces. The economic review must assess incentives and stress scenarios separately from code correctness. Reviewers may not audit their own implementation work.
Procurement and disbursement
Before each spending vote, publish the exact TIA amount, recipient address, signers, conflicts of interest, vendor quotations, milestones, acceptance authority, and return address. The USD reference is a budgeting convention. Specify a public multi-venue conversion method and valuation time when fixing the token amount. Material exchange-rate changes require an updated proposal or reduced scope; the program has no automatic right to a treasury top-up.
Use a publicly identified multisignature with at least three required signatures from at least five signers. A contractor and its affiliates may control no more than one signer position. Governance must appoint independent milestone reviewers and disclose the required acceptance threshold before funds move.
Limit mobilization payments to 20% of each approved phase and retain at least 20% until its final accepted deliverables and handover. Intermediate releases require published evidence against agreed milestones. Missed milestones pause new payments, subject to existing contractual liabilities and a public remediation decision. Return unspent and uncommitted funds at phase close under the approved settlement terms.
Publish monthly spending and progress reports, contractor payments, risks, scope changes, and remaining commitments. A phase may be terminated under its published contract, with completed work and documentation delivered to the community.
Integration and public access
Develop open interfaces and reference clients for ordinary blobs and Fibre. Sovereign SDK is a reference integration; support must remain available to other frameworks through the same interfaces, terms, and documentation. Public funding may not purchase an exclusive route to a protocol feature.
All funded deliverables must use an approved open-source license. Applications must disclose related-party ownership, intellectual property, proprietary dependencies, and expected private revenue. Public funding cannot be conditioned on a compulsory commercial license or revenue share for using the funded functionality. A provider may independently offer paid products around accessible public interfaces.
Vote interpretation
Support for this proposal endorses the staged program. Only a completed phase-specific spending proposal authorizes its stated appropriation. Completion of research does not authorize engineering, and completion of engineering does not authorize mainnet activation.
Proposal 2 Resource fees and protocol revenue accounting
Accounting before allocation
Implement a public accounting specification before introducing new fee distributions. It must reconcile token balances and events across ordinary blob payments, execution fees, Fibre escrow charges, capacity fees, service assessments, external contributions, refunds, slashing, burning, and issuance.
Maintain separate classifications for refundable customer principal, provider collateral, earned service revenue, validator and delegator rewards, and community-pool receipts. Depositing into escrow is not revenue. A reservation payment becomes earned over its service period, and amounts exposed to contractual refunds remain protected until the claim window closes.
Provider earnings remain provider earnings. Only an explicitly authorized assessment that is actually distributed into the consensus security budget can qualify as security revenue. Corporate payments routed onchain must retain a distinct source classification. The same token transfer cannot be recognized both as an incoming service payment and again as a fee-collector transfer.
Separate resource prices
The implementation CIP must specify how a blob charge measured in consumed shares interacts with execution gas and the existing global minimum. It must identify which resource costs each component covers and prevent duplicate charging for the same cost component. Clients must be able to set a maximum total payment and obtain an itemized estimate.
Ordinary blobspace and Fibre require separate capacity definitions and resource measurements. Fibre accounting must cover bandwidth, retained shards, commitment throughput, and the settlement path. Ordinary data-square occupancy alone is not an adequate utilization measure for Fibre. [4, 5]
Keep pricing denominated in TIA at the protocol boundary. Customer interfaces may display fiat estimates or acquire TIA automatically, with clear conversion costs and payment limits. Such interfaces must not introduce a price oracle into consensus without a separately specified and audited requirement.
Controller selection
Phase A must compare the existing minimum-fee framework with alternative dynamic controllers. Publish exact equations, integer rounding, initialization, controller state, time measurement, capacity-change behavior, and migration rules for any chosen design.
Test sustained load, burst submissions, idle recovery, reservation activity, proposer self-submission, and colluding validators. Report both per-block and elapsed-time price changes. A per-block percentage limit can compound rapidly; averaging utilization can also delay recovery after demand falls. Neither property by itself establishes stability.
The final CIP must set a resource-cost and abuse-resistance basis for its floor, a justified utilization target, and tested limits over defined time windows. It must explain the trade-off between limiting customer price shocks and allowing congestion prices to respond quickly enough to deter abuse. Candidate values are research inputs until approved in an activation manifest.
Fee distribution and supply effects
Do not pre-authorize a 50% burn. Simulate burn shares of 0%, 25%, and 50%, together with the existing community allocation and alternative allocations of 5% and 10%. These are comparison scenarios, not approved operating values. All shares must reconcile to 100% and identify whether the community tax has already been applied.
Evaluate each scenario before and after any revenue-responsive issuance mechanism. Once additional security revenue reduces issuance one-for-one, burning a token and using it to prevent a token from being minted can have the same net supply effect while no bound is binding. Floors, ceilings, recognition delays, community issuance, and validator incentives can change that comparison.
The assessment must include fee manipulation and private payment arrangements. EIP-1559 identifies incentive reasons for withholding base fees from block producers; a partially redistributed Celestia fee requires analysis of its own incentive properties. [9]
Select the initial split using published evidence on security funding, customer costs, net supply growth, and manipulation resistance. Until a new allocation is approved and activated, existing allocation rules continue to apply.
Client protection and activation
Do not introduce account-based free-byte credits in the initial consensus implementation. Experimental users can receive limited grants through a separately budgeted program. This avoids making address creation a route to subsidized capacity while the core mechanism is being validated.
Activation requires the evidence and controls in Proposal 6. Final specifications must state the total expected customer charge, validator and delegator distribution, treatment of Fibre timeout settlement, and the exact relationship with CIP-6 and any adopted fee-address mechanism.
Vote interpretation
Support authorizes development of the accounting and pricing specifications within approved funding. Mainnet pricing, burning, and allocation changes require their own implementation and activation approvals.
Proposal 3 Paid capacity commitments
Initial product and customer pricing
Create an optional product that gives a customer defined inclusion priority within an admitted quota. The initial product charges a reservation premium for that priority. Actual usage remains subject to the applicable DA charge and ordinary transaction costs. An invoice must distinguish the premium, usage charges, refundable balances, and any compensation credit.
The initial contract does not promise a fixed future usage price. A fixed-price or prepaid-byte product would require a separate specification for price risk, solvency, and reconciliation. No reservation can waive consensus fee requirements or use an alternative payment route to avoid an approved charge.
Price the premium using measured willingness to pay, scarce capacity, service obligations, and the cost of compensation. Any term discount applies to the premium and must be supported by commitment value or lower servicing costs. A discounted premium must not be presented as a discount on the prevailing usage fee.
Reservations can be tested against the existing fee mechanism. Their pilot need not wait for a new dynamic fee if accounting, funding, and service obligations can be enforced under current rules.
Capacity and admission rules
Define effective capacity as the protocol’s explicit, enforceable capacity budget for the relevant service class. Publish its units and measurement interval. All percentage limits below use that denominator, never a fee controller’s utilization target.
For the initial pilot, aggregate reservations may consume at most 10% of effective capacity in each service class. A single disclosed economic group may receive at most 2.5%. For ordinary blobs, apply the quota to each block. For Fibre, enforce every binding bandwidth, storage, message-count, and settlement constraint over its specified interval. A reservation must fit all relevant limits, including the shared resources used by its onchain commitment.
These are proposed pilot safety limits, subject to confirmation in the activation vote. They do not authorize an increase in physical network limits. Admission must account for all existing commitments and correlated peak use; average customer usage is insufficient evidence of deliverability.
Initially offer 30-day and 90-day terms. Reservations are nontransferable except for a verified administrative key rotation that leaves the customer and obligations unchanged. Terms of 180 or 365 days, secondary trading, and larger allocations require a later proposal supported by operating evidence.
Publish one uniform enrollment process and the applicable prices. Scarce allocations require a disclosed, manipulation-tested allocation rule rather than private preference. The pilot registry must aggregate declared beneficial ownership and disclose common infrastructure dependencies separately. Misrepresentation can stop new admissions and trigger a predefined contract remedy; it cannot authorize arbitrary confiscation.
Identity disclosures apply only to this optional pilot. Open-market submission remains permissionless. The protocol must enforce the aggregate capacity cap independently of the accuracy of ownership declarations. Address-level limits must not be described as proof of independent ownership.
Service acceptance and delivery
Every contract must identify the submission interface, quota, acceptance evidence, delivery window, exclusions, compensation schedule, and funding source. A customer must know when an obligation begins and what proves a breach.
A local mempool timestamp is not sufficient evidence of network-wide acceptance. Before advertising a delivery deadline, the implementation must provide an independently verifiable receipt binding the payload commitment, funded account, quota, and acceptance point. The receipt mechanism must address payload availability, replay, equivocation, and validator-set changes.
Deadlines must be expressed in finalized blocks or another precisely specified consensus-based interval, with explicit network-liveness assumptions. Chain-wide outages and customer submission failures must be distinguished from a provider or scheduler breach. A contract must disclose whether its remedy is a bounded service credit or a funded payment; it may not imply unlimited loss coverage.
Where objective acceptance and failure evidence cannot be implemented safely, the pilot must offer clearly described priority only and omit a guaranteed deadline. A private timestamp or subjective monitor decision cannot support automatic slashing.
Unused quota becomes available to ordinary submissions at the specified construction cutoff. Capacity must not be left empty merely because its holder is inactive. Quota release, concurrent submissions, oversized blobs, and capacity reductions require deterministic handling. If an upgrade reduces deliverable capacity, follow a pre-agreed reduction and refund process rather than silently diluting existing promises.
Customer funds and bonds
Maintain three separate balances: prepaid reservation premiums, usage-payment escrow, and any customer performance bond. Earn premiums over the service period. Retain amounts needed for eligible refunds until their claim window closes before irreversible distribution or burning.
The customer bond covers the maximum permitted unpaid exposure after available payment escrow, plus any narrowly defined abuse liability in the contract. A fully prepaid customer with no such residual exposure can have a zero additional bond. Do not impose a minimum merely to reach a token-locking target, and do not count payment escrow as a separate bond.
Default remedies begin with stopping new service obligations and collecting matured unpaid charges. Penalties require a specified breach and proof. Customer collateral does not fund compensation for a service failure attributable to the network or provider.
Before admitting contracts, identify and fund the party or reserve responsible for promised compensation. Total outstanding maximum claims cannot exceed the dedicated, unencumbered claims resources under the approved coverage rule. The community pool has no implied guarantee. Reservations must be suspended for new business when coverage is insufficient.
Release undisputed customer funds promptly after obligations and claim windows close. The normal final settlement must finish within 21 days of expiry. An unresolved claim may retain only its documented maximum disputed amount under a published resolution deadline; unrelated balances must be released.
Pilot evaluation
Run the initial pilot for 180 days. Contracts cannot extend beyond its authorized end unless continuation is approved. Begin with at least three independent customers and report all subsidies, volumes, charges, misses, refunds, and customer exits.
Expansion requires paying-customer evidence, operation at representative loads, and acceptable effects on ordinary submissions. Report renewal by both customer count and eligible premium revenue, including the number of contracts actually eligible to renew. A small sample must not be presented as proof of broad market demand.
The activation manifest must set numerical renewal and open-market performance thresholds before launch. Expansion requires a separate decision even when the thresholds are met. Any increase in capacity limits must comply with Proposal 6.
Vote interpretation
Support endorses development and evaluation of this defined product. Only a separately approved activation manifest can launch its mainnet pilot, commit compensation resources, or establish the operating parameters.
Proposal 4 Bonded archival and monitoring services
Service scope and execution boundary
Establish an optional marketplace for historical blob storage, namespace-specific retrieval, and Blobstream relay monitoring. Historical retention is a separately purchased service whose duration and retrieval terms must be explicit. Monitoring a relay and operating a relay are different obligations; monitoring contracts cannot penalize an operator for failing to perform an unpurchased relay service.
Run service agreements, indexing, customer interfaces, and claim handling outside the Celestia consensus state machine wherever practical. Base-layer changes must be limited to necessary commitments, proof verification, and settlement interfaces. Each interface must document its bridge or verification assumptions and the consequences of failure.
Sovereign-compatible proof delivery, sequencer monitoring, failover monitoring, and related adapters may be explored on testnet within separately approved work packages. They are excluded from the initial mainnet service scope. A framework or affiliated provider receives no preferential admission, collateral, pricing, or claims treatment.
Payments and liability limits
Contracts must itemize provider payments, refundable customer funds, ordinary settlement fees, and any protocol assessment. A new protocol assessment requires explicit approval; the initial pilot cannot silently deduct a percentage of provider revenue. Only the assessment actually allocated to consensus rewards counts toward the security budget.
Canonical service payments settle in TIA. Interfaces may accept another asset and acquire TIA for settlement, with disclosed conversion costs and limits. Customers may also use independent services outside this marketplace. The registry creates no exclusive right to provide Celestia-related infrastructure.
Each contract must specify its maximum enforceable liability in TIA, including refunds from provider funds, bounded service compensation, and promised migration assistance. Unused customer payment escrow is segregated and returned separately; it cannot collateralize a provider’s obligations. A contractual limit must not be advertised as insurance against all losses from missing data.
Provider collateral
For the initial pilot, require eligible collateral worth at least 150% of the provider’s aggregate maximum contractual liability. Define that liability as the sum of enforceable obligations that could arise concurrently, after eliminating explicitly non-additive remedies. Remove the separate allowance for obligations up to five times a bond.
Measure both liabilities and eligible collateral in TIA for the initial contract. Providers must also pass a disclosed operating-cost stress assessment in a common reporting currency. A dollar estimate at purchase does not create a dollar-denominated compensation promise.
Any later contract with dollar-denominated liability requires a separately audited valuation mechanism, conservative collateral discounts, stale-price handling, and margin procedures. Until those exist, such liabilities cannot enter the canonical pilot.
Collateral must be unencumbered and uniquely assigned. Do not accept a simultaneously pledged staking position, liquid-staking receipt, or asset backing another service bond in the pilot. Assessing incremental TIA commitment must distinguish new purchases, existing holdings, and withdrawals from consensus staking wherever reliable evidence exists; classify unverifiable sources as unknown.
Reject new contracts when collateral is insufficient. The contract must state the replenishment interval, restrictions during a shortfall, and orderly exit procedure. Existing claims remain enforceable under their terms. Providers cannot release collateral while it supports active liabilities.
Proofs and penalties
Use publicly specified, objectively verifiable proofs for automated penalties. Retrieval challenges must identify committed data, an accepted request, a response window, valid responses, and the chain-liveness conditions under which a timeout is meaningful. A single offchain timeout or a customer’s assertion is insufficient proof of failure.
Signed receipts and monitors may supplement evidence. Their trust assumptions, collusion risks, and appeal path must be disclosed. A quorum of monitors is not automatically equivalent to a cryptographic proof. Subjective service categories are excluded from automatic pilot slashing.
Require challenger bonds or equivalent controls proportionate to the cost of frivolous claims. Define proof verification, challenge and appeal periods, adjudication authority where needed, and a final resolution deadline. A successful response must prevent the same alleged failure from being penalized repeatedly.
Penalties follow a published waterfall: valid customer refunds and contractual compensation first; reasonable verified challenge and adjudication costs second; any remaining permitted penalty allocation last. Burning or community-pool transfers must come only from the residual amount authorized by the contract. Routine penalties must not consume collateral needed for higher-priority valid claims without a defined insolvency process.
Provider diversity and public support
Launch a publicly subsidized service pilot only after at least five independent providers are ready. Each subsidized public-good dataset must have at least three independent providers. A single economic group may receive no more than 25% of the approved program liability budget allocated to subsidized providers. Measure actual service concentration separately rather than treating grant allocations as proof of decentralized use.
Disclose beneficial ownership and common hosting or management dependencies under the same opt-in principles used for reservations. Community support may fund open software, audits, public-good coverage, and time-limited onboarding. Customer discounts must be disclosed and decline according to the funded phase’s published schedule. Ordinary commercial demand must ultimately be evaluated without those discounts.
Expiry and evaluation
Run the initial service pilot for no more than 12 months under its activation authorization. Contract expiries must fit within that authority. Publish retrieval results, paid renewals, service margins, failed challenges, resolved and pending claims, collateral coverage, subsidies, and customer migration outcomes.
The normal withdrawal delay is 30 days after the last obligation ends, provided the applicable claim period has closed. Hold only the amount needed for unresolved claims beyond that date and apply the published resolution deadline. Material changes to proof rules, liability scope, accepted collateral, or settlement trust assumptions require a new approval.
Vote interpretation
Support endorses development of the limited marketplace and its testnet evaluation. Mainnet service categories, contract liabilities, subsidy budgets, and proof mechanisms require an approved activation manifest.
Proposal 5 Revenue and the consensus security budget
Purpose and current authority
Study a mechanism under which durable protocol revenue can replace part of new issuance while preserving adequate compensation for consensus participation. The existing issuance schedule continues throughout research and the initial service pilots. This proposal contains no authority to activate adaptive issuance.
Distinguish the aggregate reward pool for validators and delegators from income retained by validator businesses. A sufficient aggregate pool does not demonstrate that smaller operators can cover their costs. Both measures must be modeled alongside bonded stake, voting-power concentration, and the capital needed to resist attacks.
Supply and budget definitions
Use protocol-recorded total outstanding TIA supply as the common supply denominator. It includes staked, vesting, escrowed, and bonded tokens and excludes tokens actually burned. Do not derive the control variable from an exchange’s circulating-supply estimate or an offchain ownership classification. State the exact snapshot and update interval in the implementation CIP. [7, 8]
The annual security target is a target amount paid into the validator and delegator reward pool after the applicable community allocation. Research may include a target equivalent to 1.5% of total supply, but the final target must be justified using operating costs, capital incentives, concentration, and stress performance. Matching an earlier terminal inflation percentage is not sufficient justification.
The model must account for the community share of issuance explicitly. To estimate gross issuance needed, subtract qualifying security revenue from the security target, set a negative shortfall to zero, and divide the remaining shortfall by the fraction of issuance that actually reaches the security pool. Then apply the approved gross issuance bounds and transition limits.
For illustration only, a 15 million TIA annual security target, 3 million TIA of qualifying security revenue, and a 2% community share of issuance would require approximately 12.245 million TIA of gross issuance before other bounds. Minting only 12 million would leave the security pool short because part would fund the community allocation. This example establishes accounting, not an operating target.
Floors can cause total compensation to exceed the target; ceilings can leave it below target. Dashboards must show both outcomes explicitly. The model must evaluate net supply growth after burns and must not count burned fees as security income.
Qualifying revenue
Count only earned, realized protocol revenue actually allocated to the consensus security pool, net of relevant community allocations, refunds, and reversals. Include supported ordinary DA and Fibre payments and the earned security share of reservation premiums or expressly authorized service assessments. Exclude refundable principal, provider bonds, gross provider payments, private corporate receipts, and projected contracts.
Recognize reservation premiums across the period of delivered service, after the applicable refund protection. An upfront payment cannot be annualized as though that amount recurred every day. Distinguish collection, earning, distribution, and recognition dates in the event schema and public dashboard.
Discretionary contributions, treasury transfers, identifiable grant-funded fees, slashing proceeds, and other nonrecurring receipts do not qualify for the automatic offset in the initial design. Where a payment cannot be assigned to an eligible event category, publish it separately and exclude it until a transparent rule is approved. Unknown beneficial ownership alone does not disqualify ordinary DA fees; unresolved ownership and subsidy risks belong in the manipulation analysis. A contribution entering a fee-address module does not automatically become recurring customer revenue. [6]
An irrevocable, protocol-enforced recurring revenue share may be proposed for inclusion only with public settlement rules and operating history. The fact that a private business receives TIA is insufficient. No confidential company accounting or discretionary promise may determine consensus issuance.
The initial research model should use the lower of an annualized 90-day exponential moving average and an annualized 365-day trailing average of eligible realized revenue. Define sampling, initialization, elapsed time, and rounding precisely. Model the lag this approach creates during a downturn and the countermeasures needed before activation.
Manipulation and security tests
Do not assume that address heuristics can identify all self-funded activity. Specify deterministic exclusions for directly identifiable subsidies and nonrecurring transfers, then test the mechanism against adversaries whose economic ownership is unknown.
Model validators paying fees to themselves, related customers recycling receipts, concentrated fee sources disappearing, prepaid revenue timing, and attempts to induce issuance reductions before withdrawing support. Account for fees the attacker recovers through rewards and any irreversibly paid cost. The review must quantify the cost and security impact of attacks rather than relying on a promise to filter abnormal activity.
Stress the combined system under large token-price declines, falling service demand, increased infrastructure costs, provider defaults, and movement of stake into service bonds. Report solvency, operator income, delegator incentives, bonded ratio, and concentration. Include a scenario in which the largest material customer stops paying.
Conditions for an activation proposal
An adaptive-issuance proposal cannot be submitted until the new DA fee framework has at least 12 months of mainnet operating history and the revenue estimator has run publicly in observation mode for at least six months. Require independent economic and security reviews and publication of all source data and calculations needed to reproduce its decisions.
As minimum eligibility conditions, qualifying revenue must cover at least 25% of the proposed security target in each of six consecutive months, and consensus-bonded TIA must remain above 55% of total supply throughout the same period. Define those measurements and treatment of brief data interruptions before the observation period begins. These conditions are eligibility screens, not evidence by themselves that a particular issuance reduction is safe.
Any revenue stream used from reservations or services must have at least six months of operating history and completed liability settlement cycles. A stream that is not operational cannot be counted. Adaptive issuance need not depend on a commercially unsuccessful optional module merely to satisfy a procedural sequence.
Bounds and transition
The eventual activation proposal must publish exact normal bounds, a fully simulated transition from the then-current issuance schedule, and deterministic responses to deteriorating revenue or bonding. Do not activate a separate emergency inflation ceiling through this RFC.
Research must include the originally contemplated 0.5% issuance floor, alternatives including the existing schedule, and the consequences of reaching each bound. Until separately approved, none replaces current monetary policy.
Any approved decline should be limited to at most 0.25 percentage points over a rolling 90-day period, including the initial activation change. Ordinary increases may be limited to at most 0.25 percentage points over a rolling 30-day period within the separately approved ceiling. The audit must assess whether a faster protective restoration is needed and specify it before deployment. Repeated parameter proposals cannot reset these counters.
Freeze further reductions when approved, objectively measurable protection conditions are breached. Offchain estimates of operator costs inform governance but do not directly set issuance. Once protection conditions recover, require a defined observation period before reductions resume; a governance decision cannot substitute for missing revenue.
Keep the community share of issuance separately visible. Any change to that share requires its own justification, since it changes both the gross issuance needed for a security target and community funding.
Vote interpretation
Support endorses research and public observation of the proposed framework. Changes to the target, supply calculation, issuance schedule, or emergency monetary authority require a separate fully specified CIP and network adoption.
Proposal 6 Mainnet activation and continuing oversight
Separate activation manifests
Each module requires its own activation manifest. Modules may proceed independently when their technical dependencies allow it. A customer service must not be bundled with an issuance change as a condition of approval.
Publish each manifest at least 30 days before the proposed activation. Include the exact software version and commit, dependency versions, parameter values, capacity denominators, economic evidence, audits, remediation status, operational ownership, customer terms, and funding for liabilities. Include the relevant executable governance or upgrade action and a clear statement of its effect.
Current chain state and source status must be rechecked at submission. A CIP marked Implemented, an available software module, and a feature activated on mainnet are distinct facts. The manifest must identify which applies to every dependency.
Required evidence
Operate the relevant implementation continuously on Mocha for at least 60 days with representative and adversarial workloads. Material changes to consensus logic or liability enforcement require renewed testing sufficient to cover the change, with the independent reviewers explaining the observation period needed.
Complete two independent security reviews of consensus-affecting code and its settlement interfaces, resolve critical findings, and disclose the disposition of other findings. Publish a bug bounty, client compatibility results, load tests, and rehearsals of pause, recovery, refund, and orderly shutdown behavior.
For each commercial pilot, publish paid-demand evidence or a defined public-good subsidy rationale. The launch decision must identify who maintains the service after the development contract and how that work is funded.
Initial authority and limits
| Control | Proposed initial rule |
|---|---|
| Aggregate capacity reservations | At most 10% of effective capacity in each service class and all shared bottlenecks |
| Reservation allocation to one economic group | At most 2.5% of effective capacity in that class |
| Reservation terms | 30 or 90 days within the authorized pilot period |
| Reservation pilot duration | 180 days unless separately renewed |
| Transferability and account-based fee credits | Disabled |
| Provider collateral | At least 150% of aggregate maximum contractual liability |
| Subsidized provider allocation | At most 25% of the approved program liability budget per economic group |
| Mainnet service scope | Archival storage, retrieval, and relay monitoring |
| Service pilot duration | No more than 12 months unless separately renewed |
| New burn and fee-controller parameters | Disabled until individually justified and explicitly approved |
| Adaptive issuance | Disabled pending Proposal 5 prerequisites and separate approval |
These rules bound a later activation decision. They do not themselves activate modules or appropriate liability reserves. The manifest must include every operational value omitted from this policy-level table; no consensus or contract parameter may remain unspecified at activation.
Performance measures and review
Publish dashboards and reviews at 90, 180, and 365 days after a module launches and annually thereafter. Include prices per resource unit, utilization, ordinary-user inclusion times, transaction failures, reservation delivery, refunds, service claims, customer retention, subsidies, operator costs, and protocol revenue by source and destination.
Report issuance, burning, net supply growth, payment escrow, refundable bonds, and consensus stake separately. Publish both TIA amounts and clearly labeled common-currency estimates. A dashboard must not add refundable principal to revenue or portray all non-staking bonds as new capital entering TIA.
The activation manifest must set numerical acceptance and suspension thresholds for inclusion delays, failed service delivery, collateral coverage, concentration, and customer renewal. Compare ordinary-user outcomes at matched offered load and comparable fee conditions. Explain the limits of any modeled counterfactual. Observational conclusions cannot be represented as deterministic facts available to consensus.
Automatic protective actions may use only audited, protocol-observable conditions. Offchain monitoring can trigger a publicly accountable review or an authorized pause request, but cannot silently change fees, confiscate bonds, or alter issuance.
Parameter changes
During the first year, cumulative absolute changes to an activated burn percentage may not exceed 10 percentage points over any rolling 90 days, and must remain inside the audited range. The limit applies across all ordinary parameter proposals together.
Reservation caps may not increase during the initial 180-day pilot. After a separate expansion approval, increases may total no more than five percentage points of effective capacity over any rolling 90 days. The per-group cap may not exceed 5% before the first annual review. Expansion still requires sufficient uncommitted capacity and compensation funding.
Reductions in new admissions and temporary suspension may occur sooner under approved protection rules. They must preserve existing contractual rights or provide the agreed remedy. Changes to collateral eligibility, proof rules, service categories, or the supply denominator require substantive public review and cannot be treated as routine price updates.
Emergency action and recovery
The development escrow multisignature has authority over program funds only. It has no implied authority to change consensus fees, halt the network, or seize customer assets.
A module-specific emergency mechanism may be proposed only with an audited authorization method and precise scope. A certificate-based design must require strictly more than two-thirds of active validator voting power. Its initial authority is limited to pausing new contracts or new reservations and, where necessary, temporarily deferring disputed penalty execution. It cannot redirect balances or issue arbitrary refunds.
An emergency pause expires after 72 hours. Permit no more than one such emergency activation in a rolling 14-day period without the separately specified ordinary governance or coordinated-upgrade process. Publish the cause, affected obligations, decision record, and recovery plan. A deterministic inability to satisfy admission requirements can continue to block new contracts after the pause expires without granting discretionary control over existing funds.
A new fee controller requires its own tested fallback. Freezing an elevated fee indefinitely is not an acceptable recovery plan. The activation manifest must define the authorized trigger, bounded fallback behavior, expiry, and recovery path, including abuse resistance when the fallback is cheaper.
Emergency monetary changes remain outside these service-pause powers. Software rollback must also be distinguished from refund settlement: an upgrade cannot assume that previously burned tokens or finalized transfers can simply be reversed.
Closure and renewal
Pilot authority expires on its stated date. Without timely renewal, stop admitting commitments that would outlast that authority, complete existing obligations, settle claims, return refundable balances, and publish a final financial and operational report. Data-service closure must include the migration assistance and retrieval period promised in customer contracts.
Expansion requires an affirmative decision after the review. A successful audit, passage of time, or achievement of a single metric does not automatically expand capacity, extend subsidies, or activate monetary changes.
Vote interpretation
An activation vote authorizes only the named module, software version, parameters, period, and funded obligations in its manifest. Further expansion and renewal require subsequent approval under the limits above.
Information required before the first spending vote
The first executable proposal must supply the phase A recipients and signers, exact TIA appropriation and conversion record, itemized bids, milestone dates, independent reviewers, acceptance threshold, maintenance and handover obligations, contract termination terms, and return address. Those are procurement facts to be established through the program’s selection process.
The community can evaluate this complete policy package before those selections. Funds cannot move until the actual spending proposal provides them. Later manifests must likewise contain exact controller parameters, receipt and proof designs, liability funding, and executable actions rather than delegating those choices to an unspecified future implementer.
Material changes in this revision
The revision retains the six-part structure and integrates the Sovereign and Fibre provisions throughout. Its principal changes are an accurate CIP-6 baseline; three separately funded phases; a defined priority product with transparent usage charges; exposure-based customer collateral; a single provider-liability collateral rule; customer-first penalty settlement; consistent total-supply accounting; explicit treatment of community issuance and external contributions; and bounded module-specific activation and recovery.
Fixed burn percentages, long reservation terms, and automatic monetary changes are deferred until supported by evidence and a separate approval. The program can produce useful services and public research even if a particular proposed mechanism does not justify deployment.
References
Protocol and commercial sources reviewed September 22, 2026. Source status and implementation versions must be revalidated before an executable proposal is submitted. Parameters introduced by this revision are proposals unless expressly identified as existing protocol rules.
[1] Celestia Forum. TIA future state and blob economy proposal package. Original post and Sovereign acquisition addendum, July 2026.
[2] Celestia Improvement Proposals. CIP-6 Minimum gas price enforcement.
[3] Celestia Improvement Proposals. CIP-17 Lemongrass Network Upgrade. and Celestia Documentation, Network upgrades.
[4] Celestia Improvement Proposals. CIP-51 Fibre Protocol and CIP-52 v10 Network Upgrade. and
[5] Celestia application reference implementation. Fibre module specification, including payment settlement destinations.
[6] Celestia Improvement Proposals. CIP-43 Fee address module.
[7] Celestia application mint module documentation. Total-supply basis and annual provisions and CIP-41.
[8] Celestia Documentation. Staking governance and supply.
[9] Ethereum Improvement Proposals. EIP-1559 Fee market change for ETH 1.0 chain.
[10] Celestia Blog. Celestia Labs Acquires Sovereign Labs To Build High-Performance Custom Blockchains. July 15, 2026.
[11] Sovereign SDK. Revenue Share for Premium Components and governing license.