eth_sendBundle

Submit a bundle of Ethereum transactions for ordered execution within a block. Transactions execute in the order submitted, with explicit controls for revertable and optional transactions.

Endpoint

https://rpc.bombora.buildClick to copy

See Getting Started for regional endpoints.

Request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_sendBundle",
  "params": [
    {
      "txs": ["0x...", "0x..."],
      "blockNumber": "0x1234567",
      "minTimestamp": 1234567890,
      "maxTimestamp": 1234567899,
      "revertingTxHashes": ["0x..."],
      "droppingTxHashes": ["0x..."],
      "replacementUuid": "uuid-string",
      "replacementSeqNumber": 1,
      "refundPercent": 50,
      "refundRecipient": "0x...",
      "refundTxHashes": ["0x..."]
    }
  ]
}

Parameters

Parameter	Required	Description
`txs`	Yes	Array of signed transactions to execute in order (RLP-encoded hex).
`blockNumber`	No	Target block number (hex). Defaults to the next block.
`minTimestamp`	No	Earliest unix timestamp at which the bundle is valid.
`maxTimestamp`	No	Latest unix timestamp at which the bundle is valid.
`revertingTxHashes`	No	Transaction hashes that are allowed to revert, or to be omitted, without invalidating the bundle. A transaction in this set that executes and reverts stays in the block in its reverted state.
`droppingTxHashes`	No	Transaction hashes that are allowed to be omitted, but never to revert. If one of these transactions fails validation or execution, it is omitted and the bundle can continue. If it executes successfully, it is included.
`replacementUuid`	No	A UUID used to replace or cancel this bundle. Submitting a new bundle with the same UUID replaces the previous one.
`replacementSeqNumber`	No	Monotonically increasing sequence number for bundles sharing the same `replacementUuid`. Later bundles must have a higher sequence or they are dropped. If `0` or omitted, ordering falls back to builder receive time.
`refundPercent`	No	Percentage (0–99) of the bundle's MEV profit to refund. `0` or omitted means no refund.
`refundRecipient`	No	Address to receive the refund. Defaults to the signer of the first transaction.
`refundTxHashes`	No	Transaction hash used to anchor the refund calculation. Defaults to the last transaction. Max 1 entry.

Execution Semantics

Transactions within a bundle execute in the order submitted.

By default, any transaction failure invalidates the bundle. The two hash sets relax that, and they grant two separate permissions:

Transaction listed in	May be omitted from the bundle	May be included in a reverted state
Neither set	No	No
`revertingTxHashes`	Yes	Yes
`droppingTxHashes`	Yes	No

Strict all-or-nothing behavior therefore applies only to transactions that are not listed in revertingTxHashes or droppingTxHashes.

Refunds

When refundPercent is greater than zero, Bombora constructs a refund transaction after executing the bundle. The refund amount is:

refund = (bundle_profit * refundPercent / 100) - transfer_cost

If the refund anchor transaction (from refundTxHashes, or the last tx by default) is never evaluated, or the refund transaction fails to construct, the bundle is dropped.

Replacement and Cancellation

Submitting a new bundle with the same replacementUuid replaces the previous bundle. Submitting an empty txs array with a replacementUuid is treated as a cancellation. You can also use eth_cancelBundle to cancel by UUID.

When multiple replacements may be in flight, set replacementSeqNumber to a monotonically increasing value so the builder can order them deterministically instead of relying on receive time. A bundle with a sequence number lower than or equal to one already seen for the same replacementUuid is dropped.

Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "bundleHash": "0x..."
  }
}

Field	Description
`bundleHash`	32-byte hash identifying the submitted bundle. Pass it to `bombora_getBundleStats` to retrieve its status.

A successful response means the bundle was accepted for inclusion. It does not guarantee the bundle will be included in a block.