Overview
useChipiSession provides a unified API for managing session keys, enabling gasless transactions without requiring the owner’s signature for each operation.
This hook combines all session-related operations:
- Session creation (local keypair generation)
- Session registration (on-chain)
- Transaction execution (using session key)
- Session revocation (on-chain)
- Status checking (remaining calls, expiration)
Session keys work with CHIPI wallets and with SHHH wallets whose signer is STARK or ED25519 (every SHHH wallet the SDK creates, including passkey wallets; SHHH needs 14.14.0 or later in this hook). READY wallets do not support session keys. Check supportsSession before offering sessions.
Prerequisites
Before using useChipiSession, you need:
- A wallet that supports sessions: CHIPI, or SHHH with a STARK / ED25519 signer (check
supportsSession, wallet.supportsSessionKeys or walletSupportsSessions(wallet))
- The user’s encryption key: a PIN (
encryptKey) or a function that resolves it on demand, such as a passkey (getEncryptKey, 14.14.0+)
- An authentication token (from Clerk, Firebase, etc.)
Session Lifecycle
Quick Start
Passkey wallets and server-held sessions (14.14.0+)
For an agent that runs on your server, create the session key there and register it from the browser with the user’s passkey. The session and its spending caps go in one owner-signed transaction, so the user sees one prompt:
Function names in allowedEntrypoints are converted to selectors. The whole flow, server side included, is in Agent with a session key and a passkey.
Configuration Options
Return Values
Session Data
Actions
Loading States
Persisting Sessions
SessionKeyData contains an encryptedPrivateKey. Where you store it matters — the SDK does not persist sessions itself; this is your responsibility.
Do not store SessionKeyData in Clerk unsafeMetadata. unsafeMetadata is client-writable and embedded in the Clerk session JWT, which means the encrypted session key is exposed to the browser on every session refresh. Combined with a low-entropy user PIN (e.g. 6 digits = 10⁶ combinations), the ciphertext is brute-forceable offline by anyone who obtains a valid session token.Use a server-side route that writes to Clerk privateMetadata (server-only, not in the JWT), or store the session in your own database. See the recommended pattern below.
Recommended: server-side route + privateMetadata
Persist SessionKeyData from a server route after verifying the user’s auth token. Chipi’s backend SDK ships JWKS verification (iss + aud validation) for Clerk, Firebase, BetterAuth, and generic providers — use it to authenticate the route. See the Gasless setup guides for JWKS configuration.
1. Server route — app/api/chipi/session/route.ts:
2. Client — load and persist via the route:
Reduce the brute-force surface
Even with server-side storage, the encryption strength of encryptedPrivateKey depends on the encryption key:
- PIN-only wallets — a 6-digit PIN has ~20 bits of entropy; an attacker who obtains the ciphertext can crack it offline in seconds. Treat the encrypted session key as sensitive even at rest.
- Passkey wallets (recommended) — the encryption key is hardware-backed via WebAuthn PRF and never leaves the device’s secure element. This is the production-grade default. See the PIN → passkey migration guide.
Minimal session whitelist
When registering a session, restrict allowedEntrypoints to the smallest set your flow actually needs. Avoid including broad approval entrypoints (approve, set_approval_for_all) unless required — a session with these permissions can drain tokens within the validity window if compromised.
Executing Transactions
The executeWithSession method accepts an array of Starknet calls:
Custom Session Configuration
Custom Duration
Custom Max Calls
Allowed Entrypoints
Restrict which contract methods the session can call:
Error Handling
Complete Example