How to Mix Tradovate and ProjectX Followers in One Copy Group

This is a HexTrade product-scope statement, not a claim that Tradovate or ProjectX natively copies to the other platform. The hosted group is the coordinating layer. It receives a supported leader-fill event, calculates a target for each eligible follower, and sends a platform-specific order request through the appropriate connector.

Mixed-platform does not mean interchangeable. Tradovate and ProjectX expose different authentication, account identifiers, contract identifiers, error responses, and rate-limit rules. The copier can normalize common concepts such as side, quantity, and status for the dashboard, but the original broker response must remain available for diagnosis.

Begin with one follower on each platform and minimum practical exposure. Prove symbol mapping, order direction, quantity, entry, partial/complete outcomes, and exit before adding accounts. A leader fill can result in a Tradovate fill and a ProjectX rejection—or the reverse—so the group is healthy only when individual results are visible and drift is reconciled.

A useful canonical record contains a unique event identity, leader account, root product, exact contract month, buy or sell side, newly filled quantity, fill timestamp, and the group's versioned configuration. This record is an audit fact. It should not be rewritten when one connector uses a different symbol or status vocabulary.

For each follower, calculate a separate target from that canonical event. Add follower account ID, multiplier, fractional carry, rounded quantity, caps, and eligibility result. Only after those decisions are recorded should the platform adapter build the order request expected by Tradovate or ProjectX.

This separation makes errors easier to locate. If both connectors receive the wrong side, inspect canonical intent. If only ProjectX receives an invalid contract ID, inspect its mapping. If one account is skipped due to a cap, inspect follower policy rather than the adapter. A common dashboard can normalize states while retaining the connector request and original response.

Futures symbols encode product and expiry, and platforms can expose them differently. A leader event for a specific MES expiry must map to that intended expiry in both follower environments. Sending a root, stale alias, or next-month contract by mistake can create a position that appears related but has different liquidity and price behavior.

Maintain a mapping record with canonical product, expiry, exchange where relevant, Tradovate symbol, ProjectX contract identifier, tick size, tick value, and review date. Validate it against current platform data around rollover. If either side cannot resolve the exact contract, skip that follower and alert; do not fall back to a nearby symbol.

Contract conversion is a separate decision. If a leader uses ES and a follower intentionally uses MES, encode the conversion and risk cap explicitly. Test quantities that produce fractions and apply rounding once at the final follower boundary. The economic ratio must come from current contract specifications, not a name-based assumption.

A ProjectX account and a Tradovate account can have different balances, trailing limits, current positions, and permitted maximums even when they trade the same contract. Calculate planned loss from stop distance, tick value, quantity, fees, and a slippage allowance for each follower. Use the lower of the sizing result and the account's current cap.

Preserve the filled leader increment as the sizing input. A submitted five-contract leader order that has filled two should not automatically generate five-contract follower requests. For partial fills and sub-one multipliers, keep a cumulative target or fractional remainder so repeated small increments behave predictably.

Display final order quantity by account before activation. Also display aggregate group exposure, because ten individually acceptable follower orders can create an unacceptable correlated total. A follower that rounds to zero should be marked as intentionally skipped rather than silently absent.

A practical normalized lifecycle includes queued, submitting, acknowledged, working, partially filled, filled, canceled, rejected, unknown, and skipped. The adapter maps a broker event into one of those states and stores the raw platform status. Do not label a request “filled” merely because the submission endpoint returned successfully.

Unknown deserves special treatment. A timeout or dropped response may occur after the broker accepted an order. The recovery path is to query by correlation details, inspect working orders and positions, and then decide whether a new request is needed. Treating unknown as rejected invites duplicates.

Cross-platform health should show mixed outcomes. If Tradovate followers are current and one ProjectX connection is stale, the group is degraded rather than wholly healthy or wholly failed. The operator should be able to pause only the affected follower while preserving visibility into all existing positions.

Each platform publishes or enforces its own request constraints. A group event can create order submissions plus status and reconciliation queries. Partial fills can increase event count, and a reconnect can create a state-refresh burst. Build separate budgets so one busy connector does not consume the assumptions of the other.

Use bounded queues, backoff for explicit throttling, and event deduplication. Before executing a delayed copy action, recalculate whether it still moves the follower toward the current target. A stale entry that arrives after the leader has exited should be discarded or escalated, not submitted because it finally reached the front of a queue.

Design failure isolation. If ProjectX authentication expires, mark those followers unavailable and continue monitoring their last known positions while the Tradovate path remains observable. Whether new copying should continue for healthy followers is a documented group policy, not an improvised decision during an outage.

Start in the safest supported environment and use minimum practical exposure. Confirm account IDs and environments, then exercise a complete entry and exit. Watch the leader fill separately from both follower submissions and outcomes. Compare final positions directly at Tradovate and ProjectX.

Next test a partial leader fill, a follower intentionally skipped by a safe local cap, a reconnect, and a mapping failure that should fail closed. You are testing observability as much as execution. Every case needs a clear timeline and account-level result.

Add followers only after no unexplained drift remains. Recalculate the request burst and aggregate loss budget at each stage. Keep a runbook for pausing one follower, one connector segment, or the entire group; querying broker truth; resolving unknown outcomes; and verifying final positions before resuming.