Funding and balances
Discover exact assets, reconcile account balances and track movements without counting the same effect twice.
/v1/accounts identifies authorized accounts; /v1/trade/account/info supplies trading permissions and capabilities for a selected account. /v1/assets identifies exact asset representations. /v1/balances and /v1/balances/{assetId} expose the shared account ledger; /v1/capital/balance is its exchange-oriented projection. These views do not create separate accounts, asset identities or spendable balances.
Shared /v1/funding-instructions, /v1/deposits, /v1/withdrawals and /v1/transfers represent funding and movement resources. Capital routes organize those operations for exchange clients and retain their underlying account, asset, movement and operation IDs. Do not submit both route families for one movement or count both projections as separate effects. Cross-route idempotency and exact mutation mapping are not defined by the current draft.
Capital routes#
| Method and path | Purpose |
|---|---|
GET /v1/capital/balance | Exchange-oriented available, reserved, pending and provisional balances. |
GET /v1/capital/history | Deposits, withdrawals, transfers, fees and trade effects. |
GET /v1/capital/deposit-info | Eligible registered funding instructions for an exact asset representation. |
POST /v1/capital/withdraw | Request an external withdrawal. |
POST /v1/capital/transfer | Same-asset internal transfer between eligible accounts. |
These views correlate the same accountId, assetId, operationId, movement identity and status dimensions as the shared account resources. Use the underlying resource IDs to reconcile balances and movements. The released contract must define movement lookups and operation replay before these paths can be relied on for recovery.
Assets, balances, deposits and movements#
| Canonical resource | Target purpose |
|---|---|
GET /v1/assets | Exact chain, token, vault, decimals and ingress status. |
GET /v1/balances/{assetId} | Separate provisional and finalized available/reserved balances. |
POST /v1/funding-instructions, GET /v1/funding-instructions/{id} | Registered funding instructions bind exact asset, route and funding reference. |
GET /v1/deposits, GET /v1/deposits/{id} | Funding observation, admission and credited amounts. |
POST /v1/withdrawals | Create a withdrawal with exact destination, amount and authority. |
GET /v1/withdrawals/{withdrawalId} | Reconcile withdrawal state; response schema and supported custody routes remain to be specified. |
POST /v1/transfers, GET /v1/transfers/{transferId} | Same-asset internal movement; request, response and error details remain to be specified. |
For deposits, discover an admitted representation and enabled ingress, obtain registered funding instructions, follow their exact chain/token/reference, then reconcile the deposit's admission and account credit. An observed chain transfer or provider callback alone does not create spendable balance. Do not send tokens to a generic vault address or to an illustrative address. Funding and deposit request/response details remain to be specified.
For withdrawals, retain the withdrawal and operation IDs. Requested, included, finalized, claimable, claim submitted and paid are separate facts. A claim requires an explicit payment transaction; issuance or root import is not token delivery. The supported chains and custody routes must be established by the released withdrawal contract. Arbitrary destination-chain support is not specified.
An internal transfer preserves the exact representation and credits another eligible Omega account. It does not pay an external wallet or bank, and it does not perform FX. Conversion and onward transfer are separate actions; an onward-transfer failure must not erase a completed conversion. The JIT execution-confirmation contract remains unresolved. Available/reserved balances must not be summed with their alternative finalized/provisional observations.