0x03 transactions with
EIP-4844 body semantics and the Osaka EIP-7594 network form. The transaction
body carries the versioned hashes. A blob sidecar carries the blob bytes, KZG
commitments, and cell proofs.
Supported transaction form
Submit the transaction in network form, with its EIP-7594 blob sidecar. The sidecar must contain:- every referenced blob, in transaction order;
- the matching KZG commitments in the same order; and
- the EIP-7594 cell proofs for those blobs.
Submit standard blob transactions to a validator RPC endpoint. Observer RPC
endpoints cannot forward blob sidecars and reject these transactions.
Limits
The six-blob cap applies across the complete block and keeps the largest block
sidecar below the 1 MiB validator message limit.
Blob transactions bypass Metal subblocks. The proposer selects them from the
transaction pool for the execution payload.
Commitment and availability
Each blob transaction lists its ordered versioned hashes. The header’s transaction root commits to those transactions. The blob sidecar has no separate header field. Before broadcasting a proposal, the proposer validates and persists the complete sidecar. Other validators obtain it over a separate consensus channel, verify its KZG proofs against the ordered versioned hashes, and persist it before certifying the block. A block sidecar contains one item per blob transaction in block order. Each item preserves the order of its blobs, commitments, and proofs.Fees
A standard blob transaction pays its transaction fee in the default gas token. Admission requires enough balance to cover the maximum gas cost and blob fee.BLOBBASEFEE value is zero. maxFeePerBlobGas must still be greater
than zero and remains subject to the transaction admission fee cap.
Retrieve sidecars
Call the Metal-specific RPC methodmetal_getBlobSidecars with a block hash:
null unless all
of these conditions hold:
- the block hash is canonical;
- the block is finalized;
- the block contains blobs;
- the complete, verified sidecar is still retained.