Skip to main content

Transaction Status

This guide explains how to check the status of cross-chain and swap transactions using the /status endpoint provided by LI.FI.

Querying the Status Endpoint

To fetch the status of a transfer, the /status endpoint can be queried with:
  1. sending transaction hash
  2. receiving transaction hash
  3. transactionId
Only one of the above values are required and need to be passed in txHash param.

Required:

  • txHash

Optional:

  • fromChain: Speeds up the request (recommended)
  • toChain
  • bridge
For swap transactions, set fromChain and toChain to the same value. The bridge parameter can be omitted.

Sample Response


Quoted vs executed amounts

When LI.FI issued a quote for the transfer, GET /v1/status includes an optional quote object so you can reconcile the quote-time estimate with what actually settled.
  • quote.action is what was requested.
  • quote.estimate records the quoted amounts and costs (toAmount, toAmountMin, fees, gas).
  • sending and receiving are the executed legs. Compare receiving.amount with quote.estimate.toAmount and quote.estimate.toAmountMin.
No extra query parameter is required. The field is omitted when LI.FI has no stored quote — for example the transaction never went through /quote or /stepTransaction, it was partner-ingested, or the record predates quote persistence. Omission is not an error and does not change status or substatus. quote can already appear while status is PENDING, because it is loaded from the quote-time record, not from destination settlement. The schema lives on the GET /v1/status API reference.

Quote object

Internal database fields are stripped and are never returned.

Reconcile a completed transfer

  1. Poll /status until status is DONE.
  2. If quote is present, compare receiving.amount to quote.estimate.toAmountMin (quoted minimum) and quote.estimate.toAmount (quoted estimate).
  3. substatus: COMPLETED means the transfer finished successfully. It does not mean receiving.amount equals quote.estimate.toAmount. The actual amount can differ from the quoted estimate while remaining at or above toAmountMin.
  4. Use PARTIAL / REFUNDED together with the amounts when the outcome is not a full delivery.

Example

Production GET /v1/status observed on 2026-09-14 (trimmed). Quoted toAmount was 377946589; actual receiving.amount was 377639049, still above toAmountMin 376056856.

Status Values

When LI.FI cannot find the hash, /status can respond with HTTP 404 and error code 1003 (other lookup paths can still return a NOT_FOUND body):
Without fromChain the message reads Transaction hash is not found in any chain. Treat this response like NOT_FOUND: normal for the first minute or two after broadcast, a problem if it persists. See Unknown and never-mined transaction hashes.

Substatus Definitions

PENDING

  • WAIT_SOURCE_CONFIRMATIONS: Waiting for source chain confirmations
  • WAIT_DESTINATION_TRANSACTION: Waiting for destination transaction
  • BRIDGE_NOT_AVAILABLE: Bridge API is unavailable
  • CHAIN_NOT_AVAILABLE: Source/destination chain RPC unavailable
  • REFUND_IN_PROGRESS: Refund in progress (if supported)
  • UNKNOWN_ERROR: Status is indeterminate

DONE

  • COMPLETED: Transfer was successful
  • PARTIAL: Only partial transfer completed (common for across, hop, stargate, amarok)
  • REFUNDED: Tokens were refunded

FAILED

  • NOT_PROCESSABLE_REFUND_NEEDED: Cannot complete, refund needed
  • OUT_OF_GAS: Transaction ran out of gas
  • SLIPPAGE_EXCEEDED: Received amount too low
  • INSUFFICIENT_ALLOWANCE: Not enough allowance
  • INSUFFICIENT_BALANCE: Not enough balance
  • EXPIRED: Transaction expired
  • UNKNOWN_ERROR: Unknown or invalid state
  • REFUNDED: Tokens were refunded

Unknown and never-mined transaction hashes

An unknown LI.FI hash does not prove the transaction was never mined. Possible causes include indexing delay, an incorrect source chain, a pending or replaced transaction, mempool eviction, or recording a hash other than the final broadcast transaction. A dropped transaction can still be rebroadcast later.
  1. Poll with backoff for a bounded window appropriate to the source chain. Elapsed time is not evidence of failure.
  2. First query the original hash’s receipt on the correct source chain (eth_getTransactionReceipt on EVM). A receipt means the original was mined, not replaced: handle a reverted source transaction as a source failure, or continue LI.FI/cross-chain reconciliation after source success. Apply your confirmation policy and account for reorgs.
  3. If there is no receipt, look up the original transaction (eth_getTransactionByHash on EVM). If pending, do not mark it replaced. A missing transaction or an RPC error does not prove it was dropped.
  4. For ordinary EVM account transactions, eth_getTransactionCount with latest can narrow the investigation, but nonce advancement can also mean the original was mined. Confirm replacement only after finding a different mined transaction on the same source chain with the same sender and nonce; a pending nonce does not prove inclusion. This nonce rule does not apply to non-EVM transactions or account-abstraction operation identifiers.
  5. Before binding a replacement hash to the original order, verify its actual operation (recipient, value, calldata and relevant events) continues the intended transfer. Speed-ups, cancellations and changed intent can all reuse a nonce. A cancellation does not complete the cross-chain operation; do not auto-bind when the original nonce or intent is unknown.
You may pause automatic polling at a duration limit, but preserve the unresolved state and transaction context for later reconciliation. Timeout, 404 and nonce advancement alone prove neither failure nor replacement and must not trigger an automatic resubmission.

Reconciling by wallet

When a tracked hash is unknown but the user’s funds may have moved under another hash, look up the wallet’s transfers instead of the hash:
Use status=ALL to include DONE, PENDING and FAILED; the default is DONE only. These are LI.FI-indexed candidates, not complete on-chain history; an empty result does not prove no replacement exists. Example response:
Chain pair, amount and timing only narrow candidates; they do not establish identity. For each candidate sending.txHash, verify the source chain, sender, nonce, receipt and intent as above before binding it to the original order and tracking /status?txHash=<sending.txHash>. Optional filters include fromChain, toChain and integrator. See the transfers endpoint reference.

Polling guidance

  • DONE and FAILED are terminal. Stop polling as soon as you receive one.
  • Back off: 10 seconds for the first minute, then 30 seconds, then 60 seconds, and cap the total duration. Most bridges complete within the quote’s estimate.executionDuration.
  • Persistent 404 / 1003 (or NOT_FOUND) is not terminal evidence. Reconcile on the source chain as above; stopping automatic polling does not establish failure or replacement.