Skip to main content
This guide covers how to create transfers, handle different asset types, and monitor transfer status using the DFNS API and SDK.

Prerequisites

  • Service account or authenticated user with Wallets:Transfers:Create permission
  • DFNS SDK installed and configured
  • Wallet with sufficient balance for the transfer and gas fees

Creating a native token transfer

Send native tokens (ETH, MATIC, SOL, etc.):

Request parameters

There is no network parameter — the network is inherited from the wallet (walletId) the transfer is created on.

Creating an ERC-20 token transfer

Send ERC-20 tokens:
Token amounts are in base units. USDC has 6 decimals, so 1 USDC = 1000000. ETH has 18 decimals, so 1 ETH = 1000000000000000000.

Creating an NFT transfer

Transfer ERC-721 NFTs:

Transfer with external ID

Use external IDs for your own tracking:

Checking transfer status

Get the status of a transfer:

Transfer statuses

For what to do when a transfer is stuck in a given status, see Troubleshooting stuck transfers.

Controlling fees and retrying a gas-failed transfer

The transfer endpoint estimates gas for you. The only fee control it exposes is the optional priority field, which accepts Slow, Standard (default), or Fast — under the hood this drives Estimate Fees to pick the fee level. Explicit gas overrides such as gasLimit or maxFeePerGas are not accepted on a transfer request; those exist only on the Sign & Broadcast Transaction endpoint (transaction kind: 'Eip1559'), where you assemble the raw transaction yourself. You set priority when you create a transfer:

Unsticking a transfer that is already in flight

Never submit a second Transfer Asset request to “retry” a transfer that has not reached a terminal status. If the original later gets mined, you will have sent the funds twice. Only create a new transfer once the previous one is Confirmed, Failed, or Rejected.
To change the fee of — or get rid of — a transfer that is already in progress, act on that transfer instead of creating a new one. On EVM networks:
  • Speed Up Transfer — for a transfer stuck in Broadcasted (in the mempool but not yet mined). Rebroadcasts the same transfer at a higher fee (the greater of a 10% bump or the Fast level) to get it mined. Use this when you still want the transfer to go through.
  • Cancel Transfer — for a transfer stuck in Broadcasted that you want to void. Submits a replacement 0-value transaction to your own wallet at the same nonce, nullifying the original. Use this when you no longer want the transfer to land.
  • Abort Transfer — for a transfer stuck in Executing (approved but not yet broadcast). Marks it Failed without any on-chain action, freeing reserved inputs such as Bitcoin UTXOs.
The safe recovery sequence for a stalled transfer is: cancel or abort it first so it settles to a terminal status, then submit a fresh transfer if you still need to move the funds. Speeding up keeps the original transfer — it does not create a duplicate. See Troubleshooting stuck transfers for the recommended action per status. The raw-transaction flow has the equivalent Speed Up Transaction, Cancel Transaction, and Abort Transaction endpoints.
If you need full control over gas (custom gasLimit, maxFeePerGas, maxPriorityFeePerGas, or replace-by-fee), build the transaction yourself and use Sign & Broadcast Transaction with kind: 'Eip1559' instead of the transfer endpoint.

Listing transfers

List transfers for a wallet:

Handling policy approvals

If a transfer triggers a policy that requires approval, the transfer enters a Pending state:
See managing policies for working with approvals programmatically.

Monitoring with webhooks

Subscribe to transfer events for real-time updates:
Handle webhook events:
See webhooks guide for complete webhook setup.

Polling for status

Alternative to webhooks - poll for transfer status:
See transaction monitoring for polling best practices.

Error handling

Handle common errors:

Transfer API

Complete API reference

Monitor transactions

Polling patterns

Set up webhooks

Real-time notifications

Manage policies via API

Handle policy approvals
Last modified on September 8, 2026