Originators no longer need to guess the number of blobs to send, ensuring optimal utilisation of the 6-blob limit per block.

  "jsonrpc": "2.0",
  "id": "1",
  "method": "eth_sendBlobs”,
  "params": [
      txs,            // Array[String], A list of blob transactions. One transaction per blob permutation.
      maxBlockNumber, // (Optional) String, a hex-encoded string representing the block number of the last block in which the transactions should be included.


Blob pools currently present a challenge to external blob originators, as they function somewhat like a black box. Typically, only a single transaction can be sent, necessitating a guess on the number of blobs to include. Here is an example of where this could be problematic:

Originator A sends a transaction with 6 blobs, but there is a higher paying transaction with 1 blob already in the mempool. Due to the 6-blob per block limit, no blobs from Originator A will be posted.


The eth_sendBlobs endpoint enables the sending of all permutations of blob transactions from a single sender. This is made possible because these blob transactions enter a custom blob pool that allows for multiple transactions with the same nonce. These blobs are then sorted individually to generate the optimal combination and added to our blocks.


If you have 6 blobs to post, you would send a transaction from the same sender with the same nonce containing different permutations of blobs. This means you would end up sending up to 6 transactions, each containing a different number of blobs:

curl -s --data '{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "eth_sendBlobs",
  "params": [{
    "txs": [
      "0x12...ab1",  // Transaction with 1 blob
      "0x34...cd2",  // Transaction with 2 blobs
      "0x56...ef3",  // Transaction with 3 blobs
      "0x78...gh4",  // Transaction with 4 blobs
      "0x9a...ij5",  // Transaction with 5 blobs
      "0xbc...kl6"   // Transaction with 6 blobs
}' -H "Content-Type: application/json" -X POST

Response example


Last updated