# Bid on Transactions

### Submitting a Bid

Bids are submitted to Blink via <https://ethauction.blinklabs.xyz/v1/{$API\\_KEY}> as a bundle.

Bundles are submitted using the [eth\_sendBundle](https://docs.flashbots.net/flashbots-auction/searchers/advanced/rpc-endpoint) RPC call along with an array of transaction rawTxHex's and a block number.

Blink operates exactly the same way as Flashbots bundles with one exception.

Given the searcher doesn't have the rawTxHex for the transaction exposed on the WebSocket they must instead include the txHash for the user's transaction.

For originator bundles (e.g. an approve + swap sequence), use the hash of the **last** transaction in the bundle rather than a single tx hash. Blink will resolve it to the full bundle and prepend all of its transactions ahead of your backrun. See [Access to Originator Bundles](/blink/ethereum/searchers/integration/listen-to-transactions/mevblocker-compatible-v3.md#2-access-to-originator-bundles) for details.

> **Note:** Originator bundles are constructed greedily, so some earlier transactions in the bundle may already be included on-chain by the time you receive it. Your simulation and bid logic should handle this gracefully — treat already-included or reverting transactions as drops, similar to how builders handle `droppingTxHashes`.
>
> Individual transactions from a bundle (e.g. the approve and the swap) may appear via `blink_partialPendingTransactions` early in the block, but a bundle is only available to bid on once it has been constructed and broadcast via `blink_partialPendingBundles`. Do not rely on individual transactions to infer the bundle — wait for the bundle broadcast.

A sample "Post Body" is included below, "txHash" & "rawTxHex" are placeholders for the actual values.

```json
{
    "id": 1,
    "jsonrpc": "2.0",
    "method": "eth_sendBundle",
    "params": [
        {
            "txs": [ 
                "txHash",
                "rawTxHex"
            ],
            "blockNumber": "0x779352"
        }
    ]
}
```

Blink will take the txHash and replace it with the rawTxHex for that transaction. The "refundPercent" & "refundRecipient" fields will also be added.

Your bundle will be immediately sent to all builders that have implemented "refundPercent" & "refundRecipient".

**Blink enforces the user's transaction to be first in the array**. For a single transaction broadcast this is the transaction hash; for a bundle broadcast this is the last transaction's hash. This ensures no malicious MEV on the user's transaction. Bundles that do not put the user's transaction first will be rejected.

For more information on bundles, see [here](https://docs.flashbots.net/flashbots-auction/searchers/advanced/understanding-bundles).

### Authentication

**Authentication is not required** but you can authenticate to establish a searcher "reputation" and be prioritised over searchers when there are matching bids.

You can authenticate using the same methodology as Flashbots, Blink requires you to sign the payload and include the signed payload in the `X-Blink-Signature` header of your request.

Any valid Ethereum key can be used to sign the payload. The Ethereum address associated with this key will be used by Blink to keep track of your requests over time and establish a searcher "reputation". You can change the key you use at any time.

For more information on authentication, see [here](https://docs.flashbots.net/flashbots-auction/searchers/advanced/rpc-endpoint#authentication).

### The Winning Bid

For a given transaction the refund percentage will be fixed for all bundles, consequently, the Searchers who bids the most to the builder should, in theory, land their bundle on-chain.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.blinklabs.xyz/blink/ethereum/searchers/integration/bid-on-transactions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.