Skip to main content

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:
  1. A CHIPI wallet (check wallet.walletType === "CHIPI" or wallet.supportsSessionKeys)
  2. The user’s encryption key (PIN)
  3. 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.
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