# Supported Blockchains

Chains are configured per deployment and per tenant. Ask the API which ones your tenant can use instead of relying on a fixed list.

## Overview

The API does not hard-code a list of networks: request schemas accept any chain identifier string, and what works for your tenant depends on three pieces of configuration — the chain registry, your tenant's blockchain configs and your tenant's token registry. The chains available to you are therefore deployment-specific; query them at runtime as shown below.

The code distinguishes two families: EVM networks, and Solana (identifier `solana`). Their capabilities differ — see **Feature Support**.

## How Chains Are Enabled

| Layer | What it holds |
| --- | --- |
| Chain registry | Platform-wide list of networks managed by platform admins (`/v1/admin/chains/`): slug `id` (lowercase letters, digits and hyphens), `name`, `isTestnet`, `rpcUrl`, `explorerUrl`, `nativeToken` and numeric `chainId`. Non-custodial sends and fee quotes read the numeric chain ID from here, falling back to your tenant's enabled blockchain config. |
| Tenant blockchain configs | Per-tenant network settings created through the admin endpoint `/v1/admin/tenants/{id}/blockchain-configs`: `chain`, `chainId`, `rpcUrl`, `isTestnet`, `isEnabled`, gas settings, metadata and native token. Tenant users can read the enabled ones with `GET /v1/tenant/blockchain-configs`. |
| Tenant token registry | Tokens registered for your tenant (`/v1/admin/tenants/{tenantId}/tokens`). A chain only appears in the runtime chain list when your tenant has at least one active token on it. |

## Listing Chains at Runtime

### `GET /v1/tokens/meta/chains`

Lists chains that have an enabled blockchain config and at least one active token for the tenant.

**Query parameters**

| Name | Type | Required | Description |
| --- | --- | --- | --- |
| `isTestnet` | string | no | `"true"` or `"false"`. Default `"false"`. |

**Responses**

`200` OK

```json
{
  "chains": [
    {
      "id": "gnosis",
      "name": "Gnosis",
      "chainId": 100,
      "nativeToken": { "symbol": "xDAI", "name": "xDAI", "decimals": 18 }
    }
  ]
}
```

- A bearer token is optional. **Send it:** with a token the list is for your tenant; without one it is for the system tenant.
- `name` is the `id` with its first letter capitalised. `nativeToken` comes from your tenant's token registry (`null` if none is registered).
- `chainId` is the id of the requested network. For an EVM chain (ethereum, polygon, gnosis, bsc, arbitrum, optimism, base, avalanche, celo, flowevm) it comes from the Hub's EVM chain list: `celo` is `42220`, and `11142220` with `isTestnet=true`. Other chains take it from the chain registry (`null` if the chain is not registered).
- `GET /v1/tenant/blockchain-configs` (bearer token required) returns your tenant's enabled configs, including `chainId`, `explorerUrl` and `nativeToken`.

See also [Supported Chains (Token Meta)](https://docs.aureahub.com/docs/tokens-chains.md).

## Chain Identifiers

Use a chain's `id` wherever an endpoint takes a `chain` parameter:

```json
{
  "walletId": "3f1c2b9e-8a4d-4c6e-9b2a-5d7e1f0a6c3b",
  "chain": "gnosis",
  "toAddress": "0x52908400098527886E0F7030069857D2E4169EE7",
  "amount": "10000000000000000"
}
```

- Mainnet and testnet are told apart by an `isTestnet` flag on wallets, registry entries and many requests. An EVM chain's wallets, blockchain configs and tokens are stored under the family chain with that flag: `polygon` with `isTestnet: true` is Polygon Amoy.
- The chain registry lists each EVM testnet under its own id (`polygon-amoy`, `celo-sepolia`, `chiado`). Wallet, blockchain config and token endpoints accept that id and store the family chain on the testnet.
- Addresses: EVM addresses are `0x` followed by 40 hex characters; Solana addresses are base58 strings of 32–44 characters.
- An EVM wallet's address is valid on every EVM network, so [Create Transaction](https://docs.aureahub.com/docs/tx-create.md) accepts a `chain` other than the wallet's own.

## Feature Support

What the API code supports for each chain family. Whether a capability is usable on your tenant still depends on its configuration.

| Capability | EVM chains | Solana (`solana`) |
| --- | --- | --- |
| Custodial sends | Native coin and tokens. | SOL and SPL tokens (`tokenAddress` = mint). |
| Non-custodial sends (`client_side`, `client_side_pending`, `mpc_tss`) | Yes, when a numeric chain ID is found for the chain. | No — `400` `Non-custodial Solana sends are not yet supported`. |
| Status from the chain (Get Tx Status, background job) | Yes, from the transaction receipt. | No receipt lookup. Custodial Solana sends are recorded as `confirmed` when the send call returns. |
| Fee quote for non-custodial wallets | Estimated from the network. | Zero quote (`isFree: true`). |
| Gasless token sends (non-custodial) | Only on chains with a gasless transfer forwarder configured, for active tokens registered with permit support. | No. |

> ℹ️ **Gasless swaps** are a separate feature: the gasless swap service works against Gnosis Chain (chain ID 100) and the EURe token, and a deployment can switch it off, in which case it returns `503` `Gasless swaps are currently disabled`. See [Token Swaps](https://docs.aureahub.com/docs/guide-swap.md).

---

Web version: https://docs.aureahub.com/#supported-blockchains