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

# Rule changes

> How trading rules, risk parameters, and protocol behavior change: notice periods, effective block heights, and why a past block's rules can never be rewritten.

Three kinds of change reach a live network: **parameter changes** (a risk limit, a fee schedule, a funding cap), **behavioral changes** (how execution itself works), and **market changes** ([listings and delistings](/programs/listings)).

They differ in how they are announced. They share one property, and it is the one that matters: a change takes effect at a **specific point in the chain's history**, and history before that point is not affected.

## Parameter changes

Risk parameters, leverage tiers, funding caps, position limits, and fee schedules are on-chain configuration. Changing one is a protocol transaction that executes in a block, at the top of [block priority](/trading/tx-sequencing).

Because the value is chain state, the change is observable rather than reported. You do not have to be told the maintenance margin on a market moved — you can read what it is, and you can read what it was at any past block.

Configuration keys are also **versioned**. When a value's shape changes rather than its number, the new shape is written under a new key and the old one remains readable. A client resolving configuration live keeps working across the change; a client that hard-coded a key path finds out immediately rather than silently reading something stale. See [State model](/protocol/architecture/state/model).

## Behavioral changes

Changing how execution *behaves* is a harder problem than changing a number, because every validator must make the change at exactly the same moment. A change that lands on different nodes at different times is not a rollout — it is a fork.

Intention handles this with **on-chain gates**. Each gate is one state key holding a block height: the height at which the new behavior begins.

<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">New behaviour ships dark</span><span className="dg-s">in the binary, not active</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">A gate is written</span><span className="dg-s">one state key holding a future block height</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">Every validator reads the same height</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">Behaviour changes at exactly that block</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">The height must be in the future</span><span className="dg-s">A gate cannot be set to a height that has already passed. That single rule is what makes the change simultaneous.</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">An absent gate means inactive</span><span className="dg-s">A node replaying history reads no key at those heights and takes the old path, so replay stays correct without a compatibility matrix.</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">Read at the version being executed</span><span className="dg-s">Never from a cache. Reading a current value while replaying an old block would apply today's rules to yesterday's history.</span></div>
  </div>
</div>

Three properties follow, and each one is load-bearing:

**The height must be in the future when it is written.** A gate cannot be set to a height that has already passed. That single rule is what makes the change simultaneous — every validator reaches that block with the same key already visible.

**An absent gate means inactive.** A node replaying history reads no key at those heights and takes exactly the old code path. Historical replay stays correct for free, without anyone maintaining a compatibility matrix.

**The gate is read at the version being executed, never from a cache.** Reading a current value while replaying an old block would apply today's rules to yesterday's history and produce a different state root. So the value is read from the execution view of the block being executed, always.

The same mechanism supports gradual enablement: a flag can be introduced inactive, verified against real traffic, and switched on at a scheduled height — rather than shipped as an all-at-once binary upgrade.

## Notice periods

Notice is proportional to what a change can do to a position you already hold.

| Change                                                                                     | Notice                                                      |
| ------------------------------------------------------------------------------------------ | ----------------------------------------------------------- |
| **Affects open positions** — margin requirements, leverage tiers, funding caps, delistings | Announced ahead of the effective date, with the date stated |
| **Affects integrations** — API surface, message shapes, key layouts                        | Announced ahead, with a migration path                      |
| **Affects cost only** — fee schedules, rebate tiers                                        | Announced ahead of the effective date                       |
| **Corrects a live risk** — a parameter tightened in response to a market condition         | May take effect immediately                                 |

The last row is a real exception, not a loophole. A position limit that has to wait a week to tighten is a position limit that does nothing during exactly the week it was needed. When it is used, the change and its reason are published with it.

<Warning>
  A change to margin requirements or leverage tiers changes your liquidation price on positions you already hold. It does not close anything, and it does not warn you individually. If you carry positions through an announced risk-parameter change, recompute your distance to liquidation against the new values rather than the ones in effect when you opened. See [Leverage](/trading/leverage).
</Warning>

## What cannot change

The rules that applied to a block that has already committed.

Every rule change takes effect at a height that was in the future when it was recorded, so replaying an old block always applies the rules that were active then. Whether a given rule was in force at some past version is a question with one answer, and it is the same answer today as it will be in a year.

This is a stronger guarantee than a published policy. It is not that the protocol *will not* rewrite history — it is that the mechanism has no representation for a rule that started in the past. See [State model](/protocol/architecture/state/model).

## Announcements

<Note>
  The notice commitments on this page begin at **public testnet on 20 September 2026**. The [private testnet](/protocol/architecture/network-status) changes parameters and behavior without notice — it exists to tune them.
</Note>

Once notice periods begin, every change is recorded in the [protocol changelog](/protocol/roadmap/changelog) with the date it took effect, and announced ahead of that date when the table above requires it.

Entries are dated by **when the change took effect on the network**, not when it was announced.

## Where to go next

<CardGroup cols={2}>
  <Card title="Protocol changelog" href="/protocol/roadmap/changelog">
    The dated record of what has shipped.
  </Card>

  <Card title="Listings and delistings" href="/programs/listings">
    Market changes and their notice periods.
  </Card>

  <Card title="State model" href="/protocol/architecture/state/model">
    Why configuration keys are versioned and resolved live.
  </Card>

  <Card title="Leverage" href="/trading/leverage">
    What a risk-parameter change does to an open position.
  </Card>
</CardGroup>