Taker’s Perspective

High-Level Flow

  1. Taker creates an RFQ using [POST] /rfqs. You can pull available instruments from [GET] /instruments and counterparties from [GET] /counterparties.
  2. Taker is able to cancel an RFQ if they wish to do so with [DELETE] /rfqs/{rfq_id}.
  3. Maker, who is a requested counterparty to the RFQ, and is notified over the rfqs JSON-RPCoverWebSockets Notification channel, is then able to submit an order to the RFQ.
  4. Taker, who will be notified of RFQ Orders on the rfq_orders JSON-RPCoverWebSockets Notification channel, is able to attempt to cross by submiting an order using [POST] /orders.
  5. Taker will receive updates about the state of their order via the orders JSON-RPCoverWebSockets Notification channel.
  6. Taker will receive clearing finality via the trades JSON-RPCoverWebSockets Notification channel where the result can either be success or rejection.

Taker managing an RFQ’s Orders

As a Taker, the desk who has created the RFQ, you will receive Orders from the Makers associated with the RFQ.

This pattern describes how as a Taker to build/store/manage Orders from Makers in relation to your RFQ:

  1. Subscribe to the rfq_orders JSON-RPCoverWebSockets WebSockets Notifications channel. Store all of the received events.
  2. Request the [GET] /rfqs/{rfq_id}/orders endpoint for the specific RFQ to return all OPEN associated Orders.
  3. Apply the received events for the associated {rfq_id} to associated group of Orders from the previous step.
  4. From the rfq_orders JSON-RPCoverWebSockets WebSockets Notifications channel, when you receive an event == ADDED, add this order to your storage of RFQ Orders.
  5. From the rfq_orders JSON-RPCoverWebSockets WebSockets Notifications channel, when you receive an event == REMOVED, add this order to your storage of RFQ Orders.

Updates about an RFQ’s Orders are communicated via the rfq_orders JSON-RPCoverWebSockets WebSockets Notifications channel. They are communicated in a manner most similar to that of an Order Book with a depth of L3. As such, you will find your system adding and removing specific associated orders. At the present moment, partial fills are not possible and your system will not receive any update messages.

DRFQv2 - Code Examples

Reach out if you ever need any help! We are more than happy to help.

You will need to update the provided Code Examples with your own Paradigm Access Key and Secret Key.

You can find all existing examples in our GitHub Repo

All examples in this section are in Python3.

DRFQv2: JSON-RPCoverWebSockets

DRFQv2: Authentication + Heartbeat + Subscribe to Notification Channel

Authenticate, establish & maintain a heartbeat and subscribe rfqs JSON-RPCoverWebSockets Notification Channel.

DRFQv2: Auto Market Maker

We encourage you to RFQ all counterparties marked as an “LP” from the [GET] /counterparties as this includes all of Paradigm’s Auto Market Makers.

The desk names of some Auto Market Makers are “DSK2”, “DSK3”, “DSK4”, “DSK5”, and “MT2” on the Test environment.

To note, this is purely a QA tool and not in any way to be used as apart of a trading system.

You can download the Auto Market Maker from here.

DRFQv2: Auto Market Taker

The Auto Market Taker will create random RFQ structures and cross them. You will need to update the counterparties you wish to RFQ (ie your desk acting as a Maker).

To note, this is purely a QA tool and not in any way to be used as apart of a trading system.

You can download the Auto Market Taker from here.