Signing & sponsorship
How device-native authority and gas sponsorship differ across Cavos chain adapters.
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
| Chain | Transaction authority | On-chain verification | Sponsorship |
|---|---|---|---|
| Starknet | Native stark key (HKDF of MasterDEK) | OpenZeppelin account validates the stark signature | Paymaster-sponsored deployment and execution |
| Solana | Native Ed25519 spend key (HKDF of MasterDEK) | Solana verifies the user's signature on the transaction message | Relayer co-signs as fee payer |
| Stellar | Native Ed25519 control key (same DEK family, or grandfathered extra signer) | Classic-account signature and Soroban authorization | Sponsored reserves and optional fee-bump |
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, signing keys live in the Cavos vault: keys in the IndexedDB of an iframe on a Cavos origin, not your page. Native applications use Secure Enclave/Keychain or Android Keystore when the device supports them. The vault means your page can only ask for a signature, within the limits your app sets.
WebCrypto cannot hold a stark key, so outside the vault the Starknet key is re-derived into memory for the session; the MasterDEK at rest stays protected by the device's non-extractable key. Use the vault.
Cavos.connect derives the appropriate key automatically.
Starknet
For a Starknet invoke:
- starknet.js computes the transaction hash.
- The stark key signs it, producing a 2-felt
[r, s]signature. - The OpenZeppelin account validates the signature against its public key.
signMessage signs SNIP-12 revision 1 typed data and returns curve: "stark".
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
the fee: 'self' path after deploy.
Solana
The user's Ed25519 key signs the Solana transaction message. The relayer may co-sign as fee payer because paying the fee does not grant authority over the source account. Sponsored extra program ids are restricted by the app's allowlist. See Solana.
Stellar
Stellar uses its native ed25519 account model. With enclave or passkey, the control key is HKDF of the MasterDEK (same wrap as Solana). Grandfathered wallets still use extra Horizon signers.
On web, the control key is a non-extractable WebCrypto Ed25519 key held by the Cavos vault. Your page cannot read it, and what it signs past your app's limits follows the rule you set in the dashboard.
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.
To have the user pay Stellar reserves and fees in a held token (USDC, not
XLM sponsored by Cavos), use @cavos/reserve and sign the
verified envelope with wallet.signXdr. That is a separate package and a
separate sponsor from the kit relayer.
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. On the web the Cavos vault bounds that: routine transfers under your app's limits sign silently, and anything larger or unrecognised follows your over-limit rule (ask the user, by default). Use Passkeys, Multi-device, and limits you would accept losing to a bug on your site.
Every future chain adapter must document its authority, replay protection, transaction binding, recovery, and sponsor capabilities before it joins the availability matrix.
Wallet actions
What you do with a connected wallet — read balances, send tokens, sign messages, and sign without submitting.
The Cavos vault
On the web, signing keys live in an iframe on a Cavos origin. Your page asks for signatures; the vault signs within the limits you set in the dashboard and asks the user for the rest.