> 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 types, fees, unspent outputs, 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.
## Address types
New Bitcoin Accounts use **Native SegWit** addresses, which begin with `bc1`. This is the only type available when creating 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 types. Your approval Rules enforce governance, not an on-chain script. A Bitcoin Account therefore holds a single-signature address governed by your Policy.
### Sending to other address types
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 form offers fee strategies from slower and cheaper through to faster. You can also set a custom **sat/byte** value.
> **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 making up the balance. Sort them by value, block height, or confirmations, and filter by amount.
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.
You are warned at approval time when a transfer needs more than 100 outputs. The final selection happens immediately before broadcast, so the warning is an estimate of what the transfer will need.
An Account holding more than 100 unspent outputs is invited to consolidate them.
### Consolidating unspent outputs
Consolidation combines many small unspent outputs into one large one. It is available from the **UTXOs** tab of an Account.
A consolidation is a **self-send**: the Account pays itself. The Account's index #0 address must therefore be on a Whitelist that its Send Rule uses.
Like any transfer, a consolidation is a Request, it needs its approvals, and it pays a fee.
> **Editorial note (remove before publishing):** The consolidation flow is not yet shipped. The 100 output limit and the self-send mechanics are confirmed. Hold this section until the flow is live, then verify the tab labels and the Whitelist requirement against the product.
## 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.
Open the transaction and choose one of two actions:
Action
What it does
Speed-up
Sends the same payment again with a higher fee
Cancel
Replaces the payment with one that returns the funds to you
Each action creates a **new Request**. It needs the same approvals and the same review as the original transaction.
> **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.
## 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.
## 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)
* [**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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.