Skip to content
Financial Context Wiki

Session Key Wallet

Learn how smart-account session keys delegate limited authority, which constraints must be enforced, and how to verify, revoke, and respond to a leaked key.

Updated

For educational purposes only; not investment advice. A leaked or overprivileged session key can cause irreversible digital-asset loss.

Direct answer

A wallet session key is usually a secondary signing key, or a delegated credential tied to one, that a smart account accepts only under defined rules. Those rules may limit time, target contracts, function selectors, token amounts, transaction count, or other conditions. The purpose is to let an app perform repeated actions without asking the account owner to approve every operation with the main signer.

“Session key” is a design pattern, not one universal Ethereum standard. ERC-4337 provides programmable account validation and time-bounded UserOperation validation, while modular-account systems such as ERC-7579 can host validators, executors, and hooks. The wallet’s deployed account and module code ultimately decide what a key can do. Expiry alone does not make a session safe, and deleting a browser copy does not necessarily revoke authority already registered on-chain or contained in an unexpired delegation.

How it works

A typical flow has 5 stages:

  1. The owner creates a fresh key pair on a device or authorizes a credential that identifies the session signer. The session private key should never be sent to the application server unless the design explicitly makes that server a trusted custodian.
  2. The owner authorizes a policy with the main wallet. Some systems install a key and policy on-chain; others use a signed delegation that the account validates when an operation arrives.
  3. The app builds an operation and signs it with the session key. In an ERC-4337 flow, the account’s validateUserOp logic checks the signature and policy; a bundler’s simulation is an admission check, not proof of execution or safety.
  4. The account must enforce every restriction before execution. Effective authority can be summarized as A_effective = K ∩ P ∩ S: possession of the key (K), the configured policy (P), and current account or chain state (S) must all permit the action.
  5. The session ends through expiry, nonce or quota exhaustion, explicit revocation, module removal, or another implementation-specific invalidation path. Confirm the resulting account state on the correct chain.

Before authorizing a session, verify:

  • the chain ID, smart-account address, account implementation, and validator or module address;
  • the session public key or credential identifier and where its private material will be stored;
  • every allowed target, function selector, token, recipient rule, native-value limit, and per-call or cumulative spending cap;
  • validAfter, validUntil, nonce rules, usage count, and whether time is measured by block timestamp or another source;
  • whether batches, nested calls, delegatecall, token approvals, module installation, account upgrades, and ERC-1271 message signatures are blocked unless specifically required;
  • who can revoke the session, whether the owner retains an independent recovery path, and whether revocation requires gas or a working bundler or paymaster.

The policy must inspect the action that will actually execute. Checking only an outer batch target can leave unrestricted inner calls; checking only the recipient while ignoring the function and value can do the same. A limit is meaningful only if the enforcing code covers every execution path.

Example

A game wallet creates a session that lasts 24 hours. It permits calls only to a verified game contract, blocks delegatecall and token approvals, caps native value at 0.02 ETH per call, and caps total spending at 20 USDC. The game can submit allowed moves without repeated owner prompts, but a request to transfer an unrelated NFT must fail validation.

Before using it, the owner records the account, chain, module, session public key, expiry, caps, and revocation method. The owner tests one low-value action, verifies the decoded call and account event, then separately tests revocation. This confirms the configured path; it does not prove that the module has no vulnerability or that a compromised device cannot spend up to the remaining limits.

Risks and controls

  • Overbroad policy: wildcard targets, unrestricted selectors, unlimited token approvals, batches, or delegatecall can turn a “limited” key into near-owner authority. Use explicit allowlists and deny administrative actions.
  • Key theft: browser storage, logs, backups, extensions, malware, and shared devices can expose the session key. Prefer hardware-backed or isolated storage where supported, short lifetimes, and low cumulative caps.
  • Faulty enforcement: an account, validator, executor, or hook can decode calls incorrectly or fail to cover an alternate execution route. Use verified deployments, reviewed code, audits, and tests for bypass cases.
  • Replay and context confusion: weak nonce handling or missing binding to the intended chain, account, module, or policy can allow reuse in another context. Verify the exact signed domain and on-chain replay protection.
  • Expiry assumptions: validUntil may bound one ERC-4337 operation without automatically removing a registered key, token allowance, or separate delegation. Check each permission’s actual state after expiry.
  • Revocation failure: deleting local data only removes one copy of the secret. Revoke through the account’s documented path and verify the on-chain result; keep enough gas and an owner-controlled fallback route.
  • Upgradeable or malicious modules: modules may have powerful execution access, and upgrades can change policy behavior. Check owners, upgrade delay, pause powers, implementation address, and module-removal procedure.
  • Gas and sponsorship abuse: a session may be able to consume account funds for gas, or become unusable when a paymaster rejects it. Bound fee behavior where possible and retain an independent submission route.

If a session key may be exposed, stop using the affected app, preserve the session identifier and relevant transaction hashes, and revoke or disable the key from a clean owner-controlled device. Then inspect pending and recent operations, token approvals, installed modules, account upgrades, and balances on every supported chain. Move remaining assets only when the account or module design makes revocation unreliable; rushing into an unverified “recovery” site can compound the loss.

Common misconceptions

  • “A session key cannot move assets.” It can perform every action its enforced policy permits, which may include transfers, swaps, approvals, or signatures.
  • “ERC-4337 defines session-key permissions.” ERC-4337 supplies an account-validation and execution framework; session policy remains wallet- or module-specific.
  • “A short expiry caps the maximum loss.” Loss also depends on per-call limits, cumulative limits, call frequency, gas, approvals, prices, and every reachable execution path.
  • “Logging out revokes the key.” Logout may delete a local copy but does not prove that on-chain registration or a signed delegation is invalid.
  • “Successful simulation means the operation is safe.” Simulation can show that current validation accepts an operation; it does not prove user intent, future inclusion, execution success, finality, or absence of module vulnerabilities.

Sources

Navigation

Search the wiki...