This project is a High-Frequency Trading (HFT) system built using the Binance Spot API. The system is designed to execute rapid and frequent trades, leveraging price discrepancies across multiple cryptocurrency pairs to generate profits. The project includes various transactions that handle the buying and selling of assets, with logic implemented to ensure efficient and profitable trading.
To get started, it's important to familiarize yourself with Binance's API and testnet environment:
- Setting up Testnet and Postman: Binance Blog Post
- Binance Spot API Documentation: Binance Spot API Docs
Follow these steps to manage and monitor the HFT system:
- Start the Application in Stage Environment:
npm run start
- Start the Application in Production Environment:
npm run start:prod
- Stop the Application:
npm run stop
- View Application Logs:
npm run logs
- View Error Logs:
npm run logs:error
- Restart all Running Processes:
npm run restart
- Delete all Running Processes:
npm run delete
- Check the Status of Processes:
npm run status
- Clean Log and CSV Files:
npm run clean
Your project requires environment variables to configure the API keys and secrets for different environments. These variables should be stored in a .env
file located in the root directory of your project.
Here’s an example of how your .env
file should look:
# Staging Environment Variables
API_KEY_STAGE=BsqzqZH5xaWHuxaTFR7O5sQxXhrnyO26ThGgcdrTHWiK0m9upREB9JuiJZSqDE3K
API_SECRET_STAGE=kYbAPQRNmOkDFTGgmkRKzkkM9RvGxJwPniI9EKGaKbWeBeoklSkuAtdLQq1xjG72
# Production Environment Variables
API_KEY_PROD=your-api-key
API_SECRET_PROD=your-api-secret
-
Create a
.env
file in the root directory of your project if it doesn’t already exist. -
Copy the sample environment variables into your
.env
file:# Staging Environment Variables API_KEY_STAGE=your-staging-api-key API_SECRET_STAGE=your-staging-api-secret # Production Environment Variables API_KEY_PROD=your-production-api-key API_SECRET_PROD=your-production-api-secret
-
Replace the placeholder values (
your-staging-api-key
,your-staging-api-secret
,your-production-api-key
,your-production-api-secret
) with your actual API keys and secrets.
- Never commit your
.env
file to version control (e.g., GitHub) as it contains sensitive information such as API keys and secrets. Ensure that your.gitignore
file includes.env
to prevent accidental commits. - Example
.gitignore
entry:# Ignore environment variables .env
The system tracks the number of API calls made during operation. You can use the following log keys to understand the system's API usage:
- COUNT[PRICES] - Number of API calls made to fetch prices.
- COUNT[ORDER] - Number of API calls made to place an order.
- COUNT[CANCEL] - Number of API calls made to cancel an order.
- COUNT[STATUS] - Number of API calls made to check the status of an order.
The system generates log files to help you monitor and debug trading activities:
- Application Logs: Tracks general system activities.
npm run logs
- Error Logs: Captures errors encountered during execution.
npm run logs:error
After running the system, a report.csv
file is generated. This file contains detailed records of all trades, including:
- Timestamp: The exact time when the trade was executed.
- Pair: The cryptocurrency pair traded (e.g., BTC/USDT).
- Order Type: Whether the trade was a buy or sell.
- Price: The price at which the trade was executed.
- Quantity: The amount of cryptocurrency traded (both executed and cumulative)
- Status: The outcome of the trade (e.g., Completed, Reversed, Undervalued, Error).
Use this file to analyze your trades and refine your strategy for better performance.
Here are some tools that might be helpful during development and monitoring:
- Merge CSV files online: merge-csv.com
- Logs Prettifier:
- String to JSON Converter: dadroit.com
-
Fetch Market and Bid/Ask Prices:
- The system fetches the current market price and bid/ask prices for relevant cryptocurrency pairs to assess profitability conditions.
-
Condition Check:
- If the calculated condition for profitability is met, a limit order is placed at the bid or ask price. The system then immediately checks the order status for the next 2 seconds.
-
Order Placement and Status Check:
- Place a Limit GTC (Good 'Til Canceled) order.
- The system checks the order status as quickly as possible.
-
Order Execution:
- If the order is fully executed within 2 seconds, the process moves to the next transaction.
- If the order is not filled within 2 seconds, it is canceled. The partially filled quantity is forwarded to the next step, and the system reattempts the remaining quantity after fetching new prices.
-
Ask Price Execution:
- The limit order is placed specifically at the ask price during this transaction.
-
Initial Setup and Price Fetching:
- The system fetches both the market price and bid/ask prices, similar to transaction 1.
-
Condition Handling:
- Condition 1 is False:
- If the primary condition is not met, the trade is reversed at the limit bid price. This reversal is attempted infinitely, with a 1-second wait between each attempt.
- Condition 1 is True and Condition 2 is True:
- A Limit GTC order is placed at the market price and waits for 1 second. Any quantity not executed in 1 second moves to the next step, while the executed quantity proceeds to transaction 3.
- If needed, a Limit GTC order is placed at the bid/ask price with up to 2 attempts. If unsuccessful, the trade is reversed.
- Condition 1 is False:
-
Reverse Handling:
- If neither condition is met, the transaction is reversed using the predefined logic.
-
Order Placement:
- A Limit GTC order is placed at the current bid/ask price. The system waits for 1 second for the order to fill.
-
Handling Multiple Attempts:
- The system will continue to attempt the order indefinitely with new bid and ask prices for the third cryptocurrency pair, with a 1-second wait between each attempt.
-
Order Execution Handling:
- If the order is partially or fully executed, the executed quantity is passed to the next transaction. If nothing is filled, the system waits for 1 second and reattempts.
-
Transaction 4 and ReverseTransaction1:
- Transaction 4 uses the same logic as described above for placing and monitoring orders.
- ReverseTransaction1 specifically reverses the order made in transaction 1, following the same logic and conditions as in transaction 4.
-
Final Checks:
- Each transaction continuously monitors the order status. If the order is fully executed, the transaction is completed. If not, the order is canceled, and the remaining quantity is reattempted.
-
Handling Partial Executions:
- If an order is only partially filled, the executed portion proceeds to the next transaction. The remaining quantity is reattempted under the same conditions.
-
Infinite Attempts:
- For transactions 3, 4, and ReverseTransaction1, the system attempts to execute the order indefinitely until it is filled.
the Target is Achieved
- Scenario 1: If the initial amount is 500 and it drops to 440, and the process completes, the entire process should be restarted.
- Scenario 2: If the amount reaches 450 at any point, the process should be restarted.
- Key Rule: Once 90% of the target amount is reached, there’s no need to run the process again just for the remaining 10%.
Additionally:
- Email Alerts: Use Nodemailer to send alerts if there are consecutive losses, ensuring that you're notified promptly when the process isn't performing as expected.
-
After Process Completion:
- The next process will only start once the current process is fully completed. (This is the current behavior.)
-
Block A:
- Restart the process based on the criteria outlined in Block A (e.g., when 90% of the target is achieved).
-
Continuous Restart:
- The process will restart every second, regardless of whether the previous process has finished or not. This ensures that the process is continually running.
When working with Binance's API for trading, it's crucial to understand the difference between executedQty
and cummulativeQuoteQty
, especially in strategies involving continuous buying and selling of cryptocurrency pairs.
executedQty
: The actual quantity of the base asset that was bought or sold in a trade.cummulativeQuoteQty
: The total quantity of the quote asset that was spent or received in the trade.
-
For Buy Orders:
- Use
executedQty
: This represents how much of the base asset was bought. - Example:
- Buying 0.1 ETH using 10 USDT at 100 USDT/ETH results in:
executedQty
= 0.1 ETHcummulativeQuoteQty
= 10 USDT
- Buying 0.1 ETH using 10 USDT at 100 USDT/ETH results in:
- Use
-
For Sell Orders:
- Use
cummulativeQuoteQty
: This represents how much of the quote asset was received from selling the base asset. - Example:
- Selling 0.1 ETH to receive 0.05 BTC at 0.5 BTC/ETH results in:
executedQty
= 0.1 ETHcummulativeQuoteQty
= 0.05 BTC
- Selling 0.1 ETH to receive 0.05 BTC at 0.5 BTC/ETH results in:
- Use
-
Step 1: Buying ETH with USDT:
ETHUSDT
pair: Buy 0.1 ETH using 10 USDT.- Quantity Calculation:
executedQty
= 0.1 ETH.
-
Step 2: Selling ETH for BTC:
ETHBTC
pair: Sell the 0.1 ETH to receive BTC.- Quantity Calculation:
executedQty
= 0.1 ETH;cummulativeQuoteQty
= 0.05 BTC.
-
Step 3: Buying QTUM with ETH:
QTUMETH
pair: Buy QTUM using 0.1 ETH.- Quantity Calculation:
executedQty
= 0.05 QTUM.
- For Buy Orders: Use
executedQty
to determine the amount of the base currency bought (e.g., ETH inETHUSDT
). - For Sell Orders: Use
cummulativeQuoteQty
to determine the amount of the quote currency received (e.g., BTC inETHBTC
).
Understanding when to use executedQty
vs cummulativeQuoteQty
is essential for correctly tracking the assets you are trading, especially in strategies involving continuous buying and selling of cryptocurrency pairs.
We welcome contributions from the community! Here’s how you can get started:
- Click the "Fork" button at the top right of this repository page to create a copy of the repository under your own GitHub account.
- Clone your forked repository to your local machine:
git clone https://github.com/your-username/BinanceSpotAlgoTrader.git
- Navigate into the project directory:
cd BinanceSpotAlgoTrader
- Create a new branch to work on your feature or fix:
git checkout -b feature/your-feature-name
- Implement your feature or fix.
- Make sure your code follows the project's coding standards.
- Stage your changes:
git add .
- Commit your changes with a descriptive commit message:
git commit -m "Add new feature: your-feature-name"
- Push your changes to your forked repository:
git push origin feature/your-feature-name
- Go to the original repository on GitHub.
- You should see a prompt to create a pull request for your new branch.
- Click "Compare & pull request" and fill out the PR template with relevant details.
- Submit your pull request for review.
- Be responsive to any feedback or requests for changes.
- Make updates to your branch as needed and push them to your fork.
- Once all feedback has been addressed, the pull request will be merged.
- Regularly sync your fork with the original repository to stay up to date:
git remote add upstream https://github.com/original-owner/BinanceSpotAlgoTrader.git git fetch upstream git merge upstream/main
If you find this project useful, you can support it by:
- Starring the repository on GitHub.
- Sharing the project on social media or with colleagues.
- Writing about it on blogs or in forums.
- Contributing to the code or documentation.
This project is licensed under the MIT License - see the LICENSE file for details.
Your contributions are greatly appreciated, and we look forward to collaborating with you on this project!