Maker’s Perspective

High-Level Flow

1. Taker will create an RFQ and the Maker will be notified on the rfqs JSON-RPCoverWebSockets Notification channel.
2. Maker is able to create an order using [POST] /orders.
3. Maker is able to cancel an existing order with [DELETE] /orders or [DELETE] /orders/{order_id}.
4. Taker submits a crossing Order that matches with the Maker’s existing order.
5. Maker will receive updates about the state of their order via the orders JSON-RPCoverWebSockets Notification channel.
6. Maker will receive clearing finality via the trades JSON-RPCoverWebSockets Notification channel where the result can either be success or rejection.

Maker managing Orders

• Each RFQ has a side_layering_limit attribute which communicates to Makers how many orders per side they are able to have with a state == OPEN at any one time. By default, and Takers are not able to configure this, all RFQs for the moment will have a side_layering_limit == 1. Therefore, Makers are only able to have 1x state == OPEN order per side per RFQ at any point in time.
• Users are able to create Orders via [POST] /orders.
• Users are able to replace existing Orders via [PUT] /orders/{order_id}.
• Users are able to cancel an Order via [DELETE] /orders/{order_id}.
• Users are able to cancel all Orders via [DELETE] /orders.
• Creating and replacing Orders will always return with a state == PENDING in response to the RESToverHTTP request. This indicates the Order is being processed by the matching engine. The Order only becomes actionable by any user when it’s state value changes to OPEN. This is communicated via the orders JSON-RPCoverWebSockets Notification channel.
• Replacing an Order is an atomic Cancel & Create request in the system. This means the original Order will lose it’s time priority.