Explore Scrypt OrdType=LimitAllIn (FIX) — all-in price-cap incl. fees

[TaprootFreak]

What

The Scrypt FIX API documents an OrdType that is not in the WebSocket/AsyncAPI spec:

40 OrdType ... A = LimitAllIn, requested price/size includes fees
(FIX PDF, "New Order Single" message, Tag 40)

Confirmed by Scrypt FAQ phrasing ("The price you see is what you get") — an order placed with OrdType: A treats the submitted LIMIT Price as the all-in execution price including the spread-embedded commission. The venue will not fill above (BUY) or below (SELL) that bound, fees included.

If accepted over our WebSocket connection too, this is the architecturally correct replacement for the applyPriceCap workaround introduced in #3738. Instead of clamping the LIMIT to reference × (1 ± maxDeviation) and hoping Scrypt's embedded spread doesn't push the effective price past the cap, LimitAllIn makes the cap definitionally binding.

Why this matters

Today's applyPriceCap (in ScryptService after #3738) bounds the quoted price, not the effective cost. If Scrypt's quote moves below the cap but the embedded commission pushes the real fill above what the cap was meant to express, we silently overpay — exactly the 2026-05-21 failure mode #3738 is designed to prevent. LimitAllIn closes that gap.

Open questions to answer in sandbox first

1. Does the WebSocket accept OrdType: "LimitAllIn" (or "A")? The AsyncAPI spec only enumerates [Market, Limit, RFQ]. Send a test order on wss://demo.scrypt.swiss/ws/v1 and observe the ExecutionReport — accepted, rejected, or silently downgraded?
2. If accepted, does the venue actually reject fills past the all-in price, or does it just target that price like a normal LIMIT? The FIX doc is unambiguous ("includes fees") but verify empirically.
3. Price semantics: same quote-per-base convention as regular Limit, or different? Order State Change Matrices in the FIX PDF should clarify.
4. OrderQty interpretation: still in base currency, or in Currency (field 15) terms? FIX doc says "requested price/size includes fees" — does "size includes fees" mean the venue deducts fee from the filled quantity?
5. Currency (FIX Tag 15): optional field defaulting to the base currency. Worth testing both base and quote currencies as the requested size unit for LimitAllIn — different from regular Limit?
6. Cumulative fee reporting: FIX surfaces CumFee (Tag 4016) and CumAmt (Tag 4015) on ExecutionReport. The WebSocket AsyncAPI spec exposes per-fill LastFee + FeeCurrency. Verify both paths populate consistently for LimitAllIn fills.

Implementation sketch (only after sandbox confirms)

// ScryptOrderType enum (scrypt.dto.ts): add LIMIT_ALL_IN = 'LimitAllIn'

// ScryptService.sell — when priceCap is provided, prefer LimitAllIn over plain Limit:
private async placeAndReturnId(
  symbol: string,
  side: ScryptOrderSide,
  orderQty: number,
  price: number,
  allIn = false,
): Promise<string> {
  const ordType = allIn ? ScryptOrderType.LIMIT_ALL_IN : ScryptOrderType.LIMIT;
  // ...
}

// applyPriceCap returns the cap value directly (not min/max of orderbook),
// because the LimitAllIn cap is binding by definition.

Risks / what to watch

• Silent downgrade: if the WS server doesn't recognize LimitAllIn it might fall back to plain Limit without telling us — undermining the safety guarantee. Always assert the ExecutionReport's OrdType echoes our request.
• No-fill rate: a tight all-in cap will more often produce zero fills than a regular Limit. Same trade-off as feat(scrypt): hard-cap LIMIT execution price (Phase 2 / followup to #3736) #3738; the alert path from feat(scrypt): hard-cap LIMIT execution price (Phase 2 / followup to #3736) #3738 is still required.
• Quote/Base size ambiguity: if Scrypt interprets OrderQty differently under LimitAllIn, our amount-conversion math (scrypt.service.ts:284-289) needs adjusting.

Acceptance criteria

• Sandbox test report: WebSocket accepts OrdType: "LimitAllIn" (or doesn't)
• If accepted: small OrdType enum + service-level opt-in for the LM adapter
• If accepted: ScryptAdapter switches sellIfDeficit / sell / buy to use LimitAllIn when a priceCap is in effect; documentation in the adapter and the docs README
• If accepted: tests for the path — both happy-path fill at cap and rejection above cap
• If rejected: comment in the docs README explaining the limitation and that the spread-cap workaround in feat(scrypt): hard-cap LIMIT execution price (Phase 2 / followup to #3736) #3738 remains the protection

References

• FIX API PDF: src/integration/exchange/docs/scrypt-fix-api.pdf, "New Order Single" section, Tag 40
• AsyncAPI WebSocket spec (no LimitAllIn): src/integration/exchange/docs/scrypt-asyncapi.yaml:3145
• Background: feat(scrypt): hard-cap LIMIT execution price (Phase 2 / followup to #3736) #3738 (current spread-cap workaround), feat(scrypt): tighten price deviation cap to 0.3% + notify on overshoot #3736 (initial 0.3 % alert), docs(scrypt): check in vendor AsyncAPI spec as reference #3737 (vendor specs checked in), Scrypt DTO drift vs vendor AsyncAPI spec #3741 (DTO drift)
• 2026-05-21 incident: buy_crypto #123090 — would have been caught by LimitAllIn if available over WS