Skip to main content
This guide covers the specifics of cross-chain deposits, where the user’s tokens originate on a different chain than the target vault.

​
How It Works

When a user deposits from a different chain (e.g., Arbitrum USDC into a Base vault), Yieldo offers two flows depending on the target vault type:

​
Single-Step (LiFi Composer)

Used for Morpho and other standard ERC-4626 vaults.
LiFi’s bridge receiver (Executor / ReceiverAcrossV4 / ReceiverStargateV2 / etc.) calls router.depositForAvailable(...) with user=<user>. V3.1.1 removed the authorizedCallers gate so any LiFi receiver works without a router upgrade. V3.2.0 made the call use depositForAvailable so the receiver doesn’t need to know the exact post-bridge amount — the router sweeps min(allowance, balance). No user signature beyond the bridge tx.

​
Two-Step

Used for vault types LiFi Composer doesn’t natively understand (Midas, Veda, Custom, IPOR, Lido).
Step 2 is a normal same-chain deposit signed by the user. Tokens are always safe in between — they sit in the user’s own wallet. The build response signals the flow via two_step: true|false. See the Deposit Flow guide for code examples of each.

​
Quote Types

The API returns a quote_type field that tells you what kind of deposit this is:

​
Slippage Handling

Cross-chain deposits have additional slippage considerations:
  • User-specified slippage (slippage parameter, default 3%) — applied to the LiFi swap/bridge.
  • Cross-chain slippage buffer — the API applies an extra ~1% buffer on the amount that will arrive on the destination, so the deposit succeeds even if the bridge slippage lands a hair below quoted.
  • Router-level minSharesOut — V3.1.0 supports an 8-arg depositFor with an on-chain share floor. The API currently emits the 7-arg compat form (minSharesOut=0) during the rollout window and will switch to the 8-arg form with a computed floor in a follow-up release.

​
Bridging

Yieldo uses LiFi to find the best bridge route. The API automatically:
  • Selects the optimal bridge protocol
  • Excludes unreliable bridges (Near, Maya, Meson, Socket)
  • Uses the same bridge for the contract-call transaction as the initial quote
The tracking.bridge field in the build response tells you which bridge was selected (e.g., "stargate", "across", "hop").

​
Tracking Cross-Chain Transfers

Cross-chain deposits take time (typically 1-10 minutes depending on the bridge). Use the status endpoint to track progress:

​
Status Progression

  • NOT_FOUND — Transaction not yet indexed by LiFi (normal for first few seconds)
  • PENDING — Bridge transfer in progress
  • DONE — Tokens received on destination chain
  • FAILED — Something went wrong
Poll every 15 seconds. Most transfers complete within 2–5 minutes.

​
Verifying the Deposit On-Chain

Once the bridge is DONE:
  • Single-step — the same LiFi tx on the destination emits the router’s Routed(partnerId, partnerType, user, vault, asset, amount, shares) event. Indexers can read shares directly from the event (V3.1.0).
  • Two-step — the user’s own step-2 tx emits Routed(...) on the destination chain.
The /v1/positions endpoint consumes the same event to power portfolio reads — Routed is the canonical record for attribution and position computation.

​
Source Chain Support

Use GET /v1/tokens?chain_id={id} to get the exact list of tokens for each chain.

​
Error Scenarios