How it works
On networks that support early detection (see the supported networks table), you can also subscribe to
wallet.blockchain_event.transfer.included to show users their incoming deposit before it’s confirmed (status: "Included"). Only sweep after wallet.blockchainevent.detected (status: "Confirmed") — sweeping an unconfirmed deposit risks a chain reorg.Implementation
Detect incoming deposits
When a deposit arrives, DFNS sends a See webhook signature verification for the implementation of
wallet.blockchainevent.detected event. Filter for incoming transfers:verifyDfnsWebhookSignature.Execute the sweep transfer
From your queue processor, create a transfer from the deposit wallet to your treasury wallet. The transfer
kind must match the deposit type.Gas fees
The deposit wallet needs native tokens to pay gas fees for the sweep transaction. This creates a chicken-and-egg problem: the wallet receives a token deposit, but may not have native tokens for gas. Two options:Option 1: Fee sponsor (recommended)
Use a fee sponsor so the deposit wallet doesn’t need to hold native tokens at all. A single funded fee sponsor wallet pays gas for all your sweep transactions.Option 2: Pre-fund with native tokens
Fund each deposit wallet with a small amount of native tokens when you create it. Top up as needed after sweeps. This works on all networks but requires more operational overhead.Batching sweeps
Instead of sweeping immediately after each deposit, you can batch sweeps on a schedule (e.g., every hour or once daily). This is particularly useful for:- UTXO networks (Bitcoin, Litecoin, Dogecoin): batching consolidates many small UTXOs and reduces total fees
- High-volume systems: reduces the number of transactions and associated gas costs
executeSweep inline.
Sweeping the full balance
The Transfer API requires an explicitamount, and there is no “send max” flag. To drain a wallet completely you must compute amount = balance − fee before transferring, because the fee is deducted from the same balance.
- Token sweeps (ERC-20, SPL, TRC-20, etc.): the gas fee is paid in the native token, not the token you’re sweeping. Sweep the full token balance as
amount, and cover gas separately with a fee sponsor or by pre-funding the wallet with native tokens (see Gas fees). - Native-token sweeps on account-based chains (EVM, Solana, TRON, etc.): estimate the fee with Estimate fees, then transfer
balance − estimatedFee. Leave a small margin so the transfer doesn’t fail if the fee rises between estimation and broadcast. - UTXO chains (Bitcoin, Litecoin, Dogecoin): the fee depends on the number of inputs and outputs. List the wallet’s balance, estimate the fee for a single-output transaction with Estimate fees, and transfer
balance − fee. A full-balance transfer leaves no change output. Note that full-balance UTXO transfers cannot be sped up afterward.
Production considerations
- Verify webhook signatures: Confirm events are from DFNS. See signature verification.
- Handle duplicates: Webhooks may be delivered more than once. Use
externalIdfor idempotency and track processed deposits in your database. - Reconciliation: Run periodic reconciliation jobs using wallet history to catch deposits your webhook may have missed.
- Policies: Add policies to control sweep behavior (e.g., velocity limits, amount thresholds). Service accounts should never have approval authority. Keep automation and oversight separate.
- Tier-1 networks only: Deposit detection via
wallet.blockchainevent.detectedis only available on Tier-1 networks. For Tier-2 networks, poll wallet history instead.
Related
Set up webhooks
Setup, verification, and best practices
Create transfers via API
Transfer API usage and asset types
Fee sponsors
Sponsor gas fees for your wallets
Automate deposits
Deposit detection and compliance