Chains
Cavos is built for every chain. Starknet, Solana, and Stellar are available today.
Cavos is built for every chain, with a native adapter boundary instead of a lowest-common-denominator transaction format. Your application keeps the same identity and connection model while each adapter implements its network's address, authority, execution, recovery, and sponsorship rules.
Status
| Chain | SDK status | Networks |
|---|---|---|
| Starknet | Available | sepolia, mainnet |
| Solana | Available | solana-devnet, solana-mainnet |
| Stellar | Available | stellar-testnet, stellar-mainnet |
| Additional chains | Design-partner and adapter roadmap | Published after implementation and validation |
All three chain adapters are shipped in the SDK. Release compatibility still requires the physical-device E2E matrix described in the React Native guide; the docs do not treat simulator/emulator results as hardware validation.
Per-chain guides
Each implemented chain has its own page with a quickstart and the chain-specific details:
Starknet
Cairo DeviceAccount, 5-felt signatures, Cavos paymaster.
Solana
Native secp256r1 precompile, device-account PDA, Cavos relayer.
Stellar
Classic G… multisig, on-chain sealed control key, Cavos relayer.
How the abstraction works
Three layers keep Cavos portable:
- The product contract is the constant. Stable identity, local authority, self-custody, recovery, and optional sponsorship are required of every adapter.
- Device-native keys stay local. Their exact role can vary: direct P-256 authorization on Starknet/Solana, or local envelope unlock for Stellar.
- A
ChainAdapterper chain handles chain-specific deterministic address computation, signature encoding, and the deploy / add-signer / remove-signer calls.StarknetAdapter,SolanaAdapter, andStellarAdaptership today.
Curves differ across ecosystems, and each adapter resolves that:
- Starknet — on-chain secp256r1 verification in the Cairo
DeviceAccount. - Solana — every guarded action pairs Solana's native secp256r1 precompile with the Cavos device-account program instruction.
- Stellar — a classic
G…multisig account (no Soroban contract): a deterministic master key with weight 0 plus a control key sealed on-chain in the account's data entries. The control key is unwrapped locally per-device (via an ECDH device key, a WebAuthn PRF passkey, or a recovery code) and signs transactions. Self-custodial, no backend key.
Writing every-chain application code
Target the unified Cavos.connect with { chains, defaultChain, network }. Use
session.wallet(chain) to get the wallet for a specific chain, and narrow on
wallet.chain before calling chain-native methods:
import { Cavos } from "@cavos/kit";
// One entry point; connect to one or more chains at once.
const session = await Cavos.connect({
chains: ["starknet"], // or ["starknet", "solana", "stellar"] for multi-chain
defaultChain: "starknet",
network: "testnet", // resolves to sepolia / solana-devnet / stellar-testnet
identity: { userId, email },
appSalt: "my-app",
appId: process.env.NEXT_PUBLIC_CAVOS_APP_ID,
// Starknet-only:
paymasterApiKey: process.env.NEXT_PUBLIC_CAVOS_PAYMASTER_API_KEY!,
});
const wallet = session.wallet("starknet");
console.log(wallet.address); // address is available immediately
console.log(wallet.status); // "undeployed" | "ready" | "needs-device-approval"
// execute() keeps each chain's native signature — narrow on `chain`:
if (wallet.chain === "starknet" && wallet.status !== "needs-device-approval") {
await wallet.execute(calls); // arbitrary Starknet calls
} else if (wallet.chain === "solana" && wallet.status !== "needs-device-approval") {
await wallet.execute(amount, destination); // lamport transfer
} else if (wallet.chain === "stellar" && wallet.status !== "needs-device-approval") {
await wallet.execute(amount, destination); // XLM transfer (stroops)
}Lazy deploy: Connect NEVER deploys the account. Wallets start as undeployed
and the first execute deploys + runs atomically. signMessage works on
undeployed wallets too.
When a new adapter ships, the SDK adds its typed chain and network values.
Identity and onboarding remain stable; execution stays chain-native. See
Concepts for the architecture rationale.