For agents & LLMs

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

The quickest way to give an assistant everything it needs:

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]

For token-pay Stellar sponsorship (@cavos/reserve), same paste, different ask:

Using the Cavos docs below, add @cavos/reserve so users pay Stellar reserves and fees in USDC and never hold XLM. Use Reserve.connect("testnet"), pay / activate / send, and a maxSend ceiling. Do not call /v1/build and sign the bytes. Token identity is CODE:ISSUER from tokens(). Never create an empty account.

What an agent should know up front

• Install: npm install @cavos/kit. Stellar token-pay sponsorship is a separate package: npm install @cavos/reserve @stellar/stellar-sdk. See Reserve.
• 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. Sign-up never prompts. Call enrollPasskeyDefault() to add one; a new device is asked on sign-in (approveDeviceWithPasskey() if dismissed). On every chain (Starknet, Solana, Stellar) the passkey stores a PRF-encrypted copy of the MasterDEK that Cavos cannot open (can spend). deviceApproval: "passkey" is one chain; use "enclave" for multi-chain. 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 on Starknet/Stellar: Connect never deploys those accounts; the first sponsored execute deploys and runs the calls in one transaction. Starknet is the standard OpenZeppelin AccountUpgradeable with a stark key from the MasterDEK. Native Solana is a system account: ready once this device has the spend key; fund it with lamports before the first transfer.
• Gas sponsorship differs per chain: Starknet uses a paymaster; Solana uses a relayer as fee payer; Stellar kit relayer (appId) sponsors reserves and fees in XLM. @cavos/reserve is not that relayer. It lets any G… pay those same costs in an allowlisted token. Use pay / activate / send; do not call /v1/build and sign the bytes. Never send Soroban, SetOptions, or arbitrary XDR. maxSend (or maxSendStroops) is required. Token identity is CODE:ISSUER. Never create an empty account — activate with a claimable in the same transaction. Unkeyed: 30 req/min. Concurrent bootstrap can return 503 bootstrap_busy — retry. See Reserve. 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.
• Cavos vault (web, kit ≥ 0.2.0): with appId set, keys live in an iframe on vault.cavos.xyz, not the page. Register the app's origins in the dashboard or connect fails. Limits and the over-limit rule (ask / block / sign) are set per app under Approvals, never in code. Handle kit/vault: the user rejected this transaction and kit/vault: this app's policy does not allow this transaction. See Cavos vault.
• 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 is the HKDF salt for the account key on every chain. Never change it.
• Recovery: Starknet, Solana, and native Stellar restore the MasterDEK with enclave login or approveDeviceWithPasskey(); there is no on-chain device list and no recovery code on those chains. Grandfathered Stellar still uses approveThisDeviceWithRecovery(code).
• Social recovery / enclave: socialRecovery: true or deviceApproval: "enclave". On every chain the enclave seals the MasterDEK. Describe it as hardware-isolated, non-custodial — never trustless. See Hardware-isolated recovery.
• Bring your own auth still uses identity + submitSocialRecoveryToken(idToken) with the provider's raw id_token (fresh, under 5 minutes). That call enrolls or restores the MasterDEK wrap on every chain. In 0.2.6 the enclave rejects Google and Apple tokens that did not come from an SDK-started sign-in, so this path is unavailable for those two providers for now.
• Device management: Starknet, Solana, and native Stellar have one account key; a new device restores the MasterDEK, so there is nothing to list or remove. Only grandfathered Stellar still uses Horizon listDevices / removeDevice.
• 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 (the HKDF no longer matches the registry row), an unregistered callback URL, gating on isAuthenticated instead of walletStatus.isReady, or social recovery not enabled for the environment. See Troubleshooting.
• Non-custodial invariant: Cavos never holds a hot spender. The enclave only wraps a MasterDEK. Don't design flows that assume a Cavos server can transfer.

Reference pages