Hello,

   I am about to attempt to migrate a strategy coded in a charting platform to Python / QuantConnect, and I had a 3 questions about using Renko on QuantConnect that I was hoping someone would be able to weigh in on?

  • On other platforms that have Renko, you have to use code to prevent trades on “phantom” bars. A phantom bar is a bar that is created at a price point that the market didn't actually reach, or at a price point that was nor tradable. An example here is an asset that gapped-up $1.50 overnight. A normal $0.25 Renko chart here would show 6 up-bars (phantom bars) and could potentially have a trade in the middle of those based on your indicator/logic, even though a trade could not actually be executed there. 
    • My question here is, do you also have to code around that on QuantConnect, or does the Renko Consolidator handle that? On another platform I would have to make the logic subordinate to windows of time that the market is open, for instance.

 

  • Is there a way to make the Renko bar size dynamic, or is it currently built to be fixed-price-only? 
    • I saw a couple of older posts about people wanting to do this, but am unsure if it ever went anywhere. I.e. A Renko bar size based on a % of the underlying asset, or a rolling ATR. 

 

  • Lastly, are there data limitations I should be aware of? In my experience, these bars are typically made with tick-level data. On other platforms, I can only get this resolution 6 months back (a main reason I want to code this on QC). But, I also read a disclaimer on QC about there being some dirtiness in the tick data that would need to be accounted for. Can anyone clarify what that issue is and how others might have handled it? Or, should I just use second based data for directional backtesting and tick-level data for live trading?

 

Any insights you have on these topics would be greatly appreciated! Thanks

Author

Aaron Farrell

May 2022