Skip to main content
After creating a swap, execute its ordered deposit_actions. Treat the API response as the transaction source of truth; do not hardcode recipient addresses, memos, calldata, decimals, or fee assets.

​
Read the actions

The create-swap response includes the actions. You can also fetch them again:
Each action describes work on the source network: Use amount_in_base_units for transaction construction. Decimal amount values are for display and can lose precision when converted through JavaScript numbers.

​
Understand the action type

  • transfer means your integration constructs or submits a source-network transaction using to_address, amount_in_base_units, and call_data.
  • manual_transfer means you show the generated address and exact amount to the sender. Its call_data is null, so the transfer can come from a wallet, custodian, or exchange.
  • A Depository-funded swap also returns a transfer action, but it targets the Depository contract. Follow Fund via the Depository contract.
  • Gasless funding returns typed data to sign instead of a transaction to broadcast. Follow Gasless deposits.
The available action depends on the funding method selected during swap creation. See Funding methods.

​
Execute by network

call_data has a different format on each network. Follow the matching guide instead of applying EVM assumptions to every chain.

​
Validate and track

Before requesting a signature, verify that the action matches the network, token, amount, and funding method the user approved. Submit call_data without changing its memo, instructions, or encoded swap identifiers. Store every submitted transaction hash, then track the swap. You can also report the hash with POST /swaps/{id}/deposit_speedup so Layerswap matches the deposit without waiting for its routine detection. An unmatched transfer can leave the swap waiting until expiry; an invalid amount can lead to failure and potentially a refund. Follow the swap lifecycle and refund flow instead of promising automatic recovery.