# Order update skips create-time validation

Mutators that rewrite order fields without re-checking create-time invariants or filled size

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; latest 2026-02-05. Updated 2026-10-23._

## How it works

Order creation enforces invariants: the output token must match the position's assets, size must respect bounds, and signed payloads must commit to every field that later drives escrow or payout. Amend/update paths often re-implement field writes without re-applying those checks. The broken assumption is that "an order valid at creation stays valid after mutation." Three invariant classes break: field-vs-position (token must belong to the position), size-vs-filled (new size must reconcile with quantity already filled), and signed-field coverage (every field consumed at settlement must be signed). When a mutator writes a field directly, the invariant no longer holds, and whoever acts between mutation and fill gains leverage over the counterparty.

## Where it shows up

- Update/amend/setter functions that assign `tokenOut`, `amount`, or similar fields without re-running create-time validation.
- Amend APIs taking absolute size fields with no reconciliation against already-filled quantity.
- Signed payloads that omit fields (e.g. consideration items) later consumed by escrow or refund logic.
- Validation comparing one party's bound to another's instead of the actual constructed quantity.
- Any async order book where fills can interleave with amendments.

## How to review

For each mutable field, find the invariant enforced at creation and confirm every mutator re-applies it. For size amendments, verify the new value is reconciled against filled quantity, not treated as absolute. For signed payloads, enumerate every field that flows into escrow, payout, or refund and confirm the signature commits to each; check whether the settlement contract can distinguish signed items from appended ones. For matching engines, confirm the check compares actual constructed item count against each party's own bound. The property: after any mutation, the order still satisfies every invariant that held at creation, and no unsigned field influences settlement.

## Variants seen

- `updateOrder` swaps `tokenOut` to an arbitrary token, front-run before fill [E2](https://bugbountylibrary.com/r/c4%3A2024-01-init-capital-invitational%3AH-02.md).
- `amendLimitOrder` overwrites amount ignoring partial fills, doubling exposure [E3](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-07.md).
- Unsigned fulfiller-appended consideration tips flow into escrow, locking assets [E1](https://bugbountylibrary.com/r/c4%3A2024-01-renft%3AH-01.md).

## Impact and severity

Forced payout of a high-value token [E2](https://bugbountylibrary.com/r/c4%3A2024-01-init-capital-invitational%3AH-02.md), doubled user exposure [E3](https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-07.md), assets locked forever [E1](https://bugbountylibrary.com/r/c4%3A2024-01-renft%3AH-01.md). Severity rises when the mutation is front-runnable or the affected field is unsigned, since the counterparty cannot detect or consent to the change; permanent lockup ranks highest because no recovery path exists.

## Evidence
- E1: https://bugbountylibrary.com/r/c4%3A2024-01-renft%3AH-01.md
- E2: https://bugbountylibrary.com/r/c4%3A2024-01-init-capital-invitational%3AH-02.md
- E3: https://bugbountylibrary.com/r/c4%3A2025-08-gte-perps-and-launchpad%3AM-07.md