> ## 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.

# Stablecoin operations guide

> Daily operating procedures for teams running live USDT and USDC flows across chains.

This section is for your operators and support teams managing the live flow of USDT/USDC through Bitnob and the external blockchain networks.

## Key responsibilities

### Finance & treasury ops

* Monitor [wallet balances](https://www.bitnob.dev/api-reference/balances/list-balances.md) across chains
* Keep balances funded and manage liquidity thresholds
* Oversee reconciliation and transaction finality

### Customer support

* Investigate missing deposits, failed transfers, or wrong chain usage
* Escalate stuck transactions or edge cases to engineering
* Communicate clearly with customers using txHash, reference, and chain context

### Risk & compliance

* Flag unusual transfer patterns or wallet usage
* Monitor webhook failure rates
* Ensure address whitelisting and transfer limits are enforced if enabled: [Validate Address](https://www.bitnob.dev/api-reference/addresses/validate-address.md) confirms an address belongs to the expected chain

## Monitoring tools

| Tool | What to Monitor |
| - | - |
| Webhook logs | Delivery failures, retries, latencies |
| Transfer status tracker | Transfers stuck in pending for too long |
| Wallet balance dashboard | Liquidity thresholds per chain/token |
| Audit log | Key usage, manual overrides, replays |
| Reconciliation reports | Bitnob vs internal ledger differences |

## Standard operating procedures (SOPs)

### 1. Deposit not showing up

* Confirm chain, token, and address used by customer
* Lookup the [Bitnob transaction record](https://www.bitnob.dev/api-reference/transactions/get-transaction-by-id.md), then the chain explorer using txHash
* Check Bitnob webhook log for deposit.success: see the [deposit webhook payload](https://www.bitnob.dev/docs/stablecoins/address-webhook-events.md#webhook)
* If not received: escalate to Engineering with txHash and address

### 2. Transfer in pending status > X mins

* Lookup transfer by reference using [Get Transaction By ID Or Reference](https://www.bitnob.dev/api-reference/transactions/get-transaction-by-id.md), and check it against the [withdrawal status lifecycle](https://www.bitnob.dev/api-reference/withdrawals/initiate-withdrawal.md)
* Check chain congestion / gas status
* If gas fees look too low → escalate. Don't resubmit with a new reference, because that can send the funds twice.
* If tx broadcasted but not confirmed → monitor block height
* If stuck >30 mins → initiate escalation protocol

### 3. Webhook delivery failure

* Contact Bitnob support to retry the delivery
* If issue persists:
  * Validate destination endpoint status
  * Check [signature verification](https://www.bitnob.dev/api-reference/webhooks.md#verify-every-delivery) is not failing silently, and that any IP allowlist still matches the published [Source IPs](https://www.bitnob.dev/api-reference/webhooks.md#source-ips)
  * Notify integration partner (client)

### 4. Wrong chain deposit

* Unfortunately, most are irrecoverable
* If sent to a Bitnob-controlled contract on the wrong chain: escalate for manual recovery (case-by-case, no guarantee)

**Response template:**

“Your deposit was sent via \[chain X], but the address issued was for \[chain Y]. These networks are not compatible. Funds are likely unrecoverable. For future deposits, please double-check the network and address format.”

## Reconciliation flow

Daily or hourly, your ops team should compare [wallet balances](https://www.bitnob.dev/api-reference/balances/list-balances.md) against the [transaction history](https://www.bitnob.dev/api-reference/transactions/list-transactions.md):

![Reconciliation Flow Diagram](https://mintcdn.com/bitnob/5PGS9OuNC096evyI/images/Reconciliation-Flow-Diagram.svg?fit=max\&auto=format\&n=5PGS9OuNC096evyI\&q=85\&s=f98e2914069400f5afbf91a204cebd25)

* Flag any mismatches > 0.5%
* Include details like reference IDs, txHashes, webhook events, and timestamps
* Use this data to correct ledger state or follow up on external deposits

## Escalation channels

| Issue | Route |
| - | - |
| API downtime | Engineering + Infra |
| Large value transfer stuck | Engineering + Treasury |
| Wrong token or chain deposit | Support → Ops → Engineering |
| Webhook system-wide failure | SRE → Engineering |
| Wallet showing unexpected balance | Engineering + Finance (Reconciliation) |

## Training & internal docs

Operations teams should be trained to:

* Read blockchain explorers (Etherscan, Tronscan, Solscan)
* Understand Bitnob reference IDs and idempotency
* Parse [webhook payloads](https://www.bitnob.dev/docs/stablecoins/address-webhook-events.md#webhook) and link to user accounts
* Use internal tools to replay or verify events
* Communicate using chain-aware language with customers


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