The Strategy Studio

Admin → Hummingbot → Strategy Studio at /admin/hb/strategies is where controller presets are authored, versioned and published. It is the fourth of the five Hummingbot admin screens, and it is the one with two very different audiences: a published preset is what your customers download for their own Hummingbot, and it is also what your own server-run bots are launched with.

That second half is what makes this screen an operator surface rather than a content editor. Editing a preset is a deployment.

The list

The row actions are Preview / download YAML, Publish or Unpublish, Edit preset and Delete; New preset is in the toolbar. Multi-select delete posts to the collection endpoint.

The nine columns tell you which preset a row is; none of them shows what it would do. The parameters live in the config JSON, and Preview YAML is how you read them.

What a row actually stores

Table hb_strategy_preset. One row is a complete strategy minus its market.

For PMM the generator picks the connector from config.market (perp → bicrypto_perpetual, otherwise bicrypto), not from makerConnector — so a PMM preset's stored maker connector is informational. For XEMM both connectors are used as stored.

The endpoints

A few behaviours worth knowing:

• The list returns up to 500 rows when no perPage is given, so the instance form's preset picker sees everything rather than the first ten. It runs non-paranoid, because this table has no deletedAt column — there is no soft delete and no restore.
• PUT is a full replace, not a patch. The whole body is re-validated and re-normalised through the same path as create. That includes the publish/unpublish action, which is why toggling status also increments version.
• Validation runs twice on write — once on the body, once by rendering the YAML — and again on export. A config that cannot render is refused with 422 before it is persisted, so a stored preset can never emit malformed YAML. Common refusals: buySpreads and buyAmountsPct must have the same length (one per level), maxProfitability must be greater than minProfitability, a connector name outside [a-z0-9_], and a pair that is not BASE-QUOTE.
• Deleting is immediate and permanent. Users who already downloaded a preset keep their copy — their bot runs on their machine — so a delete only delists it here. What it does affect is your own instances: presetId is SET NULL, and an instance with no preset refuses to start with "this instance has no strategy preset, so there would be nothing for Hummingbot to run."

Permissions

/admin/hb/strategies is gated on view.hb.strategy in the route middleware, and the section root needs access.hb.

Publishing is not an edit-only act. The Publish / Unpublish row action is an ordinary PUT, so it needs edit.hb.strategy — but the create endpoint accepts status in its body, and the New preset dialog carries the same Draft/Published toggle. A role with view and create but no edit can therefore release a preset outright, at the moment it authors it; what it cannot do is change the status of a preset that already exists. If you are handing out create.hb.strategy to staff who should not be publishing to your customers, there is no permission that stops them — review the catalogue instead.

Draft versus published

status is the only thing standing between a preset and your customers.

The user-facing list returns published presets only, newest-updated first, capped at 200, and is gated by the view_hb KYC feature — the same gate that guards the connector kit, the setup page and the bot console. It is configured per level under Admin → CRM → KYC, not on this screen.

Note the asymmetry in the last row: your own instances can run a draft. The supervisor looks up the preset by id and never checks its status, so unpublishing a preset removes it from the customer catalogue without stopping the bots that use it. That is the safe way to retire a profile.

The six seeded presets

backend/seeders/20260729000001-hbStrategyPresets.js seeds six presets, all with status: "published" and version: 1, so the Studio is not empty on a fresh install.

All six default to BTC-USDT and to modest sizes, but the two families are sized in different places. The four PMM presets carry totalAmountQuote — 1000 quote, 500 for Wide. The two XEMM presets have no totalAmountQuote at all; their size is per level, amountQuote 200 then 300, so 500 a side.

They are starting points, not tuned strategies: raise totalAmountQuote on a PMM preset, or the per-level amountQuote on an XEMM one, to your own size, and recompute the XEMM targets against your own fee schedule before running any of them.

What re-running the seeder does

pnpm seed runs every seeder unconditionally — seeder state is not tracked — and pnpm updator runs pnpm seed, so this happens on every platform update whether you asked for it or not.

It also deletes six legacy names by exact match — the pair-named presets that shipped before markets moved onto the instance (PMM — BTC/USDT (spot) and its five siblings). If an instance is still linked to one of those, its presetId goes to NULL and it must be pointed at a new profile before it will start.

Authoring a preset

The editor is a purpose-built dialog rather than the generic table form, because which fields exist depends on the family, and within PMM again on spot versus perpetual.

Validating a preset before you publish

A preset that renders is not a preset that trades. Three checks, in increasing cost:

Only then set the status to published. Remember that publishing is a PUT and bumps the version, which is exactly what you want — the version is how you tell which revision a customer downloaded.

Where to go next

• Strategies and presets — every PMM and XEMM parameter, what it does to a running bot, and how to tune a ladder.
• Bot Instances — running a preset on your own server.
• Reboots, backups and recovery — what to back up, and what the seeder does after an update.
• The admin console — the other four Hummingbot screens.