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

> ## Agent Instructions
> Bitnob API requests authenticate with an `X-Auth-Client` API key header against https://api.bitnob.com.
> Always use the sandbox environment for testing. Never put live API keys in sample code.
> Money amounts are integers in the smallest unit of the currency (satoshis for BTC, cents for fiat). Never use floats.
> Every state-changing request takes a client-supplied `reference` and must be treated as idempotent on retry.
> Quotes expire. Re-quote rather than reusing a stale quote id.

# Custody models

> Three ways to hold bitcoin on Bitnob: the default custodial wallet, business-managed custody over managed RPC, and self-custodial user wallets.

Who holds the keys is the first architectural decision in any Bitcoin product, and Bitnob supports all three answers. Everything else in this section follows from which one you pick.

| Model | Keys held by | Bitnob provides | Fits |
| - | - | - | - |
| Custodial (default) | Bitnob | The full wallet: balances, on-chain and Lightning send and receive, webhooks. | Most integrations. Zero key management. |
| Business-managed custody | Your business, on your infrastructure | Node infrastructure over managed RPC: address generation, monitoring, broadcasting, chain queries. | Exchanges, neobanks, treasuries that must control keys. |
| Self-custodial | Your end users, on their devices | Broadcast, fee estimation, and monitoring APIs; no keys ever leave the device. | Wallet apps competing on sovereignty. |

## Custodial: the default

Every Bitnob account starts with a custodial Bitcoin wallet. Bitnob manages the private keys; you integrate the API for storing, sending on-chain, sending over Lightning, and receiving to any supported address format. If you are not sure which model you need, start here: [Send bitcoin on-chain or over Lightning](https://www.bitnob.dev/docs/bitcoin/send-bitcoin.md) works against this wallet with no key management at all.

## Business-managed custody

You generate and store private keys on your own infrastructure; users have accounts inside your application; Bitnob supplies the Bitcoin node layer, so you never run Bitcoin Core yourself. Bitnob cannot access keys and never touches funds; it relays blockchain information and signed transactions.

This is the model behind custodial products you operate: exchanges, crypto neobanks, internal treasuries, payment processors. The endpoint catalog and integration flow are in [Run business-managed custody](https://www.bitnob.dev/docs/bitcoin/business-managed-non-custodial-bitcoin-wallets.md).

## Self-custodial

Keys are generated and held on the user's device; signing happens locally; your backend never sees a private key or seed phrase. Bitnob's role shrinks to infrastructure: broadcasting signed transactions, estimating fees, and watching addresses for activity.

You take on wallet engineering, BIP39 seeds, derivation, coin selection, typically via a toolkit like BDK. The build guide is [Build self-custodial wallets](https://www.bitnob.dev/docs/bitcoin/user-managed-self-custodial-wallets.md).

## Address types

All three models speak the same address formats: Legacy (P2PKH), Nested SegWit (P2SH), Native SegWit (P2WPKH, recommended default), and Taproot (P2TR). The cost and privacy trade-offs between them are covered in [UTXO management](https://www.bitnob.dev/docs/bitcoin/utxo-management-introduction.md) and [Fees and confirmation strategy](https://www.bitnob.dev/docs/bitcoin/fee-market-and-transaction-strategies.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.