> ## 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.

# ルール変更

> 取引ルール、リスクパラメータ、プロトコルの挙動がどう変わるか。予告期間、発効するブロック高、過去のブロックのルールを書き換えられない理由です。

稼働中のネットワークに届く変更は3種類あります。**パラメータ変更**（リスク上限、料率表、資金調達率の上下限）、**挙動の変更**（実行そのものの仕組み）、**マーケットの変更**（[上場と上場廃止](/ja/programs/listings)）です。

告知の仕方はそれぞれ異なります。共通する性質は1つで、それが重要です。変更は**チェーンの履歴上の特定の一点**で発効し、その前の履歴は影響を受けません。

<h2 id="parameter-changes">
  パラメータ変更
</h2>

リスクパラメータ、レバレッジティア、資金調達率の上下限、ポジション上限、料率表はオンチェーンの設定です。これらの変更は、ブロック内の[優先順位](/ja/trading/tx-sequencing)の先頭で実行されるプロトコルトランザクションです。

値がチェーン状態なので、変更は報告されるものではなく観測できるものです。あるマーケットの維持証拠金が動いたことを知らされる必要はありません。現在の値も、過去の任意のブロック時点の値も読み取れます。

設定キーには**バージョン**もあります。数値ではなく値の形そのものが変わる場合、新しい形は新しいキーの下に書き込まれ、古いキーは読み取れるまま残ります。設定をその都度解決するクライアントは、変更をまたいでも動き続けます。キーのパスをハードコードしたクライアントは、古い値を黙って読み続けるのではなく、その場で気づきます。[ステートモデル](/ja/protocol/architecture/state/model)を参照してください。

<h2 id="behavioral-changes">
  挙動の変更
</h2>

実行の*挙動*を変えるのは、数値を変えるより難しい問題です。すべてのバリデータが、まったく同じ瞬間に変更を適用しなければならないからです。ノードごとに違うタイミングで届く変更はロールアウトではなく、フォークです。

Intentionはこれを**オンチェーンのゲート**で扱います。各ゲートはブロック高を保持する1つの状態キーで、その高さから新しい挙動が始まります。

<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">未来のブロック高を持つ1つの状態キー</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">すでに過ぎたブロック高にゲートを設定することはできません。この1つの規則が、変更を同時にします。</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>

ここから3つの性質が導かれ、いずれも欠かせません。

**書き込む時点で、その高さは未来でなければなりません**。すでに過ぎたブロック高にゲートを設定することはできません。この1つの規則が変更を同時にします。どのバリデータも、同じキーがすでに見えている状態でそのブロックに到達するからです。

**ゲートがなければ無効です**。履歴をリプレイするノードは、その高さではキーを読み取らず、そのまま古いコードパスを通ります。互換性マトリクスを誰も保守しなくても、履歴のリプレイは何もせずとも正しいままです。

**ゲートは実行中のバージョンで読み取り、キャッシュからは読み取りません**。古いブロックをリプレイしながら現在の値を読めば、今日のルールを昨日の履歴に適用することになり、異なるステートルートが生まれます。そのため値は常に、実行中のブロックの実行ビューから読み取ります。

同じ仕組みは段階的な有効化にも使えます。フラグを無効の状態で入れ、実トラフィックに対して検証し、予定した高さで有効にできます。一括のバイナリ更新として出す必要はありません。

<h2 id="notice-periods">
  予告期間
</h2>

予告の長さは、その変更がすでに持っているポジションに与えうる影響に見合わせます。

| 変更                                                 | 予告            |
| -------------------------------------------------- | ------------- |
| **建っているポジションに影響する**（必要証拠金、レバレッジティア、資金調達率の上下限、上場廃止） | 発効日を明示して事前に告知 |
| **統合に影響する**（APIの構成、メッセージの形、キーの配置）                  | 移行手順を添えて事前に告知 |
| **コストにだけ影響する**（料率表、リベートのティア）                       | 発効日より前に告知     |
| **稼働中のリスクを是正する**（相場の状況に応じたパラメータの引き締め）              | 即時に発効することがある  |

最後の行は抜け穴ではなく、実際の例外です。引き締めに1週間待たなければならないポジション上限は、それが必要とされたまさにその1週間、何もしないポジション上限です。この例外を使う場合は、変更内容と理由を併せて公表します。

<Warning>
  必要証拠金やレバレッジティアの変更は、すでに持っているポジションの強制決済価格を変えます。何かを決済することはなく、個別に警告することもありません。告知されたリスクパラメータの変更をまたいでポジションを持ち越す場合は、建てたときに有効だった値ではなく、新しい値で強制決済までの距離を計算し直してください。[レバレッジ](/ja/trading/leverage)を参照してください。
</Warning>

<h2 id="what-cannot-change">
  変えられないもの
</h2>

すでにコミットされたブロックに適用されたルールです。

どのルール変更も、記録された時点では未来だった高さで発効します。したがって古いブロックのリプレイでは、常にその当時有効だったルールが適用されます。あるルールが過去のあるバージョンで有効だったかという問いの答えは1つしかなく、今日の答えは1年後の答えと同じです。

これは公表された方針より強い保証です。プロトコルが履歴を書き換え*ない*という話ではありません。過去に始まったルールを表現する手段が、仕組みとして存在しないという話です。[ステートモデル](/ja/protocol/architecture/state/model)を参照してください。

<h2 id="announcements">
  告知
</h2>

<Note>
  このページの予告に関する約束は、**2026年9月20日のパブリックテストネット**から適用されます。[プライベートテストネット](/ja/protocol/architecture/network-status)はパラメータと挙動を予告なく変更します。それらを調整するために存在するネットワークだからです。
</Note>

予告期間の運用が始まったあとは、すべての変更が発効した日付とともに[プロトコル変更履歴](/ja/protocol/roadmap/changelog)に記録され、上の表が求める場合はその日付より前に告知されます。

記載する日付は**ネットワークで変更が発効した日**であり、告知した日ではありません。

<h2 id="where-to-go-next">
  次に読む
</h2>

<CardGroup cols={2}>
  <Card title="プロトコル変更履歴" href="/ja/protocol/roadmap/changelog">
    何がリリースされたかの、日付付きの記録です。
  </Card>

  <Card title="上場と上場廃止" href="/ja/programs/listings">
    マーケットの変更と、その予告期間です。
  </Card>

  <Card title="ステートモデル" href="/ja/protocol/architecture/state/model">
    設定キーにバージョンがあり、その都度解決される理由です。
  </Card>

  <Card title="レバレッジ" href="/ja/trading/leverage">
    リスクパラメータの変更が、建っているポジションに何をするかです。
  </Card>
</CardGroup>