Submit order (openFor)

​

Request

​

Request body

​

Response

​

Behavior

• The lane decides. A signed lane with no signature, or a proxy lane with one, is EIN0010. A winner that completes through the open flow (a bridge winner) is EIN0001 pointing at POST /order. The same EIN0010 covers an unknown quote, another organization’s quote, and a malformed signature on the external gasless lane (aggregator-gasless) — one code on purpose.
• The hub does not verify an EVM escrow signature. On oif-escrow-gasless it forwards the signature as sent, and the upstream judges it: a bad one comes back as EIN0021, reference … (SOLVER_REJECTED), or http 400 (VALIDATION_ERROR) for a signature sent without the 0x00 scheme byte. A bad Solana envelope is EIN0007 (below).
• Rate limit. Every request whose body validates is charged to your organization’s order bucket (Limits) before the quote is read or anything is reserved. A shed is EIN0080 and has reserved and forwarded nothing, so re-posting the same body after error_params[0] milliseconds is safe.
• Re-posting is safe. A quote the hub has recorded a submission for is answered with the original ack, with no second forward and no time limit — provided the re-post passes the lane’s signature-presence rule above. The replay is keyed on the quote, not the body: a re-post carrying a different signature, even an invalid one, gets the original ack too. A re-post never opens a second order.
• Lost the answer? Derive hubOrderId and read the status before re-posting — Handling errors. The gateway’s availability answers (EPX0050, EPX0051, and EPX0052 when the hub took longer than the gateway’s 10 s) are lost answers too, with an unknown outcome. The gateway keeps this call running at the hub when your client times out or disconnects, but cuts it at those 10 s; if the hub was forwarding then, the forward is cancelled with it, since it runs on the request’s context: the reservation stays pending, the status read answers EIN0009, and every re-post answers EIN0052 until an operator reconciles it (known issue).
• The forward reservation. Before forwarding, the hub reserves the quote. An accepted forward records the submission (the re-post above). A forward the upstream definitively refused (EIN0021, a refused proxy-lane registration, a refused hub credential) releases the reservation, and so does a forward the hub’s own outbound admission stopped before sending (EIN0081 from its limiter, EIN0050 from an open circuit breaker): back off and re-post the same body, which forwards again. Don’t re-post a declined signed order, though: the aggregator answers the repeat with a 502, which the hub serves as EIN0050 (upstream unavailable: http 502) and then treats as a forward that went unanswered, so every later re-post answers EIN0052 (known issue). Re-quote and sign again instead. A forward that was sent and not answered (EIN0050 after a timeout or a 5xx, or EIN0081 for the upstream’s own 429), or answered in a way the hub cannot read (EIN0052 at once), keeps the reservation, because the upstream may have opened the order: every re-post then answers EIN0052 until an operator reconciles the reservation — the hub never releases it on its own. Whether an upstream 429 proves that no order was opened is an open question; until it is settled, a 429 is treated as unknown.
• Solana envelopes are checked by the hub before forwarding: 97 bytes, flag 0x00, the public key equal to the order’s user, the signature valid over the disclosed transactionMessage, and the message’s order id equal to the quote’s. A failure is EIN0007.
• Sui and Aptos are destination-only chains; no Move escrow is disclosed.
• Expiry. On the signed lanes (oif-escrow-gasless, oif-escrow-nonevm, aggregator-gasless) a submission at or after expiresAt is EIN0005, and nothing is reserved or forwarded, even while the quoting process still holds the template. The replay of a recorded submission and the EIN0052 check come first, so both still answer after expiry. On the proxy lanes the hub keeps a quote registrable for 20 minutes after it was issued, prepared or not, but the aggregator refuses a registration once expiresAt has passed: EIN0007, reference fail-closed rejected: upstream refused: http 400 (QUOTE_EXPIRED) (known issue). So register as soon as the transaction is sent, well before expiresAt. Past the hub’s 20 minutes the answer is EIN0005.
• Once a proxy-lane transaction is out, never re-quote. The user’s own transaction opened the order in escrow before this call, so a new quote would mean a second deposit, whatever this call answers. A refused registration (EIN0005, EIN0007, EIN0050 upstreamAuth) leaves the deposit where it is: it completes on chain anyway — the solver still fills it — but the hub never records the order, so it is missing from GET /orders and the status routes. Follow it by the send transaction’s hash on GET /onchain/tx/{chainDomain}/{txHash}/order, then GET /onchain/{orderId}/fill, and withdraw after the escrow expires if it is not filled (Refunds).
• A registration does not prove the deposit. Neither the hub nor the aggregator checks that the transaction was sent: a proxy-lane quote registered without it is acked created and stays created upstream (known issue). Register only after sending; the open fact on GET /onchain/{orderId}/fill is the proof.
• A non-prepared quote must be submitted to the replica that quoted it (its template is held in that process for 30 s, 20 min on the proxy lanes); a prepared quote works on any replica.
• Not configured. A deployment with no OIF aggregator (infinity.upstream.oif.baseUrl unset) answers this route EIN0007 (reference fail-closed rejected: openFor route not wired).

​

Errors

​

Example

curl -sS -X POST https://proxy-api.infinimesh.net/v1/order/openfor \
  -H "x-api-key: $HUB_API_KEY" \
  -H "X-Infinity-Subject: user-42" \
  -H 'Content-Type: application/json' \
  -d '{"quoteRequestId":"01M34FSW4R9F2C4E7A1B3D5F80","quoteId":"b9760d500009ec356eb2fc720c32cb77b8b0420a8e2b2deb6a97ce63ba64fb58","signature":"0x00<65-byte-ecdsa-hex>"}'

​

Response

{
  "success": true,
  "request_id": "1e2f3041-5263-449e-8f9a-0b1c2d3e4f50",
  "data": {
    "orderId": "0x8c7f293ae9851d2919e1543d0268483a0636bef9417240b0aa15258c508e32b9",
    "hubOrderId": "a1c662328ee36c035986071fdca2997c167288c9da362f7d540ff102dfedf4c2",
    "quoteId": "b9760d500009ec356eb2fc720c32cb77b8b0420a8e2b2deb6a97ce63ba64fb58",
    "state": "created",
    "submittedAt": "2026-09-22T12:00:20Z"
  }
}

import { evmEscrowEnvelope } from "@c8ntinuum/infinity-interop-sdk";

// client: your InteropClient. submitOpenFor recovers a lost answer: it looks the order up by its
// derived hub order id, then re-posts the SAME body once.
const submitted = await client.submitOpenFor({
  quoteRequestId: q.quoteRequestId, quoteId: q.quoteId,
  signature: evmEscrowEnvelope(sig), // "0x00" + the 65-byte signature
});

​

See also

• SDK: client.submitOpenFor() (Lost answers); client.executeQuote() signs, submits and tracks in one call (Executing orders)
• Step execution
• Handling errors
• Execution errors
• Quickstart