Skip to main content
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). 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. 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.

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

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

​
Announcements

The notice commitments on this page begin at public testnet on 20 September 2026. The private testnet changes parameters and behavior without notice — it exists to tune them.
Once notice periods begin, every change is recorded in the protocol 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

Protocol changelog

The dated record of what has shipped.

Listings and delistings

Market changes and their notice periods.

State model

Why configuration keys are versioned and resolved live.

Leverage

What a risk-parameter change does to an open position.