Skip to main content
For a product-level overview, see 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:
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

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

Backend implementation guide

Register a persistent RAC, collect owner approval, reconcile application state, and execute bounded transactions.

Smart Sessions overview

Follow the product-level authorization, execution, and revocation flow.

Wallet configuration

Understand the wallet configuration tree used for on-chain authorization.

WaaS infrastructure

Learn how the enclave, key management, and relayer protect wallet operations.