Skip to main content

Four independent virtual balances

Every account holds four virtual balances, one per currency. They are fully independent: they never mix and are never converted automatically. GET /v1/balances always returns all four (zeros if you have not used that currency yet), as decimal strings:
Internally each amount is stored as an integer in its currency’s minimal unit (micro-USDT, satoshis, micro-grams) and computed with exact rational arithmetic. There are no floats and no accumulated rounding errors.
USDT is the operating currency: payouts, fiat payins and service fees are always priced in USDT. But the payment can come from any of the four balances — see Choose which balance pays. Payins always credit the USDT balance; the other balances are funded via internal transfers (always between balances of the same currency), on-chain deposits (USDC and BTC) or credits from your operator (GOLD).

Choose which balance pays

Payouts and service fees (KYC, wallet creation, banking) can be debited from any of your four balances. The pricing pipeline does not change: the operation is quoted in USDT as always, and at the end the total translates to the chosen asset at the effective settlement price of the moment.
  • Per-account default: PUT /v1/settlement with {"default_settlement_asset": "BTC"}. From then on, every payout and service fee comes out of the BTC balance (if it covers the amount; there are no cascades into other balances).
  • Per-operation override: send settlement_asset in POST /v1/payouts (or in the QR confirm) to pay that single operation from another balance without touching the default.
Multi-asset settlement rules: The settlement block of GET /v1/rates shows the effective per-asset price (spread included) so you can estimate before operating, and the payout response records settlement_asset, settlement_amount and settlement_rate for auditability.

available and held

Each balance has its own two counters: When you create a payout or withdrawal, the debit (amount + fee) leaves available and sits in held until the operation reaches a final state:
  • completed → the hold is consumed; the money left.
  • failed → the full debit (amount + fee) is refunded to available.

FX conversion (fiat ↔ USDT)

Fiat operations convert to USDT at your account’s rates at execution time (the same ones returned by GET /v1/rates, USD base): rate for payouts and payin_rate for payins. Conversion rounds up on debits and down on credits, with at most 1 micro-USDT of difference. Example — a 50,000 CLP payout at a 950.25 rate:
Example — a 50,000 CLP payin at a 955.10 payin_rate:
The rate used is recorded on the object (fx_rate) for auditability.

Reference and settlement prices

GET /v1/rates includes an asset_prices block with the USD reference price of each currency (BTC per unit, GOLD per gram; USDT and USDC are 1 by convention) to value your balances on screen, plus a settlement block with the effective price your balance would be valued at if you pay an operation from that asset (spread included):
settlement_grade: true means the price is fresh enough to execute operations; if it drops to false, payments from that asset answer 503 pricing_unavailable until the price recovers.

Immutable ledger

Every movement produces an immutable entry with the resulting balance (balance_after) in the movement’s currency. Your full history lives at GET /v1/movements (filter by currency with ?asset=):
Every list endpoint (/v1/movements, /v1/payouts, /v1/payins, /v1/crypto/transactions, /v1/banking/operations) accepts pagination (page, page_size up to 200) and from/to date filters (YYYY-MM-DD, UTC, inclusive).

Operation states

Payouts and crypto withdrawals follow the same lifecycle: Final states (completed/failed) arrive via webhook; no polling required.
Last modified on July 16, 2026