Rule Snapshots — Why Your Trade's Terms Can't Change Mid-Flight

By Inveil Research · Updated June 1, 2026

When you start a trade on Inveil, the terms that govern it — the commission rate, the cost to open a dispute, where fees go — are copied onto your specific order and frozen at that instant. This is called a rule snapshot, and it guarantees that nothing the operator changes afterward can reach back and alter a trade already in motion. You agree to the terms you see when you commit, and those are the terms that settle your trade, even if the protocol's live settings change five minutes later. It's a small idea with a large safety payoff, and it's worth understanding because it's exactly the kind of thing that goes wrong on systems that don't do it.

The problem: terms that drift between agreement and settlement

A trade isn't instant. You create an order, a counterparty funds it, goods or payment move, and only then does it settle — minutes, hours, sometimes longer after you agreed to it. That gap is dangerous if the rules governing the trade are read live at settlement time rather than fixed at agreement time. If the operator raises the commission, changes the arbitration fee, or redirects where money flows in that window, a trade you entered under one set of terms could settle under a different, worse one. You'd have agreed to something that silently changed underneath you.

This is a general failure pattern in any system where state is "committed" at one moment and "executed" at another: unless the commit moment actually binds the execution moment, conditions can shift in between. The fix is to freeze the relevant state at commit time so execution doesn't depend on anything that can change later.

How a rule snapshot works

On Inveil, the fix is built into the order itself. At the moment an order is created, the contract takes the live rules — commission rate, treasury destination, arbitration cost — and writes a copy directly onto that order. From then on, every money movement for that trade reads the snapshot on the order, not the protocol's current live values.

The consequence is clean and absolute: an operator changing a parameter after your order exists changes it only for orders created after that point. Your order keeps the terms it was sealed with. The owner can tune the protocol's future behavior all they want; they cannot retroactively touch a trade that's already underway, because the contract simply never looks at the live values for your order again — it looks at the frozen copy.

Why "snapshot written" must mean "snapshot read"

There's a subtle requirement that makes this real rather than decorative: the snapshot has to be the value the contract actually uses at settlement, not just a record kept for display. A snapshot that's written at order creation but then ignored at payout time — where the contract reads the live rules instead — would give you a false sense of protection. The terms would still drift; the snapshot would just be a museum piece.

Inveil's design treats the snapshot as authoritative in every fund-flow path. The commission taken, the arbitration cost charged, the treasury that receives fees — all of them read from the per-order snapshot at settlement. The protection isn't "we promise not to change your terms"; it's "the contract is structurally incapable of using anything but the terms you agreed to." That's the difference between a policy and a guarantee. It works alongside timelocks, which govern how future terms can change: the timelock makes parameter changes slow and public, and the snapshot makes sure those changes never reach a trade already in flight.

A concrete example

Say you create an order when the dispute-filing cost is a certain amount. Your counterparty funds it. A day later, the operator raises that cost for new trades. Then your trade hits a snag and you open a dispute. Which cost applies — the one when you agreed, or the new higher one?

On a system that reads live values, you'd pay the new, higher cost, even though you committed under the old one — and a similar bug has bitten real platforms, where a user got charged or blocked because the execute-time path used a value that changed after they committed. On Inveil, you pay the cost frozen onto your order at creation. The snapshot decided it the moment you committed, and nothing since can move it. The same logic protects the commission on your settlement and where fees are routed.

How it compares

	Live-rules system	Rule-snapshot system (Inveil)
When terms are fixed	At settlement (read live)	At order creation (frozen)
Can terms change mid-trade	Yes	No
Operator change affects live trades	Possible	Only future trades
What you agreed to vs what settles	May differ	Always the same
Protection type	Policy / promise	Structural guarantee

The takeaway

A rule snapshot makes the moment you commit to a trade the moment its terms are sealed. Fees, arbitration cost, and fee routing are copied onto your order and read from there forever after, so no later change — well-intentioned or not — can rewrite a deal already in progress. Combined with escrow the operator can't withdraw from and timelocked, publicly-announced parameter changes, it's part of what lets you trust the contract rather than the company. For the bigger picture of how on-chain escrow protects a trade end to end, see our smart-contract escrow explainer, or open the market to see it live.

FAQ

What is a rule snapshot?

It's a copy of a trade's governing terms — commission rate, arbitration cost, fee destination — taken and frozen at the moment the order is created. Every fund movement for that trade reads the frozen copy, so the terms can't change between when you agree and when the trade settles.

Can the operator raise fees on a trade I've already started?

No. Fee and rule changes apply only to orders created after the change. Your order keeps the terms snapshotted at its creation, because the contract reads those frozen values — not the protocol's current live settings — for every payout on your trade.

How is this different from just promising not to change terms?

A promise is a policy; a snapshot is a structural guarantee. The contract is built to read only the per-order frozen terms at settlement, so it's incapable of applying a later change to your trade. You don't have to trust the operator's intentions — the code can't do otherwise.

Does this work together with timelocks?

Yes. They cover different halves of the same problem. Timelocks make any change to future terms slow and publicly announced; rule snapshots ensure those changes never reach a trade that's already underway. Together they mean changes are both visible in advance and unable to rewrite existing deals.