anasarkawi1 / mercury

A currently in development Python module made for algorithmic trading and sits at heart of Lycon.io and powers the platform.

Mercury / Quantitative Finance Made Accessible.

Mercury is a core package used in Lycon project which is a platform for traders to use and employ Quantitative Finance in their trading. The tool is still a work in progress and so far only works with Binance APIs.

Example Usage

DISCLAIMER: this is just an example of how to interact with the llibrary, and it is not an example of a viable algorithm that can be used to trade for profit. Look at the Disclaimer section for more information on using this library to trade.

In the main.py file there's a short example algorithm which buys ETH when the RSI level is 40 or below, indicating that the asset may be oversold, and sells the bought ETH when the RSI level is 60 or above.

Features

The package has many features including:

• Price Acquisition: The library has the code required to obtain historic data and update it as live data comes in.
• Indicator Calculation: The package contains all the needed functions and routines to calculate indicators for a given security.
• Basic Algorithmic Trading: By using simple functions you can define parameters for the bot to trade automatically based on market conditions.

For the future

The future plans for the bot includes but not limited to:

• Adding various other indicators,
• Adding support for other exchanges,
• Improving runtime routines to be more robust,
• Implement more advanced algorithms,
• Implement more statistical analysis tools.

Updates and more information

I will post regulat updates on the development of the project on my website in its designated section here and on my LinkedIn as reposts from the company page here.

Licensing

The software is licensed under the Mozilla Public License Version 2.0. Details of the licensing can be found under the LICENCE file.

The software is provided in "as is" basis, with no warranty or liability. More information on the license file.

Disclaimer

This is an on-going project with only one developer managing it. As of now, the code in this repository is not meant for production. Malfunctions and bugs are expected. Use this code at you own risk, the author of this code is not responsible for any damages or losses.

mercury's Issues

Add moving averages system

Due to the need of multiple moving averages a system has to be made to make it easier to calculate MAs of different lengths.

• The system should be able to automatically add moving averages into the pandas DataFrame.

Fix Algorithm Execution Function

The current implementation for algorithm execution has been scrapped but can be accessed in GitHub Gist for reference (here)[https://gist.github.com/anasarkawi1/2209590488c30ce5fe18641ff1481b66].

Order validity check

Currently, all the checks on an order (balance sufficiency, etc.) is done by the user and there are no internal checks or handling for errors (caused by the API when it rejects the order).

• Exception handling if an invalid order goes through to the API and gets rejected.
• Internal checks for the validity of orders (sufficient balance, etc.)

Optimise indicator calculations by implementing a single loop system.

Indicator calculations are done on individual loops all looping through the price DataFrame each time a calculation is being done. This should be fixed ASAP but not before issue #2 is solved, since both issues are relevant here.

Order Objects

Currently, the way order execution work is by calling the buy() or sell() function from class_data class which calls the specific connector library function that sends a market order to the exchange at the given quantity then returns the response. Few issues with this approach:

• The client has no easy way of knowing trade status (i.e. how much of the quantity is filled, at what price was the quantity executed, etc.)
• There's no easy way to reference the trade again without dealing with the raw REST API response given by the exchange (which changes from exchange to exchange)
• Makes it harder for the user to execute orders due to its rigidity

A proposed solution could be the implementation of an order object where the user can create an instance of it through the library which would hold all the necessary inputs and values for order creating and management.

Automation of indicator calculations

Indicator calculations are added into the code manually and are hard coded. The calculations should be done automatically by utilising a system that will add the calculations into the runtime as needed.

This could be done by using a indicator configuration file which tells the bot the name, the parameters, and the function responsible for their calculation.

Reversing of DataFrame indices

In its current form, the latest data is inserted into the DataFrame oldest first (i.e. index = 0) and the latest last (i.e. index = length of DataFrame) which can cause problems in the design and functioning of the library.

For this reason, the DataFrame indices should be reversed making the latest data have the index 0.