About Strategy registration, on_bar timing, and scalability concerns in multi-strategy environments?

[daydayup789]

---

I'm really excited to be learning from this project — after exploring many different trading frameworks over the past couple of weeks, this one feels like the fastest and most suitable for my needs so far.

Due to connectivity restrictions in my region, I’m currently unable to connect directly to exchanges, so I haven’t been able to test any examples yet. However, I do have a few questions:

---

1. Strategy design

After reading through all the example strategies, I noticed that most of them rely on relatively simple, first-level indicators.
But in my own strategies, I often use more complex indicator chains. For example, consider this pseudocode:

signal = KAMA30(delta_70(max(SMA_190, max(MFI_130, WMA_190))))

In this case, I maintain a time series like [(datetime, signal)] to ensure proper signal generation, and I may need to compute the mean and standard deviation over a specific window from this series.

In the examples, indicators are registered using register_indicator_for_bars, which works well for basic indicators like SMA_190, MFI_130, or WMA_190.
But for more complex cases — like KAMA30 which relies on transformed input instead of raw OHLCV — it seems that register_indicator_for_bars might not work.

So my question is: how should I handle multi-level or composite indicators like this? Is there a recommended approach to register and update them properly?

---

2. on_bar mechanism

I’d like to understand the on_bar callback behavior more clearly:

• Is it triggered on every tick, or only when a bar closes?
• When it is triggered, does it reflect the close price of the current bar, or is it based on the open price of the next bar?
• If I want to design a strategy that computes signals based on the previous bar’s indicators, and places an order on the open of the next bar, is this supported in the current design?

---

3. Strategy capacity under fixed hardware

One of the most exciting aspects of this project for me is that it seems theoretically possible to run many strategies in rotation — for example, dozens or even hundreds of strategies per symbol.

In practice, I may want to apply M strategies across N different contracts.

Given this architecture, and assuming I run on a typical 4-core CPU with Python-based strategy execution:

• What is the realistic upper limit of strategies that can be handled with node.trader.add_strategy?
• Is there any guidance or benchmark on the number of concurrent strategies supported under typical hardware conditions?

---

Thank you very much!

[cjdsellers]

Hi @daydayup789

Thanks for the feedback and for reaching out. I can provide some quick answers to some of the questions:

1. You could write your own custom indicator class which nests all required indicators. We don't have first-class support for that kind of chained functional approach at this stage. Indicators are really a specific type of user-provided code, so it's expected you would write the code for custom functionality such as this, its certainly possible though.

2. on_bar is called when an internally aggregated bar closes -> emitted on the message bus -> and arrives at the actors handler, or when an externally aggregated bar is received and passed through the message bus to the data engine -> actors handler. Timestamping is typically the close of the bar, but this is also configurable, you'd have to reference the docs for config options. Your desired order sequencing is possible.

3. I can't give any ballparks here, the only limit is machine resources and actors/strategies are extremely light weight.

The platform capability is far ahead of where the docs are at, so there is a certain amount of digging around in code and discord threads to get up to speed on what's possible -- I don't think you'll find many limitations based on your questions though.

I hope that helps!

Some docs references:
https://nautilustrader.io/docs/nightly/concepts/actors#callback-handlers
https://nautilustrader.io/docs/nightly/concepts/backtesting#bar-based-execution