Reversing positions without market orders?

With Hedge = 0 (NFA broker), when I enter a trade in the opposite direction of an existing one with a limit order, Zorro will first close the existing position with a market order. Ideally I want to reverse the position by sending a limit order in the opposite direction with twice the Lots basically. I want to only pay maker fees.

I wanted to try exiting positions first manually, bu noticed that exitLong/exitShort calls ignore OrderLimit seemingly and always transmit market orders. Can I not exit with limit orders?

I have an unconventional solution: Only use Hedge = 2 even though you have an NFA plugin.

In this case, you can only enterLong and enterShort trades. But you must never close trades. Instead, you cancel all trades for a given asset once its position is zero, using cancelTrade.

Also probably a good idea to set AutoConfirm =1 in ZorroFix.ini.

(Hopefully there's a better conventional solution....)

The more conventional solution: Just exit the current trade at limit, then open the new one. As you would also do in manual trading.

This has two problems:

- Creates an unnecessary trade. If I use a trade management function that has to "work" to get a good fill, it should be avoided to make more trades than necessary.
- exitLong/exitShort seems to ignore OrderLimit. Logging in the plugins BrokerBuy2 function shows that it is called with limit = 0 while OrderLimit is set. I read in the manual that exit calls can also use limit orders if supported by the plugin but I'm not sure how to implement that then.

That trade is necessary. Any NFA broker requires it.

Zorro sends Orderlimit in entry and exit. It indeed depends on the plugin, but most plugins should support it since they use anyway the same function for entering and exiting. Make sure that you have the latest Zorro version.

If your objective is to go from a positive position to a negative position with a single limit order (instead of two orders), my unconventional solution does exactly that.

The unconventional solution would work, but you then need to increase the order. You need to add the open position on the size of the short order.

The super-unconventional method is to supply the order() function in the script to suppress all trading activity to the broker plugin. Then manually place all orders using extra interfaces supplied by the broker plugin (or whatever trading interface you are using). Then update the status of order fills by modifying the TRADE structs. This virtually guarantees that Zorro will give you no surprises, but it's extra work for the script writer.

I'm using the FTX plugin which was recently published by a Zorro user. I don't think FTX requires NFA, but the plugin doesn't have BrokerSell2 implemented and Zorro complains that it can't exit positions without the NFA flag set. So I'm guessing Zorro requires NFA when BrokerSell2 is missing?

FTX does allow reversing orders by entering a larger trade in the opposite direction. If the broker allows it and is not NFA compliant, is there a way to achieve this in Zorro in a more conventional way?

Also, using cancelTrade to remove the old position will completely drop this trade from Zorro's trade history, no? So most of Zorro's metrics will report nothing useful for monitoring the strategy.

Yes, but you can use enterTrade() to report what happened, one enterTrade call for each time the position was positive or negative.

That's a good point. I think I got it sort of working now with enterTrade(). Also had to set the exit price of outgoing orders and more importantly toggle the TR_OPEN flag off, otherwise the trade was added as an open trade again upon enterTrade. With the flag off, Zorro didn't print an "Enter Long..." message but the trade shows up in the report at the end. It's pretty hacky but it works

Unfortunately this seems to throw off Zorro's performance measures still. The attached picture correctly shows the trades as they really happened but the equity curve is clearly bogus. I've verified that every TRADE's commission/spread etc is set to zero with the trade loops. The final report also shows zero trade costs.

The final report correctly shows the number of trades but it shows 0% winning trades when almost all of them are in fact winning. I set the fResult field appropriately to reflect the result of each trade. I can't check if the Gross win/loss are correct because my trading volume is so low, Zorro doesn't show the necessary precision.

Could mean that Zorro keeps a tally for these measures and assigns them before I can get a handle on the TRADE struct to modify it, and doesn't recalculate them by looping the trades for the report... Not sure how to fix this. Is the PERFORMANCE struct accessible per script?

I really don't know what you did. enterTrade is a beast to tame since you have to manipulate TRADE structs.

Check out the Simulate script, which gives a great example on how to use enterTrade for this kind of purpose.

This is the code that reverses a position:



Commission is also set to zero earlier. I don't think it's that I forgot something, I suspect Zorro adjusts the internal performance metrics at the enterLong() call before I can change any properties of the trade.

Any chance I could get a dev's insight?

Hmm, I admit that even I am lost about the purpose and working of that code. I can only say that it looks very dangerous.

The normal way to reverse a short position with 2 orders:

exitShort();
enterLong();

The unconventional way with 1 order, open position is ThisTrade:

enterLong(Lots+TradeLots);
cancelTrade(ThisTrade);

Yes, but problem with that is that the cancelled trade completely disappears from Zorro's grasp, thus it is lost from any performance report. The above code is messy because I tried to re-enter the cancelled trades in order to leave the performance measures intact.

Can you tell me how Zorro internally handles its performance variables? Does it iterate over all trades to calculate the performance report from scratch or does it keep a variable for the overall profit for example that is added up whenever a trade closes and then printed to the performance report?

Yes, it iterates over all open trades and calculates the open profit from scratch. The closed profit only changes when a trade is closed.

What exactly is the problem with the normal exit/enter method? It does normally not matter for transaction cost if you use 1 or 2 orders. You can exit at limit and then enter at the same or another limit.

The problem is I am trying to act as a market maker only to benefit from zero commission. The strategy is built on that. I'm sending post-only orders through the broker plugin to the exchange that either get rejected because they would act as taker orders or the plugin waits for the order to get filled. It will repost rejected orders or wait until a maximum timeout has passed and then return 0 if the order wasn't filled in time.

So the plugin has to "work" to get fills, which can take some time. E.g. on 1 min bars, I can't wait longer than that for an order to get filled. If I send two separate orders the process must happen twice within the bar duration, increasing the chance that orders are missed, or at least making the order process more complicated.




Thank you, that is good to know. But the same probably does not apply to the array of balances Zorro uses to draw the equity curve. Can you tell me how this is handled? Based on my experience it looks like this value is adjusted with spread/commission/slippage immediately upon the enterLong() call, before I can modify any values of the trade struct.

Yes, the equity curve is adjusted at opening trades and at any tick. It is the sum of open and closed profit.

If needed, you can adjust the equity by adding or subtracting from Balance.

Thank you, I will try again soon, maybe I'll have more luck this time

But if the broker plugin outputs balance and equity, this would be unnecessary I believe.

That might be true. I don't know if Zorro uses that return value from the plugin to generate the equtiy curve in the chart or if it uses something internal like ProfitTotal or similar.

That depends on which plugin and which SET_PATCH configuration you use.

The plugin does return the Account balance and if Zorro indeed uses the change of that value to draw the equity curve then that could explain why mine looked bogus. There were some other positions open in the account that were much larger in size than the 1 Lot test trades I did

Returned live parameters from the broker plugin, for account, trades, assets, override anything. Unless you disable them with SET_PATCH.

Hmm...
https://github.com/vitakot/ftx_zorro_plugin/blob/main/src/ftx.cpp#L231
If account.m_totalAccountValue is actually the account equity, then the plugin was written incorrectly.

Emphasis added:
https://zorro-project.com/manual/en/brokerplugin.htm

Yes, I think you are right, but it doesn't matter for my case because I still don't think Zorro really uses those values beyond printing it to the Zorro window and making it available in the Balance variable.

I found the variables that I was mostly looking for:
g->w.vWin and g->w.vLoss keep a tally of closed profits/losses and the difference between them is drawn as the equity in the chart and to the Zorro status section during the session. I have to modify those based on the result of the trade I'm cancelling/entering
g->w.numWin and g->w.numLoss are the number of won/lost trades, also a running tally. For some reason all trades are added to the losers upon cancelTrade, so I had to correct that manually.

Those are at least the important metrics but there are many more to take care off.

I think this is something Zorro should support natively. Is this really such a crazy use case? I don't see why trades should be split up into multiples if it's not necessary. Especially because many brokers (like IB) charge minimum order fees or flat fees, thereby increasing the overall commission if the order is split up. It's probably not too hard to implement in Zorro as an alternative order type that is activated by some flag. The normal trade logic can be left untouched, just adding it as an alternative.

If the broker has a flat fee, use virtual hedging. This ensures the minimum number of orders.

If the virtual hedging modes submit the pool trades always as one order, I might be able to work with that. I probably have no control per script over the execution of those, they will always be market orders (I assume) but I could add a brokercommand to turn them into limit orders on the plugin side perhaps.

By the way, the FTX plugin on github also has another bug I think. BrokerHistory returns T6 candles with their starting timestamp when Zorro expects the ending timestamp, doesn't it? So every minute candle is effectively shifted by one bar.