Session Keys for Mobile Crypto Apps: Auto-Sign with Limits
You launched a blockchain game or DeFi app. Users complain: every action requires biometrics. Conversion drops. Part of the audience leaves. The solution—Session Keys per ERC-4337 standard. We have implemented them in 10+ projects with Account Abstraction. Average signing time dropped from 5s to 1s, and gas costs by up to 70%.
According to Account Abstraction (ERC-4337), session keys are temporary cryptographic keys with restricted rights. They auto-sign transactions without repeated main-key confirmation. The permission policy sets limits: target contract, function, maximum value. Even if a session key leaks, an attacker cannot withdraw all funds—only what the policy allows. We offer Session Key integration into your mobile app from scratch or on top of an existing smart account. We estimate your project in one business day; typical implementation takes 3 to 5 days.
How Session Keys Reduce Gas Costs?
Compare standard signing vs. Session Keys:
| Parameter | Standard Signing | Session Keys |
|---|---|---|
| Client confirmation | Each transaction | Only first (enableSessionKey) |
| Wait time | 5–10 sec | 1–2 sec (auto-sign) |
| Gas per transaction | Full gas | UserOperation + Bundler (with Paymaster — 0) |
| Security | Maximum | High (restricted rights) |
Session Keys are 3–5 times faster. With a Paymaster, the user pays no gas at all, reducing costs by up to 70%.
Permission Policy: The Key to Security
The permission policy is a contract that validates every UserOperation. It defines the target contract, function, and value limit. Without it, a session key would be a full clone of the main key. With it, even if compromised, the attacker cannot move funds beyond the policy.
Architecture: ERC-4337 + EIP-7715
Session Keys are implemented at the smart account level (Account Abstraction). The mobile app sends userops instead of direct transactions. Stack:
- permissionless.js or @zerodev/sdk for smart account creation
- @zerodev/session-key for session management
- Bundler (Pimlico, Stackup) for sending UserOperations
The session key is an ephemeral keypair (secp256k1) generated on the device. The private part stays in Keychain/KeyStore. The public key and permission policy are registered via enableSessionKey, signed once with the main key (with biometrics).
Technical details: key generation on iOS/Android
On iOS, use SecKeyCreateRandomKey with attribute kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom. On Android, use KeyPairGenerator.getInstance("EC", "AndroidKeyStore") with secp256r1. The private key never leaves the Keychain/KeyStore.
What Happens If a Session Key Is Compromised?
An attacker obtaining the session private key can only sign permitted operations—e.g., playRound with a 0.01 ETH limit. They cannot withdraw main funds. The user can revoke the session key anytime via revokeSessionKey.
Storage and Lifecycle on Mobile
The session private key lives in Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly—no biometrics needed because the key is policy‑limited. The session TTL is shown to the user: "Session active 45 min of 60". Manual revocation is done via a revokeSessionKey UserOperation signed with the main key. When the app closes, the key is zeroed in memory but remains in Keychain until TTL expiry or revocation.
Comparison with Other Auto-Sign Approaches
| Approach | Security | Flexibility | Gas cost |
|---|---|---|---|
| Approve + permit | Medium (approve all txns) | Low | High (each approval) |
| Meta-transactions | High | Medium | Medium (relayer) |
| Session Keys (ERC-7715) | High (limited rights) | High | Low (Paymaster) |
Session Keys win on all parameters for apps with frequent micro-transactions.
How to Implement Session Keys: Step-by-Step
- Create an ERC-4337 smart account (if none)
- Generate an ephemeral keypair on device (secp256k1, store in Keychain/KeyStore)
- Form a
UserOperation enableSessionKeysigned with main key + biometrics - Define the permission policy: target, function, valueLimit, validUntil
- Integrate with a Bundler (Pimlico/Stackup) and Paymaster (Pimlico Verifying Paymaster)
- Build UI to display active sessions, TTL, and manual revocation
- Test and deploy
What's Included in the Work
- Smart account development on ERC-4337 (if absent)
- Session keypair generation (secp256k1) on device
- Permission policy with target, valueLimit, validUntil
- Bundler integration (Pimlico/Stackup)
- Paymaster connection (Pimlico Verifying Paymaster / Biconomy)
- UI for session management (TTL display, manual revocation)
- API documentation and code samples
- Training for your team
Things to Consider
Bundler fees: UserOperations via a Bundler cost gas. For sessions with frequent transactions, use a Paymaster—a smart contract that covers gas for the user. Integration with Pimlico Verifying Paymaster or Biconomy is standard.
You cannot create a session key without internet—enableSessionKey must be sent to the network. Cache sessionKeyData locally and allow reuse until TTL expiry without another request.
Timeline: 3 to 5 business days: ERC-4337 smart account (if not present), session keypair, permission policy, Bundler/Paymaster integration, session UI. If a smart account already exists, 2 to 3 days.
Contact us for a consultation—we guarantee security and reliability. Order a technical audit of your project to see how Session Keys can speed up your app.