Crypto Buy-Dip, Price Percentage Delta- Top 1% of Community.

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?