TRANSLATED CONTENT:

Hummingbot - Strategies

Pages: 73

1.20.0 - Hummingbot

URL: https://hummingbot.org/release-notes/1.20.0/

Contents:

Hummingbot v1.20.0 Release Notes¶
Introduction¶
Monthly Community Call¶
V2 Strategy Framework¶
New Dashboard Features¶
Hummingbot Library¶
Update Cython version to 3.0¶
New Chain and DEX Connector: Kujira¶
New CEX Connector: Woo X¶
New Rate Oracle Source: CoinCap¶

Released on October 02, 2023

We're thrilled to present Hummingbot version 1.20.0! This latest iteration introduces the V2 strategy framework which enables backtest-able, multi-bot strategies. For developers and advanced users, the Hummingbot Python Library has been rolled out. We've also integrated CoinCap as a new rate oracle source and expanded the list of connectors with Woo X and Kujira.

To update to the latest version, clone the latest hummingbot/deploy-examples repository and use the hummingbot-update.sh script under the /bash_scripts folder or run the following Docker command to pull the latest image:

If you're using the source version, use the ./start command to launch Hummingbot.

Join the Wednesday Oct 4th community call on Discord to learn about the new features in this release and other Hummingbot news.

Here is the recording of the event:

For more community events, check out the Hummingbot Events Calendar.

Hummingbot's V2 Strategy Framework is officially released!

The new V2 Strategy Framework significantly expands Hummingbot's capabilities, allowing users to create modular, backtestable, and sophisticated strategies. Unlike the monolithic V1 strategies, V2 Strategies are designed to be highly adaptable, allowing seamless integration of various components. Whether you're a technical expert or a trading novice, you can easily create, backtest, and deploy strategies via Dashboard.

We're introducing specialized templates for different trading paradigms, starting with Directional and Market Making strategies. These new strategy templates allow users to combine different composable components:

Watch this video for a preview:

Under Active Development

Dashboard is slated for incorporation into official Hummingbot releases before end of this year, but it is still under active development and new features and improvements are being added continuously. We highly encourage user feedback at this stage; feel free to share your thoughts and suggestions on Discord or Github. If you're excited to explore its capabilities, check out the beta.

Additions to Dashboard in the past month include:

We are excited to announce that Hummingbot is now available as a Python library, enabling more flexible usage and customization for developers!

To try it out, install the library into your Python environment with:

After installation is complete, enter your Python shell and run these commands to fetch historical OHLVC candles for BTC-USDT on Binance Futures for the past 30 days into a candles_test.csv file:

This upgrade not only brings in the latest features and bug fixes from Cython:

Modified the environment.yml dependencies to upgrade Cython to the latest 3.0 version (to move out from the alpha version the project is currently depending on).

Upgrading to the latest version allow Hummingbot to include all latest bugfixes. It will also allow the community to add the new functionality included in Cython 3.0 to generate a compiled Cythonized version of a pure Python module by just adding some Cython decorators to classes/functions.

Thanks to aarmoa for this contribution! 🙏

Kujira is a layer 1 ecosystem built on cosmos, blockchain known for its interoperability. Kujira Fin, is a decentralized order book exchange. It uses BOW as the market maker for liquidity. They claim no risk of impermanent loss with low gas fees and maker/taker fees.

See Kujira for the chain docs and Kujira Fin for the exchange connector docs.

Pull Requests: #6399, #138

Snapshot Proposal: https://snapshot.org/#/hbot-prp.eth/proposal/0x7dbd4a6f3cc7460ca6f56415a57b9727ca7a9227be625efdc4e71dee3d0d0781

Thanks to funttastic and yourtrading-ai for this contribution! 🙏

Launched in 2019, WOO X is a trading platform featuring deep liquidity, low trading costs and powerful tools & analytics. Some of you may also know us from our decentralized swap product WOOFi, which is one of the most-used cross-chain swaps with over half a million unique monthly active wallets.

Snapshot Proposal: https://snapshot.org/#/hbot-prp.eth/proposal/0x46c15f8b9cbbd97ebc8b83340bd748d5f68e84082d24383b91abdc3d8b9168c6

Thanks to waterquarks for this contribution! 🙏

This update introduces the CoinCap rate source to the rate oracle, offering an alternative to CoinGecko with price streaming capabilities.

Users can obtain an API key here.

Thanks to CoinAlpha for this contribution! 🙏

Examples:

Example 1 (unknown):

docker pull hummingbot/hummingbot:latest

Example 2 (unknown):

pip install hummingbot

Example 3 (python):

import asyncio

from hummingbot.data_feed.candles_feed.candles_factory import CandlesFactory, CandlesConfig

async def collect_candles():
    candles = CandlesFactory.get_candle(CandlesConfig(connector="binance_perpetual", trading_pair="BTC-USDT", interval="3m", max_records=1440))
    candles.start()
    while not candles.is_ready:
        print(f"Candles not ready yet! Missing {candles._candles.maxlen - len(candles._candles)}")
        await asyncio.sleep(1)
    df = candles.candles_df
    df.to_csv("candles_test.csv", index=False)

asyncio.run(collect_candles())

Controllers - Hummingbot

URL: https://hummingbot.org/v2-strategies/controllers/

Contents:

Controllers
Base Classes¶
Directional Trading Controllers¶
Market Making Controllers¶
Other Controllers¶

The Controller plays a crucial role within Hummingbot's Strategy V2 framework, serving as the orchestrator of the strategy's overall behavior. It interfaces with the MarketDataProvider, which includes OrderBook, Trades, and Candles, and forwards a series of ExecutorActions to the main strategy. The strategy then evaluates these actions, deciding to execute them based on its overarching rules and guidelines.

Users can now use controllers as sub-strategies allowing them to use multiple controllers in a single script or trade multiple pairs / configs in a single bot.

Currently, the controller base classes available are:

These strategies aim to profit from predicting the market's direction (up or down) and takes positions based on signals indicating the future price movement.

Suitable for strategies that rely on market trends, momentum, or other indicators predicting price movements.

Customizing signal generation (get_signal) allows users to change various analytical models to generate trade signals and determine the conditions under which trades should be executed or stopped.

These strategies provide liquidity by placing buy and sell orders near the current market price, aiming to profit from the spread between these orders.

Customization involves defining how price levels are selected (get_levels_to_execute), how orders are priced and sized (get_price_and_amount), and when orders should be refreshed or stopped early.

User may also adjust the strategy based on market depth, volatility, and other market conditions to optimize spread and order placement.

Cross-Exchange Market Making (XEMM) - Hummingbot

URL: https://hummingbot.org/strategies/cross-exchange-market-making

Contents:

cross_exchange_market_making¶
📁 Strategy Info¶
📝 Summary¶
🏦 Supported Exchange Types¶
🛠️ Strategy configs¶
📓 Description¶
- Architecture¶
- Live Configuration¶
- Order Creation and Adjustment¶
- Cancel Order Flow¶

Also referred to as liquidity mirroring or exchange remarketing, this strategy allows you to make a market (creates buy and sell orders) on the maker exchange, while hedging any filled trades on a second, taker exchange. The strategy attempts places maker orders at spreads that are wider than taker orders by a spread equal to min_profitability.

The description below is a general approximation of this strategy. Please inspect the strategy code in Trading Logic above to understand exactly how it works.

The cross exchange market making strategy performs market making trades between two markets: it emits limit orders to a less liquid, larger spread market; and emits market orders on a more liquid, smaller spread market whenever the limit orders were hit. This, in effect, sends the liquidity from the more liquid market to the less liquid market.

In Hummingbot code and documentation, we usually refer to the less liquid market as the "maker side" - since the cross exchange market making strategy is providing liquidity there. We then refer to the more liquid market as the "taker side" - since the strategy is taking liquidity there.

The startegy currently supports centralized exchanges on the maker side and centralized and decentralized exchanges on the taker side. Decentralized exchanges are accessed through the hummingbot gateway.

The cross exchange market making strategy's code is divided into two major parts:

Order creation and adjustment

Periodically creates and adjusts limit orders on the maker side.

Performs the opposite, hedging trade on the taker side, whenever a maker order has been filled.

The strategy now supports live configuration. That means any changes in configuration by the user are immediately taken into account by the strategy without a need for it to be restarted.

Here's a high-level view of the logical flow of the order creation and adjustment part. The overall logic of order creation and adjustment is pretty involved, but it can be roughly divided to the Cancel Order Flow and the Create Order Flow.

The cross exchange market making strategy regularly refreshes the limit orders it has on the maker side market by regularly cancelling old orders (or waiting for existing order to expire), and creating new limit orders. This process ensures the limit orders it has on the maker side are always of the correct and profitable prices.

The entry point of this logic flow is the c_process_market_pair() function in cross_exchange_market_making.pyx.

The cancel order flow regularly monitors all active limit orders on the maker side, to ensure they are all valid and profitable over time. If any active limit order becomes invalid (e.g. because the asset balance changed) or becomes unprofitable (due to market price changes), then it should cancel such orders.

The active_order_canceling setting changes how the cancel order flow operates. active_order_canceling should be enabled when the maker side is a centralized exchange (e.g. Binance, Coinbase Pro), and it should be disabled when the maker side is a decentralized exchange.

When active_order_canceling is enabled, the cross exchange market making strategy would refresh orders by actively cancelling them regularly. This is optimal for centralized exchanges because it allows the strategy to respond quickly when, for example, market prices have significantly changed. This should not be chosen for decentralized exchanges that charge gas for cancelling orders (such as Radar Relay).

When active_order_canceling is disabled, the cross exchange market making strategy would emit limit orders that automatically expire after a predefined time period. This means the strategy can just wait for them to expire to refresh the maker orders, rather than having to cancel them actively. This is useful for decentralized exchanges because it avoids the potentially very long cancellation delays there, and it also does not cost any gas to wait for order expiration.

It is still possible for the strategy to actively cancel orders with active_order_canceling disabled, via the cancel_order_threshold setting. For example, you can set it to -0.05 such that the strategy would still cancel a limit order on a DEX when it's profitability dropped below -5%. This can be used as a safety switch to guard against sudden and large price changes on decentralized exchanges.

Assuming active order canceling is enabled, the first check the strategy does with each active maker order is whether it is still profitable or not. The current profitability of an order is calculated assuming the order is filled and hedged on the taker market immediately.

If the profit ratio calculated for the maker order is less than the min_profitability setting, then the order is canceled.

The logic of this check can be found in the function c_check_if_still_profitable() in cross_exchange_market_making.pyx.

Otherwise, the strategy will go onto the next check.

The next check afterwards checks whether there's enough asset balance left to satisfy the maker order. If there is not enough balance left on the exchange, the order would be cancelled.

The logic of this check can be found in the function c_check_if_sufficient_balance() in cross_exchange_market_making.pyx.

Otherwise, the strategy will go onto the next check.

Asset prices on both the maker side and taker side are always changing, and thus the optimal prices for the limit orders on the maker side would change over time as well.

The cross exchange market making strategy calculates the optimal pricing from the following factors:

If the price of the active order is different from the optimal price calculated, then the order would be cancelled. Otherwise, the strategy would allow the order to stay.

The logic of this check can be found in the function c_check_if_price_correct() in cross_exchange_market_making.pyx.

After all the active orders on make side have been checked, the strategy will proceed to the create order flow.

After going through the cancel order flow, the cross exchange market making strategy would check and re-create any missing limit orders on the maker side.

The logic inside the create order flow is relatively straightforward. It checks whether there are existing bid and ask orders on the maker side. If any of the orders are missing, it will check whether it is profitable to create one at the moment. If it's profitable to create the missing orders, it will calculate the optimal pricing and size and create those orders.

The logic of the create order flow can be found in the function c_check_and_create_new_orders() in cross_exchange_market_making.pyx.

The cross exchange market making strategy would always immediately hedge any order fills from the maker side, regardless of how profitable the hedge is at the moment. The rationale is, it is more useful to minimize unnecessary exposure to further market risks for the users, than to wait speculatively for a profitable moment to hedge the maker order fill - which may never come.

The logic of the hedging order fill flow can be found in the function c_did_fill_order() and c_check_and_hedge_orders() in cross_exchange_market_making.py.

Decentralized exchanges have several peculiarities compared to centralized exchanges, which must be accounted for if selected on the taker side. For starters, in general interaction with them is less reliable. Unlike in case of centralized exchanges, for example obtaining an asset price from a DEX may occasionally fail. For this reason many operations on a DEX may have to be repeated until they're executed successfully.

Another difference is dependence of transaction fees on currrent gas fees. Therefore taker transaction fees may vary and therefore also position profitability checks performed in the method check_if_still_profitable() may return different results at different times for the same maker positions.

What is cross exchange market making?

Cross Exchange Market Making with Jelle

Use cross-exchange market making (XEMM) strategy to lower risk: The XMM strategy effectively reduces inventory risk. This article talks about how to proceed with XEMM in place.

Cross Exchange Market Making Strategy | Hummingbot Live: In this video, Paulo shows how to optimize a Cross Exchange Market-Making strategy using the Hummingbot app.

Check out Hummingbot Academy for more resources related to this strategy and others!

Strategies - Hummingbot

URL: https://hummingbot.org/strategies/

Contents:

Strategies
What is a Hummingbot Strategy?¶
Strategies V2¶
Strategies V1¶
Learn Algo Trading and Market Making¶

Like a computer program, an algorithmic trading strategy is a set of automated processes that executes repeatedly:

A Hummingbot strategy loads market data directly from centralized and decentralized exchanges, adaptable to the unique features of each trading venue's WebSocket/REST APIs and nodes.

Each clock tick, a strategy loads real-time order book snapshots, user balances, order status and other real-time data from trading pairs on these venues and executes the logic defined in the strategy, parametrized by a pre-defined user configuration.

To run a strategy, a user selects a strategy template, defines its input parameters in a Config File, and starts it with the start command in the Hummingbot client or via the command line with Strategy Autostart.

Starting in 2023, Hummingbot Foundation began to iteratively introduce a new framework, called Strategy V2. The new framework allows you to build powerful, dynamic strategies using Lego-like components. To learn more, check out Architecture.

There are two current ways that Hummingbot strategies can be defined:

Scripts: A simple Python file that contains all strategy logic. We recommend starting with a script if you want a simple way to prototype your strategy.

Controllers: Strategy logic is abstracted into a Controller, which may use Executors and other components for greater modularization. Controllers can be backtested and deployed using Dashboard, and a single loader Script may deploy and manage multiple Controller configurations.

Controllers are designed to add another layer of abstraction and circumvent the limit of Hummingbot to only run one strategy per bot instance. You can think of that as the most powerful and advanced setup that Hummingbot currently provides.

This table may help you decide whether to use a Script or Controller for your strategy:

When it launched in 2019, Hummingbot pioneered the concept of configurable templates for algo trading strategies, such as market making strategies based on the Avellaneda & Stoikov paper.

Initially, these strategies were confined to individual bots, complicating the management and scaling across various scenarios, and they lacked the capability to use historical market data, which forced traders to rely solely on real-time data. Furthermore, technical barriers, such as a deep prerequisite knowledge of foundational classes and Cython, hindered easy access to market data, while limited backtesting tools restricted evaluations against historical data.

Users can access these strategy templates at the Strategies V1 page.

To gain a deeper understanding of Hummingbot strategies along with access to the latest Hummingbot framework updates, check out Botcamp, the official training and certification for Hummingbot.

Operated by the people behind Hummingbot Foundation, Botcamp offers bootcamps and courses that teach you how to design and deploy advanced algo trading and market making strategies using Hummingbot's Strategy V2 framework.

Index - Hummingbot

URL: https://hummingbot.org/v2-strategies/examples/

Contents:

Index
Running V2 Strategies¶
Directional Strategies¶
- Bollinger V1¶
- MACD-BB¶
- Trend Follower¶
Market Making Strategies¶
- DmanV1¶
- DmanV2¶
- DmanV3¶

The main logic in a V2 strategy is contained in the Controller, which inherits from a base class like Directional or Market Making, that orchestrates various smart components like Candles and Executors to implement the strategy logic.

For users, their primary interface is the V2 Script, a file that defines the configuration parameters and serves as the bridge between the user and the strategy.

To generate a configuration file for a script, run:

The auto-complete for [SCRIPT_FILE] will only display the scripts in the local /scripts directory that are configurable.

You will be prompted to define the strategy parameters, which are saved in a YAML file in the conf/scripts directory. Afterwards, you can run the script by specifying this config file:

The auto-complete for [SCRIPT_CONFIG_FILE] will display config files in the local /conf/scripts directory.

Directional strategies inherit from the DirectionalTrading strategy base class.

In their controller's get_processed_data function, a directional strategy uses technical indicators derived from Candles to define thresholds which trigger long and short conditions using the signal parameter:

Here are the current V2 directional strategies:

A simple directional strategy using Bollinger Band Percent (BBP). BBP measures an asset's price relative to its upper and lower Bollinger Bands, and this strategy uses the current BBP to construct long/short signals.

Creating a Config File:

User Defined Parameters

Below are the user-defined parameters when the create command is run:

In addition, the script may define other parameters that don't have the prompt_on_new flag.

The screenshot below show what is displayed when the status command is run:

A directional strategy that combines MACD and Bollinger Bands to generate long/short signals. This strategy uses MACD for trend identification and Bollinger Bands for volatility and price level analysis.

Creating a Config File:

User Defined Parameters

Below are the user-defined parameters when the create command is run:

In addition, the script may define other parameters that don't have the prompt_on_new flag.

The screenshot below show what is displayed when the status command is run:

A simple trend-following strategy that uses Simple Moving Average (SMA) and Bollinger Bands to construct long/short signals.

Creating a Config File:

User Defined Parameters

Below are the user-defined parameters when the create command is run:

Market making strategies create and manage a set of Position Executors that place orders around a fixed mid price. They inherit from the MarketMaking strategy base class.

Customized market-making script which uses the DMAN v1 controller

Creating a Config File:

User Defined Parameters

Below are the user-defined parameters when the create command is run:

A simple market making strategy that uses Natural Average True Range (NATR) to set spreads dynamically.

Creating a Config File:

User Defined Parameters

Below are the user-defined parameters when the create command is run:

Mean reversion strategy with Grid execution using Bollinger Bands indicator to make spreads dynamic and shift the mid-price.

Creating a Config File:

User Defined Parameters

Below are the user-defined parameters when the create command is run:

In addition, the script may define other advanced parameters that don't have the prompt_on_new flag.

Directional Market Making Strategy utilizing the NATR indicator to dynamically set spreads and shift the mid-price, enhanced with various advanced configurations for more nuanced control.

Creating a Config File:

User Defined Parameters

Below are the user-defined parameters when the create command is run:

In addition, the script may define other advanced parameters that don't have the prompt_on_new flag.

Examples:

Example 1 (unknown):

create --script-config [SCRIPT_FILE]

Example 2 (unknown):

start --script [SCRIPT_FILE] --conf [SCRIPT_CONFIG_FILE]

Example 3 (unknown):

create --script-config v2_bollinger_v1_config

Example 4 (unknown):

start --script v2_bollinger_v1_config.py --conf [SCRIPT_CONFIG_FILE]

Liquidity Mining - Hummingbot

URL: https://hummingbot.org/strategies/liquidity-mining

Contents:

liquidity_mining¶
📁 Strategy Info¶
📝 Summary¶
🏦 Exchanges supported¶
🛠️ Strategy configs¶
📓 Description¶
ℹ️ More Resources¶

This strategy allows market making across multiple pairs on an exchange on a single Hummingbot instance. This is achieved by enabling users to configure the markets they would like to participate in and other market-making configurations. Volatility-Spread adjustment is another key feature of this strategy, where the spreads are dynamically adjusted based on the volatility of the markets.

Hummingbot Miner Help Center: Check out our latest announcements, campaigns, documentations, handy articles and much more.

Demystifying liquidity mining rewards

Liquidity Mining Explained | For New Users: Learn about Liquidity Mining and how to set up a market-making bot to earn rewards in an exchange.

Key concepts - Hummingbot

URL: https://hummingbot.org/developers/strategies/key-concepts

Contents:

Key concepts
Strategy folder¶
StrategyBase class¶
Market class¶
Configuration¶
- Important commands¶
- Exposing new strategy to Hummingbot client¶
- Setting question prompts for strategy parameters¶

Each strategy is contained in its own folder, with the strategy name as the folder name:

All strategies extend the StrategyBase class. This class allows extraction of logic that would be repetitively written in all strategies otherwise.

The base class also contains methods that are meant to be freshly implemented when new strategies are created.

To assist in the development of custom strategies, there are many overridable functions that respond to various events detected by EventListeners.

The ExchangeBase class contains overridable functions that can help get basic information about an exchange that a strategy is operating on, which can include the balance, prices, and order books for any particular asset traded on the exchange.

Additionally, this strategy leverages the OrderTracker listener object, in order to check if buy/sell orders have been filled or completed, the user has enough balance to place certain orders, and if there are any order cancellations. The HummingbotLogger object is also used to log the specific events when they occur.

Important commands on Hummingbot client:

The strategy name is made known to the client automatically in hummingbot/client/settings.py under STRATEGIES variable. There should also be a template file that contains config variables and its documentation in the hummingbot/templates directory. The naming convention for this yml file is conf_{strategy name}_TEMPLATE.

Strategy parameters can be set in the config_map file. Each parameter (represented as dictionary key) is mapped to a ConfigVar type where developer can specify the name of the parameter, prompts that will be provided to the user, and validator that will check the values entered.

URL: https://hummingbot.org/v2-strategies/diagrams/16.png

Command Line Autostart - Hummingbot

URL: https://hummingbot.org/global-configs/strategy-autostart/

Contents:

Strategy Autostart¶
Docker autostart¶
- Prerequisites¶
- How to autostart¶
Source autostart¶
- Prerequisites¶
- How to autostart¶

Running any trading bots without manual supervision may incur additional risks. It is imperative that you thoroughly understand and test the strategy and parameters before deploying bots that can trade in an unattended manner.

Hummingbot can automatically start the execution of a previously configured trading strategy upon launch without needing user interaction when provided with pre-existing configuration files. This can be very useful if you wish to deploy already well-tested strategies and configurations to cloud services and have Hummingbot running automatically in the background.

Stop any running containers

Use an IDE like VSCode to edit the docker-compose.yml file.

Edit or add the section that defines the environment variables:

The environment: line

The CONFIG_PASSWORD line: add the Hummingbot password to login

One of CONFIG_FILE_NAME lines: add your script OR strategy config file

Add your SCRIPT_CONFIG file if using a configurable script

The final environment section of the YAML file should look something like this:

Afterwards, save the file.

You can auto-start either a Script or a Strategy:

Scripts are Python files that contain all strategy logic. If you define a .py file as CONFIG_FILE_NAME, Hummingbot assumes it's a script file and looks for the .py file in the hummingbot_files/scripts directory.

Strategies are configurable strategy templates. If you define a .yml file as CONFIG_FILE_NAME, Hummingbot assumes it's a strategy config file and looks for the .yml file in the hummingbot_files/conf/strategies directory.

When you attach to it, the strategy or script should already be running:

Running unattended Hummingbot is very similar to running Hummingbot manually. The only differences are:

Where CONFIG_PASSWORD is the config password SCRIPT_FILE_NAME is the script / strategy file name CONFIG_FILE_NAME is the script / strategy config file name

Let's say you configured your Hummingbot password as a single letter a and you created a config for the Simple PMM Example script which you then want to autostart as soon as you start the bot. Here's how you would configure the autostart command -

a is the config password

simple_pmm_example_config.py is the script / strategy file name

conf_simple_pmm_example_config_1.yml is the script / strategy config file name

More information on strategy can be found in Strategy.

More information on configuration file name can be found in Configuring Hummingbot.

More information on password can be found in Create a secure password.

Examples:

Example 1 (unknown):

docker compose down

Example 2 (unknown):

environment:
      - CONFIG_PASSWORD=password
      - CONFIG_FILE_NAME=simple_pmm_example.py
      - SCRIPT_CONFIG=conf_simple_pmm_example_config_1.yml

Example 3 (unknown):

docker compose up -d

Example 4 (unknown):

docker attach hummingbot

1.24.0 - Hummingbot

URL: https://hummingbot.org/release-notes/1.24.0/

Contents:

Hummingbot v1.24.0 Release Notes¶
Introduction¶
How to Update¶
- Docker¶
- Source¶
Monthly Community Call¶
Configurable Scripts¶
New Sample V2 Strategies¶
- BollingerV1¶
- Trend Follower¶

Released on January 29, 2024

As we step into a new year full of infinite possibilities, we are thrilled to present Hummingbot version 1.24.0! A major highlight of this version are configurable scripts, which lets users create config files for V2 Strategies and basic scripts just like they can for V1 Strategies. We also added more sample V2 strategies, including the new DmanV4 advanced market making strategy.

This release also features substantial documentation updates, especially for exchange connector development and governance! Finally, we're excited to introduce two fresh DEX connectors: Vega Protocol and QuipuSwap, ensuring a broader range of trading opportunities for Hummingbot users across the DeFi landscape.

Clone the latest hummingbot/deploy-examples repository and use the hummingbot-update.sh script under the /bash_scripts folder.

Alternatively, run the following command to pull the latest Docker image:

Update your Hummingbot branch to this release by running:

Join the next community call on Discord to learn about the new features in this release and other Hummingbot news:

Afterwards, we will publish the recording on the Hummingbot YouTube and post it here.

For more community events, check out the Hummingbot Events Calendar.

Ever since we introduced Scripts as a lightweight way to create simple trading strategies, users have been asking for the ability to add configuration files for them, as they are able to do for V1 Strategies. Now, they finally can!

Starting in this release, scripts can define a ScriptConfig class that defines configuration parameters that users can store in a YAML file. Both V2 Scripts used to control V2 Strategies as well as more basic scripts can add this class with a few lines of code. Afterwards, users can create config files for scripts, which can be modified and shared easily.

See Config Files for details on how to use this feature.

Hummingbot's new V2 Strategies allow users to create powerful custom strategies by configuring LEGO-like components as building blocks. In this release, we have added a page with a list of Sample Strategies that users can extend and modify.

In addition, we've also added a few new sample strategies:

A simple directional strategy that uses Bollinger Band Percent (BBP), which measures an asset's price relative to its upper and lower Bollinger Bands, to construct long/short signals.

A simple trend-following strategy that uses Simple Moving Average (SMA) and Bollinger Band Percent (BBP) to construct long/short signals.

The new DManV4 strategy is a sophisticated market making strategy that utilizes Natural True Range (NATR) to dynamically set spreads, along with various advanced parameters for more nuanced controls.

This release features a revamped Building Connectors section for developers building connectors to order book spot and perpetual exchanges. We've added pages tthat describe the latest spot and perpetual connector standards, developer and QA checklists, as well as debugging and troubleshooting docs.

In addition, we have also revised the Polls section to reflect the changes approved in HGP-50, which replaced the legacy Gold/Silver/Bronze maintenance tiers with a new system that allocate HBOT bounties among the connectors for each Poll based on their pro-rata voting share. Each connector may have a public HBOT maintenance bounty allocation which the Foundation will use to fund bounties for bug fixes and upgrades related to that exchange's Hummingbot connector that can be assigned to community developers.

Vega Protocol is a new DEX built from the ground up using high performing, purpose-built smart contracts specifically for trading - meaning no fees on orders, and fairness at its core. It operates on the Vega Alpha Mainnet, a Tendermint based blockchain. For more information, see the Vega connector docs.

Snapshot Proposal: https://snapshot.org/#/hbot-ncp.eth/proposal/0x7c7e1d4590e669a1bed38335f9a2a94f4ec3adf463804488cb071e367dc7ee4d

Thanks to R-K-H for their significant contribution to this integration! 🙏

QuipuSwap, is a decentralized exchange (DEX) on the Tezos blockchain. It features on-chain governance for baking rewards, emphasizing user participation in decision-making processes. QuipuSwap offers a platform for seamless token swaps and liquidity provision, catering to users engaged in the Tezos ecosystem. For more information, see the QuipuSwap connector docs.

Snapshot Proposal: https://snapshot.org/#/hbot-ncp.eth/proposal/0x769ddfb5fd3f283e15192806c53efbf02b9e182ba8a64f5311305786265ef29a

Thanks to OjusWiZard for their significant contribution to this integration! 🙏

Examples:

Example 1 (unknown):

docker pull hummingbot/hummingbot:latest

Example 2 (unknown):

git pull origin master

Strategies & Snippets - Hummingbot

URL: https://hummingbot.org/gateway/strategies

Contents:

Strategies & Snippets
Available Scripts and Strategies¶
Code Snippets¶
- Data Feed¶
- Connect Market¶
- Get Price¶
- Get Balance¶
- Place Order¶
- Get LP Position Info¶
- Add Liquidity¶

Gateway enables sophisticated trading strategies on decentralized exchanges through Hummingbot. This page lists available Gateway-compatible strategies/scripts along with commonly used code snippets.

The following table lists Gateway-compatible scripts and strategies available in the Hummingbot repository. All links point to the development branch where the latest versions are maintained.

The following code snippets demonstrate common Gateway operations in Hummingbot scripts and strategies.

Examples:

Example 1 (unknown):

amm_data_feed = AmmGatewayDataFeed(
            connector="jupiter/router",
            trading_pairs={"SOL-USDC","JUP-USDC"}
            order_amount_in_base=Decimal("1.0")
        )

Example 2 (python):

@classmethod
def init_markets(cls):
        cls.markets = {"jupiter/router": {"SOL-USDC"}}

def __init__(self, connectors: Dict[str, ConnectorBase]):
        super().__init__(connectors)

Example 3 (unknown):

current_price = await self.connectors["jupiter/router"].get_quote_price(
                    trading_pair="SOL-USDC",
                    is_buy=True,
                    amount=Decimal("1.0"),
                )

Example 4 (unknown):

connector = self.connectors["jupiter/router"]
await connector.update_balances(on_interval=False)
balance = connector.get_balance("SOL")

Candles - Hummingbot

URL: https://hummingbot.org/v2-strategies/candles

Contents:

Candles
Supported Exchanges¶
Key Configuration Parameters¶
Downloading Candles¶
Adding Technical Indicators¶
Multiple Candles¶
Displaying Candles in status¶
Logging Candles Periodically¶
- Additional Key Methods and Properties¶

Candles allow user to compose a trailing window of real-time market data in OHLCV (Open, High, Low, Close, Volume) form from certain supported exchanges.

It combines historical and real-time data to generate and maintain this window, allowing users to create custom technical indicators, leveraging pandas_ta.

See Candles Feed for a list of the currently supported exchanges.

A common practice is to execute bots on decentralized exchanges or smaller exchanges using candles data from other exchanges.

Candles provide a concise way to access historical exchange data. See the download_candles script.

Incorporate technical indicators to candle data for enhanced strategy insights:

For strategies requiring multiple candle intervals or trading pairs, initialize separate instances:

Modify the format_status method to display candlestick data:

To log candle data in the on_tick method:

Examples:

Example 1 (python):

def format_status(self) -> str:
    # Ensure market connectors are ready
    if not self.ready_to_trade:
        return "Market connectors are not ready."
    lines = []
    if self.all_candles_ready:
        # Loop through each candle set
        for candles in [self.eth_1w_candles, self.eth_1m_candles, self.eth_1h_candles]:
            candles_df = candles.candles_df
            # Add RSI, BBANDS, and EMA indicators
            candles_df.ta.rsi(length=14, append=True)
            candles_df.ta.bbands(length=20, std=2, append=True)
            candles_df.ta.ema(length=14, offset=None, append=True)
            # Format and display candle data
            lines.extend([f"Candles: {candles.name} | Interval: {candles.interval}"])
            lines.extend(["    " + line for line in candles_df.tail().to_string(index=False).split("\n")])
    else:
        lines.append("  No data collected.")

    return "\n".join(lines)

Example 2 (python):

from hummingbot.data_feed.candles_feed.candles_factory import CandlesFactory, CandlesConfig

class InitializingCandlesExample(ScriptStrategyBase):
    # Configure two different sets of candles
    candles_config_1 = CandlesConfig(connector="binance", trading_pair="BTC-USDT", interval="3m")
    candles_config_2 = CandlesConfig(connector="binance_perpetual", trading_pair="ETH-USDT", interval="1m")

    # Initialize candles using the configurations
    candles_1 = CandlesFactory.get_candle(candles_config_1)
    candles_2 = CandlesFactory.get_candle(candles_config_2)

Example 3 (python):

def format_status(self) -> str:
    # Check if trading is ready
    if not self.ready_to_trade:
        return "Market connectors are not ready."

    lines = ["\n############################################ Market Data ############################################\n"]
    # Check if the candle data is ready
    if self.eth_1h_candles.is_ready:
        # Format and display the last few candle records
        candles_df = self.eth_1h_candles.candles_df
        candles_df["timestamp"] = pd.to_datetime(candles_df["timestamp"], unit="ms").dt.strftime('%Y-%m-%d %H:%M:%S')
        display_columns = ["timestamp", "open", "high", "low", "close"]
        formatted_df = candles_df[display_columns].tail()
        lines.append("One-hour Candles for ETH-USDT:")
        lines.append(formatted_df.to_string(index=False))
    else:
        lines.append("  One-hour candle data is not ready.")

    return "\n".join(lines)

Example 4 (python):

def on_tick(self):
    self.logger().info(self.candles.candles_df)

Quants Lab - Hummingbot

URL: https://hummingbot.org/quants-lab/

Contents:

Quants Lab¶
What is Quants Lab?¶
Installation¶
Usage¶
Next Steps¶
Tutorials¶
- Hummingbot Live: Quants Lab¶

Quants Lab contains interactive notebooks and task schedulers for quantitative trading research and development. It provides comprehensive tools for data collection, backtesting, strategy development, and automated task management.

GitHub Repository: github.com/hummingbot/quants-lab

Quants Lab acts as a research and development platform for quantitative traders, enabling systematic strategy creation and testing. It bridges the gap between raw market data and executable trading strategies, providing a complete toolkit for quants and algorithmic traders.

Quants Lab enables quantitative traders to:

Under the hood, Quants Lab uses the Hummingbot Python library and is designed to be compatible with other Hummingbot repos.

Clone the Quants-Lab Github repo to download it to your machine, and then enter the folder: git clone https://github.com/hummingbot/quants-lab.git cd quants-lab

Then, run the one-command installation script install.sh:

This script create a quants-lab Anaconda/Miniconda environment with all dependencies. Then, it sets up a MongoDB database for storage and creates a new .env file that contains starting environment variables.

For more information about other installation options, see the Quants Lab Github repository.

To get started, activate the quants-lab environment, explore available notebooks, and then customize them for your needs.

You can also create and schedule automated runs of tasks, as well as individual notebooks:

After successful installation:

The videos below demonstrate features from an pre-release version of Quants Lab. Some interfaces and functionalities may have changed in the official release.

Examples:

Example 1 (unknown):

git clone https://github.com/hummingbot/quants-lab.git
cd quants-lab

Example 2 (unknown):

./install.sh

[INFO] 🚀 Welcome to QuantsLab Installation!

[INFO] This script will:
[INFO]   1. Check prerequisites (conda, docker, docker compose)
[INFO]   2. Create conda environment from environment.yml
[INFO]   3. Install QuantsLab package in development mode
[INFO]   4. Setup databases (optional)
[INFO]   5. Create .env file with defaults
[INFO]   6. Test the installation

Example 3 (unknown):

# Activate environment
conda activate quants-lab

# Launch Jupyter notebooks
jupyter lab

# Navigate to research_notebooks/ folders

Example 4 (unknown):

# List available tasks
python cli.py list-tasks

# Run single task
python cli.py trigger-task --task pools_screener --config config/pools_screener_v2.yml

Arbitrage Executor - Hummingbot

URL: https://hummingbot.org/v2-strategies/executors/arbitrage-executor/

Contents:

Arbitrage Executor
- Workflow¶
- Sample Script¶

ArbitrageExecutor: Specialized in controlling profitability between two markets, such as between centralized exchanges (CEX) and decentralized exchanges (DEX), optimizing for arbitrage opportunities.

The ArbitrageExecutor class is a specialized component within Hummingbot designed for capitalizing on price discrepancies between different markets or exchanges by automating the process of simultaneously executes buy and sell orders on two distinct markets, aiming to exploit arbitrage opportunities for profit.

Upon initialization, the ArbitrageExecutor performs the following actions:

Below, we show code snippets from the Arbitrage with Smart Component script, which provides an example of how to use the ArbitrageExecutor.

You can define the two markets to arbitrage, the order amount, and the arbitrage profitability threshold.

The create_arbitrage_executor method is responsible for creating a new ArbitrageExecutor. First, it checks available balances on the buying and selling exchanges to ensure there's enough capital to execute the arbitrage. If so, it creates ArbitrageExecutor instances based on the settings above.

Examples:

Example 1 (unknown):

class ArbitrageWithSmartComponent(ScriptStrategyBase):
    # Parameters
    exchange_pair_1 = ExchangePair(exchange="binance", trading_pair="MATIC-USDT")
    exchange_pair_2 = ExchangePair(exchange="uniswap_polygon_mainnet", trading_pair="WMATIC-USDT")
    order_amount = Decimal("50")  # in base asset
    min_profitability = Decimal("0.004")

Example 2 (python):

def create_arbitrage_executor(self, buying_exchange_pair: ExchangePair, selling_exchange_pair: ExchangePair):
    ...
    arbitrage_config = ArbitrageConfig(
        buying_market=buying_exchange_pair,
        selling_market=selling_exchange_pair,
        order_amount=self.order_amount,
        min_profitability=self.min_profitability,
    )

Architecture - Hummingbot

URL: https://hummingbot.org/v2-strategies/

Contents:

Architecture
Components¶
Inheritance¶
Strategy Guides¶

The most important components to understand are:

One important information before we delve into the details of each strategy type and when to use which is to understand that they are all built on top of each other.

If we have a quick look together at the inheritance hierarchy this becomes obvious:

Please make sure to keep the inheritance structure in mind as this helps you a lot in learning how to code your own custom strategies.

Check out Walkthrough - Script and Walkthrough - Controller to learn how to create strategies.

Hanging Orders - Hummingbot

URL: https://hummingbot.org/strategy-configs/hanging-orders/

Contents:

Hanging Orders¶
Configuration variables¶
- hanging_orders_enabled¶
- hanging_orders_cancel_pct¶
How it works¶
Illustrative examples - when hanging orders are important¶
- Example 1 (basic)¶
- Example 2 (advanced)¶
- Market Without Hanging Orders¶
- Market With Hanging Orders¶

This feature keeps orders "hanging" (or not cancelled and remaining on the order book) if a matching order has been filled on the other side of the order book (bid vs. ask order books).

When enabled, the orders on the side opposite to the filled orders remains active.

Cancels the hanging orders when their spread goes above this value. Note that no other parameter can cancel hanging orders other than hanging_orders_cancel_pct.

Hanging orders is a function that instructs Hummingbot to treat buys and sells of the same order as a pair. If one side gets filled, the bot keeps the other side of the pairing, creating the possibility of that side to eventually get filled:

In the example above, the buy order for the first pair was filled. But since hanging orders mode was enabled, the original sell order from the first pair is not cancelled during the refresh cycle (period 2) and remains outstanding. Meanwhile, the bot continues to create new orders (see periods 2 through 5). In the example, prices changed direction and eventually at some point, the hanging sell order was filled around period 5.

The benefit of this strategy is that it creates the possibility of the pairings to be “completed” and balanced.

Typically, orders are placed as pairs in single order mode (1 buy and 1 sell order), and when a buy or sell order is filled, the other order is cancelled. The parameter hanging_orders_enabled allows Hummingbot to leave the order on the other side hanging (not cancelled) whenever one side is filled.

The hanging order will be cancelled in the following conditions:

Type config hanging_orders_enabled and config hanging_orders_cancel_pct to set values for these parameters.

Suppose you are market making for the ETH-USDT pair with a mid-market price of 200 USD ((t_0)). You set your bid spread and ask spread to 1%. Thus, the bid price is 198 USD and the ask price is 202 USD.

Now suppose that a market taker (someone taking a position in the market) thinks the price of Ethereum will rise, so they fill your ask order 202 ((t_1)).

At the next order refresh cycle, normally Hummingbot would cancel the 198 USD bid order and create 2 new bid and ask orders. However, if hanging_orders_enabled is set to True, the bid order is not cancelled and stays on the order book until it is filled. Note that if an open hanging order spread exceeds the hanging_orders_cancel_pct parameter, the hanging order will be canceled.

Suppose that you are again market making for ETH-USDT pair. The bid and ask spread is set to 1%. Consider the two strategies below, the former the default and the latter with hanging orders. The white line in the center is the mid market price in USDT; The dashed lines above the mid-market price are the active ask-orders; And the dotted lines below the mid-market price are the active bid-orders.

In this strategy, the hanging_orders_enabled parameter is False. At each interval (t_i), the order is either cancelled or filled, then refreshed with a new set of bid and ask orders (each with a 1% spread from the mid-market price). There are only two orders at a time, an ask order and a bid order. This is a great strategy as a default, however, price takers need to be willing to fill orders relatively close to your chosen spread. It may require you to tighten your spread to get more price takers to fill your orders.

In this strategy, the hanging_orders_enabled parameter is True. We set the hanging_orders_cancel_pct parameter to 2% and make the assumption that an order is filled by a market-taker if the spread is within 0.55%. When a bid order is filled or canceled, unlike the default, the ask order is left open. Similarly, when a ask order is filled or cancelled, the bid order is left open. As you can see above, from (t0) to (t{10}) generally the bid orders are "hanging" until their spreads are greater than 2% from the mid-market price line (or are filled). From (t0) to (t{10}), the ask orders are being filled as they fall within 0.55% of spread to the mid-market price line. The opposite is true from (t{10}) to (t{20}), where bid orders are being filled as they fall within 0.55% of the spread to the mid-market price line and the ask orders are "hanging" until they are cancelled when their spreads are greater than 2%.

This strategy allows for a range of spreads between the cancel percentage parameter and when a price taker fills your order (presumably when the order price is closer to the mid-market price). It is ultimately a more flexible strategy and can capture profitable trades that are lost without hanging orders. For example, in the Sample Markets above, the purple bid order starting at (t8) is lost without allowing it to be a hanging order, whereas in the second chart, the bid order is filled at (t{13}).

Let's see how this configuration works in the scenario below:

When the buy order was completely filled, it will not cancel the sell order. After 60 seconds, Hummingbot will create a new set of buy and sell orders. The status output will show all active orders while indicating which orders are hanging.

The hanging order will stay outstanding and will be cancelled if its spread goes above 2% as specified in our hanging_orders_cancel_pct.

When an order is filled on one side either buy or sell, all active orders on the opposite side are left hanging.

With the sample configuration above, the bot places 3 buy and 3 sell orders.

Buy order 1 gets filled.

This leaves the 3 sell orders hanging on top of the new orders on the next refresh.

This section provides a developer-oriented overview of the HangingOrdersTracker helper class designed to assist strategies with managing hanging orders. It automates a large part of the process, including renewing outdated orders and cancelling orders that have drifted too far from the market price.

Two examples of its usage can be found in the PureMarketMakingStrategy and the AvellanedaMarketMakingStrategy strategies.

An important fundamental concept to be aware of is that the tracker operates by maintaining a list of candidate hanging orders. This article will refer to that list as "the candidate list". Calling the update_strategy_orders_with_equivalent_orders method will perform a check that the candidate list is synchronized with the orders on the exchange and will effectively start tracking the hanging orders.

The most basic set of methods are the add_order and remove_order which respectively add and remove orders from the candidate list of hanging orders. However, the add_order function is most likely to be used in the initialization of the strategy, when hanging orders are retrieved from the database and registered with the tracker, while the remove_order function may not have to be used at all as the responsibility of removing tracked hanging orders is transferred to the tracker and automated away.

During the initialization phase, the HangingOrdersTracker must be registered with the connectors used by the strategy in order to receive updates about the orders and perform its responsibilities. This is achieved by simply calling the register_events method and passing a list of the relevant connectors. When the strategy is being stopped, the tracker's unregister_events must be called to gracefully deregister the tracker from the connectors.

When creating new orders, use the method aptly named add_current_pairs_of_proposal_orders_executed_by_strategy to register the order pairs by passing them in as CreatedPairOfOrders. The tracker then starts listening for filled orders and updates the pairs accordingly.

Once the current cycle is over and the strategy is about to cancel the current orders and replace them with a new set, calling update_strategy_orders_with_equivalent_orders will detect hanging orders from the currently active CreatedPairOrders and add them to the candidate orders list. Subsequently, as mentioned in the Fundamental Concepts section, calling theupdate_strategy_orders_with_equivalent_orders method will ensure the integrity of the candidate orders list and start tracking the hanging orders.

After this step is performed, the strategy can proceed to cancelling the orders it wants to cancel as part of the current cycle termination process. It simply needs to ask the tracker if a given order is a hanging order by calling the is_order_id_in_hanging_orders method. If it is, the strategy doesn't need to worry about that order anymore. If it's not, then the strategy can proceed to cancelling it.

Finally, for the tracker to perform its tasks, the process_tick method must be called on every strategy tick. When the method is called, the HangingOrdersTracker performs two tasks: first, it removes hanging orders with extreme spreads; second, it renews orders that have passed the max order age. To enable renewing old orders, the strategy must implement the max_order_age attribute.

Examples:

Example 1 (unknown):

Do you want to enable hanging orders? (Yes/No)
>>> Yes

Example 2 (unknown):

At what spread percentage (from mid price) will hanging orders be canceled?
>>>

Example 3 (unknown):

- filled_order_delay: 60.0
- hanging_orders_enabled: True
- hanging_orders_cancel_pct: 2

Example 4 (unknown):

- hanging_orders_enabled: True
- order_levels: 3

Market Data Provider - Hummingbot

URL: https://hummingbot.org/v2-strategies/data/

Contents:

Market Data Provider
Price¶
Volume¶
Order Book¶
Candles¶

The Market Data Provider service simplifies access to real-time market data with the following methods.

Any scripts can instantiate the Market Data Provider:

Below are a some methods that it contains. Each method receives the connector name, trading pair, and other arguments that can be defined as config parameters.

Candles are trailing intervals of OHCLV data that can be used to generate custom indicators.

Examples:

Example 1 (python):

from hummingbot.data_feed.market_data_provider import MarketDataProvider

Example 2 (python):

def get_price_by_type(self, connector_name: str, trading_pair: str, price_type: PriceType):
        """
        Retrieves the price for a trading pair from the specified connector.
        :param connector_name: str
        :param trading_pair: str
        :param price_type: str
        :return: Price instance.
        """
        connector = self.get_connector(connector_name)
        return connector.get_price_by_type(trading_pair, price_type)

Example 3 (unknown):

price = self.market_data_provider.get_price_by_type('binance', 'BTC-USDT', PriceType.MidPrice)

Example 4 (python):

def get_price_for_volume(self, connector_name: str, trading_pair: str, volume: float,
                             is_buy: bool) -> OrderBookQueryResult:
        """
        Gets the price for a specified volume on the order book.

        :param connector_name: The name of the connector.
        :param trading_pair: The trading pair for which to retrieve the data.
        :param volume: The volume for which to find the price.
        :param is_buy: True if buying, False if selling.
        :return: OrderBookQueryResult containing the result of the query.
        """

        order_book = self.get_order_book(connector_name, trading_pair)
        return order_book.get_price_for_volume(is_buy, volume)

Scripts Cheatsheat - Hummingbot

URL: https://hummingbot.org/scripts/cheatsheet/

Contents:

Scripts Cheatsheat
Getting started¶
Scripts basics¶
- Configuration¶
- Markets¶
- Execution¶
Market Operations¶
- Create and cancel Orders¶
Account Data¶
- Balance¶

See below for reference docs that help you create Scripts that inherit from the ScriptStrategy base class.

This Script Strategies Cheatsheet is also available in PDF form.

Watch the full video that accompanies this page:

Scripts are a subclass of ScriptStrategy.

You can define the variables that you will use as class variables. By default, there is no configuration file for scripts.

Define the connectors and trading pairs, in the class variable markets, with the following structure:

self.get_balance_df()

self.active_orders_df()

You can create custom handlers for various market events by implementing one or more of the following methods in your script:

To send notifications to the Hummingbot client, use the following methods:

If you have the Telegram integration activated, you will receive the notifications there too.

A connection is stored in the instance variable connectors with the following structure: Dict["connector_name", ConnectorBase]

For example, self.connectors["binance"] will return the Binance exchange class.

For example, self.connectors["binance"].get_mid_price("ETH-USDT") will return the mid price for the ETH-USDT trading pair on Binance.

Use these methods to compute metrics efficiently:

Returns a ClientOrderBookQueryResult class with:

This checks if the balance is enough to place the order, all_or_none=True will set the amount to 0 on insufficient balance and all_or_none=False will adjust the order size to the available balance.

Examples:

Example 1 (unknown):

Dict["connector_name", Set(Trading pairs)]

Example 2 (unknown):

self.buy(connector_name, trading_pair, amount, order_type, price, [position_action])
self.sell(connector_name, trading_pair, amount, order_type, price,[position_action])
self.cancel(connector_name, trading_pair, order_id)```
# position_action is only used in perpetual connectors

Example 3 (unknown):

did_create_buy_order(self, event: BuyOrderCreatedEvent)
did_create_sell_order(self, event: SellOrderCreatedEvent)
did_fill_order(self, event: OrderFilledEvent)
did_fail_order(self, event: MarketOrderFailureEvent)
did_cancel_order(self, event: OrderCancelledEvent)
did_expire_order(self, event: OrderExpiredEvent)
did_complete_buy_order(self, event: BuyOrderCompletedEvent)
did_complete_sell_order(self, event: SellOrderCompletedEvent)

Example 4 (unknown):

self.notify_hb_app(msg)
self.notify_hb_app_with_timestamp(msg)

Command Line Autostart - Hummingbot

URL: https://hummingbot.org/global-configs/strategy-autostart

Contents:

Strategy Autostart¶
Docker autostart¶
- Prerequisites¶
- How to autostart¶
Source autostart¶
- Prerequisites¶
- How to autostart¶

Stop any running containers

Use an IDE like VSCode to edit the docker-compose.yml file.

Edit or add the section that defines the environment variables:

The environment: line

The CONFIG_PASSWORD line: add the Hummingbot password to login

One of CONFIG_FILE_NAME lines: add your script OR strategy config file

Add your SCRIPT_CONFIG file if using a configurable script

The final environment section of the YAML file should look something like this:

Afterwards, save the file.

You can auto-start either a Script or a Strategy:

When you attach to it, the strategy or script should already be running:

Running unattended Hummingbot is very similar to running Hummingbot manually. The only differences are:

Where CONFIG_PASSWORD is the config password SCRIPT_FILE_NAME is the script / strategy file name CONFIG_FILE_NAME is the script / strategy config file name

a is the config password

simple_pmm_example_config.py is the script / strategy file name

conf_simple_pmm_example_config_1.yml is the script / strategy config file name

More information on strategy can be found in Strategy.

More information on configuration file name can be found in Configuring Hummingbot.

More information on password can be found in Create a secure password.

Examples:

Example 1 (unknown):

docker compose down

Example 2 (unknown):

environment:
      - CONFIG_PASSWORD=password
      - CONFIG_FILE_NAME=simple_pmm_example.py
      - SCRIPT_CONFIG=conf_simple_pmm_example_config_1.yml

Example 3 (unknown):

docker compose up -d

Example 4 (unknown):

docker attach hummingbot

Position Executor - Hummingbot

URL: https://hummingbot.org/v2-strategies/executors/positionexecutor

Contents:

Position Executor
- Spot vs Perpetual Behavior¶
- Configuration¶
- Stop Loss¶
- Take Profit¶
- Time Limit¶
- Trailing Stop¶
- Execution Flow¶
- Conclusion¶

PositionExecutor: Manages opening and closing positions of equal amounts, ensuring the portfolio remains balanced ± the position's profit or loss. It's applicable in both perpetual and spot markets, requiring pre-ownership of the asset for spot markets.

The PositionExecutor uses a configuration object, PositionExecutorConfig, to manage an order after it is placed, following the Triple Barrier Method. This configuration sets pre-defined stop loss, take profit, time limit, and trailing stop parameters.

The PositionExecutor class implements the Triple Barrier Method popularized in Martin Prado's famous book Advances in Financial Machine Learning.

The triple barrier method is a structured approach to position management, where three "barriers" determine the outcome of a trade:

Additionally, PositionExecutor also contains a Trailing Stop mechanism, which dynamically adjusts the stop loss level as favorable price movements occur.

The PositionExecutor class is designed to work on both spot and perpetual exchanges, allowing you to write strategies that be used on either type:

The PositionExecutor engages with the market by executing orders based on the PositionConfig. It applies the triple barrier method as follows:

Activated when the price moves against the position beyond a specified threshold.

Triggered when the price reaches a pre-set level that represents a desired profit.

When the time limit is reached, the position will be closed or an opposing trade will be executed.

The trailing stop evaluates the position after a certain time has passed and may close it to avoid market shifts or decay.

Here's a simplified flow of how the PositionExecutor operates in conjunction with the triple barrier method:

The PositionExecutor is a powerful tool within Hummingbot for implementing strategies that require precise entry and exit conditions. By leveraging the triple barrier method, it provides a structured and disciplined approach to trade management, vital for both market making and directional trading strategies.

Examples:

Example 1 (unknown):

class TripleBarrierConf(BaseModel):
    # Configure the parameters for the position
    stop_loss: Optional[Decimal]
    take_profit: Optional[Decimal]
    time_limit: Optional[int]
    trailing_stop_activation_price_delta: Optional[Decimal]
    trailing_stop_trailing_delta: Optional[Decimal]
    # Configure the parameters for the order
    open_order_type: OrderType = OrderType.LIMIT
    take_profit_order_type: OrderType = OrderType.MARKET
    stop_loss_order_type: OrderType = OrderType.MARKET
    time_limit_order_type: OrderType = OrderType.MARKET

Example 2 (unknown):

triple_barrier_confs = TripleBarrierConf(
    stop_loss=stop_loss,
    take_profit=take_profit,
    time_limit=time_limit,
    trailing_stop_activation_price_delta=trailing_stop_activation_price_delta,
    trailing_stop_trailing_delta=trailing_stop_trailing_delta,
)

Check Bot/Market Status - Hummingbot

URL: https://hummingbot.org/client/status/

Contents:

Check Bot and Market Status¶
Check bot status¶
Get live bot status¶
View market order book¶
View market ticker prices¶
status¶

Run status command or CTRL+S to show the bot's current status. The output may differ depending on the running strategy, but generally, it shows the following information:

The status --live command displays the real-time status of the bot.

Currently, this feature works on all strategies except liquidity mining strategy.

By default, the order_book command displays the top 5 bid/ask prices and volume of the current market, similar to how they're displayed in the exchange's order book.

Run order_book --live --lines 20 to show the top 20 bid/ask and volume in real-time.

The ticker command displays the market prices, specifically the best bid, best ask, mid price, and last trade price.

Get the market status of the current bot.

Examples:

Example 1 (unknown):

>>>  status

  Markets:
    Exchange  Market  Best Bid Price  Best Ask Price  Mid Price
     binance  ETHBTC        0.025521        0.025527   0.025524

  Assets:
                            ETH    BTC
     Total Balance       4.3725 0.1274
     Available Balance   3.3725 0.1021
     Current Value (BTC) 0.1116 0.1274
     Current %            46.7%  53.3%

  Orders:
     Level  Type      Price Spread  Amount (Orig)  Amount (Adj)       Age Hang
         1  sell  0.0257747  0.98%              1             1  00:00:02   no
         1   buy 0.02526431  1.02%              1             1  00:00:02   no



**Optional arguments**

| Command Argument            | Description                                                  |
| --------------------------- | ------------------------------------------------------------ |
| `-live`                     | Displays status in real time.                                |

AMM Arbitrage - Hummingbot

URL: https://hummingbot.org/strategies/amm-arbitrage/

Contents:

amm_arb¶
📁 Strategy Info¶
📝 Summary¶
🏦 Supported Exchange Types¶
🛠️ Strategy configs¶
📓 Description¶
ℹ️ More Resources¶

This strategy monitors prices between a trading pair (market_1) on a SPOT AMM DEX versus another trading pair (market_2) on another SPOT AMM CEX or SPOT CLOB DEX in order to identify arbitrage opportunities. It executes offsetting buy and sell orders in both markets in order to capture arbitrage opportunities with profitability higher than min_profitability, net of transaction costs, which include both blockchain transaction fees (gas) and exchange fees.

See Trading logic to understand how the strategy works.

How to arbitrage AMMs like Uniswap and Balancer: Learn how you can Arbitrage AMMs with our strategy

Quickstart Guide for amm_arb (deprecated): This guide will walk you through the installation and launch of the new amm_arb strategy

Spot Perpetual Arbitrage - Hummingbot

URL: https://hummingbot.org/strategies/spot-perpetual-arbitrage/

Contents:

spot_perpetual_arbitrage¶
📁 Strategy Info¶
📝 Summary¶
🏦 Exchanges supported¶
🛠️ Strategy configs¶
📓 Description¶
ℹ️ More Resources¶

This strategy looks at the price on the spot connector and the price on the derivative connector. Then it calculates the spread between the two connectors. The key features for this strategy are min_divergence and min_convergence.

When the spread between spot and derivative markets reaches a value above min_divergence, the first part of the operation will be executed, creating a buy/sell order on the spot connector, while opening an opposing long/short position on the derivative connector.

With the position open, the bot will scan the prices on both connectors, and once the price spread between them reaches a value below min_convergence, the bot will close both positions.

How to Use the New Spot-perpetual Arbitrage Strategy: Learn how the spot-perpetual arbitrage strategy works and how you can make use of it.

Spot-Perpetual Arbitrage Strategy Demo | Hummingbot Live: A live demo on how you can set parameters to run the spot-perpetual arbitrage strategy

Check out Hummingbot Academy for more resources related to this strategy and others!

Cross-Exchange Mining - Hummingbot

URL: https://hummingbot.org/strategies/cross-exchange-mining/

Contents:

cross-exchange-mining¶
📁 Strategy Info¶
📝 Summary¶
🏦 Exchanges supported¶
🛠️ Strategy configs¶
📓 Description¶

The Cross Exchange Mining strategy creates buy or sell limit orders on a maker exchange at a spread wider than that of the taker exchange. Filling of the order on the maker exchange triggers a balancing of the portfolio on the taker exchange at an advantageous spread (The difference between the two spreads being equal to the min_profitability) thereby creating profit.

The strategy tracks the amount of base asset across the taker and maker exchanges for order_amount and continually seeks to rebalance and maintain assets, thereby reducing any exposure risk whereby the user has too much quote or base asset in falling or rising markets.

The strategy operates by maintaining the 'order amount' base balance across the taker and maker exchanges. The strategy sets buy or sell limit orders on the maker exchanges, these orders are set when sufficient quote or base balance exists on the taker exchange in order to be able to complete or balance the trade on the taker exchange when a limit order on the maker exchange is filled.

The strategy can balance trades immediately when an imbalance in base asset is detected and although the taker trade will be acted upon immediately after an imbalance is detected subsequent balances will be spaced by at least the balance_adjustment_duration variable, just to ensure the balances are updated and recorded before the balance is retried erroneously. In this way the strategy will exactly maintain the 'order amount' in terms of base currency across the exchanges selling base currency when a surplus exists or buying base currency if short.

The strategy seeks to make profit in a similar way that cross exchange market making operates. by placing a wide spread on the maker exchange that when filled will allow the user to buy back base currency at a lower price on the taker exchange (In case of a sell order fill on the maker exchange) or sell base currency at a higher price on the taker exchange in case of buy order filled on the maker exchange. The difference in price between these two transactions should be the min_profitability variable. Setting this variable to a higher value will result in less trade fills due to a larger spread on the maker exchange but also a greater profitability per transaction and vise versa.

When an order is set with a spread that meets the min_profitability variable at that time it is then monitored each tick. The theoretical profitability of the trade will vary over time as orders on the taker orderbook changes meaning the cost of balancing the filled trade will constantly change. The order is cancelled and reset back at the min_profitability amount when the profitability either drops below the `min_profitability minus min_prof_tol_low point or rises above the min_profitability plus min_prof_tol_high point.

In addition to this basic logic a leading and lagging adjustment to the min profitability figure is made during the strategy run.

Short term, Leading adjustment:

The strategy looks at the current volatility in the maker market to adjust the min profitability figure described above. The function looks at the standard deviation of the currency pair prices across a time window equal to volatility_buffer_size. The standard deviation figure is then converted by taking the three sigma percentage away from the mid price over that range and adding it to the min profitability. In this way a higher volatility or standard deviation figure would increase the min profitbaility creating a larger spread and reducing risk during periods of volatility. The adjustment is set for a time period equal to the volatility_buffer_size unless a higher volatility adjustment is calculated in which case its set at the higher adjustment rate and timer reset.

Long term, Lagging adjustment:

The strategy looks at the previous trades completed and balancing trades in order to understand the success of the strategy at producing profit. The strategy will again adjust the 'min_profitability' figure by widening the spread if the user is losing money and tightening the spread if the trades are too profitable. This is due to the strategy aiming to essentially provide a break even portfolio to maximise mining rewards, hence the name cross_exchange_mining.

The previous trades in the users hummingbot/data file are read by the strategy at intervals equal to the min_prof_adj_timer when this function is called it looks at trades recorded within the last 24 hours in the file and based on timestamp seeks to match the filled maker and taker orders that make up a full balanced trade.

The strategy uses the trade_fee variable in this calculation to take into account the amount of money paid to the both exchanges during these trades, the calculation returns the average profitability of the trades and balance pairs completed in the previous 24 hours. This figure is then converted into an adjustment. a 0% profitability (Based on order amount) would lead to 0 adjustment.

Positive or negative percentages made are converted into an adjutsment using the relationship (Percentage * rate_curve)**3 + min_profitability. The cubed figure exponentially penalises large profit or loss percentages gained thereby greatly reducing the min_profitability (In case of large gains) or greatly increasing the min_profitability figure (In case of large losses). The rate_curve variable acts to provide a multiplier for this adjustment it is reccomended to keep this in the 0.5-1.5 range with the higher it is set the more the min_profitability adjustment is affected by previous trades.

From a personal perspective I have used the XEMM strategy for a number of years and my motivation for this strategy comes not from improving how effective the strategy is at making money but it is to increase the reliability of the strategy in maintaining a hedged position of base assets even during wild market swings. The code is entirely rewritten from the XEMM strategy aimed at making a more logical progression and removing elements that I find add complexity, reducing reliability without benefitting the user.

The strategy is intended for use with the same pairs on both taker and maker centralised exchanges. The strategy utilises market trades to fill on taker side.

TWAP Executor - Hummingbot

URL: https://hummingbot.org/v2-strategies/executors/twapexecutor/

Contents:

TWAP Executor
- Key Components:¶
- Key Functions:¶
- Example Script¶
- Conclusion:¶

The TWAPExecutor is an implementation of a Time-Weighted Average Price (TWAP) execution strategy within the Hummingbot trading framework. This strategy is used to execute trades over a specified time horizon to minimize the market impact by breaking up a large order into smaller orders and executing them at regular intervals. Below is an overview of the key components and functionalities of the TWAPExecutor class:

Class Inheritance and Initialization: The TWAPExecutor class inherits from ExecutorBase, indicating it's a specialized form of executor with additional logic for TWAP strategy execution. It initializes with a strategy, configuration, update interval, and maximum retries.

Logging: Utilizes Hummingbot's logging mechanism for logging information, warnings, and errors.

Configuration and Validation: Takes a TWAPExecutorConfig object as configuration, which defines the parameters for the TWAP strategy such as the connector to use, trading pair, number of orders, order interval, and order amount. It also validates if the order amount meets the minimum requirement of the trading pair.

Order Plan Creation: Generates a plan for when orders should be placed (create_order_plan) based on the configuration, mapping timestamps to None initially, which later gets replaced with actual TrackedOrder objects.

Order Execution and Management:

Validates sufficient balance before placing orders.

Control Task: An asynchronous control task (control_task) that evaluates conditions for creating, refreshing, and completing orders, as well as retrying failed orders.

Performance Metrics: Calculates performance metrics such as filled amount, trade PnL (profit and loss), average executed price, cumulative fees, and net PnL.

create_order_plan: Generates a schedule for when orders should be executed.

validate_sufficient_balance: Ensures there is enough balance to execute the planned orders.

control_task: Asynchronously evaluates various conditions to manage order execution lifecycle.

create_order: Creates a new order based on the current state of the order plan and execution parameters.

process_order_created_event, process_order_failed_event, process_order_completed_event: Event handlers for order lifecycle events.

Performance Metrics Methods: Includes methods to calculate and retrieve performance metrics related to the execution of the TWAP strategy.

The v2_twap_multiple_pairs.py example script defining the TWAPMultiplePairs strategy class shows how to use the TWAPExecutor within a broader Hummingbot strategy context, specifically for executing TWAP (Time-Weighted Average Price) trades across multiple trading pairs simultaneously. This script illustrates the setup and orchestration required to utilize the TWAPExecutor functionality within a strategy that can be deployed in Hummingbot.

Inherits from StrategyV2ConfigBase, indicating it's a complex strategy capable of handling multiple trading pairs and executors.

Initializes with a dictionary of connectors and the strategy-specific configuration (TWAPMultiplePairsConfig).

Defines configuration parameters for executing TWAP orders, including details for multiple trading pairs, position mode, and TWAP executor configurations (twap_configs).

Utilizes a validator to parse and validate the TWAP configurations from a string format into TWAPExecutorConfig objects, ensuring each configuration adheres to expected parameters such as connector name, trading pair, trade side, leverage, total amount in quote currency, total duration, order interval, and execution mode (e.g., MAKER or TAKER).

The TWAPExecutor class is designed to execute orders following a TWAP strategy, aiming to reduce market impact by distributing the execution of a large order across multiple smaller orders over time. It involves complex logic for scheduling orders, managing their lifecycle, and calculating execution performance, making it a sophisticated component within the Hummingbot trading bot framework for algorithmic trading strategies.

Examples:

Example 1 (unknown):

class TWAPMultiplePairsConfig(StrategyV2ConfigBase):
    script_file_name: str = Field(default_factory=lambda: os.path.basename(__file__))
    candles_config: List[CandlesConfig] = []
    controllers_config: List[str] = []
    markets: Dict[str, Set[str]] = {}
    position_mode: PositionMode = Field(
        default="HEDGE",
        client_data=ClientFieldData(
            prompt=lambda mi: "Enter the position mode (HEDGE/ONEWAY): ",
            prompt_on_new=True
        ))
    twap_configs: List[TWAPExecutorConfig] = Field(
        default="binance,WLD-USDT,BUY,1,100,60,15,TAKER",
        client_data=ClientFieldData(
            prompt=lambda mi: "Enter the TWAP configurations (e.g. connector,trading_pair,side,leverage,total_amount_quote,total_duration,order_interval,mode:same_for_other_config): ",
            prompt_on_new=True))

URL: https://hummingbot.org/v2-strategies/diagrams/20.png

Max Order Age - Hummingbot

URL: https://hummingbot.org/strategy-configs/max-order-age/

Contents:

Max Order Age¶
How it works¶
Sample configuration¶
- Max order age with order refresh tolerance¶
- Max order age with hanging orders¶
- Why max order age is important in liquidity mining?¶

Released on version 0.34.0

By default, the parameter is set to 1800 seconds.

To reconfigure, run the command config max_order_age and set the desired value in seconds.

The max_order_age parameter allows you to set a specific duration when resetting your order's age. It refreshes your orders and automatically creates an order based on the spread and movement of the market. Also, hanging orders remain as hanging orders.

We can set the maximum age of an order before it refreshes back to the set spread and amount. The example below shows that it refreshed the order's age before order_refresh_time was triggered because max_order_age was set to 20 seconds.

Setting our max_order_age at a lower time than order_refresh_time refreshes our orders based on the last spread and value.

Now try out a configuration without max order age, and let's enable order refresh tolerance.

The orders are not canceling because it is within the 0.1% order refresh tolerance percentage even though the order refresh time is 30 seconds.

Now add max order age to the config.

The max_order_age parameter tried to refresh the order but order_refresh_tolerance_pct kicked in. That's why the order was canceled, and the bot created a new order because it reached the threshold of 0.02%.

Max order age respects hanging orders and refreshes the orders but does not cancel active hanging orders. See the example below.

The hanging orders were not canceled and were only refreshed when max_order_age was triggered.

Suppose you are participating in the HARD-USDT campaign with an order refresh time of 30 minutes. Max order age refreshes depending on what you set it on as long as it is lower than the order refresh time. When participating in liquidity mining, outstanding orders that reach the 30-minute mark are not subject to rewards. Therefore, it is best to use the parameter to refresh the orders' age to be eligible for rewards.

Examples:

Example 1 (unknown):

bid_spread : 0.50
ask_spread : 0.50
max_order_age : 20.0
order_refresh_time : 60.0

Example 2 (unknown):

bid_spread : 0.50
ask_spread : 0.50
order_refresh_tolerance_pct: 0.1
order_refresh_time : 60.0

Example 3 (unknown):

bid_spread : 0.50
ask_spread : 0.50
order_refresh_tolerance_pct: 0.02
max_order_age: 15.0
order_refresh_time : 30.0

Example 4 (unknown):

ask_spread: 0.3
bid_spread: 0.3
order_refresh_time: 60
max_order_age: 30
hanging_order_enabled: True

AMM Arbitrage - Hummingbot

URL: https://hummingbot.org/strategies/amm-arbitrage

Contents:

amm_arb¶
📁 Strategy Info¶
📝 Summary¶
🏦 Supported Exchange Types¶
🛠️ Strategy configs¶
📓 Description¶
ℹ️ More Resources¶

See Trading logic to understand how the strategy works.

How to arbitrage AMMs like Uniswap and Balancer: Learn how you can Arbitrage AMMs with our strategy

Quickstart Guide for amm_arb (deprecated): This guide will walk you through the installation and launch of the new amm_arb strategy

Executors - Hummingbot

URL: https://hummingbot.org/v2-strategies/executors/

Contents:

Executors
Types of Executors¶
Benefits of Executors¶
Executor Orchestrator¶
- Key Features and Operations¶

Executors in Hummingbot are self-managing components that handle the execution of orders according to predefined conditions set by Controllers, which, in turn, utilize data from the MarketDataProvider (Candles, Orderbook, Trades). Executors are tasked with managing the state of orders — initiating, refreshing, and canceling orders, as well as halting their own operation when certain conditions are met.

The ExecutorOrchestrator serves as a utility class that enables trading strategies to dynamically create, stop, and manage executors, which are specialized units responsible for executing trading activities such as placing and managing orders.

Initialization: The ExecutorOrchestrator is initialized with a reference to the trading strategy (strategy) and an update interval (executors_update_interval). This setup allows it to periodically update and manage executors based on the strategy's requirements.

Executor Management: It maintains a dictionary of executors, where each executor is associated with a controller ID. This structure facilitates the organization and retrieval of executors for management purposes.

Action Execution: The orchestrator can execute various actions (ExecutorAction) such as creating, stopping, and storing executors. Actions are processed either individually or in batches, allowing for flexible execution management.

Creating Executors: Based on the CreateExecutorAction, it can instantiate different types of executors (e.g., PositionExecutor, DCAExecutor, ArbitrageExecutor) with specific configurations. This allows strategies to deploy diverse trading tactics dynamically.

Stopping Executors: Using the StopExecutorAction, it can gracefully stop executors, ensuring that any ongoing operations are properly concluded before termination.

Storing Executors: The StoreExecutorAction enables the orchestrator to store executor data, facilitating persistence and analysis of executor performance over time.

Performance Reporting: The orchestrator can generate detailed performance reports for individual controllers or globally across all controllers. These reports include metrics such as realized and unrealized P&L (Profit and Loss), trading volume, and the distribution of close types, providing insights into the effectiveness of the trading strategy and its executors.

Pure Market Making (PMM) - Hummingbot

URL: https://hummingbot.org/strategies/pure-market-making/

Contents:

pure_market_making¶
📁 Strategy Info¶
📝 Summary¶
🏦 Supported Exchange Types¶
🛠️ Strategy configs¶
📓 Description¶
- Architecture¶
- Refreshing Orders¶
- Executing Order Proposals¶
- Example Order Flow¶

This strategy allows Hummingbot users to run a market making strategy on a single trading pair on a spot exchanges.

It places limit buy (bid) and limit sell (ask) orders on the order book at prices relative to the mid-price with spreads equal to bid_spread and ask_spread. Every order_refresh_time seconds, the strategy replaces existing orders with new orders with refreshed spreads and order amounts.

In addition, the strategy contains a number of parameters to enable traders to control how orders are placed relative to their inventory position, use prices from a different order book, etc.

The description below is a general approximation of this strategy. Please inspect the strategy code in Trading Logic above to understand exactly how it works.

The built-in pure market making strategy in Hummingbot periodically requests limit order proposals from configurable order pricing and sizing plugins, and also periodically refreshes the orders by cancelling existing limit orders.

Here's a high level view of the logic flow inside the built-in pure market making strategy.

The pure market making strategy operates in a tick-by-tick manner. Each tick is typically 1 second, although it can be programmatically modified to longer or shorter durations.

At each tick, the pure market making strategy would first query the order filter plugin whether to proceed or not. Assuming the answer is yes, then it'll query the order pricing and sizing plugins and calculate whether and what market making orders it should emit. At the same time, it'll also look at any existing limit orders it previously placed on the market and decide whether it should cancel those.

The process repeats over and over at each tick, causing limit orders to be periodically placed and cancelled according to the proposals made by the order pricing and sizing plugins.

For each limit order that was emitted by the pure market making strategy, an expiry timestamp would be generated for that order and the order will be tracked by the strategy. The time until expiry for new orders is configured via the order_refresh_time parameter.

After an order's expiration time is reached, the pure market making strategy will create a cancel order proposal for that order.

After collecting all the order pricing, sizing and cancel order proposals from plugins and the internal refresh order logic - the pure market making strategy logic will merge all of the proposals and execute them.

Below is a hypothetical example of how the pure market making strategy works for a few clock ticks.

This cycle of order creation and order cancellation will repeat again and again for as long as the strategy is running. If a limit order is completely filled by a market order, the strategy will simply refresh it at the next clock tick.

What is market making?: A blog post that explains the basics of market making.

How to set up a simple pure market making bot on Binance: Learn how to create pure market making bot on Binance exchange.

Trader Sharing: Pure Market Making with cgambit: Eagle Club member and top Hummingbot Miner earner cgambit shares his tips and insights on pure market making.

Pure Market Making (PMM) Strategy: Use Pure Market Making Strategy but set dynamic bid/ask orders based on TradingView indicators which trigger alerts to Telegram and change the bid/ask orders using inventory skew or spreads-adjusted.

Check out Hummingbot Academy for more resources related to this strategy and others!

Strategies - Hummingbot

URL: https://hummingbot.org/strategies

Contents:

Strategies
What is a Hummingbot Strategy?¶
Strategies V2¶
Strategies V1¶
Learn Algo Trading and Market Making¶