Transaction Boost

Wallets and Dapps can seamlessly integrate Blocknative’s Transaction Boost, enabling users to send private transactions to multiple RPC endpoints simultaneously while conveniently monitoring transaction statuses. This integration offers complete customization to adapt to specific preferences.

The table below outlines the supported networks:



Setting up and customizing the endpoint

If no builder or OFA is explicitly defined, Transaction Boost automatically forwards transactions to the following RPC endpoints by default: MEV-Share, MEV-Blocker, MeowRPC,Merkle, Titan,, Builder0x69 ,rsync-builder, Flashbots, Bloxroute , and Blink.

Users can customize the entities that receive their private transactions and program the privacy of their order flow by configuring their RPC URL using the query parameters provided below.

RPC Query Parameters



Include only specific comma-separated RPC endpoints. For example, in the following URL,MoewRPC,Titan, transactions will only be sent to MEV-Blocker, MeowRPC and the Titan builder.



Defaults to false, when set to true it will exclude the RPC endpoints defined in the RPC query parameter. For example in , transactions will be forwarded to all RPC endpoints except Builder0x69.



This specifies the private ID of the transaction originator. For example: It's recommended to keep the ID private, since it allows you to later visualize all the history of your order flow.



If set to true the private transaction is converted to a single-transaction bundle targeting the next 25 blocks. If the transaction has not been confirmed after 25 blocks, the transaction will be dropped and the transaction status will be updated to DROPPED. Example:



Specify the max block number (as an Int) for transaction inclusion.


The maximum delta between current block is 25 blocks. If a block number is specified greater than 25 blocks from current block number, the maxBlockNumber will default to current block number + 25.



Specify privacy hints used by MEV-Share and Merkle OFAs.


If privacyhints are specified, we will forward to MEV-Share and Merkle ONLY (unless you specify one of them). If you specify privacy hints and other RPCs, we will honor the privacy hints and not forward to the other RPCs specified.

Read more on hints here and here.



If sending to MEV-Share, allows specifying of refunds parameters. For example:,address1:perc1. The refund can include 1 or more addresses with an associated percentage refund. Total percentage refunds must be less than 100. Remaining percentage goes to the validator. Read more on refunds here.



If sending to MEV-Share, allows for specifying which builders within MEV-Share can receive the transaction. For example,Titan will only send transactions to rsync and Titan builders on MEV-Share.


Checking Transaction Status

You can check the live status of your private transaction by using the Blocknative Explorer or by simply using the following URLs:

  • Mainnet:

After sending the request, you will receive a JSON response in the following format:

"pendingBlockNumber":9266497, // the pending block where the tx was first received
"maxBlockNumber":9266498, // max block number for the tx to be included, in this example we set it to CURRENT_BLOCK+1
"seenInMempool": false,
"firstSeenInMempool":"", //shows timestamp of when the tx entered mempool (if seen in mempool)
"refund": [{
    "refundRecipient": "0x56C8F2...Bf415a",
    "refundAmount": "10000000", //(in wei)
    "refundTxHash": "0x6a37ff...b8aeb",
"norevert":"true", // is norevert tx
"reorged": false, // set to true if the tx was included in a forked block
"forkedBlockNumber":0, // the forked block number
"forkedBlockHash":"0x..." // the forked block hash

The transaction fields are only revealed for CONFIRMED/FAILED transactions in order to ensure the privacy of pending and rejected transactions.

Example of an endpointMsg response (varies depending on what each builder/OFA returns on their status API endpoint):

"error": "invalid sender", 

Fetching Transactions By OriginID

You can retrieve the entire history of your transactions using your originID on the following URL:

query paramtypedefault




The maximum number of transaction entries to return. If the value exceeds the maximum (100), then the maximum value will be used.




The page number of transactions to retrieve.

Understanding RPC responses

When an RPC receives the transaction, the RPC responds in one of two ways:

Without Error

    "jsonrpc": "2.0",
    "id": 1,
    "result": "0xa129dc71038c20bd5cc58f08836c8616d2201581f203691d888878c734da189b"

With Error

    "id": 1,
    "error": {
        "code": -32603,
        "message": "invalid nonce"
    "jsonrpc": "2.0"

Transaction Boost takes these responses and provides a human-readable status for each endpoint:

Endpoint Status



RPC acknowledged the receipt of the transaction either without an error or with an error as per above. If there is an error message, you can find it in endpointMsg.


RPC did not acknowledge the receipt of the transaction.

Transaction Status



At least one endpoint received the transaction and none of the endpoints that received the transaction responded with an error message.


The transaction was detected on-chain.


The transaction was detected on-chain and it failed.


All endpoint statuses show NOT RECEIVED OR one of the endpoint's nodes rejected the transaction with an error (invalid nonce, invalid sender, underpriced replacement...).


When using the RPC parameter norevert, a transaction will be moved to status DROPPED if the transaction has not been confirmed after 25 blocks.

Last updated