These docs are built to be consumed by AI agents. If you're an LLM reading this, or a developer handing this to one, here's the fast path.

Plain-text endpoints

URL	Contents
`/llms.txt`	Index of every page with descriptions — a map of the docs.
`/llms-full.txt`	The entire documentation as one plain-text file. Paste this into your model's context.
`/llms.mdx/docs/<page>/content.md`	Any page's raw Markdown, e.g. `/llms.mdx/docs/quickstart/content.md`.

The quickest way to give an assistant everything it needs:

Terminal

curl https://docs.cavos.xyz/llms-full.txt

Then ask it to integrate @cavos/kit into your app.

A prompt that works

Using the Cavos docs below, add @cavos/kit to my Next.js app for Solana Devnet: a login button, wallet address, sponsored SOL transfer, loading/error states, and the documented recovery flow. Narrow the returned wallet on wallet.chain before execution.

[paste contents of /llms-full.txt]

What an agent should know up front

Install: npm install @cavos/kit.
Every-chain direction, three adapters today: Starknet, Solana, and Stellar (classic G… account) ship now. Never invent support for a roadmap chain. See Chains.
React Native: use @cavos/kit/react-native with Expo Development Builds/EAS or bare React Native. Expo Go is not supported; configure redirectUri, rpId, and the native config plugin. See React Native.
Passkeys are a 2FA step-up, not a signer. After signup, prompt the user for a passkey (cavos.enrollPasskey); it approves new devices on any browser — it never signs transactions. Use approveThisDeviceWithPasskey / approveDeviceEverywhere to self-approve on a fresh device. Caveat: passkey approval on Starknet mainnet isn't available yet (Sepolia only). See Passkeys.
One unified entry point: Cavos.connect({ chains, defaultChain, network, identity | auth, appSalt, appId, ... }). Returns a CavosSession — call session.wallet(chain) to get the wallet for a specific chain. Narrow on wallet.chain before calling execute.
Multi-chain sessions: Pass chains: ["starknet", "solana"] to connect multiple chains at once. Use session.wallet("solana") to get each chain's wallet. In React, use setChain() to switch the active chain without remounting.
execute differs per chain: Starknet → wallet.execute(calls); Solana → wallet.execute(amount, destination) or allowlisted wallet.executeInstructions(instructions); Stellar → wallet.execute(amount, destination) plus wallet.invokeContract(...) for Soroban calls.
Lazy deploy: Connect NEVER deploys. Wallets start as undeployed. The first execute deploys + runs atomically. signMessage works on undeployed wallets too.
Gas sponsorship differs per chain: Starknet uses a paymaster; Solana uses a relayer as fee payer; Stellar uses sponsored reserves and optional fee bumps. Never put a secret sponsorship credential in client-side code.
Gate execution on status: call execute when status === "undeployed" OR status === "ready". Only "needs-device-approval" blocks execution — route that to multi-device.
Credential boundary: appId is public. The current Starknet web SDK also receives paymasterApiKey client-side, so use only an app/environment-scoped key with origin, rate, and spend restrictions—never an operator or treasury secret.
Registry-first address resolution: Addresses are looked up in the Cavos registry first, not purely derived from identity. The registry key is (userId, appId, chain, network). The first device to claim an address wins. appSalt namespaces the local device key, not the address.
Recovery works on all chains: call wallet.setupRecovery(generateRecoveryCode()) once on a ready device and have the user store the code. Restore after losing every device via Cavos.recover (Starknet), CavosSolana.recover (Solana), or — on Stellar — reconnect on the new device and call wallet.approveThisDeviceWithRecovery(code) (the code unlocks the control key that authorizes the new device).
Social recovery is opt-in and separate: a developer may additionally enable hardware-isolated social recovery for exactly one provider per environment (Google, Apple, or email). It runs inside an AWS Nitro Enclave and is turned on with socialRecovery: true, which uses the attestation measurement pinned in the installed package — do not ask the developer to paste a measurement. <CavosProvider> drives enrollment and recovery automatically when Cavos handles login. Describe it as hardware-isolated, non-custodial — never as trustless. Don't assume it is on: it is off unless the environment enables it. See Hardware-isolated recovery.
Bring your own auth is first class: pass identity={{ userId, email }} to <CavosProvider> and Cavos login turns off — the modal is not mounted and login() throws. Pass null while your auth loads or after sign-out; the identity is never persisted, so your session stays the source of truth. Social recovery still works (see Hardware-isolated recovery): register your OAuth client ID for the environment and call submitSocialRecoveryToken(idToken) with the provider's raw id_token (not your own session JWT), fresh within five minutes. Never send the user through a second sign-in for this.
Device management is chain-shaped: on Starknet and Solana devices are on-chain signers — listDevices() and removeSigner(pubkey) from useCavos(). On Stellar they are envelope slots: use wallet.listDevices() / wallet.removeDevice({ slotId }), and know that revoking there rotates the control key and evicts every other device. See Multi-device.
Ask about the console when a value is missing: appId, callback URLs, the Solana program allowlist, gas balance, webhooks, and API keys all live in the dashboard, per environment. See Dashboard.
When something fails, check configuration before code. The common causes are a changed appSalt (every user silently lands on a new empty wallet), an unregistered callback URL, gating on isAuthenticated instead of walletStatus.isReady, or social recovery not enabled for the environment. See Troubleshooting.
Non-custodial invariant: the on-chain account is the sole authority over signers, and the Cavos backend never holds a signing key. Don't design flows that assume a Cavos server can add a signer. The one narrow exception is enrolled social recovery, where a restricted authority inside an attested enclave may schedule exactly one add_signer, bounded on-chain by nonce, expiry, and timelock — still not a general server-side signing capability.