QuantConnect Community

Framework Description

The framework allows experimentation with, and utilization of, two fundamental properties. Those properties are trend and curvature of price. For example you may wish to select instruments that have been trending downwards and curving upwards, or some other mix of trend and curvature. The changes1Ratio variable determines the influence of trend. A positive changes1Ratio will increase the tendency to select instruments that have been trending upwards, a negative changes1Ratio will increase the tendency to select instruments that have been trending downwards.  The changes2Ratio variable determines the influence of curvature. A positive changes2Ratio variable will increase the tendency to select instruments with a price that has been curving upwards. A negative changes2Ratio will increase the tendency to select instruments with a price that has been curving downwards. You can also set either the changes1Ratio or changes2Ratio variable to zero. This will eliminate the influence of that variable. So if you just want to select based upon trend with no regards to the curvature you would set the changes2Ratio to zero. Magnitude has the obvious effect. A large magnitude of changes1Ratio combined with a small magnitude of changes2Ratio will produce an algorithm that mostly considers trend with regards to instrument selection. Both the trend and curvature considerations are exponential in nature. So more recent events will have a higher influence upon selection than older events.
 

The emaOfChanges1Indicator indicator is the primary indicator of trend. It holds an exponential moving average of the changes in price. You can change it's length by adjusting the emaOfChanges1Length variable. The emaOfChanges2Indicator indicator is the primary indicator of curvature. It holds an exponential moving average of the change in change of price. You can change it's length by adjusting the emaOfChanges2Length variable.
 

Hey Warren, 

Have you tried trading the strategy with other instruments? Just wondering it's robustness, I have another strategy that works great on crypto but not so well on other instruments. Meaning the crypto community might be naive and technical indicators and strategies still have high impact. 

Hi Elsid,

Ya, crypto is a newer space for algo developers so I've been looking at it as an opportunity before it's swamped with more refined analysis. I do have a volatility algo that operates on similar principles as the framework here, It profits well. Results with equities might be less than stellar. Fundamentals seem to do well there.

Hi Jared,

I see you changed the headline for me. Thanks, except that it's not an EMA cross. It might be better described as a buy the dip algo. Or, as I've called it, 'the framework'. Or simply a 'crypto algo'. 

Hello everyone,

I'll explain more thorughly how the algo operates. It doesn't really have a name because it operates on principles that I invented myself. I may not be the original inventor but I haven't seen these principles in common use. The primary trend indicator calculates the ema of the percentage changes in price. Note that it's an ema of percentage change in price, not the usual ema of price. This allows one to assign a single number to 'trend'. This number is based upon percentage change in price, so you can readily compare with other instruments to find the instruments with highest or lowest trend. Because it's an ema, more recent changes have a greater influence than less recent changes. The primary curvature indicator operates in similar fashion, but it takes an ema of the change in change of price.

How's that? ;) Fixed it.

Excellent. Thanks Jared!

Hey Warden, 
I converted it to limit order but the return has a significant drop compared to the initial one. Any idea what might have affected the algo?

Thanks

Hi Nick,

A few things come to mind, though I haven't examined your algo in detail. The Liquidate call will have to go as well, it uses market orders as I understand it. You might want to cancel the limit orders if they don't go through, possibly after some amount of time. This could be why the returns have come down so much, though I haven't checked thoroughly. I'ld have just used the bid price for purchases and the ask for sales given the behavior of the instruments on GDAX. If you go to the GDAX exchange you'll see that there is practically no spread. If you set a limit order at the ask for a purchase I'm not sure if you'll meet the 'maker' requirement for fees on GDAX, which is going to be critical for this algo.

Has anyone figured out a good algo for GDAX maker orders for this algo?

Hello everyone,

I attempted to launch the code "live" at OANDA, but it gives the following werrror. Could any one tell me what is missing in the code to go live?...Thank you!

Failed to initialize algorithm: System.Exception: No default market set for security type: Crypto at QuantConnect.Algorithm.QCAlgorithm.AddSecurity[T] (QuantConnect.SecurityType securityType, System.String ticker, QuantConnect.Resolution resolution, System.String market, System.Boolean fillDataForward, System.Decimal leverage, System.Boolean extendedMarketHours) [0x00036] in <321054ea1e964454bc0d403925dda91a>:0 at QuantConnect.Algorithm.QCAlgorithm.AddCrypto (System.String ticker, QuantConnect.Resolution resolution, System.String market, System.Boolean fillDataForward, System.Decimal leverage) [0x00001] in <321054ea1e964454bc0d403925dda91a>:0 at QuantConnect.MultiCoinFramework.Initialize () [0x00067] in <0e4d1f8fc06a43f2a3bc45c24a3f6958>:0 at QuantConnect.Lean.Engine.Setup.BrokerageSetupHandler+<>c__DisplayClass24_0.b__1 () [0x000fb] in <7a802d713401490dbae6b34efb125c68>:0

Has anyone had any success live trading this on GDAX? I'd be curious to see how the actual results pan out with a market order or even a limit order.

hi Alexandre Catarino & Jared Broad 

i wanted to play around with warrens code and see how it behaves with stocks but got a runtime error.

1) could you please help me find it? IT DIES ON

 2017-03-21 00:00:00 :Runtime Error: Cannot perform runtime binding on a null reference

edit the date first!!!!!!!!!

2) where did the VRX data go? :)

thx

I have tried to run a similar stragety live, and it buys the sells the first order great, but when it goes to buy the second it says invalid because of insufficient buying power, Does anyone have any ideas?

As of this afternoon, the strategy does not work if more than 1 crypto is in the string. Was working fine from yesterday through this afternoon.  If 2 only are on the list, ETHUSD, BTCUSD or BTCUSD, ETHUSD, the 2nd listed pair will fail with this error:

Runtime Error: 'BTCUSD' wasn't found in the Slice object, likely because there was no-data at this moment in time and it wasn't possible to fillforward historical data. Please check the data exists before accessing it with data.ContainsKey("BTCUSD") (Open Stacktrace)

This algo now fails! I hacked in a quick 'data.ContainsKey' and 'continue' thinking that would solve the problem and the returns dropped dramatically. Anyone at Quantconnect know what happened? Sounds like odd behavior given Thushara's report.

Warren i think Jeremy might found the problem.

data is null so the indicator and everything might be dead?

you could of course write to support@quantconnect  :)

my english is really bad :):) hehe

Some temporary data issue? seemed to impact the algos which subscribed to more than one pair.

It seems to be working again.

Nevermind OP's code works if you add the actual ticker string instead of the Symbol:

oh, scratch my last post that as well then :)

Yes, its working again.  Thank you. Trying it live right now.

I don't recommend trading it live with cash as is. It doesn't seem to make any money if the fees are too high, I have a version with fees modeled and checked. It needs to have the market orders converted to limit orders on GDAX or be ported to a platform with low fees like Binance in order to be profitable.

Here's the same algo with fee modelling. I set the fee to the same value as GDAX's 'taker' fee. As you can see it does not profit. It needs to be modified to take advantage of GDAX's free for 'makers' fee structure. I'm working on that but probably won't give away the results for free, sorry.

Hey Warren, I'm running an algo on GDAX live trading, im fairly new to coding. I'm having a problem with my code i belive. Wondering if you had some insight for me. What it does is buys btcusd then sells then sometimes its able to buy litecoin or ether and then sell but always after the first or second trade, it comes up invalid in the orders and the algo stops trading? Any info would help, Thanks!

Hey warren I played with your algo as well look what happens when you set emaofchangelenght 1 and 2 to 5 and back test from Feb 2018 to March, huge returns, I'm also very new to this so I do not know if that changes anything else with the Algo

Hi Samuel. I think Quantconnect might use asynchronous calls when live trading so that could be the problem. You might have to put a Thread.Sleep in to delay things so that the funds from a sale will be ready to make the next purchase. Ya, I noticed that if you shorten the trade frequency the returns go up, but you get a more volatile algo.

Hi Samuel. I tried out your suggestion, the equity curve actually looks pretty smooth. Interesting, thanks. 

Compounding Annual Return: 6443733821369940000000000%. Hope it's not all too good to be true.

Here's Samuel's suggestion with fee modelling. Still no slippage, but slippage is pretty low on GDAX for these instruments so it might actually profit.

Hey Warren thanks for the help, i think that would be the problem, would you be willing to show me exatly how to do that? again im fairly new to coding, I have been day trading for 10 years now and im trying to learn how to set up some algos to run my strageties. I find it very interesting just very difficult for me! Thanks again

Note that slippage is only going to be low if you are running a small account and buying at the bid/ask. If you are running a larger account you will need position building code and will have to consider slippage more carefully.

Hi Samuel. Sure, just Google Thread.Sleep to see how the call works. You might need to add a using statement. Then insert the Thread.Sleep call in between the sale and the purchase to create the delay. I typically bill people for assistance more complex than that, sorry.

Hi!  Just a couple of comments from the peanut gallery. 

First, thanks Warren, for sharing your algorithm!    

Second, I just want to suggest that I think QC is modelling extremely optimistic trade executions.  Towards the latter part of the backtest period, the algo is doing $1M trades, and filling them at market price.  Based upon my current experiences live trading on GDAX, I'm not sure those kinds of fills are realistic for the liquidity of these crypto markets.  And it's the compounding size of these trades that is leading to most of the returns in the backtest.  

Lastly, I'm perhaps missing something, but it appears the emaOfChanges2Indicator is not actually being used, since the weight is set to 0.  I just mention it in case anyone is looking to refactor/simplify.  I removed it from the algo and got the same backtest results.

Cheers and happy trading.

Nate

We don't recommend putting Thread.Sleep into your code -- this will guarentee your algorithm explodes from RAM issues as sleeping will cause the tick data stream to back up.

 Samuel Cutler   "it comes up invalid in the orders and the algo stops trading" - this is because you've likely spent the cash in your account and don't have the coins to trade. Please see the FAQs and pay close attention to the error messages -- we've made them pretty descriptive now. 

Hi Nate,

Yes, the optimistic trade executions you speak of are the same thing as I mentioned above with slippage and larger accounts.

Yes, you could remove the emaOfChanges2Indicator but you would be defeating what 'The Scaffolding' does. It allows you to quickly model strategies based upon trend and curvature. You've removed the ability to quickly check and see if curvature of the price graph affects returns. I left it in there so people could check curvature based strategies, even though it is not used in this case. I describe 'The Scaffolding'  in further detail above.

Thanks, Warren

Two things. One are asynchronous calls likely to cause problems when trading this algo live? In particular, will the Liquidate call still be processing when the call to SetHoldings is made, resulting in a lack of funds error? If so what is the best way to wait for the Liquidate call to go through?

Liquidate is synchronous up to 5s -- if the market order takes longer than 5 sec to fill it'll move to the next line of code. 

If there are multiple orders in flight weird things can happen! We're limited by how fast the exchanges can fill. You can increase this timeout by setting the market order timeout variable here:

PS: Warren; I've edited your comment ("the framework") to the scaffolding to prevent confusion with the official QuantConnect Algorithm Framework we're shipping this week.

Thanks Jared!

Sorry Warren, I zero'd in on the code and must have missed your full description of 'The Scaffolding'.

Just for fun, here's another implementation of your Scaffolding as a custom indicator. There's also a RateOfChangePercent indicator that we can do an EMA of, but it seems to give slightly different calculations.

namespace QuantConnect {


public class RocEmaIndicator : WindowIndicator<IndicatorDataPoint>
{
public ExponentialMovingAverage EMA1 { get; private set; }
public ExponentialMovingAverage EMA2 { get; private set; }

//public RateOfChangePercent ROC1 { get; private set; }
public RollingWindow<decimal> RW1 { get; set; }
public RollingWindow<decimal> RW2 { get; set; }

public decimal changes1Ratio = -1.0m; //The influence of change upon fitness.
public decimal changes2Ratio = 0;

public RocEmaIndicator(int emaPeriod, int historyPeriod)
: this(String.Format($"ROCEMA{emaPeriod}_{historyPeriod}"), emaPeriod, historyPeriod)
{
}

public RocEmaIndicator(string name, int emaPeriod, int historyPeriod)
: base(name, historyPeriod)
{
//ROC1 = new RateOfChangePercent(name + "_ROC1", historyPeriod);
EMA1 = new ExponentialMovingAverage(name + "_EMA1", emaPeriod);
EMA2 = new ExponentialMovingAverage(name + "_EMA2", emaPeriod);
RW1 = new RollingWindow<decimal>(historyPeriod);
RW2 = new RollingWindow<decimal>(historyPeriod);
}

public override bool IsReady
{
get { return EMA1.IsReady; }
}

protected override decimal ComputeNextValue(IReadOnlyWindow<IndicatorDataPoint> window, IndicatorDataPoint input)
{
//ROC1.Update(input);
RW1.Add(input.Value);
RW2.Add((RW1.First() - RW1.Last()) / RW1.First());
if (RW2.Count() > 1) EMA1.Update(input.Time, RW2.First());
if (RW2.Count() > 1) EMA2.Update(input.Time, RW2.First()-RW2.Last());

return changes1Ratio * EMA1;
}


public override void Reset()
{
RW1.Reset();
RW2.Reset();
EMA1.Reset();
EMA2.Reset();
base.Reset();
}
}

}

Thanks Nate! Your code looks a bit more concise than mine, nice.

Say I added USD while my algo was running Live. I want the algo to see the money and start using it. Right now after load it doesn't see my money. Is there a way to just re-initialize that object without down stream effects? 

John Schwartz not at the moment sorry you'd need to restart the algorithm.

Hi,

Is there a way to use the GDAX sandbox through the live feed to test these algos is a "real-world" type scenario.  Does that paper trading mimick the actual GDAX sandbox, or just the data? Would be interestiing to see if there is a true diff between Papertading and a real GDAX trades. Possiblyu there a way to define it in the algo in AddCrypto to Market.GDAXxxxx

I've been live-trading on GDAX this week (not this particular algo) and in a few days I'm planning to go back and backtest the period for which I have live trading data, and do some analysis of the differences between backtest outcome and live outcome for the same algo/time period.

Nate I'm trying some live trading as well and it buys and sells fine then when it goes to buy a second time i get this in my log 

Hi Samuel. Jared describes how to wait above. You can try that and see if it works.

Sam, the buy order is being submitted before the sell order has filled. Personally, I find the SetHoldings() and Liquidate() methods pretty limiting and use a complex framework of classes for trade execution.   I'm not sure what the easiest fix would be if you're using an algo similar to the above... If you use the MarketOrder/LimitOrder etc. methods instead of SetHoldings and Liquidate, then you can set a flag to make the orders synchronous, which means subsequent code doesn't proceed until the order fills.

Warren, I have tried the Transactions.MarketOrderFillTimeout = TimeSpan.FromSeconds(30);. Seems to do the same thing. I beleive what Nate is saying is the cause. I have to say I'm so new to this its quite diffucult lol. I'm using limit orders to try and keep fees lower on GDAX. Warren if you or Nate would be willing to help me on this or give me a few tricks to help. I would be hapy to compensate you for your time!

If you're using LimitOrders, then you can't really assume the order will be filled in any set amount of time; hypothetically, it could never fill.  So you'll want to add logic to either check the status of the submitted order, or check your current holdings using the Portfolio class.

For the updated Samuel's algo, in live GDAX, I did put this line of code as suggested for c#: Transactions.MarketOrderFillTimeout = TimeSpan.FromSeconds(45);

There were 3 transactions:

1.) Buy BTC : successfull 

2.a) 1hr later

a) Sell BTC :sucessfull

b.) Buy ETH - failed.  I was short by $0.0000369

I think another trade will occur in about a hour or 2, but the subsequnt sell then buy will have another error. The paper trading flows fine.

Is there a recommendation to calculate the trade quanity based on the shortened dollar amount for the trade to 2 decimals e.g. $321.12 instead of the 9 decimals. or only buy based on 99 or 98% of the cash.

Sorry did not see the 2 prior messages before my last one: Do I have to be concerned with the time in the log: At 11AM CST, the Event Time shows 3PM.  

Nate -  The order for sell is filled, and then the next buy is shown in the log.  It's just that the amount is less by few micro cents, that fails the order.

I think since the failure is due to a very small amount, if the next buy is set to 99% cash after the sale may help.  Issue is how to do a write that up in the code - noob here.

Thushara does your log say X amount of cash is reserved for open orders?

Samuel, it says "... 0 USD of which are reserved for open orders, ..." It says my portfoliio holds more than than needed.

E.g. The on the log states the portfolo has $1007.50, order needs $1000.123456789, but after the last sale, only $1000.123412345 is available.  The order is short by approx $0.00044.  

Order Error: id: 3, Insufficient buying power to complete order (Value:123.3949), Reason: Your portfolio holds 124.7492390002313 USD, 0 USD of which are reserved for open orders, but your Buy order is for x.81501615 ETH. Your order requires a total value of 123.394903944 USD, but only a total value of 123.3948670848 USD is available.  : 123 are masked numbers, but decimals are accurate

You can just set the leverage equal to 0.99.

mmm Thushara seems we are having similar problems, but mine says I have a certain amount reserved for open orders. Are you using limit orders? If you are trading live on GDAX it could be because of the fees that its given you that error. I have mine set for limit orders but I keep a certain % of my portfolio in cash for rounding limit orders and fees. I belive my problem is with the asynchronous call. Its buying then selling but then trying to buy again before the sell order is filled, Im very new to this as well and I am trying to figure out how and where to code this time hold. Id like it to sell then wait a minute or so before moving on to the next line of code to buy, but i am struggling in figuring out to do so.

Make sure you set the BrokerageModel property. Without it you have the potential to sell coins before you own them (short) or buy without the cash available for the trade. With the cash model we enforce that you own the coins/USD before placing the trade.

If executing through a brokerage with leverage its not a critical issue. There is just such a lot of volatility at the moment weird fills happen which might look unrealistic -- e.g. imagine a 1-minute bar of OHLC (150, 160, 140, 150). Imagine you had 2 limit orders for 159-Sell and 141-Buy. We'll model these limit orders as both filled within the 1 minute bar as long as you have the purchasing power at the time making it appear like an instant profit.

You should also probably assume you can only fill $1,000 or less at any of the bid/ask prices. Its fairly shallow at the top of the book at the moment in crypto. It might be more realistic to use a slow-fill model which fills over many bars.

What is this strategy doing exactly? It's just buying the dip and holding? Or I guess buying with an EMA cross?

nevermind this site was glitching and I couldn't read the prior comments haha

Samuel - I'm using the algo where you chnaged the emaOfChanges1Length =5.. I've put in the leverage=0.998m and the orders seem to work, it had gone through on the 3rd order without failing.

Jared, when I used "SetBrokerageModel(BrokerageName.GDAX)" in the past,, not sure of the eact verbiage, but I was getting an error that margin trading was not allowed and would error out.  Once I commented out that line, it would work as long as I defined it in the "AddCrypto(.....)".  

Alright so anybody figure out the backtesting on this? I'm sorry but these numbers seem utterly unrealistic, $1,000 to $7,500,000 in 2 months lol, market orders, something must be going on with the ordering. 

Change the settings for ema variables to 1 

$1,000 to $250,000,000M lmao yeah right...

Samuel - are you live trading? I have the limit orders running on paper trades with no issues; also have same algo from live trading on paper too.  So I can do some verification/analysis on them.

Thushara Silva 

Why do you have limit orders on? Even with market orders and fees the backtest is showing profitable....or are the numbers that the backtest is calculating for the fees wrong?

Ok guys launched this live, do I need to have my holdings in cash when I first launch it? It's currently all in BTC... How long does it usually take to get the first order?

I set it to a very low order size too see if it's operating properly. 

  - i have market order running live on GDAX.

I also have limit orders and market orders running on paper trading.  WIll let these run for a few days to do a comparision between all 3.

Thushara Silva 

Ok cool, I started running live too with super low margin to see how it performs, I'm not seeing any orders yet how long does it take to place first order? And my holdings are in BTC, not in cash. 

Also, I basically traded Samuals code as is for market orders, do I need to make any changes? I don't see any errors.

 Elsid Aliaj  - - could take 1-3 hours.  Take a look at the backtest results, you will get an idea of when the orders times.

Thushara Silva 

Looks like I am getting error for some orders, even though I lowered the margin to .001, 

1. Insufficient buying power? I also don't know why it was trying to buy the whole account with leverage set so low.

2. ETH/USD was rejected, broker unable to submit order.

This is my code btw, do I need to set 

SetBrokerageModel(BrokerageName.GDAX) somewhere?

Thushara I'm running a little different strategy live, but more or less does the same thing, I have mine set to limit orders to keep the fees down on the GDAX exchange, The best i've got so far was a buy sell then another buy and sell then it comes invalid orders, I come to think its because the algo is trying to buy again before it has sold the previous asset. I am trying to find the approrite place to code in the delay so it would sell that asset then wait a few minutes for that limit order to fill before moving on to the next lines of code. (I'm still very new to this)

Elsid explained in previous comments is how to set holding to BTC. I have been using cash. The above would work and profit but not to that degree. Towards the end its filling orders for over $1M theres not that type of liquidity in the crypto market to fill that type of order on GDAX. Setting the EMA to 1 would also increase the sharp ratio drastically. I found 5 to be a nice number for this algo (sharp Ratio still high) for shorter term the higher the number would be better for longer term in my opinion like Warren had it at 24. 

I think I figured out the insane profits, If you leave out in the backtests:

SetBrokerageModel(BrokerageName.GDAX, AccountType.Cash); according to the API it defaults to Margin trading of 2, if I'm not mistaken, when you turn on Cash which GDAX is cash only the profits go down, still nothing to scoff at, but about 10X less.

@Samual if the order issues are due to limit orders, I would just use market orders, the profits are still mind boggling even with fees turned on, it would save you a lot of time handling logic for the orders, and also with limit orders the backtests become kind of flaky as you never know if you would fill your whole order or not. 

I'm not very familiar with QC's data to be able to distinguish if it has proper/tick data.

I still don't understand why leverage is being ignored.... All my orders seem to be for full account size + fees, even though leverage is .001...

Jared Broad 

What does the model default too if you don't set brokerage model? Because when I don't set the brokerage model the algorithm shows returns of 10 times more, than when set... trying to figure out why.

Orders are filling fine live as Market Orders. Issue I've noticed is the status of orders doesn't change they all stay as Submitted. 

Elsid mine goes back and forth some say submitted some say filled, the best i got was a buy sell buy sell then the orders start to be invalid and it does this abou 5 times over the course of 6 hours. I am trying it now with market orders. I have my     Liquidate();Transactions.MarketOrderFillTimeout = TimeSpan.FromSeconds(100); but im not sure if I have this in the right spot?
                    
                    ;

So I had market orders running live since y'day. Updated leverage to .998, set "Transactions.MarketOrderFillTimeout = TimeSpan.FromSeconds(45);"

Last night it started acting up. 

1. Around 8 PM, it submitted an ETH order, but I assume it did not get filled, 2 hours later it tired to sell it.

2. 11PM - tried to sell an LTC order for more than I owned.  AFtrer that through this AM everthing is invalid, as it kept trying to sell this higher LTC amount than I owned.

3. Another issue is the at 4AM, the next log entry is at 10 AM.  I stopped the algo aty 9:53AM, but the Log time states 14:53.  Even though I restarted, it shows the time at 15:xx. Not sure if this sync issue causes order issues.

Samuel Cutler 

Yeah I don't have the TimeSpan at all, I'm assuming TimeSpan goes into the initilize function. I noticed only 2 orders come back as filled. I don't think the TimeSpan is needed at all for Market orders, also according to QC from an old post there is a default timeout of 5 seconds which should be more than enough, when you set your brokeragetype properly to GDAX it also makes sure you have the cash/coins for the order supposedly at least.

Yes I believe in should be under liquidate(), as anything outside of the if statement won't apply, and that is the only place I can see as order logic. 

But Again I've let it out completely and my orders are going through fine as Market orders.

Thushara Silva 

1. How do you know it did not get filled? It's a Market order unless the order didn't make it to GDAX.

2. Could be a margin issue, try lowering it lower than .998 because fees are probably not covering the order, I have mine set to .01 as an experiment and every order since last night has went through fine with no amount errors. You have to calculate what percentage fee GDAX charges on orders (0.3 %) which means you should probably lower margin to cover it, to say something like .997 as a bare minimum.

3. I am ignoring the log times for now also, as they are completely off. Unrealized profits seem off too, seems like live trading stats have been completely neglected for the most part, so I am ignoring majority of them.

Been running since 6AM I'll let you know if i run into any issues

Its not the margin/leverage etc. On GDAX the top of the order book is shallow - so when you submit an order for say 1BTC @ $5,000ea it only fills 0.01 at that price; and then others at more expensive prices after that. 

Normally exchanges don't fill or allow you to submit an order which will only get partially filled -- but in this case GDAX fills say 95% of the order -- 0.95BTC for $5,000 and never sends a "Filled" message to denote its done processing your trade.

We're working on a systematic fix for this now which will detect when the order is completed (as much as we can anyway). The way for you to not encounter this in your algorithm is to put a wider margin of error in your trading -- say leave 10% of BTC and 10% USD in your account at anytime.

Samuel Cutler 

Also Transactions.MarketOrderFillTimeout = TimeSpan.FromSeconds(45); doesn't seem to do anything at least in the If statement of Liquidate(); from what I read it would need to go into it's own Transactions class which this algo doesn't have. I could be wrong, but from backtesting you still get the same results with it on or off. 

I have vetted this algo pretty good. It's going to take quite a few mods to make it work. This algo is great on the ups, but it's crap on the downs. I don't recommend using it without an algo to initialize it on up trends only. 

It'll magnify downs just as much as ups. 

Here's an updated  Gdax fee model. 

John Schwartz 

Yes I noticed that too, but that doesn't really matter unless the backtests results are completely wrong, filtering might change performance/dd. Could also think of making a long/short version of it.

And even "crap" might be a loaded word, even with the downtrends it still manages the most insane returns, and only 12%DD.....

Jared Broad 

Hey Jared, I have set my order size to .01 of the account, and am still seeing a bunch of "submitted" status', in the case you mentioned above this shouldn't really be happening right? 

Logs show the orders getting filled and no errors. 

BTC has been on a Bull run for a long time. It doesn't mean the backtest is wrong. It's just a matter of risk management. If the next month BTC goes on a bull run then you will make a alot of money. 

You want to watch the algo break?
Run this time frame. With the correct fee model. 

SetStartDate(2017, 1, 1); 
SetEndDate(2018, 3, 22);  

Again it's a great algo on the up trend. Just put some code in to prevent it from running on a down trend, and you should be good to go! It is crap on the down trend. That is just a fact not an insult. 

John Schwartz 

Maybe with the original settings, with modified settings ran it from 1/1/2018 - 03/20/18 where BTC plunged by 50-60% and the backtest shows ridiculous returns and low DD....

Only thing is if there is issues with the backtest and is not trust worthy. I was getting errors going any farther but i'll try running it farther more. 

 John Schwartz 

Haha worked now, yeah you are right it basically blows out your account, at least on the agressive settings I had lol, going to play around with them. 

Yep no settings help it, blows out your account, can't believe i didn't backtest further completely forgot after that error haha. Don't trade this live unless you want to lose everything or trade it on an uptrend.

Something to consider is making it both long/short or applying some sort of long term ema, and only take trades in that direction

So my question guys is why if you back test it from this year 2018 alone the results are huge?

If you go from start of this month or Feb it wins, same with just March, when you run from Jan 2018 till now it loses quite a bit to start then picks up?

Samuel Cutler 

Yeah, It slipped my mind the date was 2-1 I was mistaking it for January so thought it performed amazingly, when I ran a longer term backtest about a week ago it failed, and forgot about running it longer term again lol.

The strategy basically long only, so in a collapsing market you just keep getting losers. 

Samuel Cutler

The entire crypto market went on a bull run during that time frame. It could make a lot of algo's look good. 

Trying to understand exactly how 'Fitness' is measured...

Appears to be...  Fitness = (-1.0) * EMA(currentPrice - previousPrice /  previousPrice) 

So, it buys which ever symbol has most negative price change?

Hi Eric,

Yes, it buys the dip.

Any idea why this performs so poorly with stocks?

@all - We've deleted the Kaiko quote data for crypto -- this will result in different fill prices; but more accurate in this exceptional case. You can read more about it on this thread. We'll keep the other thread updated so not to thread-hijack this one.

Dear QuantConnect people i may present you my crypto buy dip price algo transformed to sell volatility & leaveraged etn. I copied warrens algo and changed the crypto to stocks but it performed really really bad.

so i changed it from going long to going short :) :)

and suddenly i was a millionaire

but what can be shorted best....of course leaveraged stuff

so Lucas performs it poorly with stocks?????

worked on this 3 minutes

thats how algos should be developed....  :) :) :)

it has everything jupiter stuff and analysis everything

i am going to bed its late in my country

Michael Manus 

when I run the backtest it shows -99% drawdown.... when i add an end date, without an end date, you get your results but no stats?

weird if you set starting capital to $1000 you get -99% if you go $10,000+ you get positive returns.....

the algo is doing 2500 trades so the frees eat up the money

As Jeremy Bowen found the solutions for his problem. there are sometimes holes in the data so this line

if (data.ContainsKey(stockData.Ticker) && data[stockData.Ticker] == null)

from jeremy is important for playing around it seems..... and you are right statistics are gone....
still all credits go to Warren

Michael Manus 

Did you try going long I used the opposite long funds, and went long on them seems to be -99%. Any idea why this would work for short but not long?

leveraged etn stuff which is why everyone plays with that ...

check ugaz or tvix  ... going short people think is free money....