Broker Execution Speed Matters More for Scalpers Than Anyone Else

[PTScalper]

Here it is:

Code: Select all

using System;
using System.Diagnostics;
using System.Threading;
using cAlgo.API;
using cAlgo.API.Internals;

namespace cAlgo.Robots
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class LatencyMeter : Robot
    {
        [Parameter("Number of Tests", DefaultValue = 10)]
        public int NumberOfTests { get; set; }

        [Parameter("Distance (Pips)", DefaultValue = 100)]
        public double DistancePips { get; set; }

        protected override void OnStart()
        {
            Print("--- Starting cTrader Broker Latency Test ---");
            
            long minLatency = long.MaxValue;
            long maxLatency = 0;
            long totalLatency = 0;
            int successfulTests = 0;
            
            for (int i = 0; i < NumberOfTests; i++)
            {
                // Calculate safe price far below the market
                double safePrice = Symbol.Ask - (DistancePips * Symbol.PipSize);
                
                Stopwatch stopwatch = new Stopwatch();
                stopwatch.Start();
                
                // Synchronous method blocks until the broker server responds
                TradeResult result = PlaceLimitOrder(TradeType.Buy, SymbolName, Symbol.VolumeInUnitsMin, safePrice, "LatencyTest");
                
                stopwatch.Stop();
                long latency = stopwatch.ElapsedMilliseconds;
                
                if (result.IsSuccessful)
                {
                    successfulTests++;
                    totalLatency += latency;
                    
                    if (latency < minLatency) minLatency = latency;
                    if (latency > maxLatency) maxLatency = latency;
                    
                    Print("Test {0} Latency: {1} ms", i + 1, latency);
                    
                    // Clean up: Cancel the pending order
                    TradeResult cancelResult = CancelPendingOrder(result.PendingOrder);
                    if (!cancelResult.IsSuccessful)
                    {
                        Print("Warning: Failed to cancel test order.");
                    }
                }
                else
                {
                    Print("Test {0} Failed. Error: {1}", i + 1, result.Error);
                }
                
                // Pause briefly between pings so we don't spam the API
                Thread.Sleep(500); 
            }
            
            // Calculate and print final statistics
            if (successfulTests > 0)
            {
                double avgLatency = (double)totalLatency / successfulTests;
                
                Print("=====================================");
                Print("cTRADER LATENCY TEST RESULTS ({0}/{1} successful)", successfulTests, NumberOfTests);
                Print("Average Latency: {0:F1} ms", avgLatency);
                Print("Minimum Latency: {0} ms", minLatency);
                Print("Maximum Latency: {0} ms", maxLatency);
                Print("=====================================");
            }
            else
            {
                Print("All test attempts failed. Check margin or distance parameters.");
            }
            
            // Stop the cBot automatically when the test is finished
            Stop();
        }
    }
}

[PTScalper]

Asynchronous Execution in cTraderIn your previous question about MT5, executing an asynchronous order required setting up an external OnTradeTransaction event handler and manually matching request_id variables to track state.cTrader's API fundamentally solves this "State Management Trap."

Because cTrader utilizes standard C# event-driven models, ExecuteMarketOrderAsync allows you to pass a callback action directly into the method.

By using an inline Lambda expression, the function captures the local scope automatically (closures), meaning you never lose track of your local logic while the network packet is in transit.

Code: Select all

// Fire the order asynchronously and move to the next line immediately
ExecuteMarketOrderAsync(TradeType.Buy, SymbolName, Symbol.VolumeInUnitsMin, tradeResult => 
{
    // This block executes independently once the server replies
    if (tradeResult.IsSuccessful)
    {
        Print("SUCCESS: Broker confirmed Async execution! Position ID: {0}", tradeResult.Position.Id);
    }
    else
    {
        Print("FAILED: Broker rejected execution. Error: {0}", tradeResult.Error);
    }
});

Print("Request dispatched. The cBot is free to process other data.");

Why this matters for scalping:

You can loop through and blast 10 different asynchronous orders into the market in a single millisecond without waiting for a single server response. Each individual order remembers its own specific logic context through its local callback, making aggressive, high-frequency volume distribution incredibly clean to code.

[PTScalper]

To enforce strict slippage limits in cTrader, you must abandon the standard ExecuteMarketOrderAsync method. Standard market orders instruct the broker to fill your volume at any available price, making them dangerous for high-volume strategies when top-of-book liquidity thins out.

Instead, use ExecuteMarketRangeOrderAsync. This method bakes your maximum allowed slippage directly into the network request. If the broker cannot fill your requested volume within that specific pip range, it will fill whatever liquidity is available inside the range and immediately cancel the rest.

This results in a partial fill. You handle this by comparing your initial requested volume against the actual filled volume inside the asynchronous callback.

Implementing Market Range and Partial Fill Detection

Here is the exact implementation pattern to trap partial fills and handle the remaining volume without blocking your main trading thread.

Code: Select all

using cAlgo.API;

namespace cAlgo.Robots
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class StrictSlippageExecution : Robot
    {
        protected override void OnStart()
        {
            // Define your execution parameters
            double targetVolume = 500000; // e.g., 5 standard lots
            double maxAllowedSlippagePips = 0.5; // Half a pip max slippage
            double expectedEntryPrice = Symbol.Ask;

            // Fire the asynchronous Market Range order
            ExecuteMarketRangeOrderAsync(
                TradeType.Buy, 
                SymbolName, 
                targetVolume, 
                maxAllowedSlippagePips, 
                expectedEntryPrice, 
                "StrictScalp", 
                null, // No initial SL
                null, // No initial TP
                tradeResult => 
            {
                // Callback triggers when the server responds
                if (tradeResult.IsSuccessful)
                {
                    double filledVolume = tradeResult.Position.VolumeInUnits;

                    // Trap the partial fill
                    if (filledVolume < targetVolume)
                    {
                        double missedVolume = targetVolume - filledVolume;
                        
                        Print("WARNING: Partial Fill Detected!");
                        Print("Requested: {0} | Filled: {1} | Missed: {2}", targetVolume, filledVolume, missedVolume);
                        Print("Average Fill Price: {0}", tradeResult.Position.EntryPrice);

                        // Decision Matrix for Partial Fills:
                        // Option A: Adjust risk management for the smaller position size
                        // Option B: Close the position immediately if it breaks your minimum size rules
                        // Option C: Re-fire a new async order for the 'missedVolume' (Dangerous if market is running)
                    }
                    else
                    {
                        Print("SUCCESS: Order fully filled at {0}", tradeResult.Position.EntryPrice);
                    }
                }
                else
                {
                    // If the entire book moved beyond your max allowed slippage before the packet arrived
                    Print("ORDER FAILED: Market moved beyond max slippage of {0} pips. Error: {1}", maxAllowedSlippagePips, tradeResult.Error);
                }
            });

            Print("Order routed with max slippage constraints. Listening for server callback...");
        }
    }
}

[PTScalper]

The Two Strategic Solutions for Partial Fills

When you detect a partial fill inside the callback, you must programmatically decide how to manage the crippled position. In algorithmic scalping, you generally have two paths:

The Risk-Adjusted Hold (Recommended):

Accept the partial fill. If your system calculated a 5-lot trade and you only got 3 lots, leave the 3 lots open. However, you must immediately recalculate and modify your Take Profit and Stop Loss cash-value targets to reflect the smaller position size, otherwise your risk-to-reward ratio for that specific trade breaks.

The Immediate Flatten (Aggressive):

If your strategy requires an exact minimum volume to cover fixed commission costs, a small partial fill might be mathematically unprofitable even if it hits the profit target. In this scenario, you call ClosePositionAsync(tradeResult.Position) immediately inside the partial fill if block to scratch the trade entirely.

[PTScalper]

When you are pushing high volumes in aggressive scalping environments, micro-fills are a mathematical liability. If a strategy expects the delta of a 5-lot position but only captures 0.1 lots, the fixed commission drag and spread cost often outweigh the potential profit of the trade.

To handle this cleanly in cTrader without blocking your main execution thread, you simply nest an asynchronous ClosePositionAsync() call inside the original entry's callback.

Here is the architectural pattern for the immediate flatten.

The Emergency Flatten Implementation

Code: Select all

using cAlgo.API;

namespace cAlgo.Robots
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class StrictVolumeFilter : Robot
    {
        protected override void OnStart()
        {
            double targetVolume = 500000;          // Intended 5 lots
            double minimumRequiredVolume = 200000; // Minimum 2 lots required to justify the trade
            double maxAllowedSlippage = 0.5;

            // 1. Dispatch the initial asynchronous entry
            ExecuteMarketRangeOrderAsync(TradeType.Buy, SymbolName, targetVolume, maxAllowedSlippage, Symbol.Ask, "ScalpEntry", null, null, entryResult => 
            {
                if (entryResult.IsSuccessful)
                {
                    double filledVolume = entryResult.Position.VolumeInUnits;

                    // 2. Trap the micro-fill
                    if (filledVolume < minimumRequiredVolume)
                    {
                        Print("WARNING: Micro-fill detected ({0}). Threshold is {1}. Initiating emergency flatten.", filledVolume, minimumRequiredVolume);

                        // 3. Dispatch the asynchronous exit immediately
                        ClosePositionAsync(entryResult.Position, closeResult => 
                        {
                            if (closeResult.IsSuccessful)
                            {
                                Print("Position flattened successfully. Spread/commission absorbed as a scratch trade.");
                            }
                            else
                            {
                                // CRITICAL: The broker rejected the close request (e.g., market closed, liquidity gap)
                                Print("FATAL: Failed to close micro-fill. Error: {0}. Position is orphaned!", closeResult.Error);
                            }
                        });
                    }
                    else
                    {
                        // The fill was partial, but large enough to meet your minimum threshold
                        Print("SUCCESS: Viable volume filled ({0}). Managing position normally.", filledVolume);
                        
                        // Proceed with normal Stop Loss / Take Profit management here
                    }
                }
            });
            
            Print("Entry order dispatched. Thread released.");
        }
    }
}

[PTScalper]

Architectural Warnings for the Immediate Flatten

Nesting asynchronous calls is powerful, but introduces two specific structural realities you must account for in your server logs:

The Guaranteed Loss: Automatically flattening a partial fill means you are aggressively exiting at the Bid price immediately after entering at the Ask price. You are mathematically guaranteeing a loss equal to (Spread * MicroVolume) + RoundTripCommissions. While this loss is tiny, if your algorithm hits a low-liquidity pocket and triggers this logic ten times in a row, you will experience rapid account drag.

The Orphaned Position Risk: The inner closeResult.IsSuccessful check is not optional. Network packets drop, and liquidity dries up. If the exit order fails, your algorithm must be prepared to catch that error and retry the close, otherwise, you leave a micro-position running entirely unmanaged with no stop loss.

[PTScalper]

There is a critical mathematical truth to understand here before writing the logic: if you are trading on a raw ECN feed with purely linear commissions (e.g., exactly $30 per million traded), the break-even distance in pips does not change based on volume.

A 10-lot position and a 0.01-lot position require the exact same pip movement to cover the spread and commission.

However, micro-fills become mathematically toxic for two reasons:

Minimum Ticket Fees: Many brokers enforce a minimum commission per ticket (e.g., $0.05 or $0.10). On a micro-fill, this flat fee drastically increases the pip-distance required just to break even.

Asymmetric Tail Risk: If a partial fill limits your maximum upside to just $5, but leaves you exposed to a sudden news spike that could slip your stop-loss by 20 pips, the risk-to-reward ratio for the trade's absolute monetary value completely collapses.

To determine whether to hold or flatten, you must calculate both the Break-Even Pip Distance and the Projected Net Monetary Return.

The Mathematical Cost Filter

In cTrader, you don't need to manually calculate the spread cost. The moment the asynchronous callback fires, the Position.NetProfit property already reflects the exact liquidation cost (current unrealized spread loss + round-trip commissions).

Here is how you extract those metrics and apply a strict mathematical threshold:

Code: Select all

using System;
using cAlgo.API;

namespace cAlgo.Robots
{
    [Robot(TimeZone = TimeZones.UTC, AccessRights = AccessRights.None)]
    public class DynamicCostFilter : Robot
    {
        [Parameter("Minimum Acceptable Profit ($)", DefaultValue = 25.0)]
        public double MinimumAcceptableProfit { get; set; }

        [Parameter("Strategy Target (Pips)", DefaultValue = 5.0)]
        public double StrategyTargetPips { get; set; }

        protected override void OnStart()
        {
            // Firing the async entry
            ExecuteMarketRangeOrderAsync(TradeType.Buy, SymbolName, 500000, 0.5, Symbol.Ask, "ScalpEntry", null, null, entryResult => 
            {
                if (entryResult.IsSuccessful)
                {
                    var position = entryResult.Position;
                    
                    // 1. Instant Liquidation Cost
                    // NetProfit instantly combines the spread gap and round-trip commissions
                    double instantLiquidationCost = Math.Abs(position.NetProfit);
                    
                    // 2. Calculate the monetary value of 1 pip for this specific filled volume
                    // cTrader's Symbol.PipValue represents the value of 1 pip for 1 unit of volume
                    double positionPipValue = Symbol.PipValue * position.VolumeInUnits;
                    
                    // 3. Calculate Exact Break-Even Distance
                    double spreadPips = Symbol.Spread / Symbol.PipSize;
                    double commissionPips = Math.Abs(position.Commissions) / positionPipValue;
                    double breakEvenPips = spreadPips + commissionPips;
                    
                    // 4. Calculate Expected Monetary Return at your target
                    // (Target Pips - Spread) * Pip Value - Commissions
                    double expectedNetProfit = ((StrategyTargetPips - spreadPips) * positionPipValue) - Math.Abs(position.Commissions);
                    
                    Print("--- EXECUTION METRICS ---");
                    Print("Filled Volume: {0}", position.VolumeInUnits);
                    Print("Instant Drag (Spread + Comm): {0:C}", instantLiquidationCost);
                    Print("Distance to Break-Even: {0:F2} pips", breakEvenPips);
                    Print("Expected Net Return at {0} pips: {1:C}", StrategyTargetPips, expectedNetProfit);

                    // 5. The Decision Matrix
                    if (expectedNetProfit < MinimumAcceptableProfit)
                    {
                        Print("ABORT: Expected return ({0:C}) fails mathematical threshold ({1:C}). Flattening immediately.", expectedNetProfit, MinimumAcceptableProfit);
                        
                        ClosePositionAsync(position, closeResult => 
                        {
                            if(!closeResult.IsSuccessful)
                            {
                                Print("FATAL: Flatten failed! Error: {0}", closeResult.Error);
                            }
                        });
                    }
                    else
                    {
                        Print("HOLD: Trade is mathematically viable. Applying risk management.");
                        // Proceed to set dynamic Stop Loss and Take Profit
                    }
                }
            });
        }
    }
}

[PTScalper]

Why This Architecture Works

1.) Precision: By using positionPipValue, the code automatically adjusts to the specific cross-rate of the asset (e.g., the fluctuating pip value of EURGBP against a USD account balance).

2.) Zero Assumptions: It pulls position.Commissions directly from the broker's server response rather than hardcoding a commission rate, guaranteeing accuracy even if the broker applies tiered commission scaling.

[PTScalper]

When porting algorithmic execution logic into Pine Script, you hit a hard architectural wall: Pine Script cannot measure millisecond network latency.

Unlike MetaTrader or cTrader, which run locally on your hardware (or a cross-connected VPS) and communicate directly with the broker's trade server, Pine Script runs entirely on TradingView's cloud servers.

You cannot use system timers (GetTickCount or Stopwatch) because the script isn't running on your machine. You cannot send dummy async orders because TradingView does not route orders that way; it relies on broker API integrations or third-party webhooks, which inherently introduce multiple external network hops.

For a high-volume forex and silver scalper, this infrastructure is generally considered too slow for millisecond-dependent execution.

However, since we cannot measure the time delay in Pine Script, we must measure the actual mathematical damage that latency causes: Slippage.

The Pine Script Slippage Monitor

Instead of measuring millisecond pings, this script tracks the exact price at the moment your logic fires, and compares it dynamically to the actual fill_price returned by your connected broker. This tells you exactly how much your broker's execution delay is costing you in pips per trade.

Note: For this to reflect reality, you must run it live on a chart connected directly to your broker via TradingView's trading panel. If run in the standard backtester, TradingView will just simulate perfect fills.

Code: Select all

//@version=5
strategy("Realized Execution Slippage Monitor", overlay=true, calc_on_every_tick=true, currency=currency.USD)

// Track state variables for the signal and slippage math
var float signalPrice = na
var float totalSlippagePips = 0.0
var int tradeCount = 0

// Determine the correct pip multiplier (Forex vs Metals like Silver)
isForex = syminfo.type == "forex"
// For Forex, a pip is usually 10 ticks (e.g., 1.00010). For metals, it depends on the broker's decimal precision.
pipMultiplier = isForex ? 10 : 1 

// 1. Define a dummy trigger condition (Replace with your actual entry logic)
// Using a simple rapid crossover for high-frequency testing
triggerCondition = ta.crossover(ta.sma(close, 5), ta.sma(close, 10))

// 2. Capture the exact market price the millisecond the signal fires
if (triggerCondition and strategy.position_size == 0)
    signalPrice := close
    strategy.entry("Scalp_Long", strategy.long)

// 3. Catch the broker's confirmed fill and calculate the drag
if (strategy.position_size > 0 and strategy.position_size[1] == 0)
    // Get the actual fill price reported back from the broker API
    fillPrice = strategy.opentrades.entry_price(strategy.opentrades - 1)
    
    // Calculate the slippage in raw pips (Fill Price - Signal Price)
    // Positive slippage means you got a worse price (drag)
    rawSlippage = (fillPrice - signalPrice) / (syminfo.mintick * pipMultiplier)
    
    totalSlippagePips += rawSlippage
    tradeCount += 1
    
    avgSlippage = totalSlippagePips / tradeCount
    
    // Log the exact execution metrics to the Pine Logs console
    log.info("--- EXECUTION REPORT ---")
    log.info("Intended Price: {0}", signalPrice)
    log.info("Actual Fill: {0}", fillPrice)
    log.info("Trade Drag: {0} pips", rawSlippage)
    log.info("Average Broker Drag: {0} pips", avgSlippage)
    
    // Reset signal state
    signalPrice := na

// 4. Flatten the position quickly to test the next iteration
if (strategy.position_size > 0 and ta.crossunder(ta.sma(close, 5), ta.sma(close, 10)))
    strategy.close("Scalp_Long")

[PTScalper]

Why Scalping via TradingView is Dangerous

If your statistical edge relies on capturing 5-10 pip moves, running automated execution natively through TradingView introduces a structural disadvantage:

The Webhook Hop: If you are using webhooks, the signal originates on TradingView's AWS servers, travels to your third-party bridge (like PineConnector), and then travels to your broker. This multi-leg journey often exceeds 500ms—an eternity in scalping.

Cloud Batching: Pine Script doesn't evaluate ticks with real-time hardware priority. Scripts are batched and processed in TradingView's cloud. During high-volatility events (like NFP or CPI), script processing can lag behind the raw data feed, meaning your signal fires after the institutional liquidity has already vanished.