@paxoslabs/amplify-sdk@1.0.0 is chain-agnostic. Every method that touches the chain takes a chainId, and the API returns chain-correct contract addresses and calldata.
That has three consequences for your app:
- Pull the list of supported chains at runtime instead of hard-coding it.
- RPC connectivity belongs to your wallet stack (wagmi / viem / Privy / Dynamic), not the SDK.
- Switching chains mid-flow is “pass a different
chainIdto the next call.” There is no client-side state to reset.
Supported chains
Networks the SDK currently serves: The snippet is the source of truth for the docs site. At runtime, derive the set dynamically (see Discovering chains below) — the backend can light up new chains without an SDK release.Discovering chains
client.amplify.vaults.list returns vault groups, each with a deployments[] array describing every chain a vault is live on:
filter string follows the same shape as every other listing endpoint: comma-separated field=value clauses with optional AND joins. Supported flags: chainId, inDeprecation, requiresKyt.
Don’t ship a hard-coded chain list in your app. Pull it from
client.amplify.vaults.list() (and cache for a few minutes) so a new chain coming
online doesn’t require a release.Per-chain RPC belongs to your wallet
The SDK never opens an RPC connection — it speaks HTTP toapi.paxoslabs.com. Submitting prepared.transaction to a chain is the wallet’s job, and configuring per-chain RPC URLs is wagmi/viem territory:
Same vault, multiple chains
A single vault fromclient.amplify.vaults.list() uses the same boringVaultAddress across all chains it’s deployed on. Each deployment carries its own accepted assets and configuration:
(boringVaultAddress, chainId). The vault address is consistent across chains, making it a stable identifier:
Chain guard before write
Always check the connected wallet’s chain matches the chain you’re preparing for. The SDK happily prepares calldata for any chain — the wallet will broadcast it on whichever network it is connected to, which is rarely what the user wants:useSwitchChain to actively switch the wallet before submitting, then re-read the chain id and assert.
Deposit flow on a specific chain
Withdrawal flow on a specific chain
Switching chains mid-flow
Because the SDK keeps no chain state, switching chains is just “pass the newchainId”:
prepare requests for the old chain before you do, so a late response can’t overwrite the new one’s UI:
Listing across chains
Mostlist* endpoints accept chainId= in the filter and paginate via pageToken:
client.amplify.vaults.listAssets, getApys, getTvls, and getSupplyCaps. Filter by chainId server-side when you only need one chain — it’s cheaper than scanning all pages.
Error handling across chains
client.amplify.vaults.list({ filter: 'chainId=<id>' }) on chain-switch events.
Related
- AI Coding Reference — full method list.
- Deposits guide
- Withdrawals guide
- Smart wallets guide — submitting prepared transactions from AA wallets.
- Migrating from 0.5 — what changed about chain config.