Stablecoins – Key Concepts
This section introduces the foundational concepts required to work with stablecoins on Bitnob. Whether you're issuing addresses, handling deposits, or sending USDT/USDC across chains, these principles define how our infrastructure behaves.
Chain Abstraction
Stablecoins exist on multiple blockchains, but your integration should not have to. Bitnob abstracts the differences between token standards, confirmation rules, and fee structures by providing a unified API interface.
Supported Chains (as of now):
Ethereum (ERC-20)
Arbitrum (ERC-20)
Binance Smart Chain (BEP-20)
Solana (SPL)
Tron (TRC-20)
What this means for developers:
You use the same request structure to send or receive stablecoins across all chains.
You specify the chain parameter (e.g., ethereum solana) and Bitnob handles the rest.
All webhooks, status codes, and response formats are consistent, regardless of chain-specific logic.
Wallets vs Addresses
A wallet in Bitnob is a logical account that holds balances of specific stablecoins across chains.
A deposit address is a chain-specific receiving address issued to your customer or application to track on-chain deposits into your Bitnob wallet.
You can issue multiple addresses under the same wallet—each tied to a chain, a stablecoin (e.g. USDT), and metadata like customer email or label.
Example: Customer A has one USDT wallet. You generate:
A Tron TRC-20 address for low-fee mobile inflows
An Ethereum address for integrations with DeFi protocols
Bitnob tracks all inbound transfers and credits the wallet’s balance accordingly.
Confirmations and Finality
Each blockchain has different rules for how many confirmations are needed before a transaction is considered irreversible (final). Bitnob enforces minimum confirmation counts based on the chain to protect against double-spends and reorgs.
| Chain | Confirmations Required | Finality Type |
|---|---|---|
| Ethereum | 15 | Probabilistic |
| Arbitrum | 15 | Probabilistic |
| Solana | 1 | Absolute |
| BSC | 15 | Probabilistic |
| Tron | 19 | Probabilistic |
What this means for your app:
You should wait for the deposit.succeeded webhook or poll for confirmation status before crediting a user.
The confirmations field in the webhook lets you show live confirmation progress in your UI.
Idempotency and Atomicity
All state-changing requests in Bitnob (sending funds, creating addresses) support idempotency key to ensure you never accidentally duplicate a transaction due to network errors or retries.
Use a unique UUID per business action (e.g., withdrawal attempt).
If the same key is reused within a 24-hour window, Bitnob will return the original result instead of executing again.
Bitnob operations are also atomic. This means:
If a send fails on-chain, your internal balance is not debited.
If a webhook fails, retries will continue until delivery or expiration.
You’ll never receive a "sent" status unless all backend operations succeed.
Event-Driven Architecture
Bitnob relies heavily on webhooks to notify your application about key lifecycle events:
deposit.succeeded
transfer.initiated
transfer.completed
transfer.failed
Why it matters:
Your backend can respond to real-time changes without polling.
You can build stateful experiences (e.g., confirmation progress bars, dashboards) without deeply understanding the underlying chain logic.
We recommend using these events as the primary trigger for balance updates, UI changes, and transaction reconciliation.
