> ## 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. # Module 2: Bitcoin and stablecoins as settlement tools > What bitcoin and stablecoin settlement makes possible for a payout product, and the risks that come with it. Bitcoin and stablecoins are not alternative currencies that you add beside a bank transfer. They are different settlement tools. They move faster, they reach further, and they do not depend on a bank to complete a transfer. That difference creates opportunities. It also creates risks that a bank rail does not have. This module covers both. ## What you will learn * What bitcoin changes about settlement, and what stablecoins change * Which opportunities each one opens for a payout product * Which risks you must design for before you launch ## What bitcoin changes | Property | Bank rails | Bitcoin | | - | - | - | | Custody | A bank holds the value. | You can hold the value yourself. | | Finality | An intermediary can reverse a transfer. | A confirmed transfer is final. | | Availability | Banking hours, holidays, and cut-offs apply. | The network runs every day, at all hours. | | Reach | Each corridor needs a bank relationship. | Any address on the network can receive. | | Price stability | Stable against the local currency. | The fiat value moves, sometimes within minutes. | Three consequences follow for a payout product: 1. You can move value across a border without a correspondent bank. 2. You get liquidity at any hour, but you must wait for confirmations and carry price risk. 3. You must catch an error before you send, because you cannot reverse the transfer afterwards. ## What stablecoins change | Property | Bank rails | Stablecoins | | - | - | - | | Price stability | Local currencies can move sharply. | The token tracks a reference asset, usually the US dollar. | | Settlement time | Clearing can take days. | A transfer completes in minutes. | | Treasury | You need a bank account in each market. | You hold one balance and pay out from it. | | User access | The recipient needs a bank account. | The recipient needs a mobile wallet. | Three consequences follow: 1. You hold dollar liquidity without a bank account in every market. 2. You reconcile faster, because the transfer and the record arrive together. 3. You can pay users who have a phone but no bank account. ## The opportunities * **Wider coverage.** Reach users in Africa, Asia, and Latin America without a local bank partner. * **Faster settlement.** Deliver in hours rather than days. * **Lower cost.** Remove the correspondent banking layer and its fees. * **New users.** Serve people who use mobile money and have no bank account. * **Continuous operation.** No holidays, no cut-off times. ## The risks * **Price risk.** If a user funds with bitcoin and you pay out fiat, the price can move before you settle. * **Liquidity risk.** Chain congestion, a depleted Lightning channel, or a bridge outage can delay funding. * **Compliance still applies.** Faster settlement does not remove KYC, KYB, or sanctions screening. * **Errors are final.** You cannot reverse a bitcoin transfer or most stablecoin transfers. * **Users need teaching.** Most users do not know what a confirmation is, or why a fee changes. > [!WARNING] > > Price risk and finality combine badly. If you quote a fiat amount, wait for three confirmations, and the price falls in between, you pay the difference. Decide who carries that risk before you launch, not after the first loss. ## Three failures to design against **A price move during the funding window.** A user funds a payout with bitcoin. The price falls 3% before you settle the fiat side. Without a buffer in your pricing, you absorb the loss or underpay the recipient. **A transfer on the wrong chain.** A user sends USDT on Ethereum when your address is on Tron. If you do not validate the chain before you show the address, the funds are delayed or lost. See [Supported chains](https://www.bitnob.dev/docs/stablecoins/supported-chains.md). **A payout at 11pm on a public holiday.** Bitcoin does not observe holidays, so the funding arrives. Your system must detect it, confirm it, and pay out within the time you promised, without a person on duty. ## What this changes for you * Model the price movement across the whole funding-to-settlement window. * Build for finality. Do not design a refund flow as your main error path. * Monitor liquidity the way a treasury desk does, continuously. * Explain confirmation time, fees, and finality to users before they commit. ## Checklist for product managers * Decide whether you accept bitcoin funding, stablecoin funding, or both. * Measure your funding-to-settlement window, and set a price buffer that covers it. * Write a liquidity policy and an alert threshold before launch. * Design the user flow to state speed, confirmations, and finality in plain words. * Agree the liquidity plan with your treasury and operations teams early. ## Summary Bitcoin and stablecoins do not only move faster than bank rails. They move differently. They give you freedom from banking hours and correspondent banks, and in exchange they require tighter discipline, clearer communication, and active liquidity management. > [card] [Next: Funding models](https://www.bitnob.dev/learn/courses/payouts-for-product-managers/module-3.md) > > Custodial or dynamic funding, and how the choice shapes the product. > [card] [See it in the API](https://www.bitnob.dev/docs/payouts/settlement-models.md) > > How the two funding models work on Bitnob. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.