Maker Integration

The maker API lets a PropAMM maker push quote updates to Bombora over a long-lived WebSocket. Each update carries a signed transaction valid for a single block; cancellations use an empty transaction.

Bombora implements the Flashbots priority update registry, supporting the same /ws/sendquoteupdate frame schema and the same /ws/pamm_quote_stream state stream, as documented for BuilderNet.

Endpoint

Authentication

Bombora issues an API key directly when maker access is granted. Present it in the Authorization header of the WebSocket upgrade request:

Authorization: <api-key>

A Bearer prefix is accepted. A connection without a valid key is rejected with HTTP 401.

Request

Requests and responses are protobuf-encoded binary WebSocket messages. Text messages are ignored.

message PWebsocketQuoteUpdateV1Args {
  bytes tx = 1;
  uint64 block_number = 2;
  bytes replacement_uuid = 3;
  uint64 replacement_seq_number = 4;
  bool disable_cross_region_sharing = 5;
  repeated bytes asset_pairs = 6;
}

Parameters

tx must be a write to the Priority Update Registry at 0xda7afeed01fe625cf15d187a19f94b45f00b8c5f. Any other target, and any other call on the registry, is rejected.

Regions

Connect to the region nearest you.

Each update carries its own disable_cross_region_sharing choice of whether it may be shared with builder regions beyond the one that received it, and that restriction is enforced again on arrival rather than trusted from the routing alone.

Maker protection

When a block is built, Bombora applies the most recent quote it has received and places it ahead of the trade that reads it. A quote still in flight at that moment cannot be applied, so what lands is the freshest update Bombora had received, not necessarily the latest the maker has sent.

To protect makers from takers racing them, a maker can opt in to a freshness buffer, agreed individually during onboarding. With one in place, only trades received more than the buffer before the latest quote are considered during block building:

taker_received_at + freshness_buffer < quote_received_at

With a 50 ms buffer, a quote received at time T is paired only with trades received before T - 50 ms. A trade that does not clear the buffer is never matched with the quote, so it cannot execute against the fresher price. This reduces exposure to stale-quote sniping and quote-stream interruptions.

Timing is judged entirely on receive times observed by Bombora's own infrastructure. Timestamps supplied by makers or takers are never used for this.

Conditional inclusion

Quote updates land only when a matching, freshness-eligible taker is included. Updates without a matching taker do not go onchain.

A matched quote is submitted as part of the block. The proposer may still select a competing builder's block, so submission is the last step Bombora controls.

Replacement

To update a quote, reuse its replacement_uuid, keep the same block_number, and use a higher replacement_seq_number.

For example:

uuid A, block 25,000,001, seq 1  → initial update
uuid A, block 25,000,001, seq 2  → replaces seq 1
uuid A, block 25,000,001, seq 3  → replaces seq 2
uuid A, block 25,000,002, seq 1  → valid reset for the next block

A stale or duplicate sequence cannot replace a newer version. Use a separate UUID for an independent update stream.

Cancellation

Send a request with:

• the same replacement_uuid;
• the relevant block_number;
• a sequence higher than the latest update;
• an empty tx.

asset_pairs may be empty on a cancellation.

Response

Every frame is acknowledged on receipt.

message PWebsocketQuoteUpdateV1Response {
  bytes replacement_uuid = 1;
  uint64 replacement_seq_number = 2;
  uint64 timestamp = 3;
  string error = 4;
}

Match responses to requests using (replacement_uuid, replacement_seq_number).