Every supported chain, one integration
Seventeen protocols live, both curve families native
Six Bitcoin-family chains and eleven account-based chains, each with mainnet and testnet. ECDSA (DKLS23) and EdDSA (FROST) are both native to the MPC core, so no chain sits behind a different signer.
Share the Trust, Guard the Keys
Chain coverage is a claim until you ask which curve and which network
Long chain lists usually hide a second-class tier: chains where signing is a different code path, where testnet does not exist, or where the token standard is half supported. The list below is the production list — both curve families are native, every protocol has its testnet, and one integration reaches all of them.
- Two curve families, nativelyECDSA and EdDSA are both first-class in the MPC core, so Solana is not a bolt-on behind a different signer.
- Mainnet and testnet in the same shapeEvery protocol has both network records. What you build against on testnet is what ships.
- Assets, not just chainsA catalogued asset list with USD pricing, so balances and reporting work without you maintaining a token list.
Bitcoin family — UTXO
Coin control, multi-account inputs and batch outputs.
Bitcoin
Bitcoin Cash
Litecoin
Dogecoin
Dash
ZcashAccount-based chains
One unified address across the EVM set; native formats everywhere else.
Ethereum
Ethereum Classic
BNB Smart Chain
Polygon
Arbitrum
Optimism
Base
Avalanche
TRON
XRP Ledger
Solana (beta)One integration, every chain
The same objects everywhere
Vaults, vault accounts, addresses and transaction requests have the same shape on every protocol — the chain is a parameter, not a second integration. The differences that survive are the ones the chains themselves impose: how an address is formatted, how a fee is priced, and whether an asset has to be registered before it shows in a balance.
- ✓One unified address across the EVM set
- ✓Native address formats on the Bitcoin family, TRON, XRP and Solana
- ✓Mainnet and testnet records per protocol, on the same API surface
Where the families genuinely differ
Bitcoin-family chains give you coin control, multi-account inputs and batch outputs. The EVM set shares one unified address. TRON, XRP and Solana keep their native formats, with fee handling where the chain has a primitive for it. Plan for those three shapes and the rest of your integration is one code path.
- ✓UTXO chains take up to 150 recipients in a single transaction
- ✓On account chains an asset appears once it is registered against the account
- ✓TRON prices in energy and bandwidth; EVM chains support sponsored transactions
Coverage specification
The same catalogue /integrations renders, read as a list rather than a logo wall.
What coverage does not mean
On account chains an asset appears in a balance after it is registered against the account. On UTXO chains generating the address is enough.
TRON prices in energy and bandwidth, Solana and TRON carry a static-fee model, and EVM chains support sponsored transactions. Budgeting logic that assumes one fee model needs a per-family branch.
A chain is on this page when it is in production. Chains we intend to add are not listed as though they already worked.
The catalogue is data-driven, so adding a protocol is roadmap work rather than a rewrite. Ask before you assume it is absent.
Frequently asked questions
Get answers to commonly asked questions.
Is every chain equally supported?
In the way that matters, yes: both curve families are native to the MPC core, so no chain sits behind a different signer. What differs is the chain's own model — UTXO versus account, and how it prices fees.
Do you have testnets?
Every protocol has mainnet and testnet records, and a pilot runs on testnet against the same API surface it will use in production.
A chain we need is missing?
Tell us in a demo — chain onboarding is a defined internal process, and real demand moves the queue.
