Jump to content

Бот для торговли на бирже Binance


Recommended Posts

Posted (edited)

Screenshot_2026-05-20-16-34-06-113_com.binance_dev.thumb.jpg.2a0a79641cd9f9155d36836e3d9ed038.jpg

ПОДРОБНОЕ ОПИСАНИЕ И АРХИТЕКТУРА МОЕГО ТОРГОВОГО БОТА
С ЦИТАТАМИ И ПРАКТИЧЕСКИМИ ПРИМЕРАМИ ИЗ ЛОГОВ
========================================================================

Назначение:
Я описываю архитектуру моего торгового бота, принципы его работы, принятие
торговых решений, работу стратегий, риск-менеджмента, защиту ордеров,
позиционный ownership, TP/DCA, потоки данных и safety-логику.

В документ добавлены:
- цитаты из моих логов и отчётов;
- примеры, как бот реально принимает решения;
- объяснение, что означает каждая ключевая строка;
- выводы, какие принципы должны соблюдаться.


ИСПОЛЬЗОВАННЫЕ ИСТОЧНИКИ / ЛОГИ
========================================================================

Источник A:
24H VERDICT / СУТОЧНЫЙ ВЕРДИКТ от 2026-05-27T03:24:44 UTC.

Источник B:
Scheduled report GRID DCA BOT от 2026-05-27T03:24:38 UTC.

Источник C:
Runtime log от 2026-05-27 07:45–07:49, где видны scanner, watchlist,
strategy router, entry quality guard, WebSocket, orderbook, live gate,
LIMIT entry и pending order.

Источник D:
Startup/runtime log от 2026-05-26, где видны real futures mode,
dry_run=False, migrations, ownership reload и runtime services.


1. ОБЩАЯ ИДЕЯ МОЕГО БОТА
========================================================================

Я использую многоуровневого торгового бота для Binance Futures. Его задача —
не просто открыть сделку по одному сигналу, а пройти полный цикл:

1. собрать рыночные данные;
2. выбрать монеты для наблюдения;
3. выбрать кандидатов для входа;
4. проверить стратегии;
5. подтвердить направление через MTF/HTF;
6. проверить качество входа;
7. проверить риск и minNotional;
8. отправить ордер;
9. закрепить позицию за стратегией-владельцем;
10. создать TP-план;
11. управлять DCA только при разрешённых условиях;
12. очистить stale protective orders после закрытия.

Мой бот — это не одна стратегия, а торговая операционная система.

Цитата из startup/runtime лога:

    MARKET DATA MODE | execution_testnet=False | market_data=REAL_BINANCE_PUBLIC
    RUNTIME BOOTSTRAP | start | dry_run=False

Что это означает:
- бот использует реальные публичные данные Binance Futures;
- режим dry_run выключен;
- торговая система запущена как реальная runtime-система;
- решения должны проходить все защитные слои, потому что речь идёт не о простой симуляции.

Практический пример:
Если scanner увидел PLAY/USDT, это ещё не означает вход. Сначала PLAY должен
попасть в активные символы, пройти strategy router, MTF, entry quality guard,
risk guard и только потом попасть в executor.


2. ПОЛНЫЙ ПУТЬ ТОРГОВОГО РЕШЕНИЯ
========================================================================

Мой бот принимает торговое решение по цепочке:

Market Data / WebSocket / Orderbook
        ↓
Scanner / Coin Selection
        ↓
Strategy Router
        ↓
Strategy Decision
        ↓
MTF / HTF фильтры
        ↓
Entry Quality Guard
        ↓
Risk Guard / MinNotional / Exposure
        ↓
Live Gate / Safety / Auto Mode
        ↓
Executor
        ↓
Binance Order
        ↓
Position Owner / TP / DCA / Protection / Cleanup

Ключевой принцип:
Стратегия не должна сама напрямую и бесконтрольно отправлять ордер.
Она создаёт intent, а дальше intent проходит контроль качества и риска.

Цитата из лога по PLAY/USDT:

    STRATEGY ROUTER V2 | PLAY/USDT | selected=breakout |
    final_score=14.61 | raw_score=14.61 | entry_intents=1

Пример:
Router выбрал breakout по PLAY/USDT. Но после этого вход не был автоматически
отправлен, потому что его проверил Entry Quality Guard.


3. MARKET DATA, WEBSOCKET И ORDERBOOK
========================================================================

Мой бот использует рыночные данные:

- тикеры;
- свечи;
- bid/ask;
- spread;
- стакан;
- imbalance;
- whale flow;
- ATR;
- RSI;
- funding;
- MTF/HTF контекст.

У меня есть два типа потоков:

1. Market Data Stream
   Отвечает за рыночные данные, свечи, стакан, MTF и быстрые таймфреймы.

2. User Data Stream
   Отвечает за аккаунт, ордера, позиции, исполнения и listenKey.

Цитата из runtime лога:

    WebSocket market data started | symbols=13 |
    connections=1 | timeframes=1d,4h,1h,5m,15m,30m,3m,1m

Цитата из runtime лога:

    WebSocket connected | symbols=1000000BOB/USDT, 1000BONK/USDT,
    1000CAT/USDT, 1000CHEEMS/USDT, 1000FLOKI/USDT, 1000LUNC/USDT,
    1000PEPE/USDT, 1000RATS/USDT, 1000SATS/USDT, 1000SHIB/USDT,
    BSB/USDT, PLAY/USDT, RENDER/USDT

Пример:
Даже если entry_live только PLAY/USDT, WebSocket может держать больше символов.
Это нормально: часть символов нужна для наблюдения и обновления данных, но не
для немедленного входа.

Проблема, которую я отдельно контролирую:
Если stream живой и stale=0, resilience не должен давать ложный hard reset.

Цитата из лога:

    WS MARKET DATA RESILIENCE | score=70 |
    action=hard_stream_reset_recommended | stale=0

Вывод:
Если stale=0 и при этом есть WebSocket connected / ORDER BOOK UPDATED, то
hard_stream_reset_recommended может быть ложной диагностикой, которую нужно
исправлять через корректный health-флаг stream.


4. SCANNER И ВЫБОР МОНЕТ
========================================================================

Scanner — это первый уровень отбора рынка. Он не открывает сделки. Он выбирает,
какие символы нужно анализировать.

Целевая логика:

- market universe: 500–580 символов;
- scanner candidates: около 40;
- data-active basket: 8–10 символов;
- entry-live basket: максимум 3 символа;
- open positions: максимум 3 позиции.

Цитата из лога:

    Hybrid scanner candidates | universe=582 | selected=40 |
    forced=10 | ticker_ready=582 | ticker_missing=0 | ticker_stale=0 |
    volume_filtered=263 | ranked=309 | anti_loop=True | new=30

Что это означает:
- scanner видит почти весь рынок;
- выбирает 40 кандидатов;
- forced=10 означает принудительный набор активных символов;
- anti_loop=True нужен, чтобы не крутиться на одних и тех же монетах.

Цитата из лога:

    STRATEGY-FIRST SCAN | market=40 | snapshots=33 |
    live=PLAY/USDT, RENDER/USDT, BSB/USDT | shadow=14

Пример:
Scanner проверил 40 рыночных кандидатов и нашёл 3 live-кандидата:
PLAY, RENDER и BSB. Но это ещё не вход. Это только кандидаты для дальнейших
проверок.


5. DATA-ACTIVE И ENTRY-LIVE
========================================================================

Я разделяю два вида активных символов:

DATA-ACTIVE SYMBOLS
------------------------------------------------------------------------
Это символы, которые бот держит в WebSocket, стакане и MTF. Они нужны для
наблюдения и свежих данных.

ENTRY-LIVE SYMBOLS
------------------------------------------------------------------------
Это символы, которые уже потенциально могут дать вход. Они проверяются
стратегиями и quality guard.

Цитата из лога:

    STRATEGY-FIRST ACTIVE SYMBOLS |
    entry_live=PLAY/USDT, RENDER/USDT, BSB/USDT |
    data_only=none |
    data_filled=3/10 |
    entry_cap=3

Вывод:
entry_cap=3 — это правильно: реально торговать нужно максимум 3 позиции.
Но data_filled=3/10 показывает, что data basket был заполнен не полностью.
Для моей целевой архитектуры нужно, чтобы data basket держал 8–10 символов,
а entry_live оставался максимум 3.

Практический принцип:

    8–10 символов смотреть,
    максимум 3 символа торговать,
    не снижать точность входа.


6. РОТАЦИЯ СИМВОЛОВ
========================================================================

Я не хочу, чтобы бот постоянно крутил одни и те же монеты.

Цитата из лога:

    ACTIVE WS WATCHLIST ONLY | no live entries | active=none |
    watch=1000LUNC/USDT, 1000BONK/USDT, 1000CAT/USDT,
    1000FLOKI/USDT, 1000PEPE/USDT, 1000SHIB/USDT,
    1000000BOB/USDT

Цитата из лога:

    SYMBOL TEMP SKIP FILTER | stage=strategy_first_scanner |
    skipped=1000000BOB/USDT:no_positive_strategy_candidate_17s,
    1000LUNC/USDT:no_positive_strategy_candidate_15s,
    1000BONK/USDT:no_positive_strategy_candidate_15s

Что это означает:
- монеты были в watchlist;
- они не давали положительного кандидата;
- бот временно пропускал их;
- если их не ротировать, watchlist может зациклиться.

Правильная логика:
- soft skip запрещает вход, но не всегда должен сразу убивать наблюдение;
- если символ несколько циклов подряд не даёт кандидата, его нужно временно
  убрать из data basket;
- вместо него scanner должен взять новые монеты;
- forced bootstrap symbols не должны бесконечно держать один и тот же набор.

Пример:
Если 1000BONK три цикла подряд получает no_positive_strategy_candidate,
бот должен временно заменить его на другой сильный символ из top-ranked списка.


7. STRATEGY GATE
========================================================================

Strategy Gate определяет, какие стратегии сейчас разрешены.

Цитата из лога:

    STRATEGY GATE | warmup=grid_dca,trend_follow,breakout,reversal,
    liquidity_grab,squeeze_breakout,mean_reversion,momentum_scalping,
    pump_protection,funding_carry,liquidity_sweep_reversal,
    pullback_continuation,vwap_mean_reversion,
    funding_squeeze_contrarian,volatility_expansion_breakout

Что это означает:
- все эти стратегии доступны для оценки;
- warmup не означает автоматическую торговлю;
- каждая стратегия должна вернуть валидный intent;
- дальше intent проходит router, MTF, quality и risk.

Пример:
Если grid_dca включён, но по символу нет импульса или нет структуры, он может
вернуть no_valid_entry_intent. Тогда Router может выбрать breakout или вообще
не выбрать стратегию.


8. STRATEGY ROUTER
========================================================================

Strategy Router сравнивает стратегии между собой.

Цитата из лога по PLAY/USDT:

    STRATEGY ROUTER FALLBACK | PLAY/USDT |
    grid_score=0.00 reason=small_size -> selected=breakout score=14.61

Цитата из лога:

    STRATEGY ROUTER V2 | PLAY/USDT | selected=breakout |
    final_score=14.61 | raw_score=14.61 | entry_intents=1

Что это означает:
- grid_dca не подошёл;
- router выбрал breakout;
- был создан один entry intent.

Пример:
Если grid_dca не видит хороший setup, но breakout видит пробой, router может
переключиться на breakout. Но это не значит, что ордер будет отправлен сразу.
После Router идёт Entry Quality Guard.

Цитата по BSB/USDT:

    STRATEGY ROUTER NO_TRADE | BSB/USDT |
    reason=no_positive_strategy_candidate

Пример:
BSB был выбран как live candidate, но ни одна стратегия не дала финальный
валидный вход. Поэтому бот правильно отказался от сделки.


9. GRID DCA
========================================================================

Grid DCA — стратегия построения позиции частями.

Мои правила для Grid DCA:

- не входить просто потому, что цена упала;
- учитывать HTF/MTF;
- учитывать ATR;
- учитывать структуру рынка;
- не делать DCA против старшего таймфрейма;
- не превышать риск;
- не управлять чужой позицией;
- не добавляться, если структура сломана.

Цитата из отчёта:

    grid_dca ENABLED 1983 ev, 0 sig, 0 ent, 0 ord
    reason=warmup_not_enough_pnl_samples:0<20

Что это означает:
- стратегия включена;
- она наблюдает рынок;
- но у неё не было реальных входов;
- warmup/statistics ещё недостаточно для агрессивного доверия.

Пример:
Если grid_dca видит символ, но нет impulse setup или MTF конфликтует, он должен
возвращать no_valid_entry_intent, а не открывать позицию.


10. BREAKOUT
========================================================================

Breakout ищет пробой уровня.

Цитата из лога:

    BREAKOUT ENTRY | PLAY/USDT | side=long |
    qty=48.00000000 | price=0.11379 | score=1.169

Что это означает:
- breakout увидел long setup;
- стратегия создала entry intent;
- дальше этот intent пошёл на качество и риск.

Практический пример:
Breakout может быть прав по направлению, но вход всё равно может быть поздним.
Если RSI слишком высок или цена уже ушла, Entry Quality Guard блокирует сделку.


11. SQUEEZE BREAKOUT
========================================================================

Squeeze Breakout ищет выход из сжатия волатильности.

Цитата из лога:

    SQUEEZE BREAKOUT ENTRY | PLAY/USDT |
    side=long | qty=48.00000000 | bb_width=0.02922

Что это означает:
- squeeze_breakout увидел сжатие и попытку выхода;
- стратегия дала intent;
- Router сравнивает её с breakout и другими стратегиями.

Пример:
Если одновременно breakout и squeeze_breakout дают похожий сигнал, router
выбирает лучший вариант по score, regime и quality.


12. TREND FOLLOW
========================================================================

Trend Follow ищет продолжение тренда.

В логах бывает ситуация, когда raw_score высокий, но entry нет:

    trend_follow raw_score=100.0
    reason=no_valid_entry_intent

Что это означает:
- общий тренд может быть сильным;
- но конкретной безопасной точки входа нет;
- стратегия не должна входить просто по факту тренда.

Мой принцип:
Trend Follow должен входить только при подтверждённом продолжении, а не на
позднем импульсе.


13. MTF / HTF ФИЛЬТРЫ
========================================================================

MTF и HTF — ключевой слой точности.

Типовые причины отказа:

- htf_not_aligned;
- htf_neutral;
- htf_conflict;
- htf_conflict_score_too_low;
- htf_not_aligned_score_too_low.

Цитата из scheduled report:

    htf_conflict_score_too_low_53.0
    htf_not_aligned
    htf_neutral

Пример:
Если младший таймфрейм показывает импульс вверх, но старший таймфрейм против,
бот должен блокировать вход или снижать размер, а не открывать сделку полным
объёмом.

Мой принцип:
- HTF против — вход блокируется;
- HTF нейтрален — нужен сильный локальный импульс;
- HTF подтверждает — вход может идти дальше по цепочке.


14. ENTRY QUALITY GUARD
========================================================================

Entry Quality Guard защищает меня от плохих входов.

Он проверяет:

- RSI chase;
- spread;
- ATR extension;
- поздний импульс;
- premium/discount zone;
- pump/dump risk;
- slippage;
- состояние стакана.

Цитата из лога:

    ENTRY QUALITY GUARD BLOCKED | PLAY/USDT |
    score=54.0/74.0 | reason=long_rsi_chase_69.8 |
    ext_atr=1.439 | rsi=69.759

Что это означает:
- стратегия дала long;
- но RSI уже высокий;
- бот не должен догонять рынок;
- вход был правильно заблокирован.

Другая цитата:

    ENTRY QUALITY GUARD BLOCKED | PLAY/USDT |
    score=15.0/74.0 |
    reason=spread_too_high_0.8787_gt_0.1600

Что это означает:
- spread слишком высокий;
- даже при сигнале вход нельзя считать качественным.

Пример, где quality не блокирует полностью, а уменьшает размер:

    ENTRY QUALITY SIZE REDUCED | PLAY/USDT |
    52.13257027 -> 18.24639959 |
    mult=0.35 | reason=pump_dump_early_momentum_capture

Что это означает:
- импульс есть;
- риск повышенный;
- бот уменьшил размер;
- это сохраняет возможность заработать, но снижает риск.


15. RISK GUARD
========================================================================

Risk Guard защищает капитал.

Он проверяет:

- долю ордера от баланса;
- риск по символу;
- общий риск портфеля;
- minNotional;
- stepSize;
- количество открытых позиций;
- DCA/add-on limits.

Цитата из Telegram/логики, которую я разбирал ранее:

    RISK GUARD BLOCKED 1000LUNC/USDT
    Reason: max_symbol_exposure(6.00%>4.00%)
    New notional: 6.6000

Практический пример:
Баланс около 110 USDT. Минимальный валидный ордер Binance может быть 6.60 USDT,
то есть около 6% баланса. Если базовый лимит 4%, бот будет блокировать даже
минимальный вход.

Моё решение:
- базовый лимит остаётся безопасным;
- для первого минимального входа разрешается dynamic minNotional exception;
- если баланс вырастает, процент автоматически снижается;
- DCA не получает автоматическое расширение.

Пример:
Баланс 110 USDT, ордер 6.60 USDT = 6%.
Базовый лимит 4%.
Динамический лимит может временно разрешить первый минимальный вход.

Но если ордер занимает 9%, а hard cap 7.5%, он должен быть заблокирован.


16. EXECUTOR И MIN NOTIONAL
========================================================================

Executor исполняет уже проверенные решения.

Цитата из лога:

    Executor | allowed=1 | create=1 | cancel=0 | blocked=0 | adjusted=1 |
    reasons={'PLAY/USDT:...':
    'auto_raised_to_min_notional:2.0758->6.6000 target=6.6000'}

Что это означает:
- стратегия дала маленький размер;
- quality guard уменьшил его ещё сильнее;
- Binance minNotional требовал минимум;
- executor поднял размер до 6.60 USDT.

Цитата из Binance final check:

    Min notional final check | PLAY/USDT |
    qty=58.00000000 | price=0.11376000 |
    final_notional=6.59808000 | min_notional=5.00000000

Вывод:
Executor должен уметь поднимать ордер до minNotional, но это должно быть
согласовано с Risk Guard.


17. ОРДЕР НА ВХОД И PENDING ENTRY
========================================================================

Мой бот использует maker-first подход, когда это возможно.

Цитата из лога:

    ADVANCED ORDER EXECUTOR | status=ok |
    policy={'maker_first': True, 'max_market_entry_notional_pct': 1.25,
    'max_slippage_pct': 0.18}

Цитата из лога:

    Создание ордера | PLAY/USDT | side=buy | type=LIMIT |
    qty=58.0 | price=0.11376 | reduce=False

Цитата:

    Ответ по ордеру | PLAY/USDT | status=NEW |
    executed=0.000000 | avgPrice=0.000000

Цитата:

    ENTRY PENDING REGISTERED | PLAY/USDT |
    id=1112311183 | cid=PLAYUSDT_BRK_ENT_e2f7e6

Что это означает:
- бот не вошёл market-ордером вслепую;
- он поставил LIMIT;
- ордер зарегистрирован как pending;
- дальше pending guard должен следить за валидностью сигнала.

Pending entry должен отменяться, если:
- сигнал исчез;
- цена ушла далеко;
- стратегия изменилась;
- символ стал неактивным;
- истёк TTL;
- появился риск ухудшения.


18. DEDUPLICATION
========================================================================

Dedup защищает от повторных ордеров.

Цитата из лога:

    SIGNAL DEDUP SKIP | PLAY/USDT |
    reason=signal_dedup_20.0_lt_60.0

Цитата:

    ORDER RECENT DEDUP SKIP | PLAY/USDT |
    reason=recent_duplicate_order_13.7_lt_45.0

Что это означает:
- сигнал уже был недавно;
- ордер уже создавался недавно;
- бот не должен спамить Binance повторными входами.

Пример:
Если PLAY/USDT даёт одинаковый breakout каждые 8 секунд, бот не должен каждые
8 секунд создавать новый ордер.


19. LIVE GATE И AUTO MODE
========================================================================

Auto Mode определяет, можно ли торговать.

Цитата из лога:

    AUTO MODE | mode=REAL_FUTURES_LIVE |
    entries=True | dca=True | score=100.0

Цитата:

    LIVE GATE | entries_allowed=True |
    exploration=False | dca=True | score=100.0 | ok

Что это означает:
- режим реальной торговли активен;
- входы разрешены;
- DCA разрешён;
- Live Gate не блокирует.

Если Safety деградирует, бот должен переходить в reduce-only:
- новые входы запрещены;
- DCA запрещён;
- TP/close/reduce-only остаются разрешены.


20. SAFETY И CIRCUIT
========================================================================

Safety следит за состоянием системы.

Цитата из scheduled report:

    status=normal reason=ok api_errors=0 order_errors=0 market_age=21.3s
    circuit=normal allow_entries=True allow_dca=True reduce_allowed=True reason=ok

Что это означает:
- Safety нормальный;
- Circuit нормальный;
- входы разрешены;
- DCA разрешён;
- reduce-only разрешён;
- ошибок API и order errors нет.

Пример:
Если safety normal, но сделок нет, проблема не в safety. Тогда нужно смотреть
scanner, strategy router, quality guard, risk guard и stream freshness.


21. POSITION OWNERSHIP
========================================================================

Я использую принцип ownership:

Позиция принадлежит стратегии, которая её открыла.

Цитата из startup/runtime лога:

    MIGRATION | 0001_owner_strategy_isolation | applied=True
    STRATEGY OWNERSHIP RELOADED AFTER MIGRATIONS

Что это означает:
- бот хранит owner_strategy;
- после перезапуска ownership восстанавливается;
- стратегия не должна управлять чужой позицией.

Пример:
Если PLAY/USDT открыл breakout, grid_dca не должен ставить свои DCA/TP поверх
этой позиции без owner-management разрешения.


22. TP / TAKE PROFIT
========================================================================

После открытия позиции бот должен создать TP-план.

Главное правило:

    Суммарный reduce-only объём всех TP не должен превышать размер позиции.

Пример правильного TP для позиции 24:

    TP1 = 12
    TP2 = 12
    Итого = 24

Пример неправильного TP:

    TP1 = 12
    TP2 = 12
    TP_MARKET = 12
    Итого = 36 на позицию 24

Почему это плохо:
- Binance может отклонять reduce-only;
- бот может получать reduceOnly position absent;
- TP coverage становится больше позиции;
- возможны конфликты стратегий.

Цитата из 24H verdict:

    tp_bootstrap_skip_recent_grace: 551
    tp_protection_recent_submit_grace: 256
    tp_bootstrap_skip_existing_valid: 148

Что это означает:
- бот уже имеет защиту от слишком частого пересоздания TP;
- если TP недавно поставлен или уже валиден, bootstrap должен его не трогать.

Мой принцип:
TP должен быть выше breakeven, учитывать комиссии, tickSize, stepSize и не
превышать размер позиции.


23. DCA / ADD-ON
========================================================================

DCA должен быть осторожным.

Я не считаю DCA спасением плохого входа. DCA — это управляемое добавление к
позиции, если структура рынка остаётся живой.

DCA запрещается, если:
- HTF против;
- структура сломана;
- owner mismatch;
- risk exceeded;
- market shock;
- spread высокий;
- orderbook stale;
- safety degraded;
- нет свежих данных.

DCA разрешается, если:
- позиция принадлежит этой стратегии;
- MTF/HTF не против;
- риск позволяет;
- DCA не ломает общий exposure;
- данные свежие.


24. PROTECTION И CLEANUP
========================================================================

У меня есть несколько защитных сервисов:

- Protective Order Sweeper;
- Position Protection Watchdog;
- Profit Protection;
- Dynamic Exit Planner;
- Cleanup Worker;
- Execution Auditor.

Цитаты из лога:

    DYNAMIC EXIT OK | positions=0

    PROFIT PROTECTION OK | positions=0

    POSITION CLOSE CLEANUP CHECK | no stale protective orders |
    open_positions=none | open_orders=0

Что это означает:
- даже когда позиций нет, бот проверяет, нет ли старых защитных ордеров;
- cleanup не должен оставлять trailing/TP после закрытия позиции;
- старый reduce-only ордер не должен закрыть будущую позицию.

Мой принцип:
После закрытия позиции все stale TP/trailing/conditional ордера должны быть
удалены и подтверждены через Binance.


25. ПОЧЕМУ БОТ МОЖЕТ МАЛО ТОРГОВАТЬ
========================================================================

Цитата из 24H verdict:

    entry_rejected: 14277
    strategy_candidate_lab_v2_90_positive: 4184
    strategy_router_v2: 1857
    entry_quality_guard_v121: 392

Цитата из TOP REASONS:

    no_positive_strategy_candidate: 3479
    selected_none: 3139
    risk_limit: 783
    ok;auto_mode_reduce_only: 726

Что это означает:
- бот видел много кандидатов;
- большая часть не прошла финальные фильтры;
- причины не всегда плохие: они показывают, где бот защищается;
- если входов слишком мало, нужно улучшать scanner/refill/rotation/risk harmonizer,
  но не отключать quality guard.

Цитата из scheduled report:

    Топ этапов отклонения:
      temp_skip_pre_mtf 197
      coin_selection 85
      strategy_decide 62
      mtf_entry_filter 7

Вывод:
Большая часть отказов была до финального ордера. Значит проблема не только
в executor, а в выборе символов, MTF и strategy router.


26. ПРИМЕР ПОЛНОГО РЕШЕНИЯ ПО PLAY/USDT
========================================================================

Реальный пример из логов:

1. Scanner выбрал PLAY/USDT:

    STRATEGY-FIRST SCAN | live=PLAY/USDT, RENDER/USDT, BSB/USDT

2. Coin selector подтвердил:

    Coin selection v4 | selected=RENDER/USDT, BSB/USDT, PLAY/USDT

3. Router выбрал breakout:

    STRATEGY ROUTER V2 | PLAY/USDT | selected=breakout |
    final_score=14.61 | entry_intents=1

4. Quality Guard сначала заблокировал плохой вход:

    ENTRY QUALITY GUARD BLOCKED | reason=long_rsi_chase_69.8

5. Позже вход был уменьшен по размеру:

    ENTRY QUALITY SIZE REDUCED | mult=0.35 |
    reason=pump_dump_early_momentum_capture

6. Executor поднял размер до minNotional:

    auto_raised_to_min_notional:2.0758->6.6000

7. Binance final check прошёл:

    final_notional=6.59808000 | min_notional=5.00000000

8. Ордер был создан:

    Создание ордера | PLAY/USDT | side=buy | type=LIMIT

9. Ордер получил статус NEW:

    Ответ по ордеру | PLAY/USDT | status=NEW

10. Бот зарегистрировал pending entry:

    ENTRY PENDING REGISTERED | PLAY/USDT

Вывод:
Это правильная цепочка. Бот не вошёл вслепую. Он сначала несколько раз
заблокировал плохой вход, потом уменьшил размер, проверил minNotional и только
после этого поставил LIMIT ордер.


27. МОЯ ЦЕЛЕВАЯ АРХИТЕКТУРА
========================================================================

Моя целевая архитектура:

    Market universe: 500–580 symbols
    Scanner candidates: 40
    Data-active basket: 8–10 symbols
    Entry-live basket: максимум 3 symbols
    Open positions: максимум 3
    Risk per symbol: безопасный базовый процент
    Dynamic minNotional exception: только для первого минимального входа
    DCA: только если структура жива и risk позволяет
    TP: покрытие не больше позиции
    Cleanup: после закрытия позиции обязательно
    Safety degraded: только reduce-only

Идеальный режим:

- бот смотрит 8–10 символов;
- реально торгует не больше 3;
- не открывает плохие входы;
- не догоняет поздний импульс;
- не превышает риск;
- быстро защищает позицию TP;
- чистит все лишние ордера после закрытия;
- stream сам восстанавливается;
- Telegram не влияет на торговлю.


28. КРАТКОЕ РЕЗЮМЕ
========================================================================

Мой бот — это многоуровневая торговая система.

Scanner выбирает рынок.
Router выбирает стратегию.
Strategy создаёт intent.
MTF подтверждает направление.
Quality Guard защищает от плохого входа.
Risk Guard защищает капитал.
Executor отправляет ордер.
Owner Strategy управляет позицией.
TP/DCA/Protection защищают прибыль.
Sweeper/Cleanup удаляют опасные остаточные ордера.
Safety переводит систему в reduce-only при деградации.
Telemetry/Telegram/Web дают контроль и диагностику.

Главный принцип:

Я хочу, чтобы бот видел рынок широко, но торговал ограниченно и точно:

    8–10 активных символов для наблюдения,
    до 3 одновременных сделок,
    без ослабления точности входа,
    с обязательной защитой позиции и очисткой ордеров.


Пока финиш!!!!

Разработка уже торгует на реальном рынке!!!

 

Edited by rottor29
Патч и улучшения в работе
Posted

@rottor29

Нарушение 3.2
У вас уже есть тема про это, пишите только в ней.  Перемещено. Последний пост, созданный как отдельная тема, прицеплен к основной.
Если вы делаете новый пост, и вдруг форум требует придумать к нему заголовок— значит, вы нажали что-то не то и создаете новую тему.
Самое простое: внизу вашей темы окно для набива сообщения. Пишем там (ну или аккуратно копипастим—убивая форматирование), нажимаем Отправить — все ок

 

Posted

Ну надо признать, весьма недурно. Тут, правда, не так много людей кто в состоянии оценить масштаб разработки, для этого надо быть глубоко в теме, но в целом весьма грандиозно. 

Даже я в своей реализации далеко не до всего описанного дошёл, когда подобным занимался.

Где-то, правда и дальше ушёл ( у меня был полноценный тестер стратегий на тиковых данных в 2007 году, когда компы были в большинстве одноядерными и медленными, но даже сейчас на питоне это будет затруднительно сделать) + донабор профитных позиций.

 

Минус всей этой грандиозности только один - вкладываться в автоматизацию надо того, что уже имеет зарабатывать. Иначе построив его и потратив месяцы/годы жизни можно обнаружить, что денег он особ не приносит.

Скажем так, если у когото есть профитаня стратегия, ему не нужно стоить такой универсальный комбайн, он быстро сделает бюджетный инструмент, который будет сразу приносить деньги.

 

Иначе говоря, сначала надо иметь прибыльные стратегии, потом уже их автоматизировать по -быстрому (это 1x временных затрат), потом переводить на автономность (это 10x временных затрат), потом уже полная автономность (это ??x временных затрат).

Posted

Спасибо за такую оценку. Ты очень точно уловил суть: проект действительно получился уже не просто “ботом”, а попыткой собрать полноценную автономную торговую инфраструктуру — со сканером рынка, сопровождением позиций, стратегическим роутером, безопасностью, журналами, восстановлением состояния, работой с ордерами, MTF, стаканом, whale-flow, TP/DCA/exit-plan и прочим.

И да, я полностью согласен с главным риском: автоматизировать ради автоматизации опасно. Можно построить огромный комбайн, потратить месяцы или годы, а потом выяснить, что сам торговый edge слабый или нестабильный. Поэтому я тоже постепенно прихожу к мысли, что ядро должно быть не в количестве функций, а в проверяемой прибыльности стратегий.

Моя логика сейчас такая:

1. Сначала добиться, чтобы бот технически работал правильно: не терял позиции, не оставлял старые ордера, не дублировал входы, корректно сопровождал TP, trailing, DCA, exit-plan, умел восстанавливаться после перезапуска и правильно работал с биржевыми ограничениями.

2. Затем через журналы, отчёты, shadow-режимы и тесты отделить реально перспективные стратегии от шума.

3. После этого уже усиливать только те стратегии, которые показывают живую устойчивость, а не пытаться заставить торговать всё подряд.

При этом это уже не просто теоретическая разработка и не тестовый проект “на бумаге”. Бот уже работает на реальном рынке и оттачивается на реальных сделках, пусть пока и в режиме постоянной доработки и контроля. Именно реальный рынок быстро показывает то, чего не видно в тестах: зависшие ордера, нюансы reduce-only, TP, условные ордера, лимиты Binance, рассинхрон состояния после перезапуска, проблемы WebSocket, сопровождение открытых позиций и реакцию стратегий на живую волатильность. Поэтому сейчас система проходит не только лабораторную проверку, а полноценную боевую обкатку.

Я понимаю, что если есть уже готовая прибыльная ручная стратегия, то под неё действительно проще быстро написать узкий инструмент и начать зарабатывать. Универсальная автономная система — это совсем другой уровень временных затрат и сложности. Она имеет смысл только если задача не просто “автоматизировать одну стратегию”, а построить платформу, которая может выбирать, проверять, сопровождать и адаптировать разные подходы в реальном рынке.

Поэтому для меня сейчас главный вопрос не “сколько ещё функций добавить”, а “какие из стратегий реально имеют edge, и как это доказать без самообмана”. Автономность ради автономности мне не нужна. Мне нужна система, которая сначала безопасно и прозрачно проверяет гипотезы, а уже потом масштабирует то, что действительно работает.

И да, насчёт тикового тестера — это отдельный уровень. Особенно если делать реалистично: очередь заявок, проскальзывание, стакан, частичное исполнение, задержки, ликвидность, комиссии. На Python это можно сделать, но придётся очень аккуратно проектировать, иначе производительность быстро станет проблемой. Тут у тебя, конечно, очень сильный опыт, особенно если ты делал полноценный тиковый тестер ещё в 2007 году.

В общем, я с тобой согласен: правильная последовательность такая:

прибыльная идея / стратегия
→ быстрая автоматизация
→ проверка на реальном/приближенном рынке
→ только потом автономность
→ и только потом универсальная платформа

Я, возможно, пошёл более сложным путём, потому что параллельно строю не только торговую стратегию, но и инфраструктуру вокруг неё. Это дольше, зато потом будет проще тестировать и подключать разные стратегии без постоянного переписывания всего бота. Но я хорошо понимаю, что инфраструктура сама по себе денег не делает. Деньги делает только рабочий edge.
 

 

11 часов назад, rottor29 сказал:

Ниже — описание последних доработок проекта простым языком, 

Проект продолжает развиваться как автономный торговый бот для Binance Futures. Это уже не просто набор индикаторов или обычная DCA-сетка, а полноценная система сопровождения сделок, выбора стратегии, контроля открытых ордеров, восстановления состояния после перезапуска и адаптации к текущему рынку.

Главная цель последних изменений — сделать входы точнее, сопровождение позиций надёжнее, а работу с активными монетами более динамической и приближённой к реальному рынку.

1. Доработка main.py и защитного слоя ордеров

В предыдущей версии часть важных компонентов уже была в архиве, но не была полностью встроена в основной main.py. Я отдельно проверил это и доинтегрировал недостающие части.

Главное исправление — подключён ProtectiveOrderSweeper.

Это отдельный защитный слой, который постоянно сверяет реальные открытые ордера на Binance с активными позициями. Его задача — не допустить ситуации, когда позиция уже закрыта, а на бирже всё ещё висит условный ордер, trailing-stop, TP или другой reduce-only ордер.

Теперь бот должен регулярно проверять:

- есть ли позиция по символу;
- какие ордера реально открыты на Binance;
- относятся ли эти ордера к активной позиции;
- не остались ли «осиротевшие» условные ордера после закрытия позиции;
- нужно ли отменить лишние protective / conditional / reduce-only ордера.

Это особенно важно для реальной торговли, потому что оставшийся после закрытия позиции trailing-stop или stop-market ордер может потом неожиданно сработать и открыть/закрыть то, чего уже не должно быть.

Также в main.py были возвращены недостающие методы ownership-журнала:

- загрузка strategy ownership;
- сохранение strategy ownership;
- восстановление стратегии-владельца позиции/ордера.

Это нужно, чтобы после перезапуска бот понимал, какая стратегия открыла позицию и какая стратегия должна её сопровождать.

2. Синхронизация config.yaml и settings.py

Была найдена проблема: в config.yaml уже присутствовали многие настройки, но config/settings.py их не читал. Из-за этого визуально в конфиге параметр был, но реально бот использовал fallback-значения из кода.

Исправлено чтение настроек для:

- protective_order_sweeper;
- event_driven_runtime;
- strategy_first;
- warmup;
- orderbook;
- TP / cleanup / conditional order cleanup;
- position protection;
- pre-entry symbol guard.

Это важно, потому что теперь параметры из YAML действительно управляют поведением бота, а не просто лежат в конфиге «для вида».

3. Strategy MTF Precision Layer

Следующий крупный слой — усиление стратегий через multi-timeframe confirmation.

Бот теперь использует разные таймфреймы для разных задач:

- 1d — общий рыночный режим;
- 4h — основное направление;
- 1h — подтверждение структуры;
- 30m — структура сетапа;
- 15m — рабочий вход;
- 5m — точная точка входа и раннее предупреждение.

Логика простая:

старшие таймфреймы говорят, куда можно торговать;
младшие таймфреймы говорят, когда именно входить.

Добавлен общий MTF-verdict для стратегий. Он проверяет, не пытается ли стратегия входить полностью против старших таймфреймов и есть ли подтверждение на младших.

MTF-фильтр подключён к основным стратегиям:

- TrendFollow;
- Breakout;
- SqueezeBreakout;
- MomentumScalping;
- LiquidityGrab;
- MeanReversion;
- ReversalTrap;
- FundingCarry;
- LiquiditySweepReversal;
- PullbackContinuation;
- VWAP Mean Reversion;
- Funding Squeeze Contrarian;
- Volatility Expansion Breakout.

GridDCA также усилен отдельно. Теперь он учитывает младшие таймфреймы и может блокировать вход, если 5m и 15m одновременно против сделки.

Это должно уменьшить количество входов «на излёте движения» и уменьшить случаи, когда бот входит слишком рано или слишком поздно.

4. Strategy Intelligence Layer

После MTF-слоя был добавлен более общий слой — Strategy Intelligence Layer.

Идея в том, что стратегии не должны просто смотреть на индикаторы и сразу давать сигнал. Каждая стратегия должна понимать, подходит ли ей текущий рыночный режим.

Например:

- TrendFollow должен работать в тренде;
- Breakout — в пробое или сжатии;
- MeanReversion — в боковике или слабом тренде;
- LiquidityGrab / ReversalTrap — после выноса ликвидности и возврата;
- FundingCarry — только если funding имеет смысл и структура рынка не против;
- GridDCA — только если структура позиции ещё жива.

Для стратегий добавлены профили:

- INTELLIGENCE_PROFILE;
- ALLOWED_REGIMES;
- EXIT_STYLE.

Перед входом стратегия теперь проходит общий intelligence gate. Он оценивает:

- режим рынка;
- MTF-подтверждение;
- spread;
- ATR / волатильность;
- качество setup;
- confidence;
- примерный reward/risk proxy.

Важно: это не означает обязательное использование стоп-лосса. Expected RR здесь используется как фильтр качества входа, а не как жёсткая SL/TP-схема.

Router тоже усилен. Теперь он может видеть, почему конкретная стратегия была пропущена или заблокирована. Это позволит в логах видеть не просто «нет входа», а конкретную причину:

- неподходящий режим;
- недостаточное MTF-подтверждение;
- плохой spread;
- слишком высокая волатильность;
- слабый setup;
- низкая confidence;
- слабое соотношение ожидаемой прибыли к риску.

5. Отдельное усиление GridDCA

GridDCA больше не должен усреднять позицию просто потому, что цена ушла в минус.

Добавлены дополнительные блокировки:

- DCA требует, чтобы структура позиции была ещё жива;
- DCA блокируется, если HTF стал против позиции;
- DCA проверяет младшие таймфреймы;
- DCA не должен быть способом спасать плохой вход.

Это важное изменение, потому что в реальной торговле DCA опасен, если он включается механически по просадке. Теперь идея такая:

DCA — это не спасение плохой сделки, а заранее разрешённый элемент стратегии, который допускается только пока рыночная структура не сломана.

6. Dynamic Active Fast Timeframes

Так как активные монеты на Binance постоянно меняются, быстрые таймфреймы нельзя включать для всех 500+ инструментов. Это создаёт лишнюю нагрузку, шум, ложные сигналы и проблемы со стабильностью потоков.

Поэтому добавлен динамический слой быстрых таймфреймов.

Основная логика:

- весь рынок анализируется на старших/средних таймфреймах;
- Coin Selector / Strategy Router выбирает активные монеты;
- только для этих активных монет включаются быстрые TF;
- если есть открытая позиция или pending order — быстрые TF сохраняются;
- если монета выпала из активных, она не отключается мгновенно, а держится через grace-period.

Добавлены быстрые таймфреймы:

- 3m;
- 1m.

Но они не включаются на весь рынок. Они используются только для:

- активных кандидатов;
- открытых позиций;
- pending entry ордеров;
- open orders, которые требуют сопровождения.

Это даёт более точные входы и выходы без перегрузки WebSocket/REST-инфраструктуры.

7. Почему это важно для реальной торговли

Все эти изменения направлены на переход от простого «бота по индикаторам» к более реальной торговой системе.

Теперь логика становится ближе к профессиональной схеме:

1. Сначала определяется рыночный режим.
2. Потом выбираются стратегии, которые подходят именно этому режиму.
3. Потом проверяется MTF-контекст.
4. Потом ищется setup.
5. Потом младшие TF дают точный trigger.
6. Перед входом проверяются spread, ATR, ликвидность и качество сигнала.
7. После входа позиция сопровождается той стратегией, которая её открыла.
8. Открытые ордера сверяются с реальными позициями на Binance.
9. Осиротевшие conditional / TP / trailing / reduce-only ордера должны автоматически убираться.
10. Быстрые 1m/3m таймфреймы включаются только там, где они действительно нужны.

8. Итог

Последние изменения можно коротко описать так:

- main.py доинтегрирован;
- ProtectiveOrderSweeper подключён;
- config.yaml и settings.py синхронизированы;
- добавлен MTF Precision Layer;
- добавлен Strategy Intelligence Layer;
- стратегии получили режимные фильтры;
- Router стал умнее и подробнее логирует причины решений;
- GridDCA стал безопаснее;
- добавлены динамические быстрые таймфреймы 3m/1m только для активных монет;
- бот стал лучше подготовлен к работе на реальном рынке, где активные инструменты постоянно меняются, а ордера и позиции должны строго синхронизироваться с Binance.

Главная идея всех изменений:

бот не должен просто «искать сигнал»;
бот должен понимать контекст рынка, выбирать подходящую стратегию, точно входить, сопровождать позицию своей логикой и постоянно контролировать реальные ордера на бирже.
 

Posted

Хочется поддержать топикстартера. Как человек тоже проектирующий и реализующий торговые скрипты могу сказать, что вы замахнулись на колоссальнейший объем,
т.к. за каждой строчкой такого гигантского ТЗ может стоять не одна неделя физической разработки и тестирования. А строчек у вас ну совсем немало.

Вижу правильным начинать именно с тестеров, чтобы выделить для себя действительно перспективные направления (стратегии) для будущей разработки.
Потому что тестер написать значительно легче, чем реально работающий на бирже механизм, а увидите вы на нем значительно больше и быстрее, чем в реальном времени.

Причем не обязательно вшивать в тестер проскальзывания и делать его тиковым. Порой даже без учета этого всего становится видно, имеет ли идея шансы на то, чтобы выстрелить. 
Если не делать тестеры своих звеньев, то не понятно, как вы будете оценивать результативность вашей торговой системы. И как проверять, что она действительно работает?

В общем я бы начал с тестирования каких-то основных концепций из вашего ТЗ. Потом бы (внутри тестера же) наращивал дополнительную фильтрацию и когда будут плюс-минус положительные результаты, 
уже воплощал бы это дело в коде для реальной торговли.   

И еще вопрос к вам. 
В какой реально стадии сейчас находится ваша разработка? Что-то уже есть кроме ТЗ?

Какие автоматизации вы уже писали?
 

Posted
17 часов назад, Criptano сказал:

Хочется поддержать топикстартера. Как человек тоже проектирующий и реализующий торговые скрипты могу сказать, что вы замахнулись на колоссальнейший объем,
т.к. за каждой строчкой такого гигантского ТЗ может стоять не одна неделя физической разработки и тестирования. А строчек у вас ну совсем немало.

Вижу правильным начинать именно с тестеров, чтобы выделить для себя действительно перспективные направления (стратегии) для будущей разработки.
Потому что тестер написать значительно легче, чем реально работающий на бирже механизм, а увидите вы на нем значительно больше и быстрее, чем в реальном времени.

Причем не обязательно вшивать в тестер проскальзывания и делать его тиковым. Порой даже без учета этого всего становится видно, имеет ли идея шансы на то, чтобы выстрелить. 
Если не делать тестеры своих звеньев, то не понятно, как вы будете оценивать результативность вашей торговой системы. И как проверять, что она действительно работает?

В общем я бы начал с тестирования каких-то основных концепций из вашего ТЗ. Потом бы (внутри тестера же) наращивал дополнительную фильтрацию и когда будут плюс-минус положительные результаты, 
уже воплощал бы это дело в коде для реальной торговли.   

И еще вопрос к вам. 
В какой реально стадии сейчас находится ваша разработка? Что-то уже есть кроме ТЗ?

Какие автоматизации вы уже писали?
 

Фактически рабочая стадия без ошибок кода.

Технически готовый к демо торговли последняя версия патча (не финальная).

Одна из версий тестируется на реальной торговле с минимальным балансом.

Posted
18 часов назад, Criptano сказал:

Хочется поддержать топикстартера. Как человек тоже проектирующий и реализующий торговые скрипты могу сказать, что вы замахнулись на колоссальнейший объем,
т.к. за каждой строчкой такого гигантского ТЗ может стоять не одна неделя физической разработки и тестирования. А строчек у вас ну совсем немало.

Вижу правильным начинать именно с тестеров, чтобы выделить для себя действительно перспективные направления (стратегии) для будущей разработки.
Потому что тестер написать значительно легче, чем реально работающий на бирже механизм, а увидите вы на нем значительно больше и быстрее, чем в реальном времени.

Причем не обязательно вшивать в тестер проскальзывания и делать его тиковым. Порой даже без учета этого всего становится видно, имеет ли идея шансы на то, чтобы выстрелить. 
Если не делать тестеры своих звеньев, то не понятно, как вы будете оценивать результативность вашей торговой системы. И как проверять, что она действительно работает?

В общем я бы начал с тестирования каких-то основных концепций из вашего ТЗ. Потом бы (внутри тестера же) наращивал дополнительную фильтрацию и когда будут плюс-минус положительные результаты, 
уже воплощал бы это дело в коде для реальной торговли.   

И еще вопрос к вам. 
В какой реально стадии сейчас находится ваша разработка? Что-то уже есть кроме ТЗ?

Какие автоматизации вы уже писали?
 

Архитектура бота

file_0000000057d0720a9b4a2e915246c53b.png

Posted (edited)

Продаю с последующей поддержкой обновлений!

Пока не вышел на уровень постоянного дохода от бота !

После выше перечисленного распространяется не будет!

Предложения и пожелания в личку!

Edited by rottor29

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Topics

    • Опенсорсный бот, который исполняет торговые команды на бирже. Ключи остаются только у вас

      Привет, форум. Мы сделали небольшого бота: он крутится у вас на ПК или сервере, по защищённому веб-сокету принимает торговые команды от ваших стратегий и исполняет их на бирже вашими ключами. Код полностью открыт: gitlab.com/veskald/veskald-execution-bridge   Зачем мы его сделали. У системного трейдера с исполнением всегда было два плохих варианта. Либо жать кнопки руками: ночные входы просыпаются, в момент сделки дрожит рука, стоп «забывается». Либо отдать биржевые ключ

      in Софт для трейдинга

    • Торговый бот hamster-bot и портфельный бэктест

      Бот для бирж BitMEX, FTX, Bybit, Binance, Huobi, OKX, HTX, Kucoin, Phemex, MEXC, Bitget, BingX. (список пополняется) Проект hamster-bot является официальным партнером биржи BitMEX    https://blog.bitmex.com/ru_ru-bitmex-x-hamster-bot-automated-trading-with-just-a-few-clicks/  А также официальный партнер (список ссылок на пруфы) FTX, Bybit, official Binance API broker, Phemex_1, Phemex_2, Bitget_1, Bitget_2, Huobi HTX Сайт https://hamster-bot.com/  Telegram канал https://t.me/

      in Маржинальная торговля

    • MarMon: Автоматизация фьючерсной торговли с умным управлением капиталом.

      Я разработал и реализовал собственную торговую систему — это умный торговый робот, который работает полностью автономно и берёт на себя все рутинные задачи по торговле на бирже. По сути, это личный финансовый аналитик, который не спит, не устаёт и не поддаётся эмоциям. Как работает моя система: подробно о каждом этапе 1. Подготовка и отбор активов (Whitelist) Система не торгует всеми монетами подряд. На первом этапе проводится глубокий анализ всего рынка, после чего формируется «б

      in Софт для трейдинга

    • Торговый бот по ошибке перевел неизвестному инвестору 167 эфиров

      В сети Эфириум торговый бот по ошибке отправил неизвестному пользователю 167 ETH стоимостью около $300 000. На странную транзакцию обратили внимание специалисты блокчейн-платформы PeckShield. Причиной перевода стала ошибка в алгоритме бота либо некорректная настройка параметров, предположили ончейн-аналитики. Вместо целевого смарт-контракта средства были отправлены на случайный адрес. Речь идет о программном сбое, а не о взломе, подчеркнули специалисты по безопасности.   Владелец бота

      in Новости криптовалют

    • Биржи в США выступили против упрощенной торговли токенизированными акциями

      Комиссия по ценным бумагам и биржам США (SEC) отложила начало применения «инновационного исключения» (innovation exemption) к торговле токенизированными акциями. Исключение позволило бы выпускать токенизированные акции без ведома компании-эмитента акции и торговать ими на любых криптоплатформах. SEC планировала запустить «инновационное исключение» уже на днях. Однако сроки сдвинуты после консультаций с руководителями фондовых бирж, узнали журналисты Bloomberg. Разногласия возникли вокруг в

      in Новости криптовалют

×
×
  • Create New...