Skip to main content
This guide walks through the complete deposit flow for integrating Yieldo into a frontend application.

Overview

The user only signs the approval (for ERC-20 deposits) and the deposit transaction itself. V3.2.0 does not require any EIP-712 intent signature — deposits are direct depositFor (same-chain) or depositForAvailable (cross-chain composer destination) calls.

Step 1: Select a Vault

Fetch available vaults and let the user choose one.

Step 2: Get a Quote

Once the user specifies a source chain, token, and amount, request a quote.
The response contains:
  • estimate - Expected output amount, estimated shares, gas cost
  • approval - Token approval details (if needed)
  • route_options - Available bridge routes for cross-chain deposits (with bridge name, logo, estimated time, gas cost)

Step 3: Approve Token Spending

If quoteData.approval is not null, the user needs to approve the token first.
Tip: For native token deposits (e.g., ETH), the approval field will be null and you can skip this step.

Step 4: Build the Transaction

Submit the deposit details to get the final transaction. Optionally pass a preferred_bridge if the user selected a specific route.

Step 5: Send the Transaction

Send the transaction using the user’s wallet.

Step 5b: Handle Two-Step Cross-Chain Deposits

For certain vault types (Midas, Veda, Custom, IPOR, Lido), the build response has two_step: true. LiFi Composer doesn’t natively understand these deposit interfaces, so we split the flow:
  1. Step 1 = bridge tokens to the user’s wallet on the destination chain (the main transaction_request)
  2. Wait for LiFi to confirm the bridge is DONE
  3. Step 2 = same-chain deposit on the destination, using buildData.deposit_tx
The user’s tokens are always safe — they land in the user’s wallet after the bridge. Step 2 can be retried if anything fails.

Step 6: Track the Deposit

For cross-chain deposits, poll the status endpoint until the transfer completes.

Complete Example