docs: prediction-market documentation (en/ru/zh-CN)

@l10n/ru/docs/advanced/hardfork-management.md

@@ -48,6 +48,8 @@ VIZ Ledger координирует обновления протокола че
 | 10 | Модель инфляции |
 | 11 | Изменения модели эмиссии |
 | 12 | Аварийное восстановление консенсуса (см. ниже) |
+| 13 | Длина эпохи распределения (`chain_properties_hf13`) |
+| 14 | Прогнозные рынки (Onix): 18 операций + 7 виртуальных, CPMM/LMSR, паримутюэль-расчёт, оракулы, споры, commit-reveal, lazy-пул; chain properties v5 |
 
 ---
 

@l10n/ru/docs/consensus/emergency-consensus.md

@@ -151,9 +151,9 @@ real_witness_slots >= CHAIN_MAX_VALIDATORS × 75%
 | Механизм | Поведение в экстренном режиме |
 |----------|-------------------------------|
 | `resync_from_lib()` | **Полностью пропускается** — извлечение блоков вблизи LIB в экстренном режиме приведёт к сбою |
-| `stale_sync_check_task()` | Если голова мастера продвигается → сбросить таймер, пропустить восстановление; если голова последователя застряла → разрешить восстановление |
+| `check_wedge_watchdog()` | **Отдельной ветки под экстренный режим нет.** Взводится только когда голова заморожена далеко ниже *подтверждённой* вершины сети (вторая по высоте голова среди установленных пиров), любое продвижение головы сбрасывает таймер. Только лог, если не выставлен `auto-resync-on-wedge = true` — тогда подтверждённый клин завершает ноду |
 | `handle_block()` (DLT, режим синхронизации, разрыв 0–2) | Обрабатывается как нормальный (не синхронизация) для предотвращения нарушения цикла производства |
-| Обнаружение зависшей синхронизации снимков | Та же логика, что и проверка зависшей синхронизации |
+| Обнаружение зависшей синхронизации снимков (`enable-stalled-sync-detection`, по умолчанию выключено) | **Именно здесь и живёт разделение мастер/последователь.** По таймауту читается `emergency_consensus_active`; если мы — экстренный мастер (держим экстренный ключ и комитет в расписании), соло-производство блоков нормально, и восстановление пропускается. Застрявшему последователю восстановление разрешено |
 
 Защита `resync_from_lib()` наиболее критична: в экстренном режиме LIB близок к HEAD. Извлечение блоков до LIB и сброс fork DB привели бы к тому, что блоки пиров из реальной сети связываются с повторно заполненным LIB, запуская переключение форка, извлечение ниже зафиксированного LIB и либо сбой, либо повреждение состояния.
 
@@ -196,7 +196,7 @@ real_witness_slots >= CHAIN_MAX_VALIDATORS × 75%
 | 6 | `maybe_produce_block` (мастер) | Обходить синхронизацию, устаревание, участие; пропускать minority fork |
 | 7 | `maybe_produce_block` (последователь) | Сначала синхронизироваться; 21-блочная проверка изоляции |
 | 8 | `resync_from_lib` | **Полностью пропускать** в экстренном режиме |
-| 9 | `stale_sync_check_task` | Пропустить если голова мастера продвигается; разрешить если последователь застрял |
+| 9 | `check_wedge_watchdog` | Ветки под экстренный режим нет; от ложного взвода защищают подтверждение вершины и сброс при продвижении головы |
 | 10 | `handle_block` | Почти догнавшие блоки обрабатываются как нормальные в DLT-экстренном режиме |
 | 11 | `database::open` | Исправление расписания при запуске |
 | 12 | `validator_guard` | Не подавлять восстановление ключей в экстренном режиме |

@l10n/ru/docs/governance/chain-properties.md

@@ -122,8 +122,28 @@
 | `chain_properties_hf4` | 1 | HF4 | inflation_validator_percent, inflation_ratio_committee_vs_reward_fund, inflation_recalc_period |
 | `chain_properties_hf6` | 2 | HF6 | data_operations_cost_additional_bandwidth, validator_miss_penalty_percent, validator_miss_penalty_duration |
 | `chain_properties_hf9` | 3 | HF9 | create_invite_min_balance, committee_create_request_fee, create_paid_subscription_fee, account_on_sale_fee, subaccount_on_sale_fee, validator_declaration_fee, withdraw_intervals |
+| `chain_properties_hf13` | 4 | HF13 | distribution_epoch_length |
+| `chain_properties_pm` | 5 | HF14 | ~30 параметров прогнозных рынков + kill-switch `pm_commit_reveal_enabled`, `pm_lazy_pool_enabled` |
 
-Для всех новых публикаций параметров валидатора используйте индекс версии 3 (`chain_properties_hf9`).
+Для всех новых публикаций параметров валидатора используйте индекс версии **5** (`chain_properties_pm`). Индекс 4 — `chain_properties_hf13` (`distribution_epoch_length`).
+
+### Параметры прогнозных рынков (v5, HF14) {#pm-parameters}
+
+Все медиан-голосуемые; см. [Операции прогнозных рынков](../protocol/operations/prediction-markets.md).
+
+Все проценты PM — в bp (10000 = 100.00%), как прочие `*_percent`; промилле (‰) нигде нет.
+
+- **Оракул:** `pm_min_oracle_insurance`, `pm_max_oracle_fee_percent` (**единственный** governance-кэп на фи — на % оракула), `pm_oracle_registration_fee`, `pm_oracle_penalty_percent`, `pm_oracle_dispute_response_sec`, `pm_oracle_accept_window_sec` (по умолчанию 3600 = 1 ч — названный оракул должен принять или отклонить пендинг-рынок в течение этого окна; по истечении крон возвращает создателю сид-ликвидность, но **не** комиссию за создание, и аннулирует рынок → `pm_market_expired`).
+- **Риск / покрытие** *(процент от объёма ставок рынка, 100 = 1.0×):* `pm_listing_min_coverage_percent` (250 = 2.5×) — рынки, чья страховка оракула покрывает меньше этой доли их объёма, скрыты из каталога `list_markets` по умолчанию (показываются через `show_risky`); `pm_betting_min_coverage_percent` (150 = 1.5×) — рекомендательный порог, публикуемый для клиентов, чтобы требовать явного подтверждения риска перед ставкой (не форсится on-chain; должен быть `≤ pm_listing_min_coverage_percent`).
+- **Рынок:** `pm_min_liquidity`, `pm_market_creation_fee`, `pm_max_outcomes`, `pm_max_market_duration`. *(Агрегатного кэпа фи нет; creator/liquidity-фи без кэпа, самолимитируются; статический инвариант `сумма ≤ 100%`.)*
+- **Batch / commit-reveal:** `pm_batch_epoch_blocks`, `pm_reveal_window_blocks`, `pm_min_batch_bet`, `pm_commit_no_reveal_penalty_percent`, `pm_commit_reveal_enabled`.
+- **Споры:** `pm_dispute_fee`, `pm_dispute_grace_sec`, `pm_dispute_vote_period_sec`, `pm_dispute_auto_close_sec`, `pm_dispute_approve_min_percent`, `pm_no_contest_penalty_percent`, `pm_dispute_reward_multiplier` (bp-множитель, 10000 = 1×).
+- **Time penalty:** `pm_default_time_penalty_percent`, `pm_max_time_penalty`.
+- **Lazy-пул:** `pm_lazy_pool_enabled`, `pm_lazy_alloc_percent`, `pm_lazy_max_total_alloc_percent`, `pm_lazy_recall_step_percent`, `pm_lazy_lock_sec`, `pm_lazy_emergency_penalty_percent`, `pm_lazy_min_liquidity_fee_percent` (по умолчанию 200 = 2% — пул отказывается со-предоставлять ликвидность рынку, чей `liquidity_fee_percent` ниже этого порога вознаграждения).
+- **Плечо (опц.):** `pm_leverage_enabled`, `pm_leverage_fund_percent`, `pm_leverage_max_per_position_bp`, `pm_leverage_max_position_ratio_percent`, `pm_leverage_min_market_liquidity`, `pm_leverage_safety_margin_percent`, `pm_leverage_max_slippage_percent`, `pm_leverage_m_factor_percent`, `pm_leverage_pool_profit_percent`, `pm_leverage_expiration_buffer_sec`, `pm_conversion_profit_cost_percent`.
+- **Справедливость:** `pm_processing_cap_per_block`.
+
+Три флага `*_enabled` (`pm_commit_reveal_enabled`, `pm_lazy_pool_enabled`, `pm_leverage_enabled`) — живые kill-switch: медиана валидаторов может отключить commit-reveal, lazy-пул или плечо без нового хардфорка.
 
 ---
 

@l10n/ru/docs/node/configuration.md

@@ -158,6 +158,11 @@ skip-virtual-ops = false
 # Разрешить производство при устаревшей цепочке (только для разработки/тестовой сети)
 enable-stale-production = false
 
+# Отключить обнаружение minority fork (ТОЛЬКО для тестовой сети/форка одного оператора).
+# В отличие от enable-stale-production, никогда не сбрасывается автоматически при
+# здоровом участии. Никогда не включайте в реальной публичной сети.
+disable-minority-fork-detection = false
+
 # Минимальный процент участия для производства блоков (0–99)
 required-participation = 33
 
@@ -203,4 +208,4 @@ logger.p2p.appenders = p2p
 | `plugins/chain/plugin.hpp` | `shared-file-size`, `min-free-shared-file-size`, `inc-shared-file-size`, `block-num-check-free-size`, `single-write-thread`, `enable-plugins-on-push-transaction`, `read-wait-micro`, `max-read-wait-retries`, `write-wait-micro`, `max-write-wait-retries`, `skip-virtual-ops`, `clear-votes-before-block`, `track-account-range`, `history-whitelist-ops`, `history-blacklist-ops`, `history-start-block` |
 | `plugins/p2p/p2p_plugin.hpp` | `p2p-endpoint`, `p2p-max-connections`, `p2p-seed-node`, `checkpoint` |
 | `plugins/webserver/webserver_plugin.hpp` | `webserver-http-endpoint`, `webserver-ws-endpoint`, `webserver-thread-pool-size` |
-| `plugins/validator/validator.hpp` | `enable-stale-production`, `required-participation`, `validator`, `private-key`, `emergency-private-key`, `fork-collision-timeout-blocks`, `ntp-server`, `ntp-request-interval`, `debug-block-production` |
+| `plugins/validator/validator.hpp` | `enable-stale-production`, `disable-minority-fork-detection`, `required-participation`, `validator`, `private-key`, `emergency-private-key`, `fork-collision-timeout-blocks`, `ntp-server`, `ntp-request-interval`, `debug-block-production` |

@l10n/ru/docs/node/validator-node.md

@@ -164,6 +164,9 @@ docker run -d \
 ### Обнаружение minority fork
 Если форк-база данных узла показывает 21+ последовательных блоков только от собственных валидаторов, узел автоматически откатывается к LIB и выполняет повторную синхронизацию. Это позволяет обнаружить сетевую изоляцию.
 
+> [!WARNING] Форки одного оператора
+> На тестовой сети или форке основной сети, где **один оператор контролирует все валидаторы**, «21 блок подряд от нас» — это нормальное здоровое состояние, поэтому детектор бесконечно откатывается к LIB. `enable-stale-production = true` здесь **не помогает**: при участии ≥33% это переопределение автоматически снимается на каждом блоке. Используйте вместо него `disable-minority-fork-detection = true` — он обходит и стандартный, и DLT-путь обнаружения и никогда не сбрасывается автоматически. **Никогда не включайте его в реальной публичной сети** — это убирает защиту от изоляции.
+
 ### Watchdog производства
 Если в течение 180 секунд (60 с для экстренного мастера) при активном `should_be_producing` не был произведён ни один блок, watchdog автоматически сбрасывает зависшие флаги (`minority_fork_recovering`, нагон P2P, синхронизация цепочки) и пытается возобновить производство.