Parlay Additional Information

1. The exchange model

The Parlay service is a request-quote-confirm exchange. A participant submits a multi-leg Parlay; Quoters respond with offers; the participant's confirmation triggers a matcher that selects among the offers; matched orders settle after the underlying events resolve.

Participant            Parlay Service                 Quoter
  │                          │                                  │
  │ POST /parlays/request    │                                  │
  │─────────────────────────▶│                                  │
  │     { parlayId }         │── price.ask.new ────────────────▶│
  │◀─────────────────────────│                                  │
  │                          │◀── POST /sp/orders/offers ───────│
  │                          │       (one or more offers)       │
  │◀── price.offers.new ─────│                                  │
  │      (aggregated)        │                                  │
  │                          │                                  │
  │ POST /parlays/confirm    │                                  │
  │─────────────────────────▶│                                  │
  │     { parlayId, quantity } │                                │
  │◀─────────────────────────│                                  │
  │                          │── price.confirm.new ────────────▶│
  │◀── order.matched ────────│                                  │
  │      (preliminary)       │                                  │
  │                          │◀── POST /sp/orders/confirmations │
  │◀── order.finalized ──────│                                  │
  │      (terminal signal)   │                                  │

---

2. Matching engine semantics

The matcher is the most non-obvious piece of the platform. Both audiences need to understand it.

Single-tier per matching round

Within one matching round, the matcher selects only offers at the single best-scored price tier. So if the live pool contains [+6789 $2, +4905 $203], round 1 selects only +6789 $2. The +4905 offer is ignored for that round.

Within a tier: parallel across Quoters

If multiple Quoters sit at the best-scored tier, the matcher selects them all and dispatches price.confirm.new to every selected Quoter simultaneously, followed by order.matched broadcasts in batch. There is no per-Quoter sequencing within a tier.

Why "tied" offers don't always all win

When multiple offers appear to share the same price, the matcher still ranks them deterministically and takes them in order until the participant's quantity is covered. Anyone past that cutoff is not selected, even at the same displayed price.

Ranking uses a composite score:

1. Price — primary factor.
2. max_risk — secondary tiebreaker; a larger offer ranks higher.
3. Submission time — tertiary tiebreaker; an earlier submission wins.

The matcher locks to the top-ranked offer's price value and only takes other offers whose price is exactly equal at full numeric precision, accumulating max_risk until the requested quantity is covered, then stops.

Practical consequences for Quoters whose offers appear to "tie" the winner but don't fill:

When investigating a "tied but didn't fill" case, check in this order:

1. Compare the full-precision price values, not the displayed integer.
2. If truly equal, compare max_risk.
3. If those also match, compare submission time.

If you have a specific parlay ID where this happened, ProphetX can look up the raw offer data and confirm which axis decided the order.

Across tiers: sequential, gated on full accept

After every Quoter confirmation, the platform tracks pending orders for the round. When all Quoters in the current round have responded, if the round was a full accept, the matcher runs again on the remaining quantity and selects the now-top tier.

So tiers do traverse sequentially across rounds, but only when each round fully accepts. Any short fill, reject, or timeout terminates the chain.

Timeouts are counted the same way as rejects. A Quoter that accumulates too many timeouts or rejects is temporarily suspended for 15 minutes.

Live pool, not snapshot

The matcher selects against the live offer pool at confirmation time, not against the offers the participant saw earlier. A better-priced offer that lands between offers-fetch and /parlays/confirm will be used. Implications:

• Participants can receive price improvement beyond the UI display.
• Quoters that revise a quote with a better price before confirmation are selected over older quotes from themselves or competitors.

Latest quote supersedes earlier

When a single Quoter submits multiple quotes for the same parlay, the matcher only considers the most recent one. Older quotes from the same Quoter stay in the pool but are skipped at match time.

---

3. valid_until constraints

Every offer carries a valid_until (Unix nanoseconds). Server-enforced bounds at offer submission:

• Min: 5 seconds in the future ("valid_until must be greater than 5s").
• Max: 10 minutes in the future ("valid_until must be less than 10m0s").

There is no expiry event broadcast when an offer becomes stale. Expired offers are silently filtered out at match time. Participants and UIs must run client-side timers from valid_until; Quoters must submit a new quote if they need extended validity.

---

4. WebSocket events

order.matched is preliminary

order.matched fires the moment the matcher selects a counterparty — at the same time price.confirm.new is dispatched to the Quoter, before the Quoter has confirmed via callback. The order's persisted status at broadcast time is sent_confirmation, not matched. For terminal "trade is done" signals, listen for order.finalized / parlay.finalized.

---

5. Status enums

Order statuses:

Offer statuses: pending → confirming → partial_confirmed / confirmed / rejected.

Match statuses (parlay-level): pending → finalized / failed.

Settlement statuses (Parlay level): tbd → profit / loss / push / void.

---

6. Common errors

---

7. Failed to validate price probability

When you quote Parlays, provide a strike_id and probability for each strike in every non-SGP (single-game Parlay). SGPs do not require probabilities, but including them improves clarity for the participant.

---

8. Outcome IDs (commonly seen)

Full list owned by the ProphetX Markets team.