Skip to main content
In this section, you’ll learn how to request ready-to-use transaction data (bytecode) for depositing into a yield position.

Request Transaction Data

Fetch ready-to-use transaction data using:
Required Parameters:
The request-lend action is only for Ondo Global Markets strategies (tokenized stocks & ETFs), whose orders settle asynchronously. For every other yield strategy, use lend.
slippage is not accepted on these yield strategies. Passing it returns 400 SLIPPAGE_NOT_SUPPORTED. Only Ondo stock strategies on BSC and Ethereum accept it — see Order slippage.
Preview quotes without a connected wallet. wallet also accepts the zero address (0x000…0) or a well-known burn address (e.g. 0x000…dEaD, 0x111…, 0x222…). The response is priced exactly like a real request but includes previewOnly: true and omits id, bytecode, userOperation, singleUseAddress, and orderUid — no Action is created, and the address is never persisted or synced to Moralis/Helius.
A previewOnly response has no bytecode to sign. Use the user’s real, owned wallet address for any request you intend to execute.
Pick the section that matches how the user is funding the deposit. Each shows the extra parameters, an example request, and the response you get back.

Simple deposit

Deposit the strategy’s underlying token directly on the strategy’s chain — no swap or bridge. Only the required parameters above are needed, and crossChain.isCrossChain stays false. Example Request:
Example Response:

Same-chain swap deposit

When strategy routing is enabled, supported Aave and Morpho investments accept same-chain swaps and cross-chain bridge/swaps through this endpoint. Select the investment using its strategy ID and pass the source token, source chain and amount in that source token’s smallest unit. Use settlementMode=direct (the default for composed routes) to receive the initial wallet transaction. Use settlementMode=depositAddress to receive an address and funding instructions instead. After the source transaction is confirmed, the service completes the strategy deposit and delivers the receipt asset to destinationAddress ?? wallet. Track the returned Action ID; the customer does not submit a second transaction for the strategy deposit. Route availability depends on the selected provider, source asset, chain and strategy. A provider that cannot deliver verified proceeds to the settlement address is not eligible. The accepted final minimum is retained if the quote expires or market conditions change. Entry fees apply once to the actual strategy input; these investment routes do not add a platform swap fee. Exact-underlying Aave depositAddress requests continue using their existing funding-instruction response. Ordinary wallet deposits and integrations without strategy routing retain the behavior described below. Hold a different token on the strategy’s chain? Pass fromTokenAddress (with a fromChainId/chainIdIn matching the strategy chain) to swap into the underlying asset before depositing. The response prepends the swap transaction(s) before the deposit bytecode, and crossChain.isCrossChain stays false. Additional Parameters:
When fromTokenAddress is provided with a fromChainId matching the strategy chain, the API automatically prepends a same-chain swap from fromTokenAddress to the strategy’s underlying asset. The amount parameter refers to the amount of fromTokenAddress to swap, and crossChain.isCrossChain remains false.
Example Request: If you hold WETH but want to deposit into a USDC strategy, pass fromTokenAddress to swap first:
Example Response:

Cross-chain swap deposit

Funding from another chain? Pass a fromChainId/chainIdIn that differs from the strategy’s chain. The response adds a quote object describing the bridge selection, the resolved tokens, and the expected/minimum output amount, and sets crossChain.isCrossChain to true. Additional Parameters: Example Request: To bridge USDC on Base into a USDC yield strategy on Arbitrum, pass the Base fromChainId and fromTokenAddress:
Example Response:
The top-level id is used for execution tracking — store it and pass it to GET /actions/:id to track the cross-chain deposit through completion (see Checking Cross-Chain Deposit Status below).The quote object describes which bridge was selected (bridge), the expected outputAmount, and the worst-case minimumOutputAmount (slippage floor). Display these to the user before they sign.

Output format options

By default the endpoint returns raw bytecode. These optional parameters change the response format and apply to any of the deposit types above. Example Request (Fireblocks output): If you are using Fireblocks custody, set output=fireblocks and pass your vault accountId. The wallet parameter must be a smart wallet previously provisioned via POST /fireblocks-smart-account (see Fireblocks Integration).
Example Response:
The transactionData.transactionRequest payload can be submitted directly to the Fireblocks Transactions API (POST /v1/transactions) — no further encoding required. The Earn Owner vault must be configured as the signer (see Fireblocks Integration).
Use GET /strategies to list available protocols, then pass the chosen strategy ID into the bytecode endpoint above.

Executing the Transaction

Batch all bytecode legs on the same chainId into one atomic transaction. Do not loop sendTransaction per leg. See Executing Bytecode.

Checking Cross-Chain Deposit Status

Cross-chain deposits are asynchronous: the source-chain bridge transaction is signed first, then the bridged funds are delivered and deposited on the destination chain. To track progress to completion, use the id returned in the bytecode response:
Path Parameters: Example Request:
Example Response (deposit in flight):
Status values: Poll this endpoint until status reaches a terminal value (SUCCESS, FAILED, REFUNDED, or EXPIRED). The transactions array lists each on-chain hash as it is confirmed, so you can surface progress to the user as the bridge and the destination-chain deposit complete in sequence.
Same-chain deposits do not need this polling — the deposit completes inline with the user’s signed transaction. The id is still returned for record-keeping and can be queried the same way.

Webhook notifications

Pods can push action updates for this deposit to your server. data matches GET /actions/:id. Pass webhookURL on the bytecode request to override the customer default for this deposit. Registration, the signature headers, and delivery rules are in Webhooks. EXPIRED is visible on GET /actions/:id and is not pushed.

Next Steps

Check Positions

Monitor your open yield positions

Withdraw

Learn how to withdraw from positions