> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metalntwx.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Blob Transactions and Sidecars

> Submitting, paying for, and retrieving EIP-7594 blob sidecars on Metal

Metal accepts standard blob transactions: type `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.

Metal rejects a blob transaction when its sidecar is missing, empty,
malformed, uses the legacy EIP-4844 sidecar shape, or fails KZG verification.

> [!NOTE]
>
> Submit standard blob transactions to a validator RPC endpoint. Observer RPC
> endpoints cannot forward blob sidecars and reject these transactions.

## Limits

| Limit | Value |
| - | -: |
| Maximum blobs in one block | 6 |
| Sidecar retention | At least 18 days |

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.

```text theme={null}
blobFee = blobGasUsed * maxFeePerBlobGas
```

Metal charges the full blob fee before execution. Blob fees are not refunded.
The EVM fee recipient receives the fee.

The EVM `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 method `metal_getBlobSidecars` with a block hash:

```json theme={null}
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "metal_getBlobSidecars",
  "params": ["0xBLOCK_HASH"]
}
```

The result contains the block's EIP-7594 sidecar items. It is `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.

Sidecars become eligible for pruning after the retention period. Availability
beyond that period depends on when pruning runs.

Clients must verify the returned commitments and blobs against the ordered
versioned hashes in the block transactions.

## Submission failures

Common rejection cases include:

| Condition | Result |
| - | - |
| Type `0x03` transaction without a sidecar | Missing sidecar |
| Legacy EIP-4844 sidecar | Rejected; EIP-7594 is required |
| More than six blobs | Block blob limit exceeded |
| Invalid commitment or cell proof | KZG validation failure |
| Zero `maxFeePerBlobGas` | Invalid blob-fee bid |
| Submission through observer RPC | Validator endpoint required |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.