How Session Keys Are Generated and Scoped
An onchain session key is a new keypair generated with a secure random source on the device that will use it. Its public address is registered with a smart contract account together with limits such as a spending cap, allowed assets or contracts, and an expiry. The account then accepts that key's signatures only within those limits.
Two meanings of session key
The term is used in two related ways, and search results mix them.
In network cryptography, a session key is a short-lived symmetric key agreed between two parties for one connection. Protocols such as TLS derive it through a key exchange so that each session is encrypted with a different key, and compromise of one session does not expose others. It is generated by the protocol, used for encryption, and discarded when the session ends.
In smart contract accounts, a session key is a separate signing keypair that an account owner authorises to act on the account's behalf, within limits and for a limited time. It exists so that software, a game client, or an agent can sign transactions without holding the owner's key.
Both share the idea behind the name: a key with narrow scope and a short life, so that losing it costs little. The rest of this page is about the second meaning, which is the one that matters for agent payments.
Generating and registering one
1. Generate the keypair locally. The device or process that will use the key creates it, using the operating system's cryptographically secure random number generator and a standard library for the chain's curve. The private key should never be generated on a server and transmitted, and never derived from anything guessable.
2. Store the private key in a protected store. An operating system keychain or hardware-backed secure storage releases the key only to the authorised process. A plain file or environment variable exposes it to anything that can read the process environment.
3. Define the scope. Decide what this key may do: a maximum amount per transaction and per period, which assets, which recipient addresses or contracts, which contract functions, and an expiry time.
4. Register it with the account. The owner signs a transaction or authorisation that adds the session key's public address and its permissions to the smart account. The session key cannot grant itself permissions; only the owner can.
5. Use it. The agent signs operations with the session key. The account's validation logic checks each one against the registered permissions and rejects anything outside them, onchain, regardless of what the agent intended.
Why generation location matters
If a service generates the session key and sends it to the client, that service had the private key at some point, and so did every log, queue, and network hop in between. Generating on the device that signs means the private key exists in exactly one place from the moment it is created.
Scope, expiry, and revocation
Enforced onchain. The limits live in the account's validation logic, not in the agent's code. A compromised agent, a prompt injection, or a bug in the payment client cannot talk the account into exceeding them.
Useful scopes for payments.
- A spending cap per transaction and per rolling period.
- A single asset, such as USDC, by exact contract address.
- An allowlist of recipients or contracts, where the set of counterparties is known.
- An expiry after which signatures are rejected.
Expiry is a safety net. A key that expires in a day limits the damage window even if nobody notices a leak. Short-lived keys that are rotated automatically are safer than long-lived ones rotated by hand.
Revocation must be fast and available. The owner should be able to remove a session key with one signed action, and the tooling to do it should be tested before it is needed.
Monitoring closes the loop. Every operation signed by a session key should be logged with its key identifier, so unusual spending can be traced to a specific key and that key revoked.
CryptoCadet uses this pattern on Base: the agent spends from a float bounded by session keys, and key custody is held through the OS keychain, so the agent can pay autonomously without holding the owner's authority.
Standards to look at
Smart account standards in the Ethereum ecosystem, including account abstraction and modular account designs, define how validation and permission modules plug into an account. Using an audited, widely deployed permission module is far safer than writing custom validation logic for session keys.
Frequently asked questions
- How are session keys generated?
- The device or process that will use the key creates a new keypair locally, using the operating system's cryptographically secure random source and a standard library for the chain's curve. The private key goes into protected storage, and only its public address is registered with the smart account.
- What can a session key be limited to?
- Typical limits are a spending cap per transaction and per period, specific assets identified by contract address, an allowlist of recipients or contracts, particular contract functions, and an expiry time. The smart account enforces these limits onchain when it validates each signature.
- How do you get a session key for a smart account?
- Generate a keypair on the device that will sign, then have the account owner sign an authorisation adding that key's address and permissions to the account. A session key cannot grant itself permissions, so the owner key is always needed for registration.
- Are TLS session keys the same as onchain session keys?
- They share an idea but differ in use. A TLS session key is a short-lived symmetric key negotiated to encrypt one connection. An onchain session key is a signing keypair authorised by an account owner to act within limits for a limited time.