Точный перенос PMMSimpleController из Hummingbot (автор — hummingbot, Apache-2.0): симметричный чистый маркет-мейкинг с 2+2 уровнями на WLDUSDT.BINANCE 1m, спреды 1%/2% вокруг средней цены, тройные барьеры для исполнителей каждого уровня (SL 3%, лимит TP 2%, ограничение по времени 45 мин, трейлинг-стоп 1.5%/0.3%), обновление каждые 5 мин, пауза 15 с, 20x

Верный перевод файла hummingbot's controllers/market_making/pmm_simple.py (PMMSimpleController, коммит 9af100d6822da7d2d0291a906c730ef172284ee2, автор: hummingbot, Apache-2.0; признание заслуг принадлежит первоначальным авторам). Файл контроллера переопределяет только get_executor_config(). Все правила торговли взяты из значений по умолчанию в MarketMakingControllerBase / MarketMakingControllerConfigBase и из тройного барьера PositionExecutor; каждое из них перечислено ниже, чтобы разработчик мог перевести их построчно. В исходнике нет утверждений о доходности; решение принимается по результатам нашего бэктеста с реалистичными комиссиями, заданными моделью. MARKET (значение по умолчанию в источнике): коннектор binance_perpetual, trading_pair WLD-USDT, сопоставленный с WLDUSDT.BINANCE (USD-M бессрочный контракт, мейкер 0.02% / тейкер 0.05%) на барах 1-MINUTE. Для WLD на Binance доступна история за 1 месяцев, начиная с 2023-07. BINANCE чрезмерно представлен в корпусе. При точном переносе он всё же сохраняется, поскольку коннектор и пара по умолчанию в источнике — бессрочный контракт Binance WLD-USDT. Сам WLD редко используется в корпусе, а механизм недостаточно представлен по нескольким параметрам: он торгует в лонг и шорт, работает на коротком временном горизонте и формирует рынок, предоставляя пассивную ликвидность с обеих сторон, с тройным барьером для каждого ордера. LEVELS: buy_spreads [0.01, 0.02] и sell_spreads [0.01, 0.02] дают четыре идентификатора уровня: buy_0, buy_1, sell_0 и sell_1. План оптимизации принимает только скалярные значения, поэтому эти списки объявлены как скалярные параметры buy_spread_0=0.01, buy_spread_1=0.02, sell_spread_0=0.01 и sell_spread_1=0.02. Для buy_amounts_pct и sell_amounts_pct по умолчанию задано None, что означает равномерное распределение: total_amount_quote делится на 50% для покупок / 50% для продаж, а затем поровну распределяется между уровнями каждой стороны, так что на каждый уровень приходится 25% (скалярные параметры level_amount_pct_buy_0 = buy_1 = sell_0 = sell_1 = 0.25). В качестве справочной цены используется средняя цена с spread_multiplier = 1, поскольку у pmm_simple нет пользовательского processed_data. Цена уровня = reference_price * (1 - спред) для покупок и reference_price * (1 + спред) для продаж. Объём уровня в базовом активе = котируемый объём уровня / цена уровня. SIZING (адаптация платформы): значение total_amount_quote по умолчанию в источнике — 100 USDT на счёте 20x. В нашем движке на $100k total_amount_quote = total_notional_equity_fraction (1.0) x get_account_equity() при создании исполнителя. Таким образом, каждый уровень составляет 25% от номинальной стоимости капитала, а максимальная односторонняя позиция — 50% от капитала (два уровня на одной стороне). config.leverage = 20 — значение по умолчанию в источнике, оно не превышает лимит BINANCE 20x; оно задаёт только маржу. Округляйте количества с помощью make_qty, проверяйте, что цена > 0, ограничивайте номинальную стоимость вычисленным значением и пропускайте уровни, номинальная стоимость которых меньше минимальных $5. EXECUTION SUBSTITUTIONS (из context.execution_capabilities): (1) hedge_mode не поддерживается (значение position_mode по умолчанию в источнике — HEDGE), также не поддерживаются per_executor_deadlines. Здесь используется эквивалентный подход: стратегия ведёт внутренний реестр максимум из четырёх исполнителей VIRTUAL, по одному на каждый идентификатор уровня. У каждого есть собственная цена входа, исполненное количество, время создания и барьеры. Каждый виртуальный вход и выход отправляется как реальный ордер по единой позиции NETTING. В рамках этой модели чистая позиция на бирже всегда равна сумме открытых виртуальных исполнителей, а PnL счёта и комиссии равны сумме PnL и комиссий исполнителей, поскольку в режиме хеджирования каждое исполнение также было бы отдельным ордером с той же комиссией. От режима хеджирования отличаются только использование маржи и отчётность по позиции. (2) Средняя цена: в этой конструкции не используются тики котировок, поэтому справочная цена — это последнее закрытие минутного бара 1m. (3) Hummingbot получает тики примерно раз в секунду; мы выполняем оценку при каждом закрытии минутного бара 1m. executor_refresh_time из 300 с — это 5 баров, а cooldown_time из 15 с округляется вверх до 1 бара, поэтому после закрытия уровня котировка может быть выставлена заново при закрытии следующего бара. Лимитные входы и лимитный тейк-профит размещаются в симулируемой торговой площадке и исполняются внутри бара, когда цена бара пересекает их уровень. Стоп-лосс — это защитный стоп, действующий внутри бара: ордер stop_market, предназначенный для сокращения позиции, выставляется по чистой позиции, исполняется внутри бара в симулируемой торговой площадке платформы и зеркально воспроизводится в реальной торговле. Выходы по временному ограничению и трейлинг-выходы исполняются рыночными ордерами при закрытии бара, на котором они срабатывают.

Сохраняет сигналы, инструмент, размеры позиций, спреды, барьеры и зафиксированный план параметров из предыдущей реализации. Устраняет первый дефект QA, сохраняя экспозицию исполнителя при частичном или отклонённом закрытии, отслеживая подписанный долг по компенсации на основании подтверждённых исполнений, повторяя попытки по окончательно неудачным ордерам в последующих циклах управления и предотвращая повторное использование уровня, пока все незавершённые ордера не урегулированы. Устраняет второй дефект, сверяя наличие и размеры барьеров в каждом цикле управления и запуская отслеживаемое завершение работы после отклонения, запрета, истечения срока действия или неудачного создания барьера. Владение регистрируется до отправки ордера, чтобы обрабатывать синхронные обратные вызовы. Сохраняются существующие адаптации платформы: закрытие бара заменяет среднюю цену, минутные циклы управления приближённо воспроизводят исходное время тиков, а реальные ордера реализуют виртуальные хеджевые исполнения на счёте NETTING. Отчётность по чистой позиции и экономика виртуальных исполнителей требуют отдельной оценки; отрицательный результат усечённого тестирования в песочнице не позволяет вынести вердикт о корректности. Независимая проверка не проводилась. Необходимый файл исходящих данных не удалось записать, поскольку эта рабочая область допускает только чтение файловой системы; в этом ответе содержится полный артефакт, относящийся к задаче JSON.

Семантический аудитор обнаружил расхождение между кодом и гипотезой — код NOT реализует гипотезу. Перепишите стратегию так, чтобы она реализовывала гипотезу EXACTLY (инструмент, таймфрейм, направление, указанный рыночный эффект или механизм, размер позиции). Конкретные проблемы: неучтённая экспозиция. В комментариях к коду сказано, что исполнение, поступившее для уже закрытого исполнителя (гонка на одном баре между TP и SL), нейтрализуется рыночным ордером. Но цикл отмены соседних ордеров в on_order_filled, а также _close_executor и _place_barriers вызывают self._omap.pop(other) сразу после self._cancel(other). В бэктесте NautilusTrader команда отмены ставится в очередь и обрабатывается только после прохождения текущего бара через движок сопоставления (open, high, low, close). Поэтому на баре, где лимитный ордер TP исполняется на максимуме, а стоп срабатывает на минимуме, стоп всё равно исполняется. При этом on_order_filled обнаруживает tag None и досрочно возвращает управление, поэтому компенсирующий рыночный ордер не отправляется. Поскольку для стопа задано reduce_only=False, это исполнение открывает противоположную позицию по 20x без записи в журнале и без защитных барьеров. В результате нетто-позиция перестаёт равняться сумме виртуальных исполнителей, нарушая требуемую гипотезой эквивалентность журнала при неттинге. Значения -100% доходности и 100% просадки согласуются с накоплением таких утечек позиций. ## Улучшения из библиотеки знаний (проверьте их, не считайте доказанными) В материалах библиотеки о маркет-мейкинге сказано, что по баровым данным нельзя установить порядок исполнений внутри бара. Основная угроза для симметричного котировщика — риск инвентаря, особенно при выставлении котировок против тренда (单边成交/逆势挂单). Рекомендуются лимиты инвентаря с ценовым смещением (价格倾斜), котировки с масштабированием по волатильности, краткосрочный фильтр тренда, отменяющий рискованную сторону, и умеренный размер. Сначала нужно сделать журнал безопасным для баровых данных, устранив утечку неучтённых исполнений за период запуска -100%; остальные улучшения снижают профиль убытков с отрицательной асимметрией (60% доля прибыльных сделок, PF 0.53). 1. [выход] Безопасное разрешение барьеров и сверка журнала на каждом баре: reduce_only=True для всех ордеров stop_market; сохраняйте идентификаторы отменённых ордеров с флагом 'cancel_pending' до получения OrderCanceled или OrderFilled, чтобы позднее исполнение нейтрализовалось рыночным ордером; если один бар затрагивает и TP, и SL, учитывайте STOP_LOSS; при закрытии каждого бара исправляйте рыночным ордером любое расхождение между нетто-позицией и журналом размером не менее 1 шага размера; прекращайте выставлять котировки на 60 баров после более чем 3 исправлений за 1440 баров (источник: 基于逐笔成交的高频回测系统兼论K线回测的缺陷 p.1) 2. [фильтр] Краткосрочный фильтр тренда: отменяйте и пропускайте сторону против тренда: если ret15 > +1.0% и close > EMA30: не выставляйте уровни продажи и отменяйте неисполненные входные ордера; если ret15 < -1.0% и close < EMA30: то же для уровней покупки; в обоих случаях закрывайте убыточных исполнителей против тренда рыночным ордером (источник: 浅谈数字货币做市策略（2）：盘口策略 p.1; 数字货币高频策略详细入门 p.1; 加止损可以控制风险……那么，古尔丹，代价是什么呢？ p.1) 3. [размер позиции] Лимит инвентаря и смещение котировки: max_inventory = 0.25 капитала (не размещать новые ордера в сторону увеличения позиции); ref = close * (1 - 0.01 * inv / 0.25) (источник: 浅谈数字货币做市策略（2）：盘口策略 p.1; 行业大佬揭秘算法交易：发明者量化平台做市商策略 p.1) 4. [параметры] Спреды и барьеры с масштабированием по волатильности: spread_0 = max(0.01, 2*ATR60/close), spread_1 = 2*spread_0, TP = spread_0, SL = 3*spread_0, активация трейлинг-стопа = 1.5*spread_0, фиксируется при создании исполнителя (источник: 行业大佬揭秘算法交易：发明者量化平台做市商策略 p.1; 浅谈数字货币做市策略（2）：盘口策略 p.1) 5. [размер позиции] Сократите общий номинал выставленных котировок до 0.25x капитала: total_notional_equity_fraction = 0.25 (источник: 行业大佬揭秘算法交易：发明者量化平台做市商策略 p.1; 基于逐笔成交的高频回测系统兼论K线回测的缺陷 p.1)

Проверка не пройдена (слой 4 — проверка QA) [класс=code_defect]: - [edge_concern] Усечённая песочница показала среднее -0.21968% на закрытую нетто-позицию при значительном моделируемом влиянии на рынок. Отдельно оцените экономические результаты на полной истории и учёт виртуальных исполнителей; эти результаты не определяют корректность. - [критическая] _close_executor удаляет исполнителя и отменяет защиту до подтверждения рыночного закрытия. Исполнения закрытия с тегом 'c' игнорируются, а отклонённые или запрещённые ордера закрытия не могут восстановить удалённого исполнителя. Поэтому неудачное или неполное закрытие оставляет неучтённую экспозицию, а уровень может создать ещё одного исполнителя. Неудачные компенсирующие ордера с тегом 'n' также оставляют экспозицию без механизма восстановления. (строка 257) — исправление: Сохраняйте закрывающего исполнителя, пока подтверждённые исполнения не покроют оставшийся объём. Отслеживайте объёмы закрытия и компенсации, обрабатывайте отклонения и неполные исполнения, а перед освобождением уровня сверяйте непогашенную экспозицию. - [критическая] Отклонение, отказ или истечение срока защитного стопа лишь очищает ex['sl'] через _release. _control_executor не создаёт отсутствующие барьеры заново. Поэтому исполнитель с неудачно отправленным стопом может оставаться под риском до истечения временного лимита или выхода по трейлинг-стопу, без обязательного 3% защитного стопа. Неудачно отправленный тейк-профит также не восстанавливается. (строка 352) — исправление: Сверяйте необходимые барьеры в каждом цикле управления и явно обрабатывайте неудачную отправку. Восстанавливайте отсутствующую защиту или закрывайте исполнителя с отслеживанием всех этапов завершения; не считайте исполнителя без защиты исправно работающим.