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.
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.
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.
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:
Recipient
The 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.
Amount
The 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.
Speed-up
Sends the same payment again with a higher fee. The form calculates the fee. You cannot change the fee, the recipient or the amount
Cancel
Replaces 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 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. 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.
Related
Last updated