# Networks and tokens

This document lists the networks and tokens of STONS and shows where the API tells your integration which assets it can offer. Read it before you choose the tokens for your product.

## What the service does on each network

| Family | Networks | Payments | Payouts |
| --- | --- | --- | --- |
| TRON | TRON | yes | yes |
| EVM | Ethereum, BNB Smart Chain, Polygon, Base, Arbitrum, OP Mainnet, Avalanche | yes | no |
| TON | TON | yes | no |
| Solana | Solana | yes | no |

- **This table says what the service can do. What is available to your project right now is what `GET /v1/assets` says** — it accounts for the catalog, the operator's switches and your project's own settings in the Dashboard. Take the list from there rather than from here: a network or a token can be switched off, for maintenance for example, and then its assets are not in the answer — see [which assets you can offer](#which-assets-you-can-offer).
- A network in the API is an identifier from the service's network registry — `tron`, `ethereum`, `bsc`, `polygon`, `base`, `arbitrum`, `optimism`, `avalanche`, `ton`, `solana` — together with its name for people in `network_name`.
- **The service makes payouts on TRON only.** A payout in an asset of any other network is refused with `422 asset_not_payable`.
- What the service does with the money after it arrives — keeps it and owes it to the project, or forwards it to the project's own wallet — changes no amount, address or invoice status either way; it is described in [where the money goes](https://stons.io/docs/invoices.md#where-the-money-goes).

## Tokens

Tokens are the service's asset catalog: contracts, decimals, minimum deposits and confirmation counts come from it, not from code. Today these are the stablecoins USDT, USDT0 and USDC and the native coins of the networks. The contracts, decimals and minimum deposits of every asset are in [assets](https://stons.io/docs/invoices.md#assets).

| Tokens | Where |
| --- | --- |
| USDT | `USDT_TRON`, `USDT_ETHEREUM`, `USDT_BSC`, `USDT_AVALANCHE`, `USDT_TON`, `USDT_SOLANA`. Payouts in `USDT_TRON` only |
| USDT0 | `USDT0_POLYGON`, `USDT0_ARBITRUM`, `USDT0_OPTIMISM`: on these networks USDT is issued as USDT0, which is a different contract |
| USDC | `USDC_ETHEREUM`, `USDC_BSC`, `USDC_POLYGON`, `USDC_BASE`, `USDC_ARBITRUM`, `USDC_OPTIMISM`, `USDC_AVALANCHE`, `USDC_SOLANA` |
| USDC on TRON: `USDC_TRON` | Switched off by the operator entirely: Circle has stopped minting USDC on TRON. It is not accepted in new invoices, and payouts in it are off as well. Invoices already open in it are paid, and a transfer to a permanent address is credited — see [what arrives at an address](https://stons.io/docs/addresses.md#what-arrives-at-an-address) |
| Native coins | `TRX_TRON`, `GRAM_TON`, `SOL_SOLANA`, `ETH_ETHEREUM`, `BNB_BSC`, `POL_POLYGON`, `ETH_BASE`, `ETH_ARBITRUM`, `ETH_OPTIMISM`, `AVAX_AVALANCHE`. A price in US dollars is converted into the coin at an exchange rate; there are no payouts in them. A transfer a smart contract made is credited too — see below |
| Other tokens | The catalog is the operator's to extend, token by token: its contract, decimals, minimum deposit and confirmations are read from the network, not written in code. A token is accepted for payments while it is either pegged to the US dollar or has a coin whose market rate prices it — a price in US dollars is then converted at that rate. Payouts need the peg, which is why there are none in the native coins |

**A native coin of an EVM network is credited whether a wallet or a smart contract sent it**: the value of the transaction itself, or a transfer a smart contract made within it — a smart-contract wallet, a multisig, an exchange's withdrawal. The service finds a transfer from a contract by tracing the block and credits it only when the trace accounts for the whole rise of the address's balance. One it cannot account for is not credited automatically: the invoice stays unpaid, and no webhook is sent. The service's operator resolves such a transfer by hand. A token is credited by its transfer event, however it was sent.

## Identifiers and decimals

An asset is a token on a network: `USDT_TRON` is USDT on TRON. The same token on different networks is different assets, with different contracts and possibly different decimals: USDT has 6 decimals on TRON and 18 on BNB Smart Chain.

- Do not build the number of decimals into your code: an amount in an API response has exactly as many digits after the point as its asset has decimals — see [amounts](https://stons.io/docs/invoices.md#amounts).
- Show the customer the network together with the asset and the full address — see [checklist](https://stons.io/docs/checklist.md#display). An address on TON is written in the user-friendly form a wallet accepts — see [addresses on TON](https://stons.io/docs/addresses.md#addresses-on-ton).

**An address on Solana is base58, 32 to 44 characters, and it is case-sensitive.** Base58 uses both cases of the Latin alphabet as distinct symbols, so `So11…` and `so11…` are different addresses. Never lower-case, upper-case or otherwise normalise an address of this network — in your database, in a URL, in a comparison or in a QR code. Doing so turns it into an address nobody holds the key to, and money sent there is gone. Store and compare it exactly as the API returned it, and show it in full. The same goes for the signature of a Solana transaction, which the service returns in `tx_hash`: base58 of 86 to 88 characters, not 64 hexadecimal digits — see [addresses on Solana](https://stons.io/docs/addresses.md#addresses-on-solana).

## Which assets you can offer

Which assets a project can offer at a given moment depends on the service's catalog, the networks the operator has enabled, the operator's switches and the project settings in the cabinet (Dashboard). The API applies them in these places:

| Where | What it gives |
| --- | --- |
| `GET /v1/assets` | Every asset the project can create an invoice in **now**, with its network, contract, decimals and minimum deposit — see [list the assets](https://stons.io/docs/invoices.md#list-the-assets). An asset switched off by the operator or by the project's settings does not appear in the answer |
| `POST /v1/addresses`, the `assets` field | The assets you can offer the user for payment to this address at the moment of the request — see [permanent user address](https://stons.io/docs/addresses.md#permanent-user-address) |
| `POST /v1/invoices` without `asset` | The customer chooses the coin and the network on the checkout page, from the assets the project accepts that have an exchange rate; the price is converted into the chosen one at the rate, and `currencies` narrows the list — see [the customer chooses the token](https://stons.io/docs/invoices.md#the-customer-chooses-the-token) |
| `GET /checkout/v1/invoices/{id}`, the `choices` field | The assets the customer can choose now, with the amount to pay in each — see [read an invoice for the page](https://stons.io/docs/checkout.md#read-an-invoice-for-the-page) |

An asset that cannot be used is refused by `POST /v1/invoices`: `422 asset_not_supported` if the service does not accept it for payments, `422 asset_payments_disabled` if the operator has disabled payments in it, `422 asset_disabled_by_merchant` if the project settings have — see [error codes](https://stons.io/docs/errors.md#code-list).

## When the list changes

A new network or a new token is recorded in the [changelog](https://stons.io/docs/changelog.md) and appears in this document. But the list your code relies on is the answer of `GET /v1/assets`: it also changes without a changelog entry, when the operator switches an asset or a network off, for maintenance for example. Read it before you show the customer a choice of network, and do not hard-code networks.