Celestia Celestia blobs: size and posting fees
A blob is a batch of application data tagged with a namespace and published to Celestia. On Mainnet Beta, the PayForBlobs fee in TIA depends on the gas limit and gas price; data size helps determine the gas required. Application execution and transaction validity belong to the rollup’s execution or settlement design.
Payload, namespace, and commitment
A blob transaction,
BlobTx
, combines one or more
Blob
payloads with a
MsgPayForBlobs
payment message. Each blob carries its data and namespace, while the payment includes a commitment to the data. The namespace lets an application request its relevant data. Namespaced Merkle trees support proofs that the response contains all data for that namespace within the block.
During block production, Celestia splits block data into shares and extends it with two-dimensional Reed-Solomon parity data. Commitments to the rows and columns contribute to the data root in the block header. This structure supports availability checks without requiring each light node to download the entire block.
Size limits and the fee basis
Under the v6 submission rules, the maximum transaction size across networks is 8 MiB (8,388,608 bytes). That allowance includes the payment transaction, every blob, and other overhead. The total blob payload must therefore be smaller than 8 MiB; the precise usable capacity depends on the payment’s space requirements and the share version and layout.
The gas budget includes transaction overhead and a component based on the shares needed for each blob. Account type and fee grants can change the overhead. Use fee estimation appropriate to the intended transaction. Calculate the unrounded fee as
fee = gas_limit * gas_price
; when gas price is expressed in TIA per gas unit, round the result up to whole utia (0.000001 TIA) for payment.
RPC access, indexing, archival services, and node hosting can carry separate costs or quotas. Fibre uses a separate escrow and storage-charge model, so its charges require their own calculation.
Encoding the intended data
For the
celestia-node
CLI, the namespace is hex-encoded. Hex-encoded payload data should retain its
0x
prefix, which works across builds before and after the blob submission fix in
celestia-node #5262
. On builds containing that fix, unprefixed data is literal text. The JSON-RPC blob
data
field uses base64 instead; the CLI prefix rule does not change that format.
A light-node submission requires a node configured for the intended network and a fee payer able to cover the posting charge. Mainnet Beta uses TIA, while Mocha testing uses testnet tokens. Those network and funding choices must agree before submission.
Example: Checking two fee offers against a balance
All balances, gas limits, and gas prices in this example are hypothetical. Assume a synchronized Mainnet Beta light node and a signer paying its own fee without a fee grant. Its spendable balance is 0.000723 TIA, and the estimated gas limit is 146,213 units for one blob transaction. Both offered gas prices are assumed to meet the receiving node’s acceptance threshold. The signer’s balance must cover the fee before either offer can be used.
Keep the blob, account state, and gas limit unchanged. Apply
fee = gas_limit * gas_price
to each offer, then round up to whole utia (0.000001 TIA):
| Offered gas price (TIA per gas unit) | Calculated fee (TIA) | Covered by the hypothetical balance? |
|---|---|---|
| 0.000000004 | 0.000585 | Yes |
| 0.000000006 | 0.000878 | No |
Only the lower-priced offer fits this balance. A higher gas price can improve mempool priority, but neither quote establishes publication. Changing the payload can change its share count and gas requirement, so the same fee totals cannot be assumed for a different blob.
For a submitted blob, retain the namespace, returned height, and commitment. A separate retrieval on Mainnet Beta using those values can check the returned bytes against the intended payload. A matching read-back establishes retrieval from that node at that time; a fee estimate or an identifier alone does not establish that result.
Availability and historical retrieval
Data availability sampling gives light nodes probabilistic confidence that block data is available. Its assumptions include sufficient collective sampling and access to an honest bridge node for fraud proofs. Light nodes sample within a rolling window. Retrieving older blobs depends on archival nodes or providers that retain the data; paying a posting fee does not include an archival provider subscription.
Updated ·