> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dfns.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Bitcoin

> Network-specific features, PSBT signing, Taproot support, UTXO handling, and integration requirements for Bitcoin wallets on the Dfns platform.

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

<Note>
  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.
</Note>

## 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](/core-concepts/how-mpc-wallets-work) 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](/guides/developers/transaction-monitoring#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     |

When creating a Bitcoin wallet, specify the key scheme:

* `EdDSA` or `Schnorr` for Taproot addresses
* `ECDSA` for SegWit addresses

## Transfers

Use the [Transfer Asset](/api-reference/wallets/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     |

Dfns uses the [Estimate Fees](/api-reference/networks/estimate-fees) endpoint to calculate appropriate fees.

## 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](/api-reference/wallets/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)

<Warning>
  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.
</Warning>

### 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](#sdk-integration) below.

## SDK integration

For full transaction control, use the Dfns SDK with [bitcoinjs-lib](https://github.com/bitcoinjs/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](https://github.com/dfns/dfns-sdk-ts/blob/m/examples/libs/bitcoinjs/basic-tx/main.ts) for building and signing custom transactions.

## Related resources

* [Bitcoin broadcast examples](/api-reference/broadcast/bitcoin)
* [Bitcoin signing examples](/api-reference/sign/bitcoin)
* [Supported networks](/networks)