Custom strategies could be more complex if UpdateWithOps was strategy specific about kelp HOT 4 CLOSED

@Reidmcc I think that most (if not all) strategies can be coded using a level provider.
Can you provide an example of a strategy that would not fit into the levelProvider interface?

from kelp.

An example would be if you wanted to implement criteria in modifySellLevel that aren't exactly the existing price and amount triggers. If you want to know how far out of tolerance the level is, the current modifySellLevel doesn't know that. You might want Kelp to change what it does to each level based on how much the price has changed. The level provider can implement logic based on what the price is, but not what the price was. This would apply for anything that requires comparing the current generated level with the previous offer, and wouldn't have to use the existing tolerance parameters.

Using UpdateWithOps you could implement logic based on what happened to the previous levels. For example, if you wanted to space your levels more widely if the price was moving more quickly, you could count the number of levels that needed modification and if it reaches a threshold regenerate the levels with a passed increased spread parameter.

from kelp.

After working on #60 I now know that the level providers can store data across cycles, which would allow the examples I gave above to be done in the level provider.

The remaining case for this issue's suggestion is for customized strategies that use a completely different concept than a strategy that wants to replace offers that were filled. If you weren't doing market making that could well be the case. Metrics based swing trading would be an example. That may be out-of-scope for Kelp if it's intended to always be a market maker.

from kelp.

I'm going to go ahead and close this. If a user requests something that requires this we can keep it in mind.

from kelp.