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.
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:
Deploy the bridge contract on that chain
Teach the relayer the chain’s RPC, chain ID, and signature format
Register solvers for the new chain pair
No new cryptography, no VM-specific private code paths, no per-chain audit cliffs.
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.
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.
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.
If your integration needs a chain that isn’t listed here, open an issue 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.
Quickstart
Try a confidential transfer on a supported testnet chain.
