Skip to main content
After submitting a crosschain transaction via the Route or Bundle API, the bridge delivery is asynchronous. Enso provides protocol-specific status endpoints to track delivery progress on the destination chain.

Quick Reference

All endpoints accept two query parameters:
  • chainId — source chain ID (number)
  • txHash — source transaction hash (string, 0x + 64 hex characters)
Rate limit: All bridge status endpoints are limited to 1 request per 10 seconds per API key (or per IP if unauthenticated). Exceeding this returns HTTP 429. Enforce a minimum 10-second interval between polls.

Status Lifecycle

Bridge transactions progress through a unified status lifecycle:
  • pending — Source transaction confirmed, bridge protocol hasn’t picked it up yet
  • inflight — Bridge protocol is processing the cross-chain message
  • delivered — Tokens and callbacks successfully delivered on the destination chain
  • failed — Bridge or callback execution failed (check error and ensoDestinationEvent for details)
  • ready_for_manual_execution — Funds are recoverable, but the destination action needs manual completion: claim an attested CCTP transfer or retry a stored Stargate payload
  • unknown — Status could not be determined

Identifying the Bridge Protocol

When using the Route API, the response tells you which bridge was automatically selected:
  1. Check the route array for the hop where action === "bridge" — its protocol field contains the bridge protocol
  2. The bridgingEstimates array provides the protocol name and estimated delivery time

Status Check Endpoints

GET /api/v1/cctp/bridge/check — Check Circle CCTP v2 bridge transaction status.
Response fields:
Fast vs Standard detection: After the burn is attested, transferType is set from finalityThresholdExecuted (≤ 1000 = fast, ≥ 2000 = standard). This is the actual path Circle took — it can differ from your requested protocolArgs.transferType if Fast allowance was exhausted or the source chain didn’t support Fast.
Forwarding Service transfers: For a CCTP transfer with a forwarding hook, including a HyperCore deposit, status is delivered only after forward.state is complete. A Circle message marked complete can remain inflight while forwarding is pending, or return failed with the forwarding error details. Enso verifies the destination MessageTransmitter nonce before returning a non-delivered result, so a consumed nonce is reported as delivered even if Iris still has a stale forwarding failure state.
Manual claim: If a transfer gets stuck, call GET /api/v1/cctp/bridge/claim to get a ready-to-submit receiveMessage transaction for the destination chain. Transfers with a pinned destinationCaller, including HyperCore forwarding transfers, return claimable: false: only Circle’s forwarder can complete them. Both endpoints are rate-limited to 1 request per 10 seconds.
Attested plain transfers: ready_for_manual_execution means Circle has attested a transfer without a forwarding hook, but the destination receiveMessage mint has not run yet. Use the claim endpoint above. Enso keeps delivered when it cannot read the destination nonce, so temporary RPC failures do not falsely report that action is required.
Upstream source: this endpoint is backed by Circle’s Iris GET /v2/messages/{sourceDomainId} — Enso wraps it with on-chain enrichment (token metadata, chain IDs decoded from CCTP domains, executed-fee vs requested-fee). See Circle’s supported blockchains matrix for which chains support Fast Transfer.
GET /api/v1/relay/bridge/check — Check Relay bridge transaction status.
Response fields:
Fee breakdown: relayRequest.fees provides a detailed breakdown in wei (gas, fixed, price), and relayRequest.feesUsd gives USD equivalents for each component.
GET /api/v1/stargate/bridge/check — Check Stargate (LayerZero) bridge transaction status.
Response fields:
Multi-hop support: Stargate supports multi-hop transactions (up to 5 sequential bridges). When isMultiBridge is true, the hops array contains per-hop status tracking with individual sourceChainId, destinationChainId, status, and layerZeroMessage fields.
Stored LayerZero payloads: ready_for_manual_execution means a LayerZero message is blocked or stored and needs a retry or clearance before delivery can continue. It does not mean the funds are lost.

Callback Execution Events

Stargate, CCIP, and Relay include both ensoSourceEvent and ensoDestinationEvent in their responses — these track whether Enso’s callback logic executed successfully on each chain. CCTP returns only ensoSourceEvent. The destination side is Circle receiveMessage execution, including HyperCore forwarding when requested, so there is no Enso destination callback event. When a callback fails, refundDetails provides information about where funds were sent:

Resources

Updated