Skip to main content
Smart Sessions let a wallet owner grant a remote party (a backend, an app’s own server, or a partner service) limited, time-bounded, revocable access to send transactions from their wallet. The remote party submits transactions without the wallet owner being online; the wallet’s on-chain Sessions Module enforces every permission.

​
The problem Smart Sessions solve

Standard wallet UX requires the user to approve every transaction. For recurring payments, scheduled transfers, batch settlements, and multi-step checkouts, that is unacceptable friction. Smart Sessions replace per-transaction approvals with a scoped, time-limited permission grant enforced on-chain.

​
The three-actor model

​
Setup flow

1

Register a credential

The remote backend calls registerCredential to register its signer as a remote access credential. WaaS returns a credentialId. The same credential can later be authorized for multiple sessions and wallets until it expires or is revoked.
2

Create an approval request

The application shares the credentialId, requested network, grants, and expiry with the client app through its own authenticated approval flow.
3

Authorize remote access

The client app calls inspectRemoteCredential and displays the returned public metadata and exact requested grants. After explicit owner approval, it calls authorizeRemoteAccess with the credentialId, network, grants, and expiry. WaaS creates an enclave-held session signer and stores the authorized session binding. Authorization itself does not submit a transaction; the wallet configuration is reconciled during a later execution.
4

Associate the session

The application associates the returned walletId and sessionId with its workflow. The client can send them through an authenticated endpoint, or the backend can reconcile its sessions with listSessions. The backend verifies authoritative session details with getSession.

​
Operating a session

Once authorized, the remote backend uses getSession to resolve authoritative session details. prepareTransaction checks the requested transaction against the approved grants, and executeTransaction revalidates the session, reconciles the wallet configuration, signs inside the enclave, and submits it. The Sessions Module independently enforces the grant on-chain. Use getTransactionStatus to read the submitted transaction’s status.

​
Revocation

Two revocation paths are available:
  • The wallet owner can revoke a specific session at any time with revokeAccess({ credentialId, sessionId }).
  • The remote backend can call revokeCredential({ credentialId }) against its own credential to retire that credential and all sessions authorized for it. This is useful for key rotation or in case of compromise.
Revocation prevents WaaS from using the affected session immediately. Its on-chain configuration entry is removed during a subsequent wallet execution.

​
What sessions can and cannot do

  • Sessions are bounded by the native-token or ERC-20 transfer grants the wallet owner approved with authorizeRemoteAccess. The Sessions Module rejects transactions outside that scope at the contract level.
  • A session cannot expire after its remote access credential.
  • The session key never leaves the enclave.
  • The remote backend cannot broaden its own grants. The wallet owner can update one existing session by authorizing again with that sessionId, or revoke it with revokeAccess.

​
Further reading

Backend implementation guide

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

Technical deep dive

How the Sessions Module is structured in the wallet’s V3 config tree, how session keys are generated, and how on-chain enforcement works.

Wallet configuration

The on-chain configuration tree that holds the Sessions Module.