> ## Documentation Index
> Fetch the complete documentation index at: https://dev.bloombot.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Chains and quote assets

> Selecting a chain, the quote assets each one supports, and how fee fields are denominated.

Bloom serves Solana and EVM from different hosts. Which host you call determines
which API key works, which fields apply, and how `priority_fee` and
`processor_tip` are denominated.

| Host                             | Key prefix       | Endpoints                        |
| -------------------------------- | ---------------- | -------------------------------- |
| `https://eu.solana.bloombot.app` | `blm_sol_live_…` | `/api/v1/swap`, `/api/v1/deploy` |
| `https://us.solana.bloombot.app` | `blm_sol_live_…` | `/api/v1/swap`, `/api/v1/deploy` |
| `https://evm.bloombot.app`       | `blm_evm_live_…` | `/api/v1/swap`                   |

Keys are not interchangeable — a Solana key sent to the EVM host is rejected
with [`UNAUTHORIZED`](/concepts/errors). Token deploys are Solana-only; see
[Deploy a token](/api-reference/deploy).

## Regions

Solana runs in two regions. They are **interchangeable**: same account, same
wallets, same keys, same request and response format. Pick whichever is closer —
the only thing that differs is network latency to the API, which is worth
getting right if you trade on tight timings.

| Region        | Host                             |
| ------------- | -------------------------------- |
| Europe        | `https://eu.solana.bloombot.app` |
| United States | `https://us.solana.bloombot.app` |

Your [rate-limit budget](/concepts/rate-limits) is **per account, not per
region** — the two regions draw on one budget, so calling both does not double
your allowance.

<Note>
  Regional budgets reconcile continuously rather than instantaneously. Just
  after you switch regions, the `X-RateLimit-Remaining-*` headers from the new
  region can briefly read high before they catch up with what you already spent
  elsewhere. Treat a sudden *increase* in remaining budget as stale rather than
  as headroom, and keep your own count if you pace against these headers.
</Note>

Latency aside, prefer to keep a given workload on one region. Nothing breaks if
you spread it, but a single region gives you the most accurate rate-limit
headers and the most predictable behaviour.

## Selecting a chain

On the **EVM host**, a swap may name the chain it targets with a top-level
`chain` field, matched case-insensitively:

```json theme={null}
{
  "address": "<TOKEN_ADDRESS>",
  "chain": "bsc",
  "side": "Buy",
  "wallets": [{ "address": "<YOUR_WALLET>", "amount": "0.05" }]
}
```

`chain` is **optional**. Omit it and the token address is resolved across the
supported chains automatically:

```json theme={null}
{
  "address": "<TOKEN_ADDRESS>",
  "side": "Buy",
  "wallets": [{ "address": "<YOUR_WALLET>", "amount": "0.05" }]
}
```

Sending an unrecognised value is an error, naming the ones that are valid:

```json theme={null}
{
  "success": false,
  "error": {
    "code": "INVALID_REQUEST",
    "message": "Unknown chain.",
    "details": "chain=arbitrum (supported: ETH, BSC, BASE, RBH, ARC)"
  }
}
```

<Tip>
  Pass `chain` explicitly when you know it. It pins the lookup to one chain, so
  a token address that exists on more than one cannot resolve to the wrong
  market — and an address absent from that chain fails fast with
  `TOKEN_OR_POOL_NOT_FOUND` instead of silently finding a different pool.
</Tip>

On the **Solana host** there is no `chain` field; the host itself is the chain.

## Supported chains and quote assets

A **quote asset** is what a Buy is denominated in — the token you spend, and
the one `wallets[].amount` is measured in. Each chain supports its native gas
token plus a set of stablecoins.

| `chain` | Network   | Native | Stablecoins            |
| ------- | --------- | ------ | ---------------------- |
| —       | Solana    | `SOL`  | `USDC`, `USD1`         |
| `eth`   | Ethereum  | `ETH`  | `USDC`, `USDT`         |
| `bsc`   | BNB Chain | `BNB`  | `USDC`, `USDT`, `USD1` |
| `base`  | Base      | `ETH`  | `USDC`                 |
| `rbh`   | Robinhood | `ETH`  | `USDG`                 |
| `arc`   | Arc       | `USDC` | —                      |

Arc's native gas token *is* USDC, so it has no separate stablecoin.

### Naming the native asset

Each chain's native token is named by its **own symbol** — `ETH` on Ethereum,
Base and Robinhood, `BNB` on BNB Chain, `USDC` on Arc. Omitting `quote_asset`
selects the native token too, so these are equivalent on Base:

```json theme={null}
{ "quote_asset": "ETH" }
{ }
```

On the **Solana host**, the native asset is `SOL`.

`quote_asset` is validated against the chain you are trading on. Asking for an
asset that chain does not support is rejected, and the error lists the ones that
are:

```json theme={null}
{
  "success": false,
  "error": {
    "code": "INVALID_REQUEST",
    "message": "Unsupported quote_asset.",
    "details": "quote_asset=USDT chain=RBH (supported: ETH (native, or omit), USDG)"
  }
}
```

Because the list is per chain, an asset valid on one chain can be rejected on
another — `USDT` works on Ethereum and BNB Chain but not on Base or Robinhood.

## What `amount` is denominated in

On a **Buy**, `wallets[].amount` is denominated in the **quote asset you
selected** — not in the chain's native token, and not in the token you are
buying. Changing `quote_asset` changes what `amount` means.

```json theme={null}
{ "quote_asset": "USDC", "wallets": [{ "amount": "10" }] }   // spends 10 USDC
{ "quote_asset": "SOL",  "wallets": [{ "amount": "10" }] }   // spends 10 SOL
{                        "wallets": [{ "amount": "10" }] }   // spends 10 of the native token
```

Those are wildly different trade sizes for the same `"10"`, so set `amount` and
`quote_asset` together.

On a **Sell**, `quote_asset` does not affect `amount` at all — it is read
according to `sell_mode`: a percentage of holdings from `1`–`100` (the default),
or an absolute token quantity when `sell_mode` is `"tokens"`.

<Note>
  `amount` is always a **decimal string**, never a JSON number — `"0.05"`, not
  `0.05`. This avoids floating-point precision loss on large or fine-grained
  amounts. Sending a number is rejected with `INVALID_REQUEST`.
</Note>

## Fee denomination

`priority_fee` and `processor_tip` mean different things on each host. This is
the most common source of mis-sized fees.

| Field           | Solana | EVM                          |
| --------------- | ------ | ---------------------------- |
| `priority_fee`  | SOL    | **gwei**                     |
| `processor_tip` | SOL    | the chain's **native asset** |

So a `priority_fee` of `0.001` is a *thousandth of a SOL* on Solana, but a
*thousandth of a gwei* on EVM. A typical EVM priority fee is a whole number of
gwei:

```json theme={null}
{
  "chain": "bsc",
  "priority_fee": 3,
  "processor_tip": 0.0005
}
```

Here `3` is 3 gwei of priority fee, and `0.0005` is 0.0005 BNB of processor tip.

The same split applies to the `priority_fee` and `processor_tip` fields inside
[auto-orders](/concepts/auto-orders).

Setting `auto_tip: true` lets the server choose both values for you, and is the
safer default if you are not tuning fees per chain.