Skip to main content

​
Get Transfer Status

Track the progress of a cross-chain deposit by its source transaction hash. Backed by LiFi’s transfer tracker. 
GET /v1/status

​
Query Parameters

ParameterTypeRequiredDescription
tx_hashstringYesSource chain transaction hash
from_chain_idintegerYesSource chain ID
to_chain_idintegerYesDestination chain ID

​
Example Request

curl "https://api.yieldo.xyz/v1/status?tx_hash=0xabc...&from_chain_id=42161&to_chain_id=8453"

​
Response

{
  "status": "DONE",
  "substatus": null,
  "sending": {
    "tx_hash": "0xabc...",
    "tx_link": "https://arbiscan.io/tx/0xabc...",
    "amount": "1000000000",
    "chain_id": 42161
  },
  "receiving": {
    "tx_hash": "0xdef...",
    "tx_link": "https://basescan.org/tx/0xdef...",
    "amount": "999500000",
    "chain_id": 8453
  },
  "bridge": "stargate",
  "lifi_explorer": "https://explorer.li.fi/tx/0xabc..."
}

​
Status Values

StatusDescription
DONETransfer completed AND the user’s wallet received a share-mint event
PENDINGTransfer is in progress
FAILEDTransfer / deposit reverted on-chain
NOT_FOUNDTransaction not yet indexed
The DONE status is verified end-to-end — the API checks the destination receipt for an ERC-20 Transfer(from=0, to=user, ...) event of the vault’s share token before reporting completion. If the bridge or composer call delivered tokens to the user’s wallet but the actual deposit didn’t mint shares (e.g. a silent composer drop, or a vault rejected the deposit at the function level), the status stays as partial rather than incorrectly reporting DONE. See substatus for the specific reason.

​
Response Fields

FieldTypeDescription
statusstringCurrent transfer status
substatusstring/nullAdditional status detail from LiFi
sendingobject/nullSource chain transaction info
receivingobject/nullDestination chain transaction info
bridgestring/nullBridge protocol used
lifi_explorerstring/nullLink to LiFi explorer for this transfer

​
Errors

StatusDescription
404Transaction not found

​
Verifying the Deposit On-Chain

The Yieldo router (V3.2.0) does not use signed deposit intents. Once the bridge is DONE, the deposit has either already happened (single-step / Composer flow — the bridge receiver called depositForAvailable atomically) or is pending the user’s step-2 tx (two-step flow — for non-composer vault types like Veda / Midas / Lido). In both cases the router emits: 
event Routed(
    bytes32 indexed partnerId,
    uint8 partnerType,
    address indexed user,
    address indexed vault,
    address asset,
    uint256 amount,
    uint256 shares
);
Filtering this event for user == <user> and vault == <vault> on the destination chain gives you a definitive on-chain record of the deposit and the exact shares minted. The same event powers /v1/positions for portfolio reads.