Flash

Update an order

Update a previously submitted flash order's limit price and/or trigger price.

Executed as a cancel-and-replace under the same orderId. What each order type accepts:

Order typelimitCrossPrice / limitNotionalPricetrigger
limityes (exactly one)no
stop, stop-loss, take-profit (no limit price — market execution)noyes
stop-limit / take-profit-limit (placed with a limit price)yes (exactly one)yes

Every other order type is rejected with 422. Send at least one of the limit or trigger fields; on the -limit variants both can travel in one update.

On the -limit variants the limit price is the post-trigger execution limit — where the order rests once its trigger fires — and the trigger price is where it arms; each moves independently. A trigger update moves the threshold only: the direction (triggerType) and the price basis (cross vs notional) must match what the order's trigger was placed with — unlike the limit price, whose basis can be switched freely. Updating after the trigger has already fired is also valid for the limit price: the resting limit order is cancelled and re-placed at the new price (a trigger update at that point is rejected — there is no trigger left to move).

Signature required. Construct the canonical UTF-8 update message and sign it with the funder wallet:

  • Message format (a Limit ... Price: line, a Trigger ... Price: line, or both — limit first):
Definitive Flash — Update Order
Order: <orderId>
Issued At: <RFC3339 UTC>
Limit Cross Price: <decimal>
Trigger Lower Cross Price: <decimal>
  • The Limit line is Limit <Cross|Notional> Price:, matching the request's limit field. The Trigger line is Trigger <Lower|Upper> <Cross|Notional> Price: — direction from trigger.triggerType, kind from which trigger price field is set. Each price must be byte-identical to the request value.
  • The message binds the order id, every updated value, and an Issued At: freshness stamp (rejected outside a small skew window) to prevent replay of a captured signature. Use RFC3339 with sub-second precision (e.g. new Date().toISOString()) to issue more than one update per second on the same order.
  • EVM chains — sign with EIP-191 personal_sign over the message bytes; pass the 65-byte 0x-prefixed hex signature as userSignature.
  • SVM (solana) — sign with Ed25519 over the message bytes; pass the 64-byte base58 signature as userSignature.
  • Echo the exact message text back as updateMessage.

Errors: 422 when the order type does not accept the fields sent (e.g. a trigger update on a limit order, a limit update on a market-execution trigger type), the new trigger changes direction or basis, the new trigger price would fire immediately at the current market, the order is already pending an update, or the order is in a terminal resting state; 404 when the order cannot be found — a nonexistent order, or one that triggered on entry and never rested — or the signature does not verify.

patch/orders/{orderId}

Path parameters

orderIdstring uuid required

Flash order ID.

Request body

limitNotionalPricestring

New USD limit price for the traded (targetAsset) asset. Mutually exclusive with limitCrossPrice; set exactly one. Must equal the value signed in updateMessage exactly — no normalization is applied.

limitCrossPricestring

New pair-rate limit price — how many contraAsset units one targetAsset unit is worth. Mutually exclusive with limitNotionalPrice; set exactly one. Must equal the value signed in updateMessage exactly — no normalization is applied.

updateMessagestring required

UTF-8 plaintext the funder wallet signed. Binds the order id, an RFC3339 Issued At: freshness stamp, and every updated value. Format:

Definitive Flash — Update Order
Order: <orderId>
Issued At: <RFC3339 UTC>
Limit Cross Price: <decimal>
Trigger Lower Cross Price: <decimal>

The Limit line (Limit Cross Price: or Limit Notional Price:) and the Trigger line (Trigger <Lower|Upper> <Cross|Notional> Price:, direction matching trigger.triggerType) are each optional and appear at most once, matching the request fields; at least one is required, and when both are present the Limit line comes first. Same bytes across EVM and SVM.

userSignaturestring required

Funder wallet signature over updateMessage. Accepts 0x-prefixed hex (EVM convention) or base58 (Solana convention). EVM: 65 bytes from EIP-191 personal_sign. SVM: 64 bytes from Ed25519.

Example request

{
  "limitNotionalPrice": "4000",
  "limitCrossPrice": "4000",
  "trigger": {
    "notionalPrice": "3500",
    "crossPrice": "3500"
  }
}

Response

Order updated successfully

oktrue required

Changes