> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Изменения правил

> Как меняются торговые правила, риск-параметры и поведение протокола: сроки уведомления, высоты вступления в силу и почему правила прошлого блока нельзя переписать.

До живой сети доходят три вида изменений: **изменения параметров** (лимит риска, тарифная сетка, потолок финансирования), **изменения поведения** (как работает само исполнение) и **изменения рынков** ([листинги и делистинги](/ru/programs/listings)).

Объявляются они по-разному. Общее у них одно свойство, и оно главное: изменение вступает в силу в **конкретной точке истории блокчейна**, и на историю до этой точки оно не влияет.

<h2 id="parameter-changes">
  Изменения параметров
</h2>

Риск-параметры, ступени плеча, потолки финансирования, лимиты позиции и тарифные сетки — это ончейн-конфигурация. Изменить любой из них — значит провести транзакцию протокола: она исполняется в блоке, в самом начале [приоритета блока](/ru/trading/tx-sequencing).

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

Ключи конфигурации к тому же **версионированы**. Когда меняется не число, а форма значения, новая форма записывается под новым ключом, а старый остаётся читаемым. Клиент, который читает конфигурацию вживую, переживает изменение без правок, а клиент с зашитым в код путём ключа узнаёт об этом сразу и не читает молча устаревшее значение. См. [Модель состояния](/ru/protocol/architecture/state/model).

<h2 id="behavioral-changes">
  Изменения поведения
</h2>

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

Intention решает это **ончейн-переключателями**. Каждый переключатель — это один ключ состояния с высотой блока: с неё и начинается новое поведение.

<div className="dg" data-dg="gated-change">
  <div className="dg-c" style={{aspectRatio:"720 / 250"}}>
    <svg className="dg-w" viewBox="0 0 720 250" aria-hidden="true">
      <path className="dg-wire" d="M 163.00 43.00 L 176.60 43.00" />

      <path className="dg-head" d="M 183.00 43.00 L 176.60 47.40 L 176.60 38.60 Z" />

      <path className="dg-wire" d="M 350.00 43.00 L 363.60 43.00" />

      <path className="dg-head" d="M 370.00 43.00 L 363.60 47.40 L 363.60 38.60 Z" />

      <path className="dg-wire" d="M 537.00 43.00 L 550.60 43.00" />

      <path className="dg-head" d="M 557.00 43.00 L 550.60 47.40 L 550.60 38.60 Z" />
    </svg>

    <div className="dg-b dg--sky" style={{left:"0.0000%",top:"0.0000%",width:"22.0833%",height:"34.4000%"}}><span className="dg-t">Новое поведение выпущено</span><span className="dg-s">в бинарнике, но не активно</span></div>
    <div className="dg-b dg--blue" style={{left:"25.9722%",top:"0.0000%",width:"22.0833%",height:"34.4000%"}}><span className="dg-t">Переключатель записан</span><span className="dg-s">один ключ состояния с будущей высотой блока</span></div>
    <div className="dg-b dg--blue" style={{left:"51.9444%",top:"0.0000%",width:"22.0833%",height:"34.4000%"}}><span className="dg-t">Все валидаторы читают одну высоту</span></div>
    <div className="dg-b dg--green" style={{left:"77.9167%",top:"0.0000%",width:"22.0833%",height:"34.4000%"}}><span className="dg-t">Поведение меняется ровно на этом блоке</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"49.6000%",width:"31.8519%",height:"46.4000%"}}><span className="dg-t">Высота обязана быть в будущем</span><span className="dg-s">Переключатель нельзя выставить на уже пройденную высоту. Именно это правило делает изменение одновременным.</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"34.0741%",top:"49.6000%",width:"31.8519%",height:"46.4000%"}}><span className="dg-t">Нет переключателя — выключено</span><span className="dg-s">Узел, воспроизводящий историю, не читает ключа на этих высотах и идёт по старой ветке, поэтому воспроизведение корректно без матрицы совместимости.</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"68.1481%",top:"49.6000%",width:"31.8519%",height:"46.4000%"}}><span className="dg-t">Читается на исполняемой версии</span><span className="dg-s">Никогда из кэша. Прочитать текущее значение при воспроизведении старого блока — значит применить сегодняшние правила к вчерашней истории.</span></div>
  </div>
</div>

Отсюда следуют три свойства, и каждое из них несущее:

**В момент записи высота обязана быть в будущем.** Переключатель нельзя выставить на уже пройденную высоту. Именно это правило делает изменение одновременным: каждый валидатор доходит до этого блока с уже видимым ключом.

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

**Переключатель читается на исполняемой версии, а не из кэша.** Прочитать текущее значение при воспроизведении старого блока значило бы применить сегодняшние правила к вчерашней истории и получить другой корень состояния. Поэтому значение всегда берётся из представления исполнения того блока, который обрабатывается сейчас.

Тот же механизм поддерживает постепенное включение: флаг можно ввести выключенным, проверить на реальном трафике и включить на запланированной высоте — а не выкатывать всё сразу, обновлением бинарника.

<h2 id="notice-periods">
  Сроки уведомления
</h2>

Уведомление соразмерно тому, что изменение может сделать с уже открытой позицией.

| Изменение                                                                                                     | Уведомление                                             |
| ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| **Затрагивает открытые позиции** — маржинальные требования, ступени плеча, потолки финансирования, делистинги | Объявляется до даты вступления в силу, с указанием даты |
| **Затрагивает интеграции** — поверхность API, формы сообщений, схемы ключей                                   | Объявляется заранее, с путём миграции                   |
| **Затрагивает только стоимость** — тарифные сетки, уровни ребейтов                                            | Объявляется до даты вступления в силу                   |
| **Устраняет живой риск** — параметр, ужесточённый в ответ на состояние рынка                                  | Может вступить в силу немедленно                        |

Последняя строка — реальное исключение, а не лазейка. Лимит позиции, которому надо неделю ждать ужесточения, — это лимит, который ничего не делает ровно ту неделю, ради которой он был нужен. Когда этим исключением пользуются, изменение публикуют вместе с его причиной.

<Warning>
  Изменение маржинальных требований или ступеней плеча меняет цену ликвидации по уже открытым позициям. Оно ничего не закрывает, и персонально вас о нём не предупредят. Если вы держите позиции через объявленное изменение риск-параметров, пересчитайте расстояние до ликвидации по новым значениям, а не по тем, что действовали при открытии. См. [Плечо](/ru/trading/leverage).
</Warning>

<h2 id="what-cannot-change">
  Что не может измениться
</h2>

Правила, действовавшие в уже зафиксированном блоке.

Любое изменение правил вступает в силу на высоте, которая на момент записи была в будущем, поэтому при воспроизведении старого блока всегда применяются правила, действовавшие тогда. Вопрос о том, действовало ли конкретное правило на какой-то прошлой версии, имеет один ответ, и сегодня он тот же, каким будет через год.

Это более сильная гарантия, чем опубликованная политика. Дело не в том, что протокол *не станет* переписывать историю, — дело в том, что у механизма нет способа выразить правило, начавшееся в прошлом. См. [Модель состояния](/ru/protocol/architecture/state/model).

<h2 id="announcements">
  Объявления
</h2>

<Note>
  Обязательства по уведомлению, описанные на этой странице, начинают действовать с **публичным тестнетом 20 сентября 2026 года**. В [приватном тестнете](/ru/protocol/architecture/network-status) параметры и поведение меняются без уведомления — он для того и существует, чтобы их настраивать.
</Note>

Как только сроки уведомления заработают, каждое изменение фиксируется в [журнале изменений протокола](/ru/protocol/roadmap/changelog) с датой вступления в силу и объявляется заранее, когда этого требует таблица выше.

Записи датируются по тому, **когда изменение вступило в силу в сети**, а не когда о нём объявили.

<h2 id="where-to-go-next">
  Что дальше
</h2>

<CardGroup cols={2}>
  <Card title="Журнал изменений протокола" href="/ru/protocol/roadmap/changelog">
    Датированная запись о том, что уже выпущено.
  </Card>

  <Card title="Листинги и делистинги" href="/ru/programs/listings">
    Изменения рынков и сроки уведомления по ним.
  </Card>

  <Card title="Модель состояния" href="/ru/protocol/architecture/state/model">
    Почему ключи конфигурации версионируются и читаются вживую.
  </Card>

  <Card title="Плечо" href="/ru/trading/leverage">
    Что изменение риск-параметра делает с открытой позицией.
  </Card>
</CardGroup>