Hummingbot + Meteora

Hummingbot & Gateway#

Hummingbot runs the rules.

Hummingbot is a trading framework. A strategy decides what to do; the client runs it. A bot can follow a schedule and limits without panic or revenge trading. It can also repeat a bad decision faster than you can.

Gateway connects those rules to the DEX.

Gateway is the middleware: a service that translates API requests into blockchain interactions. Its Meteora connector handles pool reads, swaps, and liquidity operations. Your strategy still decides when to act.

1. Hummingbot clientYour strategy & limits
2. GatewayQuotes & transactions
3. Meteora DLMMPositions on Solana

Market making can earn a spread, venue incentives when available, or repeated buy/sell gains in a range. For a DLMM LP, the direct income is a share of swap fees. None of these removes the risk of holding the tokens as their prices change.

What Meteora supports#

Meteora’s live CLMM connector supports DLMM positions. CLMM is Gateway’s interface category; your Meteora liquidity still lives in discrete bins. The connector docs list Solana networks mainnet-beta and devnet.

Gateway v2.17.0 adds DAMM v2 through the AMM interface, alongside DLMM. It also supports wider DLMM ranges by splitting work across transactions. Wider ranges can therefore mean more transactions and costs.

The Meteora docs list these 12 CLMM operations, grouped by job. Their documented prefix is /connectors/meteora/clmm/. These are the older route names; check the version note below before making requests.

Pools & quotes

fetch-poolspool-infoquote-position

Positions

positions-ownedposition-infoopen-positionclose-position

Liquidity

add-liquidityremove-liquidity

Fees

collect-fees

Swaps

quote-swapexecute-swap

• Version matters. v2.17.0 removes the connector-specific paths and uses /trading/clmm/*, /trading/amm/*, and /trading/router/*, with the connector supplied as a parameter. Request fields may differ from older examples too. Use your installed Gateway’s Swagger docs as the request contract. Read the migration notes.

The code lives in Gateway’s src/connectors/meteora. met.guide’s author reviewed the repository and noted pool-state and slippage fixes through September 2026 (fb5a626, 94911bc). Alongside the release work, that suggests active maintenance. It is not a guarantee against bugs.

Meteora was also an Agent Builders Cup sponsor, as noted in the official connector page. Sponsorship does not validate a strategy’s returns.

What you can automate#

Think in rules you can explain before you automate them. Gateway supplies the operations; a controller or your script combines them.

• Open, close, and rebalance positions. Watch whether liquidity is out of range, then close or withdraw from the old range and open a new one. Set a cooldown and a maximum allocation so every small price move does not trigger rebalancing.
• Ladder new ranges. Split a fixed budget across several price bands. Define a total inventory cap so overlapping positions do not quietly multiply your exposure.
• Collect fees on a schedule. Check accrued fees and collect only when the amount justifies the transaction cost. Fee collection by itself does not compound your position.
• Remove → swap → re-add. Withdraw liquidity, swap into the token balance your new range needs, then deposit again. Treat this as several transactions: confirm each result and inspect the wallet before retrying a failed step.
• Quote and execute swaps. Use the pool’s swap interface or Gateway’s router with a supported routing connector. In v2.17.0, router operations live under /trading/router/*. A route quote is not a guaranteed fill; check slippage and expiry.
• Build a position dashboard. Poll the operations documented as positions-owned and position-infoto track ranges, balances, and fees. Limit polling and flag stale data before letting it trigger a trade.

These are possible workflows, not six switches that turn on when you install Gateway. Start with one pool and one rule. Log the reason for every action so you can tell whether the bot followed it.

Beginner quickstart#

The first milestone is a complete position lifecycle on devnet: inspect, quote, open, read, collect, and close. Use test tokens and a separate wallet before committing real funds.

1. Install Hummingbot and Gateway.

   Follow Hummingbot’s installation guide, then use the recommended Docker Gateway setup. In the Hummingbot directory, uncomment the Gateway service in docker-compose.yml. It uses port 15888. The sample sets GATEWAY_PASSPHRASE=admin; replace it with a strong passphrase. The sample also publishes the port on every network interface. For local HTTP testing, bind it to localhost instead:

   Local Docker port mapping

   ports:
     - "127.0.0.1:15888:15888"

   Copy

   Start both services, then attach to the client:

   Terminal · Hummingbot directory

   docker compose up -d
   docker attach hummingbot

   Copy

   The Condor quickstartis another path: its Hummingbot API can manage Gateway for you. You do not need both installation paths.

   Prefer installing Gateway from source?

   With Hummingbot already installed, Node 20+ and pnpm available:

   Terminal · Gateway source installation

   git clone https://github.com/hummingbot/gateway.git
   cd gateway
   pnpm install && pnpm build && pnpm run setup
   pnpm start --passphrase="<PASSPHRASE>" --dev

   Copy

   Replace the placeholder locally; keep the secret out of shared shell history and logs. The --dev flag selects HTTP development mode. It does not select Solana devnet.

2. Connect a Solana test wallet.

   Run this inside the Hummingbot client, then follow the wallet prompts:

   Hummingbot client · connect wallet

   gateway connect solana

   Copy

   Select devnet in your Solana network configuration and requests; connecting a wallet does not select the network. Fund that wallet with devnet SOL and obtain the test tokens for your chosen devnet pool. Mainnet addresses and balances are not interchangeable with devnet. See the wallet connection instructions.

3. Configure Meteora.

   Edit /conf/connectors/meteora.yml inside Gateway (the mounted gateway-files/conf/connectors/meteora.ymlin the Docker setup). This block is copied verbatim from the official configuration section:

   meteora.yml · official defaults

   # Global settings for Meteora
   # Default slippage percentage for swaps (e.g., 1 = 1%)
   slippagePct: 1
   
   # default DLMM strategy type for positions
   # SpotImBalanced = 0,
   # CurveImBalanced = 1,
   # BidAskImBalanced = 2,
   # SpotBalanced = 3,
   # CurveBalanced = 4,
   # BidAskBalanced = 5
   strategyType: 0

   Copy

   slippagePct: 1 means a default 1% swap tolerance, not a target return. strategyType selects one of six liquidity distribution presets. It does not define when to rebalance. Restart Gateway after editing its file and verify the loaded settings before testing.

4. Make your first endpoint calls in Swagger.

   With local development mode running, open the interactive docs:

   Local Swagger URL

   http://localhost:15888/docs

   Copy

   Start with a pool read and a position quote. Choose Meteora, Solana devnet, your test wallet, a devnet pool, the token amounts, and your lower and upper range. Use the fields and authentication shown by your installed schema, then review the response.

   For the open-position example, find the CLMM position-opening operation under /trading/clmm/* on v2.17.0+. On an older version matching the connector page, it is /connectors/meteora/clmm/open-position. Use Swagger’s “Try it out”, fill the required fields, and execute only after confirming the network is devnet. Its generated curl command is the example to reuse for your version; do not simply change an older request’s URL.

   Record the returned position and transaction identifiers. Read the position back, try fee collection when fees exist, and close it. Confirm the on-chain state after each step. See the v2.17.0 route changes and Swagger setup.

5. Run a compatible LP controller.

   A V2 controller decides when to act; executors carry out its actions. The controller catalogincludes an LP rebalancer. Check its Meteora support and network settings in the version you installed, then generate its config:

   Hummingbot client · create LP controller config

   create --controller-config generic.lp_rebalancer.lp_rebalancer

   Copy

   Set your devnet pool, budget, range rules, and limits. Follow the V2 controller walkthroughto load that config with v2_with_controllers:

   Hummingbot client · create controller runner

   create --v2-config v2_with_controllers

   Copy

   Supply your controller config filename when prompted. If you save the runner as conf_v2_with_controllers_1.yml, the start command is:

   Hummingbot client · start configured runner

   start --v2 conf_v2_with_controllers_1.yml

   Copy

   Check logs and positions while it runs. A generic order-book market-making controller is not automatically a DLMM strategy. Move to small mainnet size only after the full workflow works.

What it costs#

• Software: $0. Hummingbot’s Apache 2.0 license has no subscription charge. Optional third-party services have their own pricing.
• Pool fees: know which side you are on. As an LP, you earn your share of trading fees when your liquidity is used. As a swapper, including during a rebalance, you pay the pool’s applicable swap fees. Protocol shares affect what LPs receive.
• Solana transactions: small, not zero. Budget SOL for network and priority fees, plus any account rent needed to create positions. Frequent small adjustments can cost more than they earn.
• Infrastructure: your choice. A local machine can handle practice. An always-on bot may use a small VPS and a paid RPC service. Include those bills in net PnL.

References: Hummingbot license, Meteora fee mechanics, and Gateway’s wide-range transaction notes. Deposited capital is separate from these costs and remains at risk.

Risks & honest notes#

Automation makes execution consistent. It does not make a strategy profitable. met.guide’s author collected notes on public $1,000-scale bot experiments, with results ranging from about +$65 to −$3. One reported $64.97 on roughly $22,000 of volume over 36 hours. Another lost $3.24 with poor parameters. We have not linked or verified the original posts. Treat them as anecdotes, not Hummingbot or Meteora results or DLMM benchmarks. Do not annualize a short run. Parameters and venue choice matter.

• Adverse selection. Traders can trade against your liquidity just before price moves against you. Fee income may not cover the loss.
• Inventory risk. You can end up holding more of the falling token. A range ladder spreads entry levels; it does not remove token exposure.
• Impermanent loss. Your LP position can underperform simply holding the same tokens. Fees may offset that difference, but they may not.
• Gas, fee drag, and slippage. Repeated swaps and range moves consume the edge you hoped to capture. Price impact and a stale quote can make execution worse than expected.
• Parameters and operations. Tight ranges, excessive retries, stale pool state, or RPC failures can turn a reasonable idea into losses. After an uncertain transaction, reconcile the position before resubmitting.
• Key hygiene. Protect the Gateway passphrase and wallet private keys. Use a dedicated wallet with limited funds. Keep development HTTP local; use HTTPS with configured certificates for production and restrict access to Gateway.

Practice on devnet first, then use small size on mainnet. Devnet can test mechanics; it cannot prove your strategy’s live-market returns. Gateway’s installation docscover production certificates and connection settings.

met.guide is an independent educational site, not affiliated with Meteora or Hummingbot. Do your own research (DYOR). This guide is not a promise of returns or a recommendation to fund a particular bot.

Common questions#

Further reading#

Keep the mechanics close while you learn the tooling.

• Meteora DLMM beginner’s guide — how a position earns fees.
• DLMM bins and ranges explained — the choices your bot will automate.
• Meteora connector docs and v2.17.0 release notes — capabilities and API changes.
• Gateway installation and V2 controllers — setup and strategy building blocks.
• Meteora’s DLMM overview — the underlying protocol.