Bitcoin is the original cryptocurrency using a UTXO (Unspent Transaction Output) model. This guide covers Bitcoin-specific features when using Dfns wallets.
UTXO model
Unlike account-based blockchains, Bitcoin uses UTXOs. Each transaction consumes existing UTXOs and creates new ones. Key implications:
- UTXO selection: Dfns automatically selects UTXOs for your transactions, including unconfirmed UTXOs from pending transactions
- Consolidation: Many small UTXOs can increase transaction fees; consider consolidating by sending funds to yourself
When Dfns builds transactions, it may use unconfirmed UTXOs as inputs. This creates an implicit Child-Pays-for-Parent (CPFP) relationship where miners are incentivized to confirm both the parent and child transactions together to collect both fees.
Multiple addresses
If you need multiple Bitcoin addresses (e.g., one per customer for deposit tracking), create a separate key for each address. Each key generates an independent Bitcoin wallet with its own address. Key creation scales the same whether you need hundreds or millions of addresses.
Dfns uses MPC rather than HD (BIP-32/BIP-44) derivation. There are no seed phrases or derivation paths — each key’s shares are generated and stored independently. This provides the same outcome (unique addresses per customer) with stronger isolation between keys.
For a complete deposit tracking implementation using unique wallets, see Matching deposits to your records.
Address types
Dfns supports multiple Bitcoin address types:
| Address Type | Prefix | Signature |
|---|
| Pay-to-Taproot (P2TR) | bc1p... | Schnorr |
| Pay-to-Witness-Public-Key-Hash (P2WPKH) | bc1q... | ECDSA |
EdDSA or Schnorr for Taproot addressesECDSA for SegWit addresses
Transfers
Use the Transfer Asset endpoint with kind: Native to send BTC. Specify the amount in satoshis (1 BTC = 100,000,000 satoshis).
Fee priority
Bitcoin fees are based on network congestion. Use the priority field to control fees:
| Priority | Description |
|---|
Slow | Lower fees, longer confirmation time |
Standard | Balanced fees and confirmation time |
Fast | Higher fees, faster confirmation |
Fee bumping
Bitcoin supports two mechanisms to increase fees on pending transactions: Replace-By-Fee (RBF) and Child-Pays-For-Parent (CPFP).
Replace-By-Fee (RBF)
All Dfns Bitcoin transactions are RBF-enabled by default. If a transaction is stuck in the mempool, use the Speed Up Transfer endpoint to replace it with a higher-fee transaction.
RBF works by creating a new transaction that:
- Reuses the same inputs as the original transaction
- Pays to the same recipient with the same amount
- Includes higher fees (deducted from the change output)
The original transaction must have a change output for RBF to work. Transactions that send the exact full balance cannot be sped up using this endpoint.
Child-Pays-For-Parent (CPFP)
CPFP works by spending an unconfirmed output with a high enough fee to incentivize miners to confirm both the parent and child transactions together.
Dfns enables implicit CPFP by including unconfirmed UTXOs in transaction building. For explicit CPFP transactions, use the SDK to build a custom PSBT that spends the unconfirmed output. See SDK integration below.
SDK integration
For full transaction control, use the Dfns SDK with bitcoinjs-lib. This allows you to:
- Select specific UTXOs (including unconfirmed ones for explicit CPFP)
- Build custom PSBTs with multiple inputs and outputs
- Set custom fee rates
See the PSBT signing example for building and signing custom transactions.
