API Flows

The Cross, End to End

A cross is an instant, not a window. Everything below happens at a cutoff, and the RESToverHTTP [GET] /crosses endpoint lists the cutoffs ahead.

1. Freeze. MPX reads every active Leg settling on the venue and records it. Interest canceled before that read takes no part, and neither does a Submission an earlier cross still holds. From the cutoff until the cross has settled, Reduce, Remove and Cancel on the Submissions it took are refused with error 3609.
2. Price. The venue’s mark for each instrument in the frozen set is captured at the same instant, with the option’s delta beside it. An instrument with no usable mark does not cross this round and costs its Legs nothing.
3. Match. Each instrument is matched on its own, oldest interest first, at the captured mark. Partial fills are always allowed, a desk never crosses with itself, and a pairing smaller than the venue’s minimum Block size is skipped rather than blocking the queue behind it, unless both sides asked for Add Hedge: the minimum is judged on the Block Trade, so a hedge can carry it.
4. Package. The fills between one Submission on each side form a Settlement Package, and packages with the same maker account, the same taker account, the same settlement currency and the same underlying coin are packed into one Block Trade. A Block Trade names each instrument once, so packages that trade one instrument in opposite directions travel in separate Block Trades. The Block Trade is what the venue is asked about and what settles or fails whole, so one account facing two different counterparty accounts has two Block Trades.
5. Hedge. Where both sides of a package asked for Add Hedge, MPX adds one future or perpetual Leg to the package so its delta nets to zero within tolerance. The hedge prices at the same captured mark and travels in the package’s Block Trade. A pairing no hedge can be found for is left unmade, without asking the venue.
6. Validate. Each Block Trade is checked against the venue before anything is sent: the invariants MPX guarantees, the venue’s minimum on the Block Trade with its hedges included, and a simulation the venue answers. A Block Trade the venue would refuse is dropped whole: the pairs of Submissions it carried are not matched against each other again in that cross, their quantities return to the pool with the timestamps they were submitted with, and matching runs again over what is left.
7. Settle. Finalized Block Trades are queued and submitted to the venue one at a time, so Block Trades sharing an account settle in a deterministic order and an outcome never depends on which request reached the venue first. Each one’s packages are checked once more as it is sent, and one package failing that check sends none of them.

The Life of a Submission on the cross Channel

One Channel carries the whole cycle, and type says which moment a message is about. One Channel and not one per event: the ordering guarantee is per Channel, and these events are only worth reading in order.

A message about a cross carries run_id and cutoff_at, which identify it. REDUCED, REMOVED and CANCELLED are your own amendments, which no cross made, so they leave both out. Every message carries one entry per Leg the event is about. quantity on a Leg entry is what the event did to it: taken into the cross, matched, traded, handed back, or left with the venue. remaining_quantity, pending_quantity and crossings_remaining are where the Leg stands once that has been done, so a message is read on its own and a lost one costs one event rather than the state.

locked on every message says whether a cross holds the Submission once the event has happened, and locked_reason names the stage while it does. It turns true on ENTERED, and the message that ends the hold carries false, so there is no separate unlock event. The one release no message announces is a cross that was never matched after its cutoff, and the next read of the Submission shows it.

A Submission absent from a cutoff’s ENTERED stood in no cross, which is how a client learns it was not eligible. A Submission that took no part in a cross is sent nothing for it.

A Cross That Matches Your Interest

1. Subscribed to the cross WS Channel.
2. Receives a message with type == ENTERED when the cutoff takes the Submission into the cross.
3. Receives a message with type == CROSSED carrying quantity and price, the mark both sides traded at. That quantity moves into pending_quantity, and no later cross may offer it.
4. Receives a message with type == SETTLED once the venue has traded it. The quantity leaves pending_quantity as traded, and the message that answers for the last of it carries locked == false.

Where Add Hedge gave the Submission a hedge, hedges carries it beside the Legs, one entry per instrument and side, your side, summed over the counterparties: what the cross assigned on CROSSED, what traded on SETTLED, what came back on RETURNED, and what is still with the venue on SETTLEMENT_UNKNOWN. hedges is empty on ENTERED, since the hedge is chosen after matching.

Your Own Amendments

A reduction, a removal and a cancel are sent on the Channel once they commit, as REDUCED, REMOVED and CANCELLED, carrying the Legs they moved. quantity on a Leg entry is what the amendment took off the offer. Cancel All sends a CANCELLED per Submission it withdrew and nothing for a Submission a cross holds.

A Cross That Matches Nothing

A Leg that nobody wanted the other side of receives ENTERED and nothing further for that cross. It has spent one crossing and its quantity stands in the next cross unchanged.

An instrument that could not be priced is the one outcome a quantity of zero cannot be read for: the Leg comes back untouched and is charged no crossing. price is left out of the message rather than sent as null.

Rejection at Settlement

A Block Trade the venue refuses returns the quantity of every package it carried to the pool.

1. Subscribed to the cross WS Channel.
2. Receives a message with type == RETURNED, with reason == VENUE_REJECTED where the venue refused the Block Trade, or reason == NOT_SENT where it was never sent.
3. The quantity leaves pending_quantity and is offered again by the next cross.

Returned quantity keeps the place in the queue it already had, so there is nothing to resubmit. Only the Block Trade that failed is affected: Block Trades that settled in the same cross are untouched. A refused Block Trade can carry packages of more than one of your Submissions, and each of them receives its own message.

An Answer the Venue Never Gave

1. Subscribed to the cross WS Channel.
2. Receives a message with type == SETTLEMENT_UNKNOWN, with reason == NO_VENUE_ANSWER.

This is quantity in neither state: the platform stopped waiting, so what was matched is neither traded nor back in the pool, and the Leg goes on holding it as pending_quantity. No further message is sent about it, and the RESToverHTTP [GET] /submissions/{submission_id} endpoint is where it is read from then on.

What Happens to Interest That Does Not Trade

Interest is good for a number of crosses, not for a length of time.

• Quantity that matches is out of the pool until the venue answers.
• Quantity that does not match rolls into the next cross keeping its original timestamp, so it stays ahead of interest that arrived later.
• A cross that runs spends one crossing even when it matches nothing. A cross that does not run spends none.
• When the crossings a participant asked for are spent, whatever is left expires.
• A residue too small for the venue’s minimum Block size is finished rather than carried, since no later cross could settle it either.

Leg and Submission States

From the state key on a Leg, and from the RESToverHTTP [GET] /submissions/{submission_id} endpoint:

A Submission is ACTIVE or CANCELLED. What became of the interest is read on the Legs, which reach their own states independently of one another.

What the Channel Does Not Carry

MPX interest is private and a cross pairs two desks who never see each other.

A pairing that never became a package is not on the Channel, whether Add Hedge left it unmade or the venue would not settle it, because naming one would say a counterparty stood opposite the reader. The same rule keeps package identifiers, venue transaction identifiers and counterparties off every message and off the [GET] /fills endpoint.