During the initial development of Blink, searchers will need to be onboarded for access. Searchers should reach out to or @YNBlink / @ciaranmcveigh on telegram or discord for access.

Listen to Transactions

The V1 WebSocket is designed for ease of integration. It auto subscribes and streams base64 serialized transactions. The signatures on the transactions have been altered (hashed) to prevent the use of the transaction outside of the auction.

You can connect to Blink's WebSocket via wss://{$API_KEY}.

As soon as you connect to the WebSocket transactions will sent over that connection.

Base64 Serialized Transaction


Bidding on Transactions

Submitting a Bid

Bids are submitted to Blink via{$API_KEY} as a bundle.

Bundles are submitted using the sendBundle RPC call along with an array of Base58 Serialized transactions. For the user transaction just take the Base64 that has been exposed on the websocket and convert to Base58.

The sendBundle endpoint operates the same way as Jito bundles. Blink enforces the User transaction to be the first in the array. This ensures no malicious MEV on the User's transaction. Bundles that do not put the users transaction first will be rejected. When the bundle is sent to Blink the signatures will be reinserted on the user transaction.

A sample "Post Body" below.

    "id": 1,
    "jsonrpc": "2.0",
    "method": "sendBundle",
    "params": [

The endpoint will return a bundle hash, this is the SHA-256 hash of the bundle's transaction signatures. This will be the same as the expected Jito bundle hash. (Note: you can't compute these yourself as you don't have the real signatures)

    "id": 1,
    "jsonrpc": "2.0",
    "result": "b82190b536340d69c2437e54fe298449d9e44b32d1cb61144454145e01999315"

Analysing Why Bids Fail

The getSignature endpoint allows you to get the real signature after some delay, 30 seconds. This enables you to see the real transaction and work out why your bundle didn't land.

Last updated