There are some design decisions that should be documented:
- It is not planned to implement further strategies, in order to keep the complexity low.
- Placing or cancelling orders as batches was tried before, but handling those was cumbersome back then. Now it might be better, but since 80% of the code only exists in order to keep track of orders and don't break if Kraken's API messes up, refactoring the whole code might not worth the effort. The benefit would be less requests (and thus faster execution) in some cases. This might need to be explored, but for now nothing is planned.