RFC: ROME — RFQ Negotiation on the Block-Trade Booking Core

ROME lets participants negotiate block-sized trades off the lit book — a requester asks the market for a price, makers quote, the requester accepts one — and books the result atomically in EP3. The design question this RFC answers is not "how do we book a two-sided trade" (that already shipped) but "how do we run the negotiation on top of it without adding a second settlement path."

The block-trade protocol landed first and independently (A-3622): submit → counterparty affirm → book once to EP3 via InsertTwoSidedBlockTrade, built into the order-gateway, with Postgres as system of record. That work deliberately carved out the two-sided booking spine and dropped the separate rome service. This RFC is re-baselined on that reality: ROME is the negotiation layer, the booking core is the settlement layer, and there is exactly one EP3 caller.

Three conclusions everything else follows from:

1. ROME never calls EP3. An accepted quote is already a consummated agreement — the maker quoted firm, the requester accepted. ROME turns it into a born-affirmed two-sided ticket and hands it to the block-trade booking core, which owns the sole InsertTwoSidedBlockTrade call and the book-exactly-once discipline. No second EP3 caller, no second dedup/idempotency story, no new settlement surface.

2. ROME is not a service. Following the block-trade precedent, RFQ negotiation builds into the order-gateway — it needs only what the gateway already owns (per-user WS, margin gating, EP3 connectivity via the booking core, Redis cross- replica pub/sub). There is no rs/rome crate; the prototype rome service and its compose entry were closed the day they were built.

3. ROME owns negotiation state; the booking core owns settlement state. ROME's state machine ends at "quote accepted → ticket produced." It has no Settling/ Settled/needs_manual_reconciliation — those belong to the ticket. Durability, cross_id minting, never-retry latch, reconciliation, position/fee/PnL flow-through are all inherited unchanged.

Load-bearing commitments. §2–§8 are elaboration.

• D1 — Settle as a block trade, not via EP3's native RFQ. EP3 ships a native Quotes/RFQ service whose acceptance books through InsertOrder-with-quote (a lit-book order/trade). ROME instead settles accepted quotes through the block-trade booking core (InsertTwoSidedBlockTrade, a block print). One EP3 caller, one audited settlement discipline, correct block-print tape semantics. EP3's native service stays available as a future option and as the source of fair-market controls (§6). See §11 alt A1.

• D2 — Born-affirmed ticket, entering the booking core past allege/affirm. The block-trade ticket has an allege→affirm front half. An accepted RFQ has already completed the equivalent handshake, so ROME produces a ticket that is born affirmed: both parties bound, terms fixed by the accepted quote, version_hash computed over those terms. It enters the booking core directly at the accepted → booking hop, skipping pending_counterparty. This is the one new seam ROME adds to the block-trade layer; everything downstream is unchanged. See §11 alt A2.

• D3 — RFQ margin-checks at accept only (single phase). Block-trade tickets reserve in two phases (submitter at submit, counterparty at accept) because a directly- alleged ticket pends for hours and a submit-side gap is an open-limit bypass. An RFQ quote is short-lived and the requester is uncommitted until accept, so ROME checks and reserves both legs in the accept transition, reusing the booking core's can_send_order / ProspectiveOrder gating with both legs supplied at once.

• D4 — Build into the order-gateway; no new crate, no new datastore. Negotiation state is in-memory in the gateway process. The block_trades Postgres table is the settlement SoR. Redis carries only cross-replica directed-event pub/sub — the same role it plays for bt events. No rs/rome crate.

• D5 — Anonymity and targeting are protocol-level, decided at emit time. disclose_identity = false strips the requester's identity to a per-request pseudonym on outgoing WS frames only — it is a presentation flag, not a privacy flag. Targeted RFQs (target_makers: Vec<UserId>) route through the per-user directed channel and never touch the public stream. The audit log and the produced ticket always carry real identities.

• D6 — Cancel-on-disconnect mirrors order behavior. A dropped requester WS cancels their open requests and quotes; a dropped responder WS cancels their open quotes. Subscribers see QuoteRequestRemoved/QuoteRemoved. This is the load-bearing correctness surface (house rule on connection/session state); hardening is A-3295.

• D7 — RFQ types live in sdk-internal until the feature ships. Per the #2068 revert policy — the public SDK must not advertise RFQs before integration — RFQ wire types live in sdk-internal/src/protocol/rfq.rs and WS dispatch handles them as an untagged fallback. Same policy that governs the block-trade "bt" tag.

• D8 — Single-leg v1. The booking core is single-leg (InsertTwoSidedBlockTrade carries one symbol/price/quantity), and the EP3 atomic-multi-leg question is unanswered in #ext-architect-connamara (block-trade plan §2f). Multi-leg RFQs are v2, blocked on both the vendor answer and the booking core gaining a multi-leg form. The wire carries a forward-compat legs shim (§4.1) so v2 doesn't break v1 clients.

This is the center of the RFC. ROME is layered, not standalone.

Per Brett's framing (2026-06-09, block-trade plan §2d): block trades "use a subset of ROME which is the two-sided trade booking thing." That subset landed first; ROME builds the negotiation on top.

ROME's deliverable is the first three rows. Everything below the line ROME reuses — wired, tested, live-bound under A-3622.

The load-bearing constraint inherited from the block-trade work (plan §2h): there is exactly one path to InsertTwoSidedBlockTrade — the order-gateway booking core. The RPC does not dedup (vendor-confirmed 2026-05-26) and exposes no idempotency_key, so the book-exactly-once discipline (snapshot-before-call, definitive-vs-ambiguous classifier, never-retry latch, Postgres CAS, reconciliation) is non-negotiable and lives in exactly one place. A second caller would mean a second, differently-behaved dedup story. ROME feeds the core consummated tickets; it never books itself.

Two ways to map an accepted RFQ onto the booking core:

• (A) Re-run allege/affirm. ROME submits a ticket on the requester's behalf and synthesizes the maker's affirm. Reuses the public bt path verbatim but adds a redundant round-trip and a window where the synthesized affirm could be lost.
• (B) Born-affirmed ticket — decided (D2). ROME hands the core an already-consummated two-sided ticket that enters at accepted → booking directly. The RFQ accept is the affirmation. No redundant round-trip, no extra loss window.

The booking core exposes an internal, non-public born-affirmed entry point that ROME alone calls with: buyer account, seller account, symbol, price, quantity, both legs' client order ids, and a version_hash over the economic terms. The core's economic-terms binding (compute_version_hash) still applies, computed over the accepted quote. From the entry point down, settlement is the block-trade protocol verbatim.

• One EP3 call. InsertTwoSidedBlockTrade, two-sided and atomic, called exactly once after consummation.
• Book-exactly-once. Never auto-retry. classify_booking_error splits outcomes — definitive-no-commit = INVALID_ARGUMENT, FAILED_PRECONDITION, OUT_OF_RANGE, NOT_FOUND, ALREADY_EXISTS, UNAUTHENTICATED, PERMISSION_DENIED, RESOURCE_EXHAUSTED; ambiguous (latch, never retry) = UNAVAILABLE, DEADLINE_EXCEEDED, INTERNAL, CANCELLED, ABORTED, UNKNOWN, DATA_LOSS, UNIMPLEMENTED, plus any non-gRPC error. Ambiguous outcomes latch to needs_manual_reconciliation.
• cross_id. Fresh ULID minted by the core, snapshotted to Postgres before the EP3 call, propagated to both order legs and every drop-copy Execution (vendor-confirmed 2026-05-27) — enabling self-healing reconcile and SearchOrders(cross_id=…) lookups. ROME does not mint or own cross_id.
• Durability + recovery. Postgres block_trades is the SoR; transitions are CAS; a 1s sweeper drives the reconciliation latch; restart rebuilds in-flight ticket state from Postgres.
• Position / fee / PnL flow-through. Drop-copy Executions with block_trade_indicator = true update positions, fees, and PnL through existing machinery — no ROME plumbing.

Earlier drafts of this RFC owned a Settling/Settled/needs_manual_reconciliation state machine, cross_id minting, a Redis durable_state module, a layered ambiguous- outcome retry-safety analysis, and the EP3 idempotency contract. All of that moved to the block-trade protocol. ROME keeps only: produce the ticket, observe its terminal state, emit the negotiation-side Filled/reject event. If the seam or its semantics change, that is a block-trade-plan change, not a ROME change.

In-process in the order-gateway. Owns the request/quote book and the negotiation lifecycle. Does not own settlement.

The per-entry lock is parking_lot::Mutex, not tokio::sync::Mutex: ROME never holds a lock across an await to EP3. The only cross-process call happens inside the booking core, after ROME has produced the ticket and released the entry. Accepted records the ticket_id purely so a status query can correlate the negotiation with its settlement.

• DashMap shards lookup across requests; a single request's lifecycle is serialized by its per-entry mutex.
• Accept transition: take the entry mutex, verify Active and the quote is present/unexpired, flip to Accepted, build the ticket, drop the mutex, then call the booking core. Concurrent AcceptQuote/Cancel on the same request see Accepted and reject cleanly — exactly-one-winner from mutex-then-flip ordering, same as the order path.
• Competing-quote DONE_AWAY notifications are cloned under the mutex and sent after release (clone-and-release), so a slow directed consumer can't stall the entry.

SubmitQuoteRequest — WS frame → mint request_id → DashMap insert → publish on public/targeted stream → push expiration → log → SubmitQuoteRequestResponse. No margin reserve, no EP3 hop; the requester is committed only at accept.

SubmitQuote — WS frame → gateway risk-*check* (no reserve) → take entry mutex → verify Active → mint quote_id → append → release → emit QuoteReceived → push expiration → log → SubmitQuoteResponse. No EP3 hop; the maker is committed only when the requester accepts.

AcceptQuote (the handoff) —

1. WS frame → gateway risk-checks and reserves both legs at the locked price (single margin phase, D3). Fail → typed RfqReject, nothing produced.
2. Take entry mutex; verify Active, quote present and unexpired.
3. Flip Active → Accepted; mark competing quotes DONE_AWAY; build the born-affirmed ticket. Drop the mutex.
4. Call the booking core's born-affirmed entry point (§2.3). Settlement begins here; the block-trade protocol owns correctness from this point.
5. On the ticket reaching a terminal state, emit Filled (cleared) or a pending/reject event to both parties; log.

ROME never retries the EP3 call and never inspects EP3 status codes — that is the core's job.

One in-process task. State is BinaryHeap<Reverse<(deadline_ns, key)>> behind a parking_lot::Mutex. Loop: peek, sleep to the head deadline, pop, look up the entry, take its mutex, and if still Active transition to Expired (or drop the quote), then broadcast QuoteRequestRemoved/QuoteRemoved and log. If the entry already moved (Accepted/Cancelled), drop the heap entry silently. Once Accepted, expiration is a no-op — the produced ticket has its own TTL in the booking core (end-of-day default, settable shorter). Same pattern trade-engine uses for GTD orders.

Wire types in sdk-internal/src/protocol/rfq.rs (graduating to the public SDK when RFQ ships, D7). They follow the conventions frozen in the #2087 review (block-trade plan §2g), shared with the block-trade bt family.

Conventions (§2g):

• y = state on the wire (st/s rejected — collisions).
• Row types noun-typed for graduation: QuoteDetails mirrors public OrderDetails; RfqFilled/RfqCancelAck/RfqReject carry the prefix, matching ticket analogs.
• Prefixed-ULID ids: R-… requests, Q-… quotes (modeled on O-/L-); tickets mint their own B- prefix. Internally carried as u128 for compact indexing.
• Optional-sides quote shape: RfqQuote is a struct of Option<Decimal> bid/ask (key presence encodes sides), validated in validate() (≥1 side, positive, not crossed/locked). Ingest must call validate and the gateway must echo the parsed quote — unknown keys are ignored on decode, so a mistyped side key silently degrades to one-sided (pinned in submit_quote_ignores_unknown_keys). RfqQuoteSides tokens are b/a/2.

Settlement identifiers (cross_id, trade_id, ticket B-…) are not ROME's to mint (§2.4). The constraint that they must not be derivable from request_id — which the public stream exposes — is satisfied automatically: the core mints fresh ULIDs independent of any RFQ field.

A-3295 introduces a legs: Vec<Leg> representation behind the single-instrument shape so 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 — and only once the EP3 multi-leg block question is answered (D8).

Every client message goes through order_gateway; ROME and the booking core both live in-process there.

Two state machines, one handoff. ROME negotiation (in-memory): Active → {Cancelled, Expired, Accepted}; Accepted is terminal for ROME. Block-trade ticket (Postgres SoR, owned by the core): enters at accepted → booking, then cleared (or needs_manual_reconciliation). ROME observes the outcome to emit Filled but does not drive it.

Everything in the alt block is the block-trade protocol's behavior, reproduced only so the end-to-end path is legible. The authoritative settlement spec is A-3622; §2 is the seam.

EP3 ships a native Quotes/RFQ service (connamara/ep3/quotes/v1beta1/), distinct from the block-trade API. ROME mirrors its semantics and sources its fair-market controls but does not use it to settle (D1).

What it does. CreateRequestForQuote (requester) → CreateQuote (dealer, references the RFQ) → requester accepts. There is no AcceptQuote RPC: acceptance is InsertOrder with the quote field set — the accepted quote becomes ACCEPTED, competitors become DONE_AWAY. Dealers may PassQuote; either side may DeleteQuote. FIX wraps the lifecycle (QuoteRequest, Quote, QuoteStatusReport, QuoteResponse <AJ>; HIT_LIFT synthesizes a LIMIT+IOC order with order.quote set). The key fact: native acceptance settles through InsertOrder — a lit-book order/trade, a different primitive from InsertTwoSidedBlockTrade.

Fair-market controls ROME folds in (§3.2 knobs):

• Reciprocal firm associations govern RFQ visibility (set once, both directions); anonymity is a presentation choice, not a requirement — matches ROME's disclose_identity.
• Minimum Unaffiliated Firms — the floor of distinct unaffiliated firms a targeted RFQ must reach for a fair market (SEF/CFTC). V1: config knob, unenforced (mirrors how the block-trade prototype stubs min-block-size); enforcement lands at the AIEX/SEF tier.
• Self-RFQ restriction (quotesServer.behavior.restrictFirmAcceptOwnRfqs) — a policy flag ROME carries so an AIEX rulebook can forbid accepting RFQs from same-firm accounts.

The native service remains available if AIEX later needs EP3-side RFQ-to-trade with DONE_AWAY audit on EP3 (open question Q8); D1 does not foreclose it.

Negotiation audit → ClickHouse (settlement is recorded by the block-trade protocol in Postgres; the two correlate on ticket_id/cross_id):

event_type: request_submitted, quote_submitted, quote_accepted, quote_done_away, request_cancelled, quote_cancelled, request_expired, quote_expired, ticket_produced, trade_booked, trade_book_failed. The settlement-outcome values (trade_booked/trade_book_failed) are written by ROME on observing the ticket's terminal state, for correlation only — they are not the authoritative settlement record.

Writer: bounded mpsc::Sender<RfqLogRow>, batched async inserts, drop-oldest-on-full with a rome.log_drops counter — never block a hot path on logging.

Anonymity + the log (D5). ClickHouse rows always carry the real user_id for compliance; stripping happens only at RfqEvent emission. The produced ticket records real buyer/seller accounts regardless.

Trade-tape marker. RFQ prints are block trades — drop-copy Executions carry block_trade_indicator = true, and the public-tape block condition marker rides with the block-trade tape work (A-3294).

Prometheus (ROME negotiation path; settlement metrics are the core's): rome_active_requests, rome_active_quotes, rome_event_total{type}, rome_accept_to_ticket_latency_seconds (accept → ticket produced), rome_tickets_produced_total, rome_log_drops_total, rome_public_rfq_subscribers, rome_public_rfq_lagged_total. Tracked under A-3219.

Negotiation-layer failures are ROME's; settlement-layer failures are inherited and listed for completeness only.

The detailed retry-safety-by-layer analysis (double-click, reconnect-resubmit, gateway retry, core→EP3 retry, restart) is the block-trade protocol's. ROME's only contribution is accept-idempotency (Q5): a reconnecting client that re-issues AcceptQuote after the quote was consumed gets a clean reject, but cannot yet distinguish "trade booking" from "quote expired" — a recovery-UX gap, tracked, not a correctness gap.

Integration tests under rs/order-gateway/tests/, using ax_test_utils containers (Postgres, ClickHouse, Redis) and Ep3Mock (whose InsertTwoSidedBlockTrade validates parties, preserves cross_id, emits drop-copy fills with block_trade_indicator = true). Each drives real WS clients against the gateway. Tracked under A-3260.

Required scenarios:

1. Happy-path bid: two responders quote, requester accepts, a born-affirmed ticket books and clears, both see Filled, rfq_log and the block_trades row correlate on ticket_id.
2. Happy-path two-sided: requester asks bid+ask, accepts the bid; ask side discarded.
3. Quote after request expires → reject.
4. Accept after quote expires → reject.
5. Concurrent AcceptQuote same request → exactly one wins; exactly one ticket produced → no double-book.
6. Definitive EP3 4xx → ticket rejected, reservations released, both notified, trade_book_failed logged. 6a. Ambiguous EP3 (5xx / DEADLINE_EXCEEDED / crash mid-call) → latch needs_manual_reconciliation, no auto-retry, operator/sweeper path (primarily a block-trade test, asserted through the RFQ entry point). 6b. Client-retry-after-accept → clean reject, no second ticket, no duplicate core call.
7. Requester WS disconnect → requests cancelled; subscribers see QuoteRequestRemoved.
8. Responder WS disconnect → quotes cancelled.
9. Gateway restart with in-flight ticket → settlement recovers from Postgres; non-accepted negotiation state gone by design.
10. Margin moves between SubmitQuote and AcceptQuote → AcceptQuote rejected, no ticket.
11. Snapshot tests (insta, inline) for every RfqRequest/RfqEvent, incl. optional-sides RfqQuote and the submit_quote_ignores_unknown_keys degradation guard.
12. Side-enforcement matrix — quote-includes-disallowed-side, accept-on-missing-side, two-sided-on-one-sided, empty-quote.
13. Targeted-RFQ visibility: a non-targeted maker on the public stream must not see a targeted QuoteRequestPosted.
14. Anonymous RFQ: outgoing QuoteRequestPosted must not contain the requester's user_id; the rfq_log row and the ticket carry real accounts.
15. Competing-quote DONE_AWAY: on accept, other quotes emit QuoteRemoved with a done-away reason.
16. position_cache flow-through: after clear, a tight opposite-side follow-on order reflects the new position (inherited block-trade behavior; regression guard).