Solana Kolibrio OFA Searcher Connection

GRPC Latest protofile:

Current gRPC connection URL: https://searcher.kolibr.ioarrow-up-right (requires authorization header in metadata)

Current WS connection URL: wss://solana.kolibr.io/ws (requires x-api-key header)

For the connection, a searcher requires an ApiKey that can be retrieved from the Kolibrio team


Glossary: OFA - order flow auction Originator - entity that produces a transaction Signal - originator’s transaction with metadata Jito - https://www.jito.wtf/arrow-up-right Jito Backrun - transaction bundle that consists of 1 to 3 transactions and follows the following rules:

  • Transaction order is guaranteed

  • Every transaction in a bundle simulates on top of the previous one

  • If one of the transactions reverts, the whole bundle will not be mined

Priority Backrun - a set of transactions with a priority feearrow-up-right. Order is not guaranteed, but most likely they will be sorted by Fee. No revert protection. Faster inclusion


Workflow: After the connection establishment and stream subscription, searchers will start to receive signals Each signal consists of the following fields:

{
"id": string,
"revshare_address": string,
"message": []byte,
"priority_revshare_address": string,
}

id

unique identification of the target transaction. The searcher should pass it back to bind backrun transactions to the target transaction.

message

bytes array that represents Solana Transaction Messagearrow-up-right

revshare_address

solana address where searcher should do transfer as bribe in jito backrun transaction

priority_revshare_address

solana address where searcher should do transfer as bribe in priority backrun transaction

To submit a result, a searcher needs to send a message in a following format:

id

unique identification of the target transaction. Refer to the id from the signal.

jito_backrun

array of fully signed backrun transactions in bytes for Jito bundle and transfer to revshare_address this transactios will be sent in jito bundle with target signal

priority_backrun

array of fully signed backrun transactions in bytes for sending with the fastest inclusion and transfer to priority_revshare_address this transactios will be sent in via fastest swqos & paladin connection. learn more below

⚠️NOTE: For a bid to be valid, the searcher transaction MUST include a separate transfer instruction to the revshare_address or priority_revshare_address.


WS example:

GRPC example:

file-archive
18KB


⚡ Priority Backruns

Due to Solana’s high-throughput architecture and the varying broadcast requirements of different originators, there are edge cases where the Kolibrio target signal reaches the block leader before the full atomic Kolibrio bundle (i.e., the original transaction + arbitrage).

If this happens, and the signal gets included in a block without the associated arbitrage backrun, the arbitrage opportunity remains live on-chain. In such cases, the first random searcher to detect the transaction in the shred stream can still capture the value.

To handle these edge cases, Kolibrio introduces fallback auctions via Priority Backruns — a fast, parallel execution path for high-value recovery, which gives a clear advantage to Kolibrio participants over regular shred-stream searchers.

🛠 How it Works

  • Optional fallback: In addition to the standard jito_backrun, searchers can include a priority_backrun — a high-speed backup arbitrage path.

  • Requirements for a priority_backrun:

    • Should include a priority fee.

    • Must send a tip to a priority_revshare_address defined by the originator.

  • Execution mechanics:

    • Priority backruns are broadcast via SWQoS and Paladin low-latency channels with ~2 ms artificial delays between each, based on Kolibrio Tip — higher tips are sent earlier (resulting in ~5–10 index positions between broadcasts).

    • Kolibrio will only broadcast priority_backruns if:

      • The target signal was created by a high-quality originator (e.g., trusted dApp, not a spam bot).

      • There is a credible probability that the signal will land non-atomically (i.e., without its associated arbitrage bundle).

  • Risk/Reward trade-off:

    • priority_backrun transactions may revert if the arbitrage is already handled in the original atomic bundle.

    • However, they give searchers a chance to catch leftover MEV faster than public shred-stream observers.

📦 How to Land a Priority Backrun

To land a priority backrun, your goal is to get as close as possible to the original signal in block position.

You need to balance:

  • 🧾 Priority Fee — affects your on-chain placement.

  • 💸 Kolibrio Tip — determines the broadcast order via SWQoS.

Kolibrio broadcasts selected backruns using SWQoS + Paladin, with ~2 ms artificial delays (resulting in ~5–10 index positions between each).

⚠️ A low priority fee can place you too far below the target, even if your Kolibrio Tip is high. Your goal is to land close — tune precisely for maximum impact.


Multiregion:

Kolibrio's main engine is located in Amsterdam, but there are also endpoints in other regions.

If a user transaction is created outside the EU, it will still be forwarded to the main server in Amsterdam — and if you're connected only to it, you'll receive it. However, a small percentage of transactions might appear slightly faster on another regional endpoint.

Recommendation: Use the Amsterdam main server for both listening to the stream and submitting transactions, but also monitor other regional endpoints to gain a small timing advantage.

Region

GRPC URL

WS URL

Amsterdam Main

wss://solana.kolibr.io/ws

Tokyo

wss://tokyo-solana.kolibr.io/ws

Salt Lake City

wss://slc-solana.kolibr.io/ws

New York

wss://ny-solana.kolibr.io/ws

Frankfurt

wss://fra-solana.kolibr.io/ws


⚠️ Main Rule: NO FORM OF FRONTRUNNING IS ALLOWED.

Kolibrio system continuously monitors searchers behavior and runs analytics on top of target signal transactions. if any malicious behavior such as non atomic frontruns will be discovered - searcher will receive forever ban.

Last updated