v1.7.0 - 2025-08-27

🔄 Changed - RFQ Response Event Improvements

Breaking Change: WebSocket rfq_response Event Split into Two Distinct Events

The single rfq_response WebSocket event has been split into two semantically distinct events for improved clarity and event handling:

• rfq_post_response: Emitted when a market maker posts a new response to an RFQ request with pricing
• rfq_cancel_response: Emitted when a market maker cancels a previously posted RFQ response

Before:

// Single event type for both posting and cancelling
ws.on('message', (msg) => {
  if (msg.type === 'rfq_response') {
    // Had to check fills array to determine if it was a post or cancel
    if (msg.data.fills && msg.data.fills.length > 0) {
      // Handle new response
    } else {
      // Handle cancellation
    }
  }
});

After:

// Distinct event types for clearer handling
ws.on('message', (msg) => {
  if (msg.type === 'rfq_post_response') {
    // Handle new RFQ response with pricing
    const fills = msg.data.fills; // Always contains pricing data
    processPricing(fills);
  } else if (msg.type === 'rfq_cancel_response') {
    // Handle RFQ response cancellation
    const responseId = msg.data.response_id;
    removePricing(responseId);
  }
});

Benefits:

• Clearer semantics: Event type immediately indicates the action without checking payload
• Improved type safety: TypeScript users get better type inference for each event
• Simplified event handling: No need to check fills array to determine event intent
• Better observability: Easier to track and monitor different RFQ response actions

Migration Guide:

1. Update WebSocket message handlers to check for rfq_post_response and rfq_cancel_response instead of rfq_response
2. Remove any logic that checks the fills array to determine if it's a cancellation
3. Handle each event type with its specific business logic

Note: RFQ cancellations are now properly emitted only on the rfq channel and no longer appear on orderbook channels.