> ## Documentation Index > Fetch the complete documentation index at: https://docs.polygon.technology/llms.txt > Use this file to discover all available pages before exploring further. # Smart Sessions: Technical Deep Dive > How Smart Sessions use enclave-held session signers, lazy wallet configuration, and on-chain grant enforcement. For a product-level overview, see [Smart Sessions](/wallets/smart-sessions). This page explains the security and execution model behind the public Smart Sessions APIs. ## Remote access credential A remote access credential (RAC) is a persistent keypair owned by the remote backend. The TypeScript SDK's `RemoteAccessClient` uses it to authenticate registration, session-management, and execution requests. `registerCredential` returns an opaque `credentialId`. Registering the credential does not grant access to a wallet. A wallet owner must explicitly authorize every smart session through an owner-facing OMS Wallet SDK. The requested credential lifetime is bounded by server configuration. The credential's effective expiry caps every session authorized for it, so a session can expire earlier than its RAC but never later. Registering the same active signer again returns the same credential and does not renew it. ## Session signer When the owner authorizes a new session, WaaS generates a separate session signer inside the enclave. Its private key is stored encrypted and is never returned to the client app or remote backend. The RAC authenticates the backend to WaaS. The session signer authorizes the bounded on-chain operation. These are distinct credentials with different responsibilities. Every session has its own `sessionId`. Omitting `sessionId` from `authorizeRemoteAccess` creates a new session. Supplying an existing `sessionId` replaces that session's grants, network scope, and expiry while retaining its signer. ## Public grant model The public SDKs expose two EVM smart-session grant types: * A native-transfer grant allows one recipient and a cumulative native-token limit in wei. * An ERC-20 transfer grant identifies the token, an optional recipient, and a limit in token base units. Its `cumulative` field defaults to `true`; set it to `false` to apply the limit independently to each call. Grant amounts are raw integer values. Applications should convert user-facing token amounts to base units before asking the owner to approve them. Before authorization, the client app can call `inspectRemoteCredential` and display the returned app name, URL, logo URL, and custom metadata. The consent UI should also display the exact network, grants, limits, and expiry requested by the application. ## Sessions Module and wallet configuration For an EOA wallet with no active smart sessions, the wallet configuration contains only its owner signer. It does not contain an empty Sessions Module entry. When active sessions are reconciled, WaaS builds a threshold-1 configuration containing the owner signer and a Sessions Module entry: ```text theme={null} root (threshold 1) ├── owner signer └── Sessions Module └── one entry per active session ``` Either the owner signer or an authorized session can satisfy the wallet threshold. Each session entry commits to its signer, approved grant rules, network scope, and expiry. `authorizeRemoteAccess`, `revokeAccess`, and `revokeCredential` update the authoritative session bindings in WaaS. They do not independently submit wallet-configuration transactions. During a later wallet execution, WaaS reconciles the active bindings and settles any required configuration update before the requested operation. After the last active session is removed, the next reconciliation returns the wallet configuration to its owner-only form. For EOA wallets, EIP-7702 delegation is also established lazily on the first WaaS-mediated transaction for a network. Applications do not need a separate Smart Sessions setup transaction. ## Validation and on-chain enforcement Session execution is fail-closed at both layers: 1. `prepareTransaction` checks that the requested call matches one of the session's approved grants. 2. `executeTransaction` resolves the prepared transaction and session again, rejects revoked or expired access, reconciles the active session configuration, and signs inside the enclave. 3. The Sessions Module independently verifies the session signature, network scope, expiry, recipient or token restrictions, and value or usage limit on-chain. A call that does not match an approved grant is not signed by WaaS. If an on-chain check fails, the wallet operation is rejected by the Sessions Module. Revocation prevents WaaS from using the session immediately. Its entry is removed from the wallet's on-chain session configuration during a subsequent reconciliation. Expiry remains independently enforced by the Sessions Module even before that cleanup occurs. ## Credential and session lifecycle | Event | What happens | | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | `registerCredential` | Registers the backend signer for a server-bounded lifetime. It has no wallet access. | | `authorizeRemoteAccess` without `sessionId` | Creates a session binding and enclave-held signer. Authorization itself does not submit a transaction. | | `authorizeRemoteAccess` with `sessionId` | Replaces that session's grants, network scope, and expiry while retaining its signer. | | `prepareTransaction` | Confirms that the requested transaction matches the session's grants and returns a prepared transaction. | | `executeTransaction` | Revalidates the session, reconciles the wallet configuration, signs, and submits the prepared transaction. | | `revokeAccess({ credentialId, sessionId })` | Immediately prevents WaaS from using that session; its on-chain entry is removed during a later reconciliation. | | `revokeCredential({ credentialId })` | Retires the RAC and every session authorized for it. | | Credential or session expiry | WaaS rejects expired access, and the Sessions Module independently rejects expired session signatures. | After submission, use `getTransactionStatus({ txnId })` to read the current transaction status. Continue polling according to the application's own retry and timeout policy until the transaction reaches a terminal status. ## Further reading Register a persistent RAC, collect owner approval, reconcile application state, and execute bounded transactions. Follow the product-level authorization, execution, and revocation flow. Understand the wallet configuration tree used for on-chain authorization. Learn how the enclave, key management, and relayer protect wallet operations.