dxFeed vs Rithmic: Choosing a Data Feed for Futures Prop Trading

Ask a trader on a Rithmic-connected platform whether their fills match their chart and you'll get a shrug. Ask a trader whose platform sources data from one vendor and execution from another, and you might get a story about the one time those two things disagreed. That difference isn't an accident of software quality. It comes from how dxFeed and Rithmic are actually built, and what each one is, and isn't, responsible for.

If you trade a funded futures account, you've probably seen both names without a clear explanation of what separates them. This article covers what each vendor actually does, why Rithmic became close to a default in funded futures trading specifically, and what to check before you assume you're picking between them freely.

What dxFeed actually is

dxFeed is a market-data infrastructure vendor, a subsidiary of Devexperts. It runs a ticker plant that pulls direct feeds from exchanges around the world and redistributes that data in a normalized, consolidated format: real-time, delayed, and historical. Platforms integrate dxFeed through APIs (Java, C/C#, Python, FIX, REST) rather than building their own exchange-by-exchange data parsing from scratch.

Coverage, as published, spans equities, options, futures and futures options, indices, ETFs, crypto, and forex, among other asset classes. The point of normalization is that a charting platform doesn't need a different code path for every exchange it wants to display, dxFeed hands it one consistent format regardless of source.

The detail that matters most for a futures trader: dxFeed is a data vendor. It is not an order-routing or execution system. A platform that pipes in dxFeed for charts and quotes still needs a completely separate connection to a broker or FCM to actually route and fill orders. MyFundedFutures is a real example of this pattern: it integrates dxFeed (via the Volumetrica/DeepCharts platform, with a TradingView connection) specifically for market data, while execution for funded accounts still runs through its own separate broker/order-routing connection.

What Rithmic actually is

Rithmic, LLC is different in kind, not just in market share. It supplies both real-time market data (Level 1 and Level 2) and order-routing/execution connectivity to futures exchanges, through interfaces like R|API and R|API+, R|Protocol API, and R|Diamond API. It's a combined data-and-execution rail, not a data-only vendor sitting next to someone else's execution path.

If you want a deeper walkthrough of how that data side works day to day, what a Rithmic futures data feed actually delivers covers the mechanics in more detail.

Rithmic connects to exchanges through Futures Commission Merchants (FCMs). A trader's Rithmic connection is provisioned through a broker/FCM relationship, not handed out directly by Rithmic to individual traders. Platforms commonly cited as connecting to Rithmic's infrastructure for data and/or execution include NinjaTrader, Sierra Chart, MotiveWave, Quantower, and R|Trader Pro.

Because Rithmic is the same rail for data and execution, the chart a trader is watching and the order that gets filled are more likely to be sourced from the same underlying infrastructure. That reduces, it doesn't eliminate, one whole category of disagreement between what you saw and what you got filled at.

Why Rithmic became the prop-firm standard

Rithmic has long been the underlying data-and-execution infrastructure for a large number of futures prop trading firms, and plenty of funded futures programs still mandate a Rithmic-connected platform for funded accounts specifically. That history is why Rithmic functions as something close to a default reference point in funded futures prop trading conversations, even as the landscape has gotten more crowded.

It isn't the only rail in that conversation anymore, though. Tradovate and ProjectX (the infrastructure behind TopstepX) have both become real competing options at the funded-futures-prop level specifically, not just alternatives used elsewhere in retail or institutional trading, and firm-by-firm platform requirements have shifted more than once in the last couple of years as a result. CQG shows up in the same conversation as a further, typically more institutional-grade option.

The exact list of firms that mandate Rithmic, versus Tradovate, versus ProjectX, and which platforms they approve, changes over time and has already changed materially within 2026 alone. Treat any specific firm-by-firm list you see, including this one, as a snapshot, not a permanent fact. Confirm directly with your prop firm.

A shared rail doesn't guarantee a perfect fill. It just removes one whole category of ways things can go wrong.

This isn't really about Rithmic being "better" data in some abstract sense. It's that prop firms managing thousands of funded accounts benefit operationally from a standardized, auditable connection where the data feed and the execution path are the same infrastructure. That makes dispute resolution, slippage audits, and risk monitoring simpler for the firm, which is exactly the kind of institutional incentive that turns a vendor into a near-standard.

The practical distinction for your platform

Here's the shorthand worth remembering. If a platform advertises its data as "powered by dxFeed," that typically covers charting and quotes, and order execution still routes through a separate broker or FCM connection layered on top. If a platform runs "on Rithmic," data and order execution typically share the same rail end to end.

Neither column is inherently the "correct" one. It depends on what you're trading and, more often than you'd like, what your specific funded program already requires.

Here's a clean, vendor-neutral way to see why the seam matters. One ES (E-mini S&P 500) futures contract has a fixed $50 per index point multiplier, a stable CME contract spec, not something that changes by vendor. If your chart shows price moving from 5000.00 to 5002.25, a 2.25 point move, and your fill confirmation shows the same 2.25 point move, the math is simple: 2.25 x $50 = $112.50 on one contract. No ambiguity, no disagreement.

Now suppose the fill confirmation shows a different price than the last tick your chart printed at the moment you sent the order. Say the chart last showed 5000.00, but the fill confirms 5000.50, a 0.50 point gap (roughly $25 per contract). That gap is exactly the kind of data-feed-versus-execution-rail mismatch that's structurally less likely when data and execution share one rail (the Rithmic-style model), and structurally possible, though not necessarily frequent, when they're two separate systems, say, a dxFeed-sourced chart paired with a separate broker execution connection.

None of this is about one vendor's data being wrong. It's about the fact that when two independent systems each have their own path to the exchange, their timestamps and prints will occasionally diverge by a tick or two, purely from being different systems. When one system does both jobs, that particular failure mode structurally can't happen, because there's only one clock.

Why fill price matters more than it seems

Scale the same idea to a position size. Say you're holding 2 ES contracts through an adverse move from 5010.00 to 5006.50, a move of 3.50 points against you. The P&L is 3.50 points x $50 per point x 2 contracts = $350.00.

That arithmetic doesn't care which vendor supplied your chart. What it does care about is whether the fill price you're using in that calculation actually matches what happened at the exchange, not just what your chart displayed at that instant. If you're marking your stop-loss discipline, your daily drawdown limit, or your risk-per-trade against a chart price that turns out to differ from your real fill, you're managing risk against a number that isn't quite the truth. That's the whole practical reason the "does data match execution" question is worth caring about instead of treating it as vendor trivia.

The honest tradeoff

A unified data-and-execution rail, the Rithmic-style model, reduces the number of moving parts and lowers the chance of a chart-versus-fill desync, because there's structurally one system instead of two. That's a real, practical advantage for active futures trading where a half-point discrepancy matters.

But it ties you to that ecosystem's specific quirks: its symbol conventions, its FCM-provisioning process, its fee structure, and whatever platform-specific behavior comes bundled with it. You don't get to swap in a different data source just because you like its historical depth better, you're on the rail your FCM and platform give you.

A platform sourcing data from a separate vendor like dxFeed can, in exchange, offer richer, cheaper, or broader-asset-class data independent of whichever broker handles your execution. If you trade equities and crypto alongside futures and want one consistent charting experience across all of it, a dxFeed-based platform can be genuinely better suited to that than a futures-only, execution-coupled rail. That's not a small thing if your trading isn't futures-only.

The cost is the seam: two systems that are, at least in principle, capable of disagreeing, even if that disagreement is uncommon in practice. If you've read up on the practical differences between Rithmic and ProjectX as data feed options, you've seen this same tradeoff show up in a different pairing: unified rails buy consistency, separate systems buy flexibility, and neither is a free lunch.

To be clear about where a trade copier fits into this conversation: a copier like Thor doesn't resolve a data-versus-execution seam for you, and it isn't the answer if your actual problem is that your chart and your fill disagree. A copier's job is replicating executed trades across accounts once those trades are real, it can't manufacture agreement between a data vendor and a broker connection that are, by design, two separate systems. If you're chasing down fill discrepancies, that's a platform, broker, or data-vendor question, not a copying question.

Symbol and tick history coverage differs, and it isn't fixed

Beyond the execution question, coverage itself is a moving target for both vendors. dxFeed's exact list of supported exchanges and instruments changes over time and by data plan; what's included in one integration isn't guaranteed to match another platform's dxFeed integration. Rithmic's list of connected FCMs and supported platforms shifts too, along with which prop firms mandate it for which programs.

Historical tick-data depth, how far back you can pull intraday tick history for backtesting, differs by vendor, plan, and instrument for both dxFeed and Rithmic. Neither has a fixed, universal retention window you can assume applies to your account. If tick history depth matters for a backtest you're building, verify the actual retention window with the vendor or platform directly rather than assuming a number.

Understanding the mechanical difference in data granularity, not just the vendor, also matters here. If you haven't already, it's worth reading the difference covered in Level 1 versus Level 2 market data for futures, since that distinction applies regardless of which vendor is behind the feed.

Is this even your choice

Here's the part that makes most of this discussion theoretical for a lot of traders: many funded evaluations simply require a specific data source or platform already. If your prop firm's funded program mandates a Rithmic-connected platform, the dxFeed-versus-Rithmic decision isn't yours to make, it was made by the firm before you signed up. Choosing between the two vendors is a live decision mainly if you're selecting your own platform for a self-directed account, evaluating multiple prop firms with different requirements, or building out a personal trading setup independent of any funded program's rules.

Before you spend more time weighing dxFeed against Rithmic in the abstract, check what your specific program actually mandates. That single check resolves the question faster than any vendor comparison.

What to verify before you decide anything

None of the specifics in this article, pricing, exact exchange lists, latency figures, are things you should treat as fixed facts going forward. Pricing for dxFeed data plans and for Rithmic-connected platform/data packages varies by reseller, broker, and bundle, and changes over time. Get current numbers directly from the platform or FCM you're evaluating.

Latency is the same story: neither vendor publishes one universal number that applies to every integration, since actual latency depends on the specific platform, broker, region, and network path involved. Treat any millisecond figure you encounter, including anecdotal ones from other traders, as illustrative at best, not a guarantee, and verify with the platform or broker directly if latency is decision-critical for your strategy.

Finally, and most importantly for anyone trading funded capital: confirm directly with your prop firm which data source and platform your specific program requires, since those rules can and do change between cohorts and account types.

Frequently asked questions