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 only work with CHIPI wallets. READY wallets do not support session keys.
Prerequisites
Before using useChipiSession, you need:
- A CHIPI wallet (check
wallet.walletType === "CHIPI" or wallet.supportsSessionKeys)
- The user’s encryption key (PIN)
- An authentication token (from Clerk, Firebase, etc.)
Session Lifecycle
Quick Start
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