Skip to main content
A session key is a separate signing key that you authorize to act on behalf of a smart account. Its authority comes from the session configuration you approve, rather than from ownership of the account. This lets an application perform repeated actions or run background automation without asking you to approve every transaction. The transactions are still signed—by the session key instead of your main signer.

​
Keys, permissions, and policies

Three pieces define a session:
  • The key signs requests on behalf of the account.
  • Permissions specify the actions it can request, such as calling a particular function on a contract.
  • Policies constrain those actions, such as fixing a recipient, limiting an amount, or setting an expiry.
Rhinestone’s session-key validator checks the signature and applicable policies onchain. The application cannot bypass those checks by submitting a request that exceeds the enabled authority. For example, you could authorize an application to transfer USDC on Base to a fixed recipient, with a maximum of 10 USDC per transfer, at most ten times, within seven days. The application can initiate those payments without further owner approval, but it cannot use that restricted permission to change the recipient or exceed the limits.

​
What can be scoped

Session permissions can cover more than contract calls:
  • Executions: which contracts and functions the key can call, with limits on parameters, recipients, and amounts.
  • Bridging and crosschain activity: which chains and tokens can fund an operation, how much can be spent, and where funds can arrive.
  • Swaps: which tokens can be sold and bought, spending caps, recipients, and permitted trading venues.
  • Signing: whether the key can authorize offchain messages or typed data, separately from executing transactions.
Time windows and usage limits further bound the session’s authority.

​
Authorize once, use within scope

  1. Define the session. Your application creates a signer and specifies the permissions and limits it needs.
  2. Approve the authority. The account owner authorizes the session configuration. Depending on the integration, it is enabled immediately or when first used.
  3. Execute permitted actions. The application signs with the session key, and the smart account checks the enabled policies before executing.
Time limits are configurable, not inherent to session keys. A session without an expiry should not be treated as temporary.

​
Sessions across chains

A session can authorize activity on multiple chains, but its onchain state remains chain-specific. Usage counters and revocation on one chain do not automatically apply to another. For crosschain intents, permission to execute destination calls is separate from permission to spend assets on funding chains. Both sides need the appropriate authorization.

​
Protecting and ending a session

Anyone who obtains the session private key can exercise its remaining authority. Narrow permissions limit the damage a compromised key can cause; they do not remove the need to protect it. Deleting a key from your application does not revoke its onchain permissions. Revocation requires changing the account’s session state on each affected chain. See Session security for key protection and incident response.

​
Next steps

  • Create a session: authorize an application-held key with an embedded wallet.
  • Session limits: configure action, parameter, time, and usage constraints.