ROME (RFQ)

§0Principles

Five invariants govern the design. Everything in the tracker is mechanics that follows from these.

§1Progress & Dependencies

Eight parallel tracks from protocol design through production rollout. The core engine and integration tracks (B, C) are in review; pre-rollout hardening, GUI, and rollout (E–H) are backlog, gated on the core landing. Snapshot 2026-06-08.

Dependency map

How the tracks block one another. Solid arrows are hard blockers; dashed arrows are soft dependencies. The critical path runs B (engine core) → C (integration) → E (hardening) → H (rollout), with D (visibility) and F (GUI) converging before rollout.

§2aArchitecture & data flow

rome is an internal Rust service following the existing AX convention for service-to-service IPC (marketdata-publisher): TCP loopback listener + remoc::Connect::io + a typed RFn shipped over the connection. No .proto, no generated client crate. tonic is used only for the EP3 admin call.

   requester WS ─► gateway (R) ──remoc──► rome ──tonic gRPC──► EP3 admin
                       │                  │              │
                       ▼ broadcast        │              │
              public RFQs ◄─── gateway (P) ◄── responder WS
                                          │
                                          ▼ async insert (batched)
                                     ClickHouse rfq_log

Three channel types out of rome:

• Public RFQ events — tokio::sync::broadcast<PublicRfqEvent>, one per rome process. Each gateway holds one subscription and rebroadcasts. Slow consumers Lagged rather than back-pressuring.
• User RFQ events — broadcast::Sender<UserRfqEvent> per user. Directed quotes and fills. Multiple connections per user all see every event.
• Log — mpsc::Sender<RfqLogRow> to the bounded ClickHouse writer. Off the hot path; never blocks matching.

§2bThe AcceptQuote critical path

The only flow that crosses a process boundary and the only one whose correctness depends on a specific lock-release ordering.

§2cEP3 booking & the no-retry contract

AdminAPI.InsertTwoSidedBlockTrade is the only EP3 RPC rome calls. Connamara confirmed (2026-05-26) that EP3 does not deduplicate this RPC on cross_id or any other field. Identical retry produces two block trades with distinct trade IDs.

The contract:

• Definitive 4xx (e.g. INVALID_ARGUMENT, FAILED_PRECONDITION) — EP3 did not commit. Roll back Settling → Active, return typed reject, client may retry.
• Ambiguous outcome (5xx, DEADLINE_EXCEEDED, crash, lost response) — leave the Settling snapshot in Redis, log trade_book_ambiguous, return typed error. No auto-retry. Operator reconciles.

cross_id is a fresh ULID per cross, minted at accept time, persisted on the Settling snapshot before the EP3 call. It is a correlation key, not an idempotency token. It enables future SearchOrders-based reconcile if the vendor confirms propagation to order records.

§2dState machine & concurrency

Live RFQ state lives in-memory in rome. No new database is introduced.

RequestState transitions: Active → Settling { accepted } → Settled { trade_id } (happy path), with Cancelled, Expired, and needs_manual_reconciliation as terminal/stuck states. A single request's lifecycle is serialized by its per-entry tokio::sync::Mutex (held across await in the AcceptQuote critical section). DashMap reads and inserts are lock-free across requests.

§2eRisk checks & gateway enforcement

Risk checks are enforced in the gateway, not in rome. rome never calls EP3 for margin — it trusts the gateway's attestation.

If any check fails the gateway short-circuits with RfqReject and never calls rome. Risk-check attestation lives in each proxy struct (risk_checked_at_ns) since remoc has no headers.

§2fFailure modes & retry safety

Five layers where a "retry" can fire in the end-to-end booking flow. Only Layer 4 (rome→EP3) can reach EP3 unguarded; the policy is "never auto-retry on ambiguous."

§3Open Questions

The questions the code can't answer. Each carries its current resolution status.

1. Counterparty disconnect between SubmitQuote and AcceptQuote — cancel the quote, or leave it live?
   • Needs discussion Current proposal: cancel the quote when the responder's WS drops, mirroring order behavior. Decision unblocks the cancel-on-disconnect design in A-3295 item 5.
2. Two-sided requests — can a requester partially accept (accept the bid, leave the ask live)?
   • Decided — no Accepting closes the entire request. Partial acceptance deferred to v2 (A-3297 F3).
3. Does EP3 deduplicate InsertTwoSidedBlockTrade?
   • Resolved — no dedup Connamara confirmed (2026-05-26): EP3 does not dedup on cross_id or any other field. Identical retry produces two block trades. The idempotency_key pattern from AdjustAccountBalanceRequest is not exposed on this RPC. Policy: latch-and-page on ambiguous outcomes (§2c).
4. Does EP3 commit-before-respond, and does cross_id propagate to drop-copy order records?
   • Open — vendor follow-up Sub-questions (iii) and (iv) from Q9. Affects whether drop-copy self-healing is viable (auto-transition Settling → Settled by matching Execution.order.cross_id). Does not block V1 — operator reconciliation is the contract regardless.
5. Multi-gateway counterparty re-check on AcceptQuote — what if the counterparty is on a different shard?
   • Open Current behavior: if the counterparty's user replica is not reachable on the caller's gateway, rome refuses the accept. UX cliff at scale. Partially tracked under A-3295.
6. Does BTP support GTC or post_only time-in-force? (for future RFQ-on-Bitnomial)
   • Not applicable to v1 Rome v1 books through EP3 InsertTwoSidedBlockTrade, not BTP. Relevant only if RFQ is extended to the Bitnomial edition.
7. Fee schedule for RFQ fills?
   • Commercial gate Same as standard fees for v1; RFQ-specific rebates are v2 (A-3297 F7). Needs commercial sign-off before scoping.
8. Risk-check attestation trust — risk_checked_at_ns is unsigned, "stale" is undefined, and gateways can lie.
   • Open Cross-cutting concern (C3 in the RFC). Not yet a blocking question, but shapes what the code looks like if rome needs to independently verify margin.

§4Documentation

The reference material this project is built against — the RFC, Linear epics, and related AX plans.

Internal — design & specs

• RFC: ROME — Request for Orders Matching Engine — the founding design (docs/rfc/rome.md); this plan tracks its execution.

Linear — epics & tickets

All under the Perpetuals exchange project · Features & Functionality milestone.

Feature comparison

A 25-row feature matrix (AX v1 vs Bybit RFQ vs Deribit Block RFQ) is maintained in the RFC (§17). Key v1 gaps: no multi-leg strategies, no quote aggregation, no partial fills, no restart recovery, no fee rebates — all deferred to v2 under A-3297.

Related AX plans

• Bitnomial DCM Edition (AIEX) — the parallel Bitnomial integration; Rome v1 books through EP3, not BTP.
• Multi-Accounts — the identity/ownership rekey; not directly blocking Rome but informs account-keying discussions.