{"id":"297a81f3-262b-45ef-863d-c0fba2044865","arxiv_id":"2608.02424","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A programmable switch can maintain a limit order book and run ML price-movement inference in the data plane, achieving microsecond latency with accuracy close to server benchmarks.","lead":"This paper builds limit order books and runs machine-learning price predictions inside programmable network switches instead of on servers, reporting microsecond latency and near-server accuracy. If the results hold, trading firms could shift prediction workloads into the network fabric, cutting latency and server load at once.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Evaluated LOBIN prototype does not process MBO cancellation/update actions, so the in-switch LOB diverges from the real book and the reported ML and hybrid-deployment numbers are computed on corrupted state.","rationale":"I read the paper as a proof-of-concept that limit order books can be constructed in programmable P4 switches and used for ML prediction. For that central claim to hold, the in-switch LOB must track the true book under real MBO feeds. The paper's pseudocode, Algorithms 1–2, and its own Discussion show that the evaluated prototype does not process order cancellations or updates. The reader's weakest_assumption identifies exactly this, and I agree it is the most load-bearing concern. It is more severe than a missing optimization: every supervised feature and label in the ML evaluation derives from a book that accumulates phantom volume and fails to remove canceled orders, so the reported accuracy/F1 scores, the on-switch/on-server comparison, and the hybrid confidence-threshold analysis are not trustworthy as measurements of prediction on real market state. At the same time, the issue is localized, explicitly acknowledged, and fixable in principle; the paper is transparent about the prototype's limitations. A conditional verdict that requires cancellation/update handling or a clear scope restriction to add-only feeds is the right frame, so I do not change the reader's verdict.","tokens_in":17590,"tokens_out":5696,"duration_ms":61081,"concrete_test":"Replay the same NASDAQ TotalView-ITCH data through the LOBIN P4 target while logging the action field of each message, and independently reconstruct the ground-truth LOB using the ITCH specification. Compare LOBIN's mid-price time series against ground truth message by message. If LOBIN's mid-price differs on more than a small fraction (e.g., >1%) of messages across FANG, EXC, and AZN, then the features/labels in Table I are corrupted; the evaluation must be rerun after implementing cancellation/update/delete handling. If the divergence is below tolerance, the concern is defused.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim requires that the P4 LOB construction faithfully reflects the real order book when fed raw MBO messages. Section III-A explicitly lists the MBO action field as including add, cancel, and update; Algorithms 1–2 are the advertised LOB-update logic, yet neither algorithm branches on the action field, tracks order IDs, or handles cancellation/delete/replacement messages. A cancel message entering Algorithm 1 is indistinguishable from a new order: line 18 executes R_l[Po] += So, inflating depth and potentially shifting the best-bid/ask registers. A replace/update similarly corrupts state. The paper itself concedes this in Section VI: 'LOBIN does not store MBO states but can update volumes within LOBs, allowing for order cancellations and updates, with minor changes to the current prototype.' Because the ML features and the 100-tick mid-price labels in Section V-A are derived from this maintained state, Table I and the hybrid-deployment results (Figure 8; 45% traffic / 38% value / ~3% error) are computed on a book that diverges from the true exchange book. This is not a secondary implementation detail; it directly undermines the paper's claim to construct limit order books and perform meaningful market prediction on real feeds.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents LOBIN, a P4-based in-network system that maintains a limit order book (LOB) from market-by-order (MBO) feeds, extracts LOB features, and runs pretrained ML models for short-horizon mid-price movement prediction on programmable switches (BMv2, Intel Tofino, and emulated Tofino 2). The authors also propose a hybrid deployment in which low-confidence switch predictions are forwarded to a server-side model. The evaluation uses one day of NASDAQ TotalView-ITCH data for three stocks and reports ML metrics (precision, recall, F1, accuracy) for several models, relative latency and throughput on Tofino, and hybrid-deployment results claiming about 45% of traffic and 38% of transaction value processed on-switch with only about 3% error-rate degradation. The paper concludes that LOBIN achieves microsecond-level latency and over 10% latency reduction relative to a server benchmark.","tokens_in":17949,"tokens_out":4065,"duration_ms":43898,"significance":"If the evaluation is sound, LOBIN would be a valuable proof of concept: it shows that LOB construction, feature extraction, and ML inference can coexist in the data plane, and that a hybrid switch/server design can cut latency and server load with a small accuracy penalty. The use of public NASDAQ data, multiple ML models, two hardware/software targets, and a reproducible benchmark framework are strengths. However, the central claim of constructing a faithful LOB is undermined by the lack of support for MBO cancellation and update actions in the described algorithms, and the evaluation methodology omits a train/test split and reports only point estimates. These issues must be resolved before the headline results can be accepted.","major_comments":[{"comment":"The MBO action field is stated to include add, cancel, and update (Section III-A), yet Algorithms 1 and 2 do not branch on this field, do not track order IDs, and provide no explicit handling of cancellation or replacement messages. In Algorithm 1, a cancel message with Po < Pa is treated as a new order and line 18 executes R_l[Po] += So, inflating depth and potentially misplacing best-bid/ask registers. Algorithm 2 has the same structure. The paper concedes this in Section VI: 'LOBIN does not store MBO states but can update volumes within LOBs, allowing for order cancellations and updates, with minor changes to the current prototype.' Since the ML features and labels in Section V-A are computed from this maintained LOB, Table I and the hybrid results in Figure 8 are based on a book that can diverge from the real exchange book. This is load-bearing: the paper claims LOBIN 'constructs lim","section":"Section III-A, Algorithms 1-2, Section VI"},{"comment":"The evaluation does not report a train/test split, cross-validation, or repeated runs. The text says the server benchmarks avoid overfitting, but no split is described. Without a held-out test set, the reported accuracies, F1 scores, and especially the 'optimal' confidence thresholds in Section V-C can be optimistically biased. The dataset is also a single trading day (January 30, 2020) for three stocks, so the generalization claim is thin. The authors should provide the split (or cross-validation), report confidence intervals, and temper the cross-stock conclusions.","section":"Section V-A"},{"comment":"The headline hybrid-deployment numbers—'approximately 45% of the traffic' and '38% of the total potential transaction value' with 'average change in error rate around 3%'—are not supported by the per-stock data in Figure 8 as presented. The thresholds are selected per stock (0.98 for EXC, 0.96 for AZN), and the reported switch fractions are about 20% for FANG, 48.12% for EXC, and 27.81% for AZN; the aggregate 45% requires a clear weighting (by message count or value) and the error-rate change needs to be defined across the three stocks at the selected thresholds. As written, the aggregate claim appears to conflate per-stock optimal thresholds with an average, and the 'around 3%' figure is not derived from a transparent procedure.","section":"Section V-C and Abstract"},{"comment":"The claim of 'over a 10% reduction in latency compared to the NASDAQ order-matching server benchmark' is based on comparing LOBIN's relative latency (Figure 7) to an external benchmark from reference [56], not on a same-testbed measurement. The paper itself notes the Tofino latency is under NDA and reports only ratios to switch.p4, so the absolute latency and the comparison basis are unclear. The authors should either measure the server benchmark in the same testbed or clearly state the conditions under which the 10% improvement is obtained, including that the external benchmark excludes ML inference.","section":"Section V-B"}],"minor_comments":[{"comment":"The introduction says Tofino 2 is an 'emulation environment,' but Table I and the text sometimes treat it as a hardware target. Clarify that Tofino 2 results are emulated, not measured, in the table caption and around Figure 6.","section":"Section I and Table I"},{"comment":"Line 33 uses the bound 'P_h' in the for loop, but P_h is never defined in the pseudocode or in the variable list. The intended bound (presumably the highest price level in the LOB) should be stated.","section":"Algorithm 2"},{"comment":"The table includes 'KM' (k-means) as a classifier, but k-means is a clustering algorithm. Clarify how it is used for classification (e.g., cluster labels assigned to training data) since the comparison otherwise mixes methods.","section":"Table I"},{"comment":"The text says 'around 440K entries from three distinct stocks' and later mentions 'all MBO messages for each trading day.' Please state whether 440K is the total number of MBO messages across all three stocks or per stock, and clarify how missing consecutive days may affect the feature/label construction.","section":"Section V-A"},{"comment":"There is a typo in the opening sentence: 'LOBsBy Design' should be 'LOBs by design.' Also, the statement that LOBIN 'can update volumes within LOBs, allowing for order cancellations and updates' is misleading given the algorithms lack action handling; this should be corrected to align with the actual implementation.","section":"Section VI"}],"recommendation":"major_revision","confidential_remarks":"The paper tackles a relevant and timely problem, and the system is nontrivial. However, the missing MBO action handling is not a cosmetic concern: it affects the validity of the LOB state used for all ML and hybrid metrics. A revision that fixes or clearly scopes the LOB update logic and adds a proper train/test split could turn this into a solid contribution. The aggregate hybrid-deployment and latency claims also need to be backed by a transparent methodology. I recommend major revision rather than rejection because the underlying idea and prototype are promising and the issues appear addressable within the scope of the paper."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"LOBIN is a real first: a programmable switch that builds and updates a limit order book and runs ML inference on it. The P4 engineering is substantial — 622/680 lines of LOB code, Tofino deployment with recirculation, line-rate throughput, and a thoughtful hybrid confidence-threshold design. The paper is also honest about hardware constraints and compares against a reasonable server benchmark. The novelty over the authors' earlier stateless MBO work is clear.\n\nThe stress-test concern is accurate, and it's load-bearing. Section III-A lists the MBO action field as including add, cancel, and update, but Algorithms 1 and 2 never branch on it. Line 18 of Algorithm 1 does R_l[Po] += So for every incoming message, so a cancel is treated as a new order that inflates depth. The Discussion admits the prototype doesn't store MBO states and says cancellations/updates would need \"minor changes.\" That's not minor — without order IDs and a way to decrement or delete levels, the maintained book diverges from the exchange's book. Since the ML features and the 100-tick mid-price labels are computed from this maintained book, Table I and Figure 8 report performance on a book that doesn't match reality. The server benchmark, by contrast, uses a proper LOB reconstruction. So the BMv2 \"tracks the server\" result isn't a valid comparison; it's comparing a corrupted-book model to a correct-book model.\n\nOther soft spots are secondary but real: no explicit train/test split, one day of data, three stocks, no confidence intervals. Those are addressable. The book-construction flaw is the one that matters.\n\nIf the authors fix the book construction — either by implementing cancel/update handling or by restricting the evaluation to add-only synthetic feeds and saying so clearly — the hybrid results and throughput would be worth taking seriously. As it stands, the central claim is overclaimed. The paper deserves a serious referee because the artifact is novel and the flaw is fixable, but it needs major revision before the reported numbers can be trusted.","headline":"A genuine first for in-network LOB construction and ML inference on a switch, but the prototype doesn't handle MBO cancel/update actions, so the LOB it maintains isn't the real book and the headline numbers are computed on corrupted state.","tokens_in":18376,"tokens_out":3102,"would_cite":false,"duration_ms":33327,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A programmable switch can build a limit order book and run market prediction in the data plane, cutting latency by over 10% versus a server benchmark.","keywords":["in-network machine learning","programmable switches","limit order book","market-by-order data","high-frequency trading","price movement prediction","hybrid inference","P4 data plane"],"falsifier":"Replay a market-by-order feed with frequent cancellations through the current prototype and compare the switch's maintained best bid/ask and level volumes against a correct server-side reconstruction; any divergence invalidates the ML labels. Separately, reproduce the end-to-end latency measurement on the same hardware with the same exchange order-matching benchmark to verify the claimed over-10% reduction.","tokens_in":17545,"feed_emoji":"📈","tokens_out":5076,"duration_ms":50287,"temperature":0.7,"pith_summary":"The paper's central claim is that programmable network switches can do more than forward packets: they can reconstruct a stock's limit order book from market-by-order feeds and run small machine-learning models on that book to predict short-term price moves, all at microsecond-scale latency. If true, high-frequency trading systems could move prediction from servers into the network path and remove a host round-trip. The authors demonstrate this with a prototype on a hardware switch, an emulated next-generation switch, and a software switch, comparing against server-based models. The software target stays within a few percent of server accuracy and F1, the hardware target retains about 72% of precision and 64% of F1 on average, and a hybrid switch-plus-server design keeps roughly 45% of traffic and 38% of transaction value on the switch while holding the average error-rate change near 3%.","feed_headline":"Switches can build order books and predict price moves","feed_subtitle":"In-network ML cuts latency by over 10% versus a server benchmark and keeps accuracy close to server models.","key_machinery":"The load-bearing mechanism is the in-switch limit-order-book update algorithm. Because hardware switches cannot loop and can access a register only once per pipeline pass, the authors flatten matching into parallel per-price-level comparisons: each level compares its stored volume with the order's remaining size and its price with the current best bid and ask; one of four outcomes decides whether to add volume, consume volume, or leave residual size. Recirculation provides a second pipeline pass to write updated state back. The maintained book feeds feature extraction, mid-price labeling, and the mapped tree-based model in the same data plane.","core_discovery":"On the paper's own terms, the discovery is that a limit order book—a stateful structure normally maintained by an exchange matching engine—can be constructed and updated entirely inside a programmable switch pipeline, and the same pipeline can extract features and run a pre-trained tree-based model on every message. Quantitatively: microsecond-scale end-to-end latency with over 10% reduction versus an exchange order-matching server benchmark; line-rate throughput; average hardware-target precision and F1 at roughly 72% and 64% of the server benchmark; near-server performance on the software target; and a hybrid deployment that handles about 45% of traffic and 38% of transaction value on the","pith_inferences":["The authors leave implicit that the same pipeline could serve other microstructure targets—spread, depth, volatility, or trade sign—by changing only the label and retraining; nothing in the architecture is specific to mid-price direction.","The acknowledged gap on cancellation and modification messages means the reported ML metrics describe the switch-maintained book; a natural next experiment is to replay a feed with heavy cancellations and measure how far the switch book's best prices and volumes drift from a true server-side reconstruction.","The hardware resource trade-off suggests a testable scaling law: as switch ASICs gain stages and memory, increasing book depth from three to ten price levels should close most of the remaining accuracy gap, which the authors' emulation of a less-constrained target already hints at.","One could generalize the hybrid design to per-stock or dynamic confidence thresholds rather than a single fixed threshold, using the authors' observed threshold-error-rate curves as calibration data."],"forward_implications":["Programmable switches can host stateful financial data processing, not just stateless packet forwarding.","Prediction can happen in the network path, yielding microsecond-level latency and over 10% reduction versus an exchange order-matching server benchmark.","Tree-ensemble models fit switch constraints well enough to keep accuracy within a few percent of server models on a software target and within about 25-35% on a hardware target.","Hybrid deployment with a confidence threshold gives operators a tunable trade-off: roughly 45% of traffic and 38% of transaction value can be handled on-switch while the average error-rate change stays near 3%.","The same generated pipeline can be applied to different stocks and sectors with consistent behavior."],"fun_headline_variants":["In-network ML builds order books and predicts prices 10% faster","Switch-based ML cuts market prediction latency below server benchmarks","Programmable switches host ML models for microsecond price forecasts","Hybrid in-network ML handles 45% of trading traffic on switches"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The evaluation assumes the switch-maintained order book accurately mirrors the real exchange book; the current prototype does not process cancellation or modification messages, so with frequent cancellations the book—and therefore the features and labels—can drift from the true state.","fun_headline_variants_meta":{"raw":{"variants":["In-network ML builds order books and predicts prices 10% faster","Switch-based ML cuts market prediction latency below server benchmarks","Programmable switches host ML models for microsecond price forecasts","Hybrid in-network ML handles 45% of trading traffic on switches"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000311,"raw_usage":{"total_tokens":1619,"prompt_tokens":766,"completion_tokens":853,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":510,"completion_tokens_details":{"reasoning_tokens":794}},"tokens_in":510,"tokens_out":853,"duration_ms":7837,"temperature":1.0,"reasoning_tokens":794,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T07:35:57.488507+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Replay a market-by-order feed with frequent cancellations through the current prototype and compare the switch's maintained best bid/ask and level volumes against a correct server-side reconstruction; any divergence invalidates the ML labels. Separately, reproduce the end-to-end latency measurement on the same hardware with the same exchange order-matching benchmark to verify the claimed over-10% reduction.","supporting_citations":[],"review_version":1}