Signing & sponsorship

Cavos keeps the user experience consistent—local authority, no seed phrase, no routine signing popup—while preserving each chain's actual cryptography and fee model.

Capability matrix

The backend can transport, sponsor, or submit a transaction. It does not hold the user authority required to move funds.

Local keys

On the web, Cavos uses non-extractable WebCrypto keys stored through IndexedDB. Native applications use Secure Enclave/Keychain or Android Keystore when the device supports them. “Non-extractable” means application code can ask the key to perform an operation but cannot export the private material.

import { WebCryptoSigner } from "@cavos/kit";

const signer = await WebCryptoSigner.loadOrCreate({ keyId: address });
const publicKey = await signer.getPublicKey();

Cavos.connect provisions the appropriate key or unwrap factor automatically. Most applications should not instantiate low-level signers directly.

Starknet

For a Starknet invoke:

1. starknet.js computes the transaction hash.
2. The device signs sha256(tx_hash) with P-256.
3. Cavos serializes the signature as [r_low, r_high, s_low, s_high, y_parity].
4. The Cairo account recovers the signer and checks that it is authorized.

Sponsored execution is routed through the Starknet paymaster. The current web SDK receives its API key in browser code, so that value is client-visible and must be narrowly scoped by app, environment, origin, rate, and spend. Never use an operator, admin, or treasury credential there. The dedicated Starknet guide contains the chain-specific flow and self-funded fallback.

Solana

Each guarded action pairs two instructions:

1. Solana's native secp256r1 precompile verifies the device signature over a domain-separated action.
2. The Cavos device-account program binds that verified public key and message to the requested transfer, signer change, or CPI set.

The relayer may co-sign as fee payer because fee payment does not grant authority over the device account. Sponsored arbitrary CPIs are restricted by the app's program allowlist. See Solana.

Stellar

Stellar uses its native ed25519 account model. The deterministic master key is made powerless after creation and a random control key becomes the active signer. That control seed is encrypted in the account's data entries and unwrapped locally using an enrolled device, passkey PRF, or recovery factor.

For Soroban, invokeContract simulates the call and re-signs the account's authorization entries with the local control key. A fee-bump relayer can pay the outer fee without becoming an account signer. See Stellar.

Signing without submission

Every adapter can sign a transaction without submitting it — useful when your own relayer does the submitting. The payload is chain-specific, so narrow on wallet.chain first. See Wallet actions for the call, the per-chain payloads, and how a backend verifies a signature.

Security trade-off

Silent signing removes a per-transaction biometric prompt. That improves embedded-wallet conversion but means application authorization and device security matter. Cavos places explicit user verification on device enrollment and recovery rather than every routine transaction. Use Passkeys, Multi-device, spending policy where available, and clear in-app transaction confirmation for high-risk actions.

Every future chain adapter must document its authority, replay protection, transaction binding, recovery, and sponsor capabilities before it joins the availability matrix.