Should the scripts feature be kept alive?

Author: zappra 0x412

Original Post Date: 12 Jan 2022

I believe it’s the general intention, sometime in the future, to deprecate scripts in Hummingbot.

Personally I find the script feature pretty useful, and I think some of the original custom scripts like price band and spreads-on-volatility are popular with some other long term users.

I think the problem is not so much the feature itself, but it’s current implementation, which is very limited and resistant to new features. I outlined some of my thoughts on this here:

Run scripts in main process · Issue #3150 · hummingbot/hummingbot (

We still get a lot of “can I do xxx in scripts?” questions in the HB discord, the answer to which is invariably “no” due to scripting’s limited feature set.

At it’s core, the script feature could be a simple way of injecting custom code, and extending/customising Hummingbot or its strategies in all kinds of interesting ways, without modifying the core code itself, which means you don’t have to worry about resolving merge conflicts or creating custom docker images.

For example, some of the stuff I do:

  • Custom kill switch/shutdown behaviour
  • Create a named pipe to receive messages eg. from bash scripts
  • Write out custom PnL or other data for later analysis or chart plotting
  • Read/write global or strategy config programmatically
  • Load candle data from exchange (I demoed this in a long lost PR)
  • etc

Curious to know others thoughts on this :slight_smile:

Author: fengtality 0x352

Thanks for raising this issue! I definitely agree that customizing strategies is a sorely needed feature. Scripts was an experiment intended to serve this function, but it was implemented as something that ran in a separate thread. This was intentional to prevent buggy scripts from crashing the main thread, but it also meant that any main thread variables needed to be explicitly passed to the scripts thread to be accessed and modified. Also, the scripts feature was limited to the Pure Market Making strategy and would be difficult to port to other strategies.

In order to enable users to customize strategies, I think it would be better to improve the strategy interface directly and add a domain specific language (DSL) to let users develop customized strategies more easily. The CoinAlpha team is planning to propose some foundational work needed to accomplish that, and there’s a community member who will propose such a DSL.

Author: nullably 0x10b

I agree with all the limitation of scripts as discussed here. I lean more towards simplifying strategy creation rather than updating existing script architecture. I created this feature request (an epic) Introduce new Lite strategies. · Issue #4715 · hummingbot/hummingbot · GitHub

I called it lite strategies. @zappra I think this is in the same direction as what you mentioned here

Author: zappra 0x412

I think scripting goes beyond strategies - having used Hummingbot for a while now, the most useful scripting stuff that I’ve developed is actually charting/reporting and bot management. Kill switch is a really good example, it’s a simple feature, but you inevitably end up with requests like “can you customise it to do blah” or “can you add a take profit kill switch” etc. Python is already a very easy language to use - in this specific instance if you had the ability to call “hb.stop()” in a script, users can run wild and code up whatever kind of killswitch they want.

Creating new strategies is not a good use for the existing scripting. It is possible to force pure market making to be something more akin to a position based strategy using the existing scripts feature (I know this because I’ve tried!) - but that’s really a case of forcing a square peg into a round hole.

I would personally caution against a DSL. In my day job I’ve encountered a ton of these and you’ll likely end up with a) a ton of feature requests to extend a limited feature set or b) some arcane runtime you can’t debug or c) some weird broken authoring environment or d) all of the above

For me, if I wanted to create a new strategy I’d just roll my sleeves up and code it in python. Granted, you need enough experience with HB in general to be able to manage the learning curve, but at least I know that I’m not going to bump into some arbitrary feature wall where I can’t do what I want because “HummingScript doesn’t support that order type” or whatever. Thats the precise issue with scripting in hummingbot as it stands - there’s nothing stopping you accessing the order book, open orders, the connector, the strategy, and poking about to your hearts content - all oft requested features - but for the fact that the way it’s set up - in a separate thread - means you can’t.

Author: fengtality 0x352

@zappra I think you’re highlighting a good point, which is that scripts may be a useful feature outside of their current context, which only allows them to modify the PMM strategy. I agree that kill switch or other features that might be better candidates for this functionality.

Re: DSL, my thought process here is that it should be something akin to Keras and Tensorflow. When Keras was first introduced, it only allowed users to build very simple Tensorflow models. Over time, it became more powerful and eventually got folded into the main Tensorflow repo.

Similarly, I think we could simplify the logic of a strategy so that users can create relatively simple bots that execute a create/cancel order loop based on various exchange data sources every tick.

Author: zappra 0x412

@fengtality yes definitely worth emphasising that even if you take away anything strategy related, scripting still has (potential) value

Author: AG Hunter 0x3d5

I think the current script functionality is a core feature of Hummingbot. Deprecating it would significantly reduce Hummingbot’s functionality. Scripting provides a way for non dev users to be able to customise their strategies in an accessible way. I note Zappra’s comments above re: “python being a very easy language to use” and “I’d just role up my sleeves and code it myself”, but these are easy statements to make if you have a strong technical background. For those of us who do not, modifying the source code is not achievable, so the easiest way we can implement custom tweaks is via scripts. Scripting also provides a good on ramp for the less technically competent user to dip their toe in the water and improve their coding, whilst experimenting with their strategies. The goal of Hummingbot is “to democratize high-frequency trading by enabling decentralized maintenance and community governance” This should include making market making as accessible as possible to users who do not have a dev background. I believe that scripts are one of the key ways that Hummingbot caters to this segment of the user base.

I know there are some other threads discussing ways to allow users to customise strategies, so some of the types of functionalities I have referred to may be captured in other improvement proposals, but scripting is a great way to allow users to individualise their strategies. I would be concerned that a drag and drop style of interface, or some other form of drop down list of pre configured options would limit this. I do also support the implementation of a more interactive UI that allows more predefined strategy customisation options, but I don’t believe that this should come at the expense of the scripting feature.

Author: cgambit 0xdEa

We do fully agree with AG Hunter’s comments. Even with our yet limited python skills at the moment, we were able to use the script functionality relatively easily. We were able to change parameters based on certain conditions / logic.

We support for enhancement & maintenance of script functionality, until something far superior features will replace it in the near future.

Author: PHBR0 x58B

@zappra You can also create a pool on the thread. Could be an interesting way to check community feelings about the topic.

Author: zappra 0x412

@PHBR how do I do that?

Author: PHBR0 x58B

On the top Right of the thread, usually there is an option to create a pool.

Author: PHBR0 x58B

Currently yes, scripts are an useful tool.

But i think is more about reworking the way custom strategies can be created, and integrating the scripts functionality inside the strategy creation.

There is some work being done related to this topice, like this: Introduce new Lite strategies. · Issue #4715 · hummingbot/hummingbot · GitHub

Author: mobiwan 0x1B2

+1 for keeping the scripting feature alive.

Like others in this thread, I rely heavily on my custom script to automatically manage Hummingbot instances at scale, including:

  • Operating bots automatically by updating settings in an online database

  • Managing trading activity via bespoke campaign budgets, order amounts, inventory levels, order spreads, etc

  • Capturing regular snapshots of bot configs and trading metrics

  • Logging heartbeats, snapshots, and custom events to an online log management system

  • Several other custom helpers

I was also planning to extend my script to include:

  • Custom stop loss / kill switch

  • Internal commands to start, stop, pause, and quit bots

  • External commands to start and stop containers/processes

  • Advanced order spread management

  • Etc

I appreciate the logic behind deprecating PMM scripts, and I understand that it was never intended to do this much. But whether we like it or not, this feature is used in production by many traders and liquidity miners, so deprecation would constitute a significant breaking change. And without a viable migration path, deprecation would be detrimental to many traders and liquidity miners.

In my case, I would have to reevaluate whether to continue liquidity mining with a manual approach (and far fewer bots), or retire from liquidity mining on centralised exchanges altogether.

IMHO, now that the Hummingbot platform is in the hands of the community, this decision should be handled via a HIP. And if the vote is ultimately in favour of deprecation, then there should be a viable migration path on a realistic timeframe to accommodate changes to production environments.

Author: fengtality 0x352

Actually, I don’t think the Foundation should prioritize deprecation of PMM Scripts, since both it and the new generalized Scripts can co-exist together. We recently modified the Scripts documentation to reflect that.

After there’s a larger library of examples of the new Scripts, especially once there’s a PMM-like script that users can customize more easily, I think PMM Script users may choose to migrate over if they like, but there doesn’t seem to be much downside to keeping PMM Scripts in the codebase.

Agree that deprecation of key features like PMM Scripts should be handled via HIP or even HGP.

Author: mobiwan 0x1B2

That’s fantastic news, thanks for clarifying that. Will keep an eye out for the HIP/HGP.