> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abs.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Going to Production

> Learn how to use session keys in production on Abstract Mainnet.

While session keys unlock new ways to create engaging consumer experiences, improper or malicious implementations of session keys
create new ways for bad actors to steal assets from users.

Session keys are permissionless on **testnet**, however, **mainnet** enforces several security measures to protect users.
This document outlines the security restrictions and best practices for using session keys.

## Session Key Policy Registry

Session keys are restricted to a whitelist of allowed policies on Abstract Mainnet through the [Session Key Policy Registry contract](https://abscan.org/address/0xA146c7118A46b32aBD0e1ACA41DF4e61061b6b93#code), which manages a whitelist of approved session keys.

Applications must pass a security review before being added to the
registry to enable the use of session keys for their policies.

### Restricted Session Key Policies

Session key policies that request `approve` and/or `setApprovalForAll` functions *must* be passed with additional `constraints` that restrict the approval to a specific contract address.

For example, the following policy must include a `constraints` array that restricts the approval to a specific contract address,
or will be rejected with "Unconstrained token approval/transfer destination in call policy."

```typescript theme={null}
{
  target: "0x...",
  selector: toFunctionSelector("approve(address, uint256)"),

  // Must include a constraints array that restricts the approval to a specific contract address
  constraints: [
    {
      condition: ConstraintCondition.Equal,
      index: 0n,
      limit: LimitType.Unlimited,
      refValue: encodeAbiParameters(
        [{ type: "address" }],
        ["0x-your-contract-address"]
      ),
    },
  ],
}
```

## Session Key Signer Accounts

Session keys specify a **signer** account; an <Tooltip tip="Externally Owned Account, i.e. a public/private key pair.">EOA</Tooltip> that is permitted to perform the actions specified in the session configuration. Therefore, the private key of the signer(s) you create are **SENSITIVE VALUES**!

Exposing the signer private key enables attackers to execute any of the actions specified in a session configuration for any AGW that has approved a session key with that signer’s address.

```typescript theme={null}
await agwClient.createSession({
  session: {
    signer: sessionSigner.address, // <--- The session key signer account
    // ...
  },
});
```

## Recommended Implementation

Below is an example implementation of creating a unique signer account for each session key, and storing them encrypted in the browser's local storage.

<Card title="Example Repo: Encrypted Unique Signer Keys in Local Storage" icon="github" href="https://github.com/Abstract-Foundation/examples/tree/main/session-keys-local-storage">
  View the example repository for generating unique signer accounts and storing
  them encrypted in the browser's local storage.
</Card>

## Risks of Using Session Keys

Temporary keys enable transactions without owner signatures; this functionality introduces several legal risks that developers should be aware of, particularly around security and data management. These include:

* If session keys are compromised, they can be used for unauthorized transactions, potentially leading to financial losses.
* Failing to follow recommended practices, such as creating new keys per user or managing expiration, could result in security vulnerabilities.
* Storing session keys, even when encrypted, risks data breaches. You should comply with applicable data protection laws.