Skip to main content
PIN is weak — not recommended for production.A user-typed PIN is a short, low-entropy string. Anyone who shoulder-surfs the PIN, observes a phishing form, or compromises the browser at typing time can decrypt the wallet’s private key. PIN remains in the SDK only as a fallback recovery surface for users who lose access to their platform authenticator.Production embedded-wallet apps should default to a platform passkey (Touch ID, Face ID, Windows Hello, Android biometrics) via the @chipi-stack/chipi-passkey package. For SHHH V8.4 wallets, signerKind: "WEBAUTHN_P256" keeps the private key inside the platform authenticator — it never leaves the device, never reaches Chipi servers, and is never derived from a user-typed secret.Only prompt for a PIN as the encryption key when:
  • The user explicitly opted into a PIN-only flow (e.g. cold-storage / paper-backup recovery), or
  • The platform genuinely has no WebAuthn / biometric support available.
If you are migrating an existing PIN-based wallet to a passkey, look up useMigrateWalletToPasskey in your framework’s hook docs.

What are Session Keys?

Session keys allow your application to execute transactions on behalf of a user without requiring their owner private key for every action. Instead, a temporary keypair is created and registered on-chain with specific permissions (time limit, call limit, allowed functions). This enables gasless, frictionless UX for gaming, DeFi automation, social apps, and more.
Session keys only work with CHIPI wallets - OpenZeppelin accounts extended with SNIP-9 session key support.

When to Use Session Keys

Requirements

  • A CHIPI wallet (not READY)
  • Valid bearer token from your auth provider
  • User’s encryptKey (PIN) for signing

1

Install the Backend SDK

2

Initialize the SDK

3

Create a Session Key

Generate a session keypair locally. The SDK returns the data but does NOT store it - you must persist it on the client side.
Never store session keys in your backend database. Store only in client-side secure storage (localStorage, Secure Enclave, Keychain).
4

Register Session On-Chain

Before using a session key, you must register it on the CHIPI wallet smart contract. This requires the owner’s signature (one-time setup).

Session Configuration Options

For security, whitelist specific entrypoints when possible:
5

Execute Transactions with Session

Now you can execute transactions using the session key - no owner private key needed!
Signature Format Difference:
  • Owner signature: [r, s] (2 elements)
  • Session signature: [sessionPubKey, r, s, validUntil] (4 elements)
The SDK handles this automatically.
6

Query Session Status

Check if a session is still active and how many calls remain:
7

Revoke Session

Always revoke sessions when no longer needed or when the user logs out:
Always revoke sessions on logout to prevent unauthorized access.

Security and Best Practices

Storage Guidelines

Never store session keys in your backend database. This defeats the purpose of self-custodial security.
Store session keys only in client-side secure storage:
Use sessionStorage instead of localStorage for sessions that should expire when the browser tab closes.

Lifecycle Best Practices

  1. Always revoke on logout - Never leave active sessions when user signs out
  2. Set short durations - Use 1-6 hours, not days
  3. Limit maxCalls - Set realistic limits based on expected usage
  4. Whitelist entrypoints - Restrict to only the functions your app needs

Example: Secure Logout Handler

Example: Session with Restricted Permissions


Full Example: Gaming Session


Next Steps

Need help? Join our Telegram Community for support.