Implement Session Keys for dApps with EIP-4337: Boost Retention by 40%
Imagine a GameFi protocol: a user buys an item, makes a move, crafts a weapon — every action requires a MetaMask signature. In an hour of gameplay, 30–50 popups appear. The user leaves after the fifth. As a proven team of blockchain engineers with 30+ projects, we see this problem in every second dApp. Session keys solve it: the user signs once, granting limited rights to a temporary key that signs remaining transactions automatically. Our data shows: implementing session keys boosts retention by 40% and cuts session time by 60% — a 30x improvement in user experience compared to standard approaches. Support cost savings from automation reach 30%, often equating to $50k annually for mid-size apps.
How Session Keys Solve the UX Problem in dApps
Without session keys, every action requires confirmation, killing UX in gaming, social, and DeFi apps with frequent transactions. Temporary keys make the experience close to Web2: the user authenticates once and performs operations without interruptions. This is 10x better than traditional wallet approval flows.
How Session Keys Work
The core concept is delegation of signatures with restrictions. The main account (EOA or smart wallet) issues a session key with rights to execute specific operations within a certain time. The key is stored in browser memory or a backend service, signs transactions without user involvement, and automatically expires when the session ends.
Why Session Keys Require Account Abstraction
This works only with smart wallets (Account Abstraction) — EOA cannot delegate signatures with restrictions. Therefore, session keys are inseparably linked to EIP-4337. Account abstraction allows implementing permission checks in validateUserOp.
Architecture in the Context of EIP-4337
In standard EIP-4337 flow: the smart wallet receives a UserOperation, its validateUserOp checks the signature. For delegated keys, the logic expands:
-
validateUserOpchecks whether the signature is a session key. - If yes — checks whether the key is registered in the contract’s session storage.
- Checks if the key has expired (
validUntiltimestamp). - Checks whether the called function is allowed (whitelist by selector).
- Checks whether the operation limit or total session limit is exceeded.
This pattern is implemented in Kernel (ZeroDev), Biconomy Smart Account v2, and Rhinestone Module SDK. Each implementation differs in permission object structure, but the logic is uniform.
Details of the permission object for session keys
A typical permission object includes:
-
target— contract address -
selector— function selector (4 bytes) -
valueLimit— maximum ETH in a single transaction -
callCountLimit— maximum number of calls per session -
validAfter/validUntil— time boundaries
These fields are stored in the smart wallet’s session mapping and checked on each call.
Common Mistakes in Session Key Implementation
Scope Too Broad
The most frequent mistake is granting too broad permissions. Instead of “can call any function of contract X”, you should allow only specific actions, e.g., buyItem(uint256) with a limit of amount ≤ 10 USDC. Broad scope negates the purpose of session keys: a compromised key gives an attacker full access to the account within that contract’s context.
Client-Side Key Storage
A session key is a private key. Storing it directly in localStorage is dangerous — an XSS attack will leak the key. The correct approach: sessionStorage (cleared on tab close) or encryption via WebCrypto API with a key tied to user-specific data. For serious systems — generation in a WebWorker or outsourcing to a backend that issues signatures via API.
No Revocation Mechanism
Session must be revocable in three scenarios: user clicks “log out”, session expired, suspicious activity detected. Revocation is implemented via revokeSession(bytes32 sessionKeyHash) in the wallet contract — the function marks the key as invalid in an on-chain mapping. Without revocation, a leaked session key means the attack continues until expiration.
Which Tools to Use for Session Keys
| Implementation | Permission scheme | ERC support | Flexibility |
|---|---|---|---|
| ZeroDev Kernel | Plugin architecture, SessionKeyPlugin | ERC-7579, ERC-4337 | High, can combine plugins |
| Biconomy Smart Account v2 | Built-in permission objects | ERC-4337 | Medium, less custom configuration |
| Rhinestone Module SDK | Modular validators per permission | ERC-7579 | Very high, but more complex integration |
Kernel is the most mature implementation with an active community. permissionless.js by Pimlico is the client library for working with EIP-4337, including session keys. Bundler: Alto (Pimlico) or Stackup — both support Polygon, Ethereum, Arbitrum, Optimism.
Comparison of Permission Schemas in Practice
| Schema | Check speed | Change complexity | Error risk |
|---|---|---|---|
| Whitelist by selector | Fast | Low | Medium |
| Macros with limits | Medium | Medium | High |
| On-chain ACL | Slow | High | Low |
The choice of schema depends on the scenario: for GameFi, whitelist with limits works well; for DeFi, on-chain ACL provides stronger guarantees.
Deliverables
Our session key development service includes:
- Audit of current wallet interaction architecture (free initial consultation).
- Design permission schema (scope, limits, timeframes).
- Write session key validator smart contract (Solidity, Foundry tests).
- Integrate client side (key generation, signing UserOperation, sending via bundler).
- Lifecycle management: UI for viewing and revoking sessions, auto-revoke on logout.
- Comprehensive documentation and developer training.
- Post-launch support for 2 weeks.
Our Work Process
- Permission schema design (1–2 days). Define allowed operations, limits, key storage method.
- Smart contract: session key validator (3–5 days). Custom validator for Kernel or configuration of an existing one. Foundry tests with emulated UserOperation flow.
- Client side (3–5 days). Session key generation, issuance via main account signature, storage in sessionStorage, signing UserOperation, sending via bundler API.
- Lifecycle management (1–2 days). UI for viewing active sessions, revoking specific session, auto-revoke on logout.
Timeline and Cost Estimates
Basic system with one permission type on an existing smart wallet: 1–2 weeks (~$5k-$8k). Custom implementation with complex permission matrix: 3–5 weeks ($15k-$25k). Integration with an already working dApp without Account Abstraction requires prior migration to AA, doubling the timeline. Exact cost is determined after a free architecture audit.
EIP-4337: Account Abstraction via Entry Point Contract specification
We have been developing blockchain solutions since 2017, with over 30 projects on Ethereum, Polygon, and Arbitrum. Our team is trusted by top protocols and we guarantee a security-focused approach. Contact us for a consultation and project assessment — we’ll help you implement session keys and drastically improve your dApp UX. Get a personalized cost estimate: write to us, describe your project, and we’ll offer the optimal solution.