ROME adds an RFQ (request-for-quote) workflow to AX so participants can negotiate block-sized trades off the lit book and have them booked atomically in EP3.

Architecture in one paragraph. Participants speak only to order_gateway over the existing WebSocket. The gateway proxies to a new internal service rome over a remoc RFn channel after running the same risk checks it already does for orders. rome owns the per-request state machine and the in-memory request/quote indexes; it is the only component that talks to EP3's AdminAPI.InsertTwoSidedBlockTrade. ClickHouse rfq_log is the audit trail. No new public network surface.

What's decided. Anonymity is a protocol-level flag, not a UI cosmetic. Targeted RFQs route through the per-user directed channel and skip the public stream. Quote prices are strategy-net (when multi-leg lands), not per-leg. Cancel-on-disconnect mirrors order behavior. Public tape policy: emit RFQ fills with condition: "block" (Bybit/Deribit parity).

What's open. Counterparty mid-flow disconnect policy (A-3295 item 5). Multi-rome sharding strategy (v2). Whether two-sided requests can be partially accepted (currently no). Fee/rebate schedule (commercial gate, A-3297 F7).

What's explicitly v2. Multi-leg strategies, hedge legs, quote aggregation across makers, quote amendment without cancel+resubmit, maker quality scoring, restart recovery, fee rebates, off-protocol OTC accept. All tracked in A-3297.

Add an RFQ workflow to AX. Exchange participants submit a QuoteRequest, other participants subscribe to a public stream of requests and post Quote responses, the requester accepts one quote, and the resulting trade is booked in EP3.

The matching logic and per-request state machine live in a new service rome (Request for Orders Matching Engine). rome is internal — it has no public network surface. Participants reach it over the existing order_gateway WebSocket, which proxies after running the same kind of risk checks it already does for orders.

• Single-instrument requests with size on one or both sides (bid / ask / bid+ask).
• Public and targeted RFQs (targeted via target_makers: Vec<UserId>).
• Protocol-level anonymity (responders see a per-request pseudonym when disclose_identity = false).
• Caller-set, server-enforced expiration on requests and quotes.
• Cancel-on-disconnect on both sides (mirrors order behavior).
• ClickHouse audit log; Prometheus metrics.
• Confirm-then-send modal in the GUI for both submit and accept.
• Per-instrument minimum block size + per-user submission rate limit.
• Public trade-tape print of accepted RFQs with a block condition marker.

• Multi-leg / strategy RFQs and explicit hedge legs.
• Quote aggregation across makers; per-quote AON opt-out.
• Quote amendment (today: cancel + resubmit).
• Partial fills of a request.
• Maker quality / response-rate scoring.
• Restart recovery from rfq_log (today: in-memory only; restart drops live state).
• RFQ-specific fee schedule / maker rebates.
• Cross-engine sharding of rome.
• FIX entrypoint.
• Off-protocol OTC quote acceptance (Bybit-style accept-other-quote).

• We do not build a generic RPC framework. The internal IPC reuses the existing remoc + RFn pattern from marketdata-publisher.
• We do not introduce a new database. Live RFQ state lives in-memory in rome; ClickHouse holds the audit log. Redis is used only for short-lived live-state snapshots needed to recover in-flight Settling requests across a rome restart (see C1 in §7.4.3 and the durable_state module). This piggybacks on AX's existing Redis deployment — no new persistent store is added.

End-to-end picture: requester on the left, rome in the middle, EP3 on the right. Every client message goes through order_gateway; rome has no public surface.

• Public RFQ events — tokio::sync::broadcast<PublicRfqEvent>, one per rome process. Carries QuoteRequestPosted / QuoteRequestRemoved. Each gateway holds exactly one Rome::SubscribeRfqEvents { user_id: None } stream and rebroadcasts in-process to its WS subscribers. Slow consumers Lagged rather than back-pressuring.
• User RFQ events — broadcast::Sender<UserRfqEvent> per user. Carries quotes back to the requester and Filled to both parties. Multiple connections per user (desktop + mobile) all see every event.
• Log — mpsc::Sender<RfqLogRow> to the bounded ClickHouse writer task. Off the hot path; never blocks matching.

Phase 1 — request creation

1. Requester's UI sends RfqRequest::SubmitQuoteRequest{symbol, qty, req_bids, req_asks, expiration} as a JSON WebSocket frame to its connected order_gateway.
2. order_gateway parses, validates the session, and runs check_margin_requirement_using_position_cache against a synthetic worst-case fill at the requested size on each requested side, using the local position_cache and mark_price_cache. If margin is insufficient it short-circuits with RfqReject; rome is never called.
3. order_gateway invokes the shared RomeIpcFn with ToRomeIpc::SubmitQuoteRequest(SubmitQuoteRequestProxy{ caller_user_id, caller_session_id, risk_checked_at_ns, req }). This is a remoc RFn call over the existing TCP-loopback connection — no new serialization per call beyond the bincode-shaped remoc framing.
4. rome mints a request_id, builds RequestEntry { state: Active{quotes:[], expires_at_ns} }, inserts it into the requests DashMap, and pushes the deadline onto the expiration heap.
5. rome broadcasts PublicRfqEvent::QuoteRequestPosted and sends RfqLogRow{event_type=request_submitted} to the bounded log channel.
6. rome returns SubmitQuoteRequestAck { request_id }. Gateway echoes SubmitQuoteRequestResponse to the requester's WS.

Phase 2 — fanout to subscribers

7. Each order_gateway process holds one long-lived Rome::SubscribeRfqEvents { user_id: None } stream. The new event arrives on every gateway's listener task and is rebroadcast on the per-process broadcast::Sender<RfqEvent>.
8. Every WS client subscribed via RfqRequest::SubscribeQuoteRequests receives the event as RfqEvent::QuoteRequestPosted.

Phase 3 — quote submission

9. A responder's UI sends RfqRequest::SubmitQuote{request_id, bid?, ask?, expiration}.
10. The responder's gateway runs check_margin_requirement_using_position_cache for the offered side(s) at the offered price. On failure it short-circuits.
11. Gateway issues Rome::SubmitQuote.
12. rome looks up the RequestEntry in the DashMap, takes its tokio::sync::Mutex, verifies state is Active, mints quote_id, appends to the quotes SmallVec, releases the mutex, and pushes the quote's expiration onto the heap.
13. rome looks up the requester's user_streams entry and broadcasts UserRfqEvent::QuoteReceived on it.
14. rome logs quote_submitted and returns SubmitQuoteAck { quote_id }.
15. The responder's gateway echoes SubmitQuoteResponse back to the responder.
16. The requester's gateway receives the directed event via its Rome::SubscribeRfqEvents { user_id: Some(requester) } listener and forwards it to the requester's WS as RfqEvent::QuoteReceived.

Phase 4 — accept & book (the only EP3-bound critical path)

17. The requester's UI sends RfqRequest::AcceptQuote{quote_id, side}.
18. The requester's gateway risk-checks the acceptor at the locked price for the side being accepted. If the counterparty's user replica is reachable on this gateway, it re-checks the counterparty's margin too.
19. Gateway issues Rome::AcceptQuote.
20. rome resolves quote_id → request_id via quotes_index, takes the RequestEntry mutex, and verifies state is Active and the quote is still present and unexpired.
21. rome mints a fresh ULID cross_id, persists Settling { accepted, cross_id } to Redis via durable_state so a rome crash from this point onwards is reconcilable, transitions Active → Settling { accepted: quote_id }, and drops the mutex.
22. rome calls ep3_admin.insert_two_sided_block_trade(...) with the just-minted ULID populated on TwoSidedBlockTrade.cross_id. cross_id is not a dedup token — Connamara confirmed EP3 does not deduplicate this RPC on any field (see §10) — but it propagates onto the resulting Order records that every Execution on drop-copy carries (api.proto:100, 154, 157), enabling future self-healing of ambiguous outcomes (see step 28 and §12.1). This is the only RPC on the critical path that crosses a process boundary.
23. EP3 books the trade and returns trade_id (happy path; failure branches below).
24. rome retakes the mutex, transitions to Settled { trade_id }, removes the entry from the active maps, and removes the Settling snapshot from Redis.
25. rome broadcasts UserRfqEvent::Filled on both parties' user channels and logs trade_booked.
26. rome returns AcceptQuoteAck { trade_id }. The requester's gateway echoes AcceptQuoteResponse to the requester.
27. Both parties receive RfqEvent::Filled over their WS via their respective Rome::SubscribeRfqEvents { user_id: Some(..) } listeners.
28. Independently, EP3 emits an Execution on the drop-copy stream for each side of the booked block trade. Each Execution carries an embedded Order with block_trade_indicator = true, the propagated cross_id, and the EP3-generated trade_id. order_gateway's existing dropcopy handler (lib.rs:61) updates position_cache for both parties — so the next margin check after this trade already reflects the new positions, with no additional plumbing from rome. This same drop-copy stream is the substrate for the future self-healing path described in the ambiguous-outcome branch below.

Failure branches (replacing the original "may retry" line — see §7.4.1 for the state-machine view and §12.1 for the full layered retry-safety analysis):

• Definitive EP3 reject (4xx) — e.g. INVALID_ARGUMENT, FAILED_PRECONDITION, OUT_OF_RANGE, NOT_FOUND. EP3 did not commit. Step 24 transitions back to Active instead of Settled, the Settling snapshot is removed from Redis, ClickHouse logs trade_book_failed, step 26 returns a typed reject. The quote is still alive; the client may retry against it. Classification follows the same definitive-vs-ambiguous pattern that order-gateway applies to InsertOrder errors (exchange_reject.rs:237).
• Ambiguous EP3 outcome — 5xx, DEADLINE_EXCEEDED, mid-call rome crash, or lost response. EP3 may or may not have committed; rome cannot tell from the synchronous response alone. Step 24 transitions to needs_manual_reconciliation, the Settling snapshot stays in Redis (so it survives subsequent rome restarts and is visible to operators), ClickHouse logs trade_book_ambiguous, step 26 returns a typed error. No auto-retry. Any retry would double-book — Connamara confirmed EP3 does not dedup (§10). V1 path: operator reconciles by checking EP3 and either confirming the trade booked (mark Settled in rome) or rolling back to Active. Planned enhancement (pending vendor confirmation that the request's cross_id propagates to the resulting Order.cross_id): rome subscribes to drop-copy, watches for an Execution whose embedded Order has block_trade_indicator = true AND cross_id == <our persisted cross_id>; on match, auto-transition Settling → Settled using execution.trade_id; on timeout, escalate to operator. This converts the operator path from primary handler to fallback, matching how order-gateway's drop-copy loop already handles ambiguous InsertOrder outcomes.
• rome crash between step 21 and step 24 — on restart, durable_state::load_requests finds the Settling snapshot and routes it to needs_manual_reconciliation (same recovery path as the in-process ambiguous case).

Other layers where a "retry" can fire (user double-click, client WS reconnect with resubmit, gateway → rome IPC retry) do not risk a double-book — rome's state machine cleans up quotes_index and requests on the Settled transition, so a retried Accept for the same quote_id returns QuoteNotFound. They do, however, leave the client unable to learn the trade outcome after a reconnect; see §12.1 for the recovery-UX gap and its planned mitigation (client_accept_id + GetAcceptStatus query, analogous to AX's existing clord_id + GetOrderStatus pattern on the order path).

Solid arrows are synchronous request-response (remoc RFn for gateway↔︎rome, tonic gRPC for rome↔︎EP3, JSON-over-WS for client↔︎gateway). Dashed arrows (-->>) are the corresponding responses. Async-fire arrows (--)) denote events that don't block the caller — remoc broadcast/mpsc subscriptions, log inserts, durable-state writes via the dedicated Redis writer task, and EP3's pre-existing drop-copy stream. The position_cache updates in the happy-path branch flow through machinery that already exists for plain orders; rome itself never pushes them. The Phase 4 alt block enumerates the three outcomes from §2.2 step 23: happy path, definitive 4xx (safe to roll back), and ambiguous (latch to manual reconciliation — see §10 and §12.1). A rome crash anywhere between the Settling persist and the response handler is recovered on restart via durable_state::load_requests, which routes Settling snapshots to the same needs_manual_reconciliation state as in-process ambiguous outcomes.

rome follows the existing AX convention for internal Rust↔︎Rust services (marketdata-publisher): TCP loopback listener + remoc::Connect::io + a RFn shipped over the connection. No .proto, no generated client crate. tonic is used only for the EP3 admin call, because EP3 is the third-party Connamara service.

rome is added to the workspace members list in rs/Cargo.toml. There is no separate rome-client crate — the gateway imports RomeIpcFn and the request/response/error types directly from ax-sdk-internal.

rs/sdk/src/protocol/rfq.rs adds the WebSocket-facing types. They follow the existing convention from order_gateway.rs:27 — single-letter t tag for the request enum, untagged response, single-letter field names where bandwidth matters.

RequestId and QuoteId are u128 carrying the node prefix in the high bits (see §11).

A-3295 (Tier 2) introduces a forward-compat legs: Vec<Leg> representation behind the existing single-instrument shape so that the v2 multi-leg work doesn't break the wire. Single-leg v1 clients deserialize unchanged; multi-leg requests are accepted by the wire and rejected by the engine with not_implemented until A-3297 F1 lands.

Internal-only. Types live in sdk-internal/src/protocol.rs under a new ipc::rome submodule, alongside the existing ipc module that already holds the marketdata-publisher IPC types (ToMdPubIpc, MdPubIpcResponse, MdPubIpcError, MdPubIpcFn).

Server side mirrors marketdata-publisher/src/ipc.rs:66–92: bind a TCP listener on loopback, accept connections, set up remoc::Connect::io, build a RomeIpcFn (an rfn::RFn::new_1 closure that dispatches on ToRomeIpc), send it to the client over a rch::base::Sender<RomeIpcFn>.

Client side mirrors the existing connect_to_md_pub helper in sdk-internal/src/protocol.rs:194–215: connect TCP, set up remoc::Connect::io, receive the RomeIpcFn, hand it to the gateway's AppState.

SubscribeRfqEvents { user_id: None } returns a RomeIpcResponse::PublicRfqEventsSubscription { snapshot, rx } where rx: rch::broadcast::Receiver<PublicRfqEvent>. remoc transparently ships the receiver across the connection; on the gateway side it's just a broadcast::Receiver you can .recv() from. Slow consumers get broadcast::error::RecvError::Lagged, exactly mirroring tokio::sync::broadcast. This is cleaner than a server-stream RPC because the snapshot and the subscription handle arrive atomically in a single response — no separate "snapshot then resume" handshake needed.

SubscribeRfqEvents { user_id: Some(user_id) } returns rch::mpsc::Receiver<UserRfqEvent> because directed events are point-to-point (per-user) rather than fanned out; mpsc makes back-pressure explicit so a stuck gateway can't make rome buffer unboundedly.

Risk-check attestation lives in each proxy struct (risk_checked_at_ns) rather than as a transport header, since remoc has no headers. rome refuses requests where it's missing or stale.

rs/order-gateway/src/state.rs gains:

RomeIpcFn is Clone (an rfn::RFn is just a handle to the remoted closure) so handler tasks can clone-and-call without coordination.

Two long-lived background tasks per gateway process. The public RFQ listener, started at gateway boot:

A per-user listener spawned lazily on first RFQ subscribe for that user and torn down when their last WS connection closes:

ws_service.rs dispatches new variants in the existing match on OrderGatewayRequest. Decision (D2): nest under OrderGatewayRequest::Rfq(RfqRequest) to keep the top-level enum focused on order entry.

Enforced in the gateway, not in rome.

• SubmitQuoteRequest: the requester must be able to honor any fill that could result. Use check_margin_requirement_using_position_cache against a synthetic order at the worst of the last mark vs configured slippage buffer, on whichever side(s) they asked for.
• SubmitQuote: the responder must be able to honor a fill at the offered price on either side they offered. Two checks if two-sided.
• AcceptQuote: the acceptor must be able to honor the fill at the locked price on the side being accepted. The counterparty was already checked at quote-submit time, but margin can move; we re-check the counterparty here too. Counterparty re-check requires the gateway to know the counterparty's current margin state — this works because user replicas are global per gateway process. If the gateway can't re-check (e.g. counterparty is on a different gateway shard), it forwards a flag and rome refuses.

If any check fails the gateway short-circuits with an RfqReject and never calls rome.

The full counterparty re-check on AcceptQuote (M5 in the original rollout plan) is tracked as part of A-3295.

DashMap for sharded lock-free lookup (matches marketdata-publisher). tokio::sync::Mutex on RequestEntry.state because the lock is held across an await in the AcceptQuote critical section. parking_lot elsewhere, per the existing convention.

• DashMap reads and inserts are lock-free across requests.
• A single request's lifecycle is serialized by its per-entry mutex.
• The public RFQ event stream is a remoc rch::broadcast so slow subscribers Lagged rather than back-pressuring publishers; on lag, the gateway's listener task re-subscribes (which atomically returns a fresh snapshot + new receiver in the same RomeIpcResponse::PublicRfqEventsSubscription).
• Per-user directed channels are remoc rch::mpsc because they're point-to-point; the in-process gateway-side fanout to a user's multiple WS connections (desktop + mobile) is done via a local tokio::sync::broadcast per user inside the gateway.

SubmitQuoteRequest. WS frame → gateway.parse → check_margin → RomeIpcFn::call(SubmitQuoteRequest) → rome mints request_id → DashMap insert → publish on public RFQ broadcast → push expiration → log → return SubmitQuoteRequestAck → gateway emits RfqResponse on the WS. No EP3 hop.

SubscribeQuoteRequests. Gateway already holds one process-wide public RFQ subscription returned by RomeIpcFn::call(SubscribeRfqEvents { user_id: None }). On client subscribe: gateway hands the client the cached initial snapshot, then begins forwarding from its in-process public_rfq_events_tx broadcast. No new remoc subscription per WS client; one per gateway process.

SubmitQuote. WS frame → gateway risk-check → RomeIpcFn::call(SubmitQuote) → take request mutex → verify Active → mint quote_id → push to quotes vec → release mutex → publish UserRfqEvent on requester's user mpsc → push expiration → log → SubmitQuoteAck. No EP3 hop.

AcceptQuote — critical path.

1. WS frame → gateway risk-checks acceptor (and counterparty if reachable).
2. Rome::AcceptQuote.
3. Take request mutex.
4. Verify state is Active and the named quote is still present and unexpired.
5. Transition to Settling { accepted: quote_id }. Drop the mutex.
6. Call ep3_admin.insert_two_sided_block_trade(...). This is the unavoidable cross-process latency.
7. Retake the mutex.
8. On success: transition to Settled { trade_id }, broadcast Filled on both parties' directed channels, log, return AcceptQuoteAck { trade_id }.
9. On failure: transition back to Active, log a trade_book_failed row, return a typed error so the gateway can reject the WS frame.

Why release-around-RPC is required. Holding the mutex across the EP3 call would serialize all activity on that request (including new quotes from other responders, which are valid up until we successfully book) for as long as EP3 takes to ack. Because the state is Settling during the gap, concurrent AcceptQuote and Cancel on the same request both reject cleanly.

Cancel (request or quote). Take the per-request mutex, transition to Cancelled (or remove the quote from the vec), broadcast QuoteRequestRemoved or QuoteRemoved, log, return.

The following three tables formalize the request lifecycle, the AcceptQuote critical-path ordering, and the cross-cutting concerns that span multiple transitions. They exist to make implementation review concrete and to give each open design question a specific row to attach to. Test references map to the scenarios in §13.1.