Payments & confirmations
Supported currencies and networks, and how on-chain confirmations work.
A confirmation is a block mined after the block that contains the deposit transaction. Requiring a minimum number of confirmations protects against chain reorganisations: the deeper the transaction is buried, the less likely it vanishes.
Supported currencies and networks#
The table below is live — rendered from GET /api/v1/currencies, the
same endpoint your integration should use, so it always reflects what the
platform accepts right now:
| Currency | Networks | Display decimals |
|---|---|---|
| BTC | bitcoin | 8 |
| ETH | ethereum, base | 6 |
| POD | base | 18 |
| TAO | bittensor | 4 |
| USDC | ethereum, base | 2 |
| USDT | ethereum, tron, base | 2 |
| XMR | monero | 8 |
| XPOD | base | 18 |
xPOD is the yield-bearing vault wrapper of POD (ERC-4626): it is accepted like POD and priced at the live on-chain conversion ratio times the POD price, so holders keep their accrued yield when paying.
Networks can be enabled or disabled by platform operators at any time — if a pair is missing from the table above, it is currently disabled.
All networks are mainnet. There is no testnet or sandbox environment today — when you're integrating, use small real amounts on a dedicated test merchant.
Confirmation targets#
Confirmations are counted per network, regardless of the currency:
| Network | Default confirmations | Typical wait |
|---|---|---|
bitcoin | 3 | ~30 min |
ethereum | 12 | ~2.5 min |
bsc | 3 | ~10 s |
base | 3 | ~6 s |
tron | 1 | ~3 s |
bittensor | 1 (finalized) | ~15 s |
monero | 2 | ~4 min |
These defaults are enforced by the platform. If they change, the
/currencies endpoint and this page are the canonical sources.
The state transitions you observe#
invoice.pending— deposit observed. No confirmations yet.invoice.confirming— at least one confirmation, fewer than target.invoice.confirmed— confirmations ≥ target.
Non-2xx webhook delivery has no effect on state — the on-chain data is authoritative.
Batch transactions#
One on-chain transaction can legitimately pay several invoices at once (exchanges batch their withdrawals). Each invoice funded by such a transaction is credited independently — the shared transaction hash does not collapse them into one payment.
Mempool-only deposits#
A deposit seen only in mempool never transitions past pending. If the
sender double-spends or replaces the transaction, the invoice stays pending
until either a confirming transaction lands or the TTL elapses.