Skip to main content

​
What is a session key?

A session key is like a temporary access card. It works on specific doors, during specific hours, and you can revoke it anytime. A session key lets an agent transact from your wallet with restrictions: only certain contracts, only up to a certain amount, only until a certain time. The agent never gets the owner’s private key.

​
The session key systems that exist today

There are three main approaches, and they don’t talk to each other:
SystemWho uses itHow it works
ZeroDev session keysZeroDev Kernel walletsSession key + policies validated by Kernel’s permission validator during UserOp validation.
MetaMask Delegation FrameworkMetaMask smart accounts (open framework, but adoption is MetaMask-centric)Signed delegation objects with caveats (policy contracts). Redeemed through a DelegationManager contract.
SmartSessions (Rhinestone / Biconomy)Any ERC-7579 account (Kernel, Nexus, Safe)ERC-7579 module with session keys and policies. Closest to a cross-wallet standard for session key enforcement.

​
The problem: none of these are portable

A common assumption: “I go to MetaMask, set guardrails on Ethereum to trade. Any agent I connect to that wallet can make use of it, and stay within those guardrails.” That is not how it works. Here is what actually happens:
  • You set up guardrails on MetaMask. Those guardrails live inside MetaMask’s DelegationManager contract. Only agents built for MetaMask’s system can use them. An agent built for ZeroDev? Can’t read them. Different system.
  • You set up guardrails on ZeroDev. Those guardrails live inside ZeroDev’s permission validator. MetaMask agents can’t read them. Biconomy agents can’t read them.
Each system stores its policies in its own contracts, in its own format. Switch wallets? Start over. Switch agent frameworks? Start over.

​
What’s still missing

Even with SmartSessions, concrete problems remain:
  • Spending limits are lifetime, not rolling. You set 1000 USDC. Agent spends 900. Limit hit. Session dead. No “1000 USDC per day that resets tomorrow.”
  • New session = fresh counters. Agent hits its limit. Gets a new session key. All counters reset to zero. The limit meant nothing.
  • Key management is per-wallet. You run 5 agents across 3 accounts. A key is compromised. You revoke it on each account separately. Miss one and the compromised key is still active.
  • No unified audit trail. An investor asks what your agents did last month. No single log exists. You piece together block explorer data manually.

​
What Functor brings: the KeyStore layer

Functor’s KeyStore is a standalone onchain contract that stores your keys independently of any wallet. The FunctorPolicyHook enforces policies per key, not per session.
Today (without Functor)With Functor
Each wallet manages its own keys separatelyKeys live in the KeyStore. Register once, use on any ERC-7579 account.
Policies are tied to sessions. New session = reset.Policies are tied to keyIds. New session, same keyId = same counters.
Spending limits are lifetime onlyRolling time-windowed limits (1000 USDC/day, resets daily)
Revoke a key on each account separatelyRevoke once in the KeyStore, revoked everywhere
No unified log of agent activityEvery transaction emits an audit event onchain

​
Simple analogy

Session keys today = company badges. Each company issues their own. Your Google badge doesn’t work at Apple. Your MetaMask session key doesn’t work on ZeroDev. Functor KeyStore = a passport. Issued once, recognized everywhere. Your identity and permissions are yours, not the company’s.