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

# Supported chains and assets

> Chains, VMs, signature schemes, and assets Tachyon settles directly, plus how unsupported source chains are reached via interop.

Tachyon's confidential settlement is live on a focused set of chains today and **expands rapidly**. The protocol is VM-agnostic by design: recipient derivation, signatures, and settlement do not care whether the destination is EVM, SVM, Move, or something else. On-chain dependencies are minimal, which is why adding a chain typically takes days, not months.

## Why we can add chains quickly

Most bridges bake chain-specific assumptions into their contracts, signature schemes, and message formats. Tachyon doesn't. The on-chain footprint per chain is small (one `BridgeIntent`-style contract that understands native tokens on that chain), and the confidential machinery (recipient derivation, re-encryption, settlement checks) is chain-independent and runs off-chain. Adding a chain is mostly:

1. Deploy the bridge contract on that chain
2. Teach the relayer the chain's RPC, chain ID, and signature format
3. Register solvers for the new chain pair

No new cryptography, no VM-specific private code paths, no per-chain audit cliffs.

## Signature schemes and VMs we handle

| Family | Signature scheme         | Examples                                                   |
| ------ | ------------------------ | ---------------------------------------------------------- |
| EVM    | ECDSA over secp256k1     | Ethereum, Base, Polygon, Optimism, Arbitrum, Horizen, Rari |
| SVM    | Ed25519                  | Solana, Eclipse                                            |
| Move   | Ed25519                  | Aptos, Sui                                                 |
| Canton | Canton-native signatures | Canton Network                                             |

Recipient addresses, viewing keys, and stealth derivation adapt to whatever scheme the destination chain uses. Your users don't see any of this, they just specify a destination chain and recipient address in the native format.

## Direct support (mainnet)

| Chain    | VM     | Chain ID     | Status      |
| -------- | ------ | ------------ | ----------- |
| Horizen  | EVM    | 26514        | Live        |
| Base     | EVM    | 8453         | Live        |
| Polygon  | EVM    | 137          | Live        |
| Ethereum | EVM    | 1            | Live        |
| Optimism | EVM    | 10           | Live        |
| Rari     | EVM    | 1380012617   | Live        |
| Solana   | SVM    | mainnet-beta | Rolling out |
| Aptos    | Move   | mainnet      | Rolling out |
| Sui      | Move   | mainnet      | Rolling out |
| Canton   | Canton | mainnet      | Rolling out |

## Direct support (testnet)

Same set, on each chain's canonical testnet. Use `POST /get-routes` on the relayer ([API ref](/api/relayer)) to enumerate live testnet pairs at any time.

## Assets

| Asset | Notes                                           |
| ----- | ----------------------------------------------- |
| USDC  | Primary stablecoin across all chains            |
| USDT  | Stablecoin                                      |
| ETH   | Native on Ethereum, Base, Optimism, and rollups |
| ZEN   | Native asset of Horizen                         |
| cBTC  | BTC-pegged asset                                |

Asset availability varies per chain. `POST /get-routes` with a source + destination chain pair returns the exact routes live between them.

## Reaching chains we don't yet settle on directly

If your user holds funds on a chain Tachyon doesn't yet settle natively, the SDK (WIP) routes the funds in via interop partners before the confidential settlement leg:

* **Near Intents**, used to source liquidity from chains where Tachyon does not yet have a direct integration.
* **Relay**, used to hop assets from unsupported source chains to a chain Tachyon settles on.

The hops to a Tachyon-supported chain happen on public infrastructure. **The final leg, into the recipient, is always handled by Tachyon, and is always private.** Observers on the intermediate chain see a public hop; observers on the destination chain see only a fresh stealth address receiving funds, with no linkage to the user.

```mermaid theme={null}
sequenceDiagram
    autonumber
    participant User
    participant Hop as Near Intents / Relay
    participant Tachyon
    participant Recipient

    User->>Hop: source chain → Tachyon-supported chain (public)
    Hop->>Tachyon: funds available on supported chain
    Tachyon-->>Recipient: confidential settlement (private)
```

<Info>
  From the integrator's perspective, you do not need to wire up Near Intents or Relay yourself. The SDK detects when the source chain is not directly supported and routes through the appropriate interop layer automatically. Until the SDK ships, integrators handle the public hop themselves and then create an intent whose source chain is one of the directly supported chains above.
</Info>

## What this means for your users

| Source chain status              | What the user sees                       | Privacy on the final leg |
| -------------------------------- | ---------------------------------------- | ------------------------ |
| Directly supported               | Single confidential intent               | Private                  |
| Reached via Near Intents / Relay | A public hop, then a confidential intent | Private                  |

## Where to ask if your chain isn't listed

If your integration needs a chain that isn't listed here, [open an issue](https://github.com/TachyonPay) or reach out to the team. Chain prioritization is partly demand-driven, and because the protocol is VM-agnostic and has minimal on-chain dependencies, the turnaround is typically short.

<Card title="Quickstart" icon="play" href="/quickstart">
  Try a confidential transfer on a supported testnet chain.
</Card>