What is a session key in cryptography?

A temporary symmetric key used to encrypt and authenticate traffic for a single session, as in TLS or Kerberos. It exists so expensive asymmetric operations happen once while bulk traffic uses fast symmetric cryptography, and it is discarded afterwards so that any one key protects a limited amount of data.

What is an onchain session key?

A separate keypair registered with a smart account and granted narrow authority: a spending cap, permitted assets or contracts, and an expiry. The account enforces those limits when validating signatures, so a process holding the key cannot exceed the scope it was given.

Are the two kinds of session key related?

Only by analogy. Both are temporary and scoped, which is why the name was reused, but they solve different problems. The classical one provides confidentiality for a conversation; the onchain one provides bounded authorisation for actions. Neither can substitute for the other.

Is a session key the same as an API key?

No. An API key is a long-lived bearer credential that identifies a caller, and possessing it generally grants whatever access that caller has. A session key in either sense is deliberately temporary and limited, which is the property an API key specifically lacks.

What happens when an onchain session key expires?

The account stops accepting its signatures, so any process still holding it can no longer act. That is the point of the expiry: it bounds the window in which a leaked key is useful, without requiring anyone to notice the leak and revoke it manually.

Does a session key mean funds are held by someone else?

Not necessarily. In a non-custodial design the account remains under the owner's control and the session key is a scoped delegation from it, so the key holder can act within limits but cannot withdraw the account's assets or change its rules.

Session Keys in Cryptography vs Onchain Session Keys

In classical cryptography a session key is a temporary symmetric key that encrypts traffic for one session, as in TLS or Kerberos. In smart account systems an onchain session key is a separate keypair registered with an account and granted narrowly scoped, time-limited authority to sign transactions. Both are temporary and scoped; they do different jobs.

The classical meaning

In TLS, a handshake establishes a shared secret from which symmetric keys are derived, and those keys encrypt and authenticate the records exchanged for the rest of the connection. They exist so that expensive asymmetric operations happen once, while the bulk of traffic uses fast symmetric cryptography. They are discarded when the connection ends, which limits how much traffic any single key protects and means compromise of a long-term key does not retroactively decrypt past sessions where forward secrecy applies.

In Kerberos, a session key is issued by a trusted third party and shared between a client and a service so they can authenticate to each other and protect their exchange. The ticket carrying it has a lifetime, and the same reasoning applies: a short-lived secret limits exposure.

The defining property in both cases is confidentiality and integrity for a conversation. The key answers can this traffic be read or tampered with. It says nothing about what either party is permitted to do, and it is typically symmetric, held by both sides.

What it is not

A session key in this sense is not a session cookie, which is an identifier a browser presents to be recognised, carrying no cryptographic function of its own. It is also not an API key, which is a long-lived bearer credential identifying a caller. Both are sometimes called session keys informally, and neither is temporary in the way the term implies, which is part of why the vocabulary is muddled.

Why both are short lived

The shared reasoning behind the name is worth stating, because it is the one real similarity. A secret that exists forever accumulates exposure: more traffic protected by one key, more chances for it to leak, more value behind it if it does. Making it temporary caps that accumulation and removes the need for anyone to detect a compromise in order for the damage to end. In TLS this shows up as a key discarded when the connection closes, so past sessions stay protected even if a long-term key is later compromised. Onchain it shows up as an expiry after which the account simply stops accepting the key's signatures. In both cases the expiry does work that no monitoring has to do.

The onchain meaning

In smart account systems a session key is a fresh keypair generated on the device that will use it. Its public address is registered with the account contract together with constraints: a spending cap, which assets or contracts it may touch, and an expiry. The account then accepts signatures from that key for actions inside those limits, and rejects everything else.

The purpose is authorisation, not confidentiality. Nothing is being encrypted. The question answered is what may this key do, and the value is that the answer is enforced by the account rather than promised by the software holding the key.

This is what makes autonomous operation tractable. A process can hold a key that is genuinely incapable of exceeding its budget or touching assets outside its scope, so delegating signing authority to it does not mean delegating everything. For agent payments that is the whole design: a bounded float under session-key control, with the main account's authority never present in the running process.

The constraints are the substance of the mechanism. A session key registered without meaningful limits is just another key with full authority and a shorter life, which is a much weaker property than it sounds.

Why the account enforces the limits, not the software

The distinction that makes onchain session keys useful is where the constraint lives. Software holding a key can be told to stay within a budget, and that instruction is only as good as the software. If the process is compromised, or a bug lets it construct a transaction it should not, the instruction provides nothing, because the key itself was always capable of signing anything the account would accept. Registering limits with the account moves the check to the side that validates signatures. The account rejects an over-limit transfer regardless of what the holder intended or what state the holder is in. That is why a session key with registered constraints is a meaningfully different object from a key that some wrapper promises to use carefully, and it is the property that makes handing signing authority to an autonomous process a bounded decision rather than an open-ended one.

Frequently asked questions

What is a session key in cryptography?: A temporary symmetric key used to encrypt and authenticate traffic for a single session, as in TLS or Kerberos. It exists so expensive asymmetric operations happen once while bulk traffic uses fast symmetric cryptography, and it is discarded afterwards so that any one key protects a limited amount of data.
What is an onchain session key?: A separate keypair registered with a smart account and granted narrow authority: a spending cap, permitted assets or contracts, and an expiry. The account enforces those limits when validating signatures, so a process holding the key cannot exceed the scope it was given.
Are the two kinds of session key related?: Only by analogy. Both are temporary and scoped, which is why the name was reused, but they solve different problems. The classical one provides confidentiality for a conversation; the onchain one provides bounded authorisation for actions. Neither can substitute for the other.
Is a session key the same as an API key?: No. An API key is a long-lived bearer credential that identifies a caller, and possessing it generally grants whatever access that caller has. A session key in either sense is deliberately temporary and limited, which is the property an API key specifically lacks.
What happens when an onchain session key expires?: The account stops accepting its signatures, so any process still holding it can no longer act. That is the point of the expiry: it bounds the window in which a leaked key is useful, without requiring anyone to notice the leak and revoke it manually.
Does a session key mean funds are held by someone else?: Not necessarily. In a non-custodial design the account remains under the owner's control and the session key is a scoped delegation from it, so the key holder can act within limits but cannot withdraw the account's assets or change its rules.