> For the complete documentation index, see [llms.txt](https://help.enterprise.ledger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.enterprise.ledger.com/help-center-v2/reference/networks/bitcoin.md). # Bitcoin (BTC) Bitcoin on Ledger Enterprise: the UTXO model, address formats and options, fees, unspent outputs, stuck and failed transactions, message signing, and what is not available. ## How Bitcoin differs Bitcoin does not hold a balance as a number. It holds a set of discrete **unspent outputs**, each one the change from an earlier payment. An Account's balance is the sum of its unspent outputs. Two consequences follow, and both are visible in this product: * A transfer spends whole outputs. It rarely matches the amount exactly, so it returns change to you. * The fee depends on the **size** of the transaction in bytes, not on the amount. Spending many small outputs costs more than spending one large one. Readers who know Ethereum should note that there are no contracts, no tokens and no Account balances on Bitcoin. For the protocol itself, see the [Bitcoin developer documentation](https://bitcoin.org/en/developer-documentation). ## Token coverage Ledger Enterprise supports **BTC only** on Bitcoin. There are no token Accounts on this network. ## Addresses New Bitcoin Accounts use **Native SegWit** addresses, which begin with `bc1`. This is the only address format available when you create an Account, and it gives the lowest fees. Existing **legacy** Accounts continue to work normally for sending and receiving. New ones cannot be created. **Multi-signature script addresses are not supported**, as Accounts or as address formats. Your approval Rules enforce governance, not an on-chain script. A Bitcoin Account therefore holds a single-signature address governed by your Policy. ### Dynamic and Static addresses When you create a Bitcoin Account, the **Address options** field sets how the Account receives: * **Dynamic**, the default: a new address for each payment, derived from the Account's extended public key (xpub). * **Static**: one reusable address, the Account's first receive address (index #0). All payments to the Account are then linked to each other, so this option gives less privacy. You cannot change this option after the Account is created. The **Account info** tab shows it as **Address type**: **Dynamic** or **Static**. The API offers the same choice at creation. See the [API documentation](https://help.enterprise.ledger.com/api-documentation-v2). ### Sending to other address formats You can send to any valid Bitcoin address, including legacy, Nested SegWit, and Native SegWit destinations. The address is validated for format before you can continue. ## Fees The fee shown is a **Max fee**, in BTC: `Max fee` = `Estimated base fee` + `Buffer`, where the buffer is **400%** of the estimated base fee. The buffer exists because a Bitcoin fee depends on network congestion and on transaction size. A transfer of the same amount can cost different fees on different days. You pay the actual network cost at broadcast, and the unused buffer stays in the Account. The send form offers four fee strategies: **Normal**, **Fast**, **Urgent** and **Custom**. **Fast** is the default. **Custom** opens the **Custom fee** dialog, where you enter a value in **Sat/vByte**. The interface and the API both accept at most 2,147,483 sat/vB. A Speed-up or a Cancel does not offer this choice. See [If a transaction is stuck](#if-a-transaction-is-stuck). > **Note:** If a transfer fails because the required fee exceeded the authorized maximum, create it again with a faster strategy. Nothing moved and nothing was spent. ## Unspent outputs The **UTXOs** tab lists the individual unspent outputs that make up the balance. It shows on Bitcoin Accounts only. * Columns: **Address**, **Spendability**, **Height**, **Confirmations** and **Amount**. * Sort order: by **Amount**, **Height** or **Confirmations**. The default order is by **Amount**, largest first. * Filters: an **Amount** range, a **Height** range, and the **Hide not worth spending** checkbox. The list includes unconfirmed outputs, with 0 **Confirmations**. The **Spendability** column tags the outputs that the platform does not spend: * **Not worth spending**: at current fees, the output costs more to spend than it holds. * **Banned**: the output is excluded from spending. The list is read-only. It reconciles against your own records, and it explains a fee that is higher than expected. Many small outputs mean a larger transaction in bytes. ### The 100 output limit **A transaction can draw on at most 100 unspent outputs.** A transfer that needs more than 100 fails. The send form checks this when it estimates the fee. Two different errors can appear beside the fee. Either one stops the form: * The amount needs more than 100 outputs. Send a smaller amount, or consolidate the outputs first. * The Account holds more outputs than one transaction can spend. This error can appear even for a small amount. Consolidate the outputs first. The final selection happens immediately before broadcast, so this check is an estimate. ### Consolidating unspent outputs Consolidation combines many small unspent outputs into a few large ones. There is no dedicated action for it. You consolidate by sending from the Account to itself. Create the transfer as described in **Sending assets**, with these values:
FieldValue
RecipientThe Account's own index #0 address. On a Static Account, the Receive window shows it directly. On a Dynamic Account, set Index to 0 in the Receive window.
AmountThe available balance, minus the maximum fee
The transfer spends the outputs and returns their value to the Account. Outputs tagged **Not worth spending** or **Banned** are not spent. They stay in the Account. The send form can refuse a consolidation. This happens when the fees would leave less than the minimum amount that an output needs. Try again when network fees are lower. The platform selects which outputs to spend. You cannot choose them. The self-send must match a Send Rule, like any transfer. If those Send Rules only allow whitelisted destinations, add the index #0 address to one of their Whitelists first. A consolidation is a Request. It needs its approvals, and it pays a fee. The fee grows with the number of outputs spent, because each one adds to the size of the transaction. ## If a transaction is stuck A Bitcoin transaction can stay unconfirmed for a long time. This happens when its fee is too low for current network demand. Bitcoin lets you replace an unconfirmed transaction with a new one that pays a higher fee. This is called **Replace by Fee**. Use it to speed the transaction up, or to cancel it. The two actions are on the original **Request**, not on the operation: * In the **Requests** list, on the row of the Request: the Speed-up icon, labeled **Speed-up transaction**, and **Cancel transaction** in the row actions menu. * In the Request details: the **Speed-up** and **Cancel** buttons. The **Operations** tab does not offer them. In the interface, only the user who created the original Request sees them, and only while its transaction is unconfirmed. Over the API, any user who can create the matching send can replace the transaction. See the [API documentation](https://help.enterprise.ledger.com/api-documentation-v2).
ActionWhat it does
Speed-upSends the same payment again with a higher fee. The form calculates the fee. You cannot change the fee, the recipient or the amount
CancelReplaces the payment with one that sends the same amount back to the Account: to a fresh address on a Dynamic Account, or to the static address on a Static Account
Each action creates a **new Request**, which you send to your Ledger device with **Review**. The form matches the new Request against the Send Rules again, like any transfer: * A Speed-up keeps the recipient and the amount, so it normally matches the same Rule as the original. * A Cancel pays an address of the Account itself. Under a Send Rule that allows only whitelisted addresses, a Cancel can find no matching Rule. On a Static Account, add the static address to a Whitelist of that Rule. > **Important:** Cancel does not make the transaction free. You still pay a fee for the replacement. Cancel stops the transfer, it does not undo the cost. Only one of the two transactions can confirm. Until one does, either still can. A replacement is not instant. It has to be approved, then it competes on the network like any other transaction. A replacement priced at or below the original may also stick. Each Bitcoin transaction accepts one replacement. You cannot speed up a replacement. If the replacement ends **Failed** (`FAILED`) or **Dropped** (`DROPPED`), the original transaction accepts a new replacement. You cannot speed up or cancel a transaction with the status **Failed**. The network did not accept it, so there is nothing to replace. ## If a transaction fails because of unconfirmed incoming transactions. A Bitcoin transaction can reach the status **Failed** (`FAILED`). The network did not accept it. Nothing moved. The **History** section of the Request shows the reason. A common cause is large incoming transactions that pay a low fee and stay unconfirmed. A new transaction that spends their outputs joins them in a **cluster**. Bitcoin Core refuses a cluster of more than 64 transactions or 101 kvB. The network error is `too-large-cluster`. > **Note:** These limits are the Bitcoin Core defaults. They were checked against the [Bitcoin Core 31.0 release notes](https://bitcoincore.org/en/releases/31.0/) on 7 October 2026. To confirm the cause, open the Account **Overview**. In the **Balance details** card, **Incoming 0** shows the incoming amount that has no confirmation yet. The **UTXOs** tab also lists these outputs, with 0 **Confirmations**. The problem stops when the incoming transactions confirm. Until then, a new attempt can fail for the same reason. To clear it: * **Wait** for network fees to fall. This can take from a few hours to several days. * **Ask the sender to raise the fee** on the incoming transactions. Only the sender can replace them. > **Warning:** Do not ask the sender to replace an incoming transaction that one of your pending transactions spends. Your pending transaction is then removed, and you must create it again. To prevent it, send deposit sweeps and other large consolidations at a fee rate that matches the network, not the minimum. For help, give Support the Request ID of the failed transaction and the hash of each unconfirmed incoming transaction. ## Signing messages A Bitcoin Account can sign a message. See [**Signing messages**](/help-center-v2/guides/transactions/signing-messages.md). The address that signs depends on the address option: * On a Static Account, the form uses the static address. * On a Dynamic Account, you enter an address of the Account. The platform refuses an address that the Account does not own. ## What is not available There is no coin control. You cannot choose which unspent outputs fund a transfer, and there is no change-address picker. The platform selects the outputs for you. ## Testnet Ledger can also enable a Bitcoin testnet, testnet4, for a Workspace. Its assets have no market value. See [**Testnets**](/help-center-v2/reference/networks.md#testnets). ## Related * [**Sending assets**](/help-center-v2/guides/transactions/sending-assets.md) * [**Finding Accounts and balances**](/help-center-v2/guides/accounts/finding-accounts-and-balances.md) * [**Signing messages**](/help-center-v2/guides/transactions/signing-messages.md) * [**Networks**](/help-center-v2/reference/networks.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.enterprise.ledger.com/help-center-v2/reference/networks/bitcoin.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.