> ## 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. # Bitnob Enterprise API overview > Non-custodial, policy-governed wallets. Keys are generated in hardware you control access to, and Bitnob cannot move funds on your behalf. The Bitnob Enterprise API provides **non-custodial**, policy-governed wallets for banks, exchanges, and fintech companies. You hold the assets. Private keys are generated inside hardware-isolated enclaves, every signature is governed by policies you write, and Bitnob cannot move funds on your behalf. > [!NOTE] > > **The Bitnob Enterprise API is a separate product from the Bitnob Business API**, with its own keys, base URL, and authentication. [Choose a product](https://www.bitnob.dev/docs/choose-a-product.md) compares the two. ## What non-custodial means here Three properties define it, and each is enforced in hardware rather than by policy alone. * **Keys never leave the enclave.** They are generated inside AWS Nitro Enclaves and are never exposed, including to Bitnob engineers. * **Every signature passes your policies first.** The enclave releases a signature only when your enforced policy allows it. * **There is no administrative override.** Bitnob cannot sign a transaction for you. Root quorum governance applies even to Bitnob-side operations on your organization. ## What the platform gives you Managing private keys, signing transactions, enforcing spending limits, and coordinating approvals across several blockchains is hard engineering. This platform provides: * Hardware-isolated key management that no single person on your team can bypass * A declarative policy engine that runs before every signing event * Multi-chain support across EVM chains, Bitcoin, Solana, Tron, and TON * Gas sponsorship, so your customers never hold a fee token * Batch transfers and HD wallets that scale from one customer to millions Signing latency is 50 to 100 ms, and there are no volume caps. ## Supported chains The live list for your organization is returned by [List Chains](https://www.bitnob.dev/api-reference/platform/assets/list-chains.md), with per-asset detail in [List Assets](https://www.bitnob.dev/api-reference/platform/assets/list-assets.md). | Chain | Identifier | Native asset | Networks | | - | - | - | - | | Ethereum | `ethereum` | ETH | mainnet, sepolia | | Bitcoin | `bitcoin` | BTC | mainnet, testnet | | Solana | `solana` | SOL | mainnet, devnet | | Tron | `tron` | TRX | mainnet, nile | | Polygon | `polygon` | POL | mainnet, amoy | | Base | `base` | ETH | mainnet, sepolia | | Arbitrum | `arbitrum` | ETH | mainnet, sepolia | | BSC | `bsc` | BNB | mainnet, testnet | | Optimism | `optimism` | ETH | mainnet, sepolia | | Avalanche | `avalanche` | AVAX | mainnet, fuji | | TON | `ton` | TON | mainnet, testnet | | Plasma | `plasma` | XPL | mainnet, testnet | ## Key features * **Bitnob Secure Enclave.** Private keys are generated and stored inside AWS Nitro Enclaves, hardware-isolated memory that never exposes key material, not even to Bitnob engineers. Every signing event is logged as an immutable audit trail. * **Declarative policy engine.** Set spending limits, destination allowlists, time locks, and multi-party approval thresholds as ordered rules. Your policy runs before every signing event, and the first matching rule decides whether the Enclave signs, holds, or blocks. * **HD vault hierarchy.** A single BIP-39 seed generates unlimited wallets and addresses across all supported chains. Use a dedicated [vault](https://www.bitnob.dev/api-reference/platform/vaults/list-vaults.md) for treasury wallets or a pool vault to assign one [wallet](https://www.bitnob.dev/api-reference/platform/wallets/list-wallets.md) per customer. * **Gas station abstraction.** Pre-fund a gas station once per chain, send with `sponsor: true`, and the gas station pays the network fee, so customer wallets never hold the native asset. For users who hold their own keys, [sponsored transfers](https://www.bitnob.dev/docs/platform/gas-sponsorship/how-sponsored-transfers-work.md) take the fee in the token instead. * **50 to 100 ms signing latency.** The Bitnob Secure Enclave is optimized for low-latency signing. Fully governed transactions are signed and broadcast within milliseconds of request. ## Common use cases * A crypto exchange that needs [one deposit address per customer per chain](https://www.bitnob.dev/api-reference/platform/wallets/create-wallet.md), with automated withdrawal governance: see the [Exchange integration guide](https://www.bitnob.dev/docs/platform/exchange-integration-guide.md) * A neo-bank that holds customer balances in Bitcoin and stablecoins and needs to enforce daily spend caps * A treasury management product that rebalances across chains and requires dual-admin approval for large transfers * A fintech platform that processes cross-border payments and must comply with address-whitelist requirements * A DeFi aggregator that [sponsors gas fees](https://www.bitnob.dev/docs/platform/gas-sponsorship/overview.md) for its users using USDC and ETH across multiple L2s ## Designed for institutions Bitnob Enterprise is built with: * **Non-custodial by design**: keys never leave the hardware boundary; Bitnob cannot move funds unilaterally * **Root quorum governance**: a configurable set of senior approvers must sign off on policy changes themselves * **Immutable audit logs** for every signing event, policy change, and approval decision * **Managed blockchain nodes** with their own per-second RPC limit, so you don't need to run your own infrastructure * **Idempotency keys** on `POST`, `PATCH`, and `DELETE` requests, such as [Create Transaction](https://www.bitnob.dev/api-reference/platform/transactions/create-transaction.md), to guarantee safe retries under network failures You focus on the product experience. We handle key management, signing infrastructure, policy enforcement, and chain connectivity. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.