Concepts

Non-custodial by construction

Cavos is non-custodial because authority lives in the account contract, not the backend. The Cairo DeviceAccount gates add_signer / remove_signer so they only succeed when called by the account itself — which only happens inside a transaction whose signature was validated against an existing, authorized device signer.

Consequences:

• The Cavos backend holds no key material and has no privileged role on any account. A full backend compromise cannot add a signer to any wallet.
• Every signer change is authorized by a key the user holds (a device key or a passphrase-derived backup key), verified on-chain.
• Backend services (registry, recovery relay) only move messages — they request, notify, and relay. They never sign.

This is the single invariant to remember: the contract is the sole authority over its signers.

Deterministic addresses

The wallet address is f(identity, appSalt) via deriveAddressSeed (Poseidon) → counterfactual contract address. It depends only on identity and salt, never on the device key, so:

• The same user always lands on the same wallet.
• You can compute the address before the account is deployed.
• A new device on an existing account is recognized, not forked into a second wallet.

The account starts with zero signers; the first device key is registered via a one-time initialize submitted atomically with deployment, which prevents front-running of the first signer.

Silent signing trade-off

Device keys sign silently — no per-signature user-verification prompt. The key is non-extractable and device-bound, so it is non-custodial and on-chain verified. This is the embedded-wallet model used by Privy and Turnkey: maximum UX, no friction per transaction.

The user-verification step lives on device management, not signing. An optional passkey acts as a second factor for approving new devices; it never gates individual transactions. Together with multi-device and recovery, that covers device loss without compromising the silent-signing UX.

Networks & constants

import { STARKNET_NETWORKS, DEVICE_ACCOUNT_CLASS_HASH } from "@cavos/kit";

STARKNET_NETWORKS.sepolia;            // RPC + chain config
DEVICE_ACCOUNT_CLASS_HASH.sepolia;    // deployed DeviceAccount class hash

Cavos.connect takes network: "testnet" | "mainnet" and resolves it to the chain's concrete network (Starknet testnet → sepolia). The STARKNET_NETWORKS / DEVICE_ACCOUNT_CLASS_HASH maps are still keyed by the concrete Starknet network (sepolia, mainnet); the kit ships the current class-hash values.

Multi-chain by design

The kit is structured around a ChainAdapter interface, with StarknetAdapter, SolanaAdapter, and StellarAdapter implemented today (all three live on testnet and mainnet). New chains slot in behind the same Cavos.connect API surface, so application code written against Cavos.connect stays stable as chains are added. Each chain keeps its native execute signature (narrow the returned wallet on wallet.chain); see Chains for the per-chain guides.