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 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 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.

{
    "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.

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.

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.