Hummingbot PMMSimpleController (by hummingbot, Apache-2.0) faithful port: 2+2-level symmetric pure market making on WLDUSDT.BINANCE 1m, 1%/2% spreads around mid, per-level triple-barrier executors (SL 3%, limit TP 2%, 45-min time limit, 1.5%/0.3% trailing stop), 5-min refresh, 15-s cooldown, 20x

Faithful translation of hummingbot's controllers/market_making/pmm_simple.py (PMMSimpleController, commit 9af100d6822da7d2d0291a906c730ef172284ee2, author: hummingbot, Apache-2.0; credit goes to the original authors). The controller file only overrides get_executor_config(). Every trading rule comes from the defaults in MarketMakingControllerBase / MarketMakingControllerConfigBase and from the PositionExecutor triple barrier, and each one is named below so the developer can translate them line for line. The source makes no performance claims; our backtest with real fees decides. MARKET (source default): connector binance_perpetual, trading_pair WLD-USDT, mapped to WLDUSDT.BINANCE (USD-M perpetual, maker 0.02% / taker 0.05%) on 1-MINUTE bars. Binance has 1m history for WLD back to 2023-07. BINANCE is over-represented in the corpus. A faithful port still keeps it, because the source's default connector and pair are Binance perpetual WLD-USDT. WLD itself is rarely used in the corpus, and the mechanism is under-represented on several counts: it trades long and short, works on a short horizon, and makes markets by providing passive liquidity on both sides with a triple barrier on each order. LEVELS: buy_spreads [0.01, 0.02] and sell_spreads [0.01, 0.02] give four level ids: buy_0, buy_1, sell_0 and sell_1. The optimization plan accepts only scalars, so these lists are declared as the scalar parameters buy_spread_0=0.01, buy_spread_1=0.02, sell_spread_0=0.01 and sell_spread_1=0.02. buy_amounts_pct and sell_amounts_pct default to None, which means equal distribution: total_amount_quote is split 50% buy side / 50% sell side, then equally across each side's levels, so each level gets 25% (scalars level_amount_pct_buy_0 = buy_1 = sell_0 = sell_1 = 0.25). The reference price is the mid price with spread_multiplier = 1, because pmm_simple has no custom processed_data. Level price = reference_price * (1 - spread) for buys and reference_price * (1 + spread) for sells. Level amount (base) = level quote amount / level price. SIZING (platform adaptation): the source's total_amount_quote default is 100 USDT on a 20x account. On our $100k engine, total_amount_quote = total_notional_equity_fraction (1.0) x get_account_equity() at executor creation. Each level is therefore 25% of equity notional, and the maximum one-sided exposure is 50% of equity (two levels on one side). config.leverage = 20 is the source default and within the BINANCE 20x cap; it only sets margin. Round quantities with make_qty, guard price > 0, cap notional at the computed value, and skip any level whose notional is below the $5 minimum. EXECUTION SUBSTITUTIONS (from context.execution_capabilities): (1) hedge_mode is unsupported (the source's position_mode default is HEDGE), and per_executor_deadlines are unsupported. The equivalent used here: the strategy keeps an internal ledger of up to four VIRTUAL executors, one per level id. Each has its own entry price, filled quantity, creation timestamp and barriers. Every virtual entry and exit is sent as a real order on the single NETTING position. The venue's net position therefore always equals the sum of the open virtual executors, and account PnL and fees equal the sum of the executors' PnL and fees, since in hedge mode each fill would also have been a separate order paying the same fee. Only margin usage and position reporting differ from hedge mode. (2) Mid price: this design uses no quote ticks, so the reference price is the latest 1m bar close. (3) Hummingbot ticks about once per second; we evaluate on each 1m bar close. executor_refresh_time of 300 s is 5 bars, and cooldown_time of 15 s rounds up to 1 bar, so a closed level may re-quote at the next bar close. Limit entries and the limit take-profit rest in the simulated venue and fill intrabar when a bar trades through their price. The stop loss is an intrabar protective stop: a reduce-oriented stop_market order on the net position, matched inside the bar by the platform's simulated venue and mirrored live. Time-limit and trailing exits are market orders at the close of the bar that detects them.