SDK

revokeSession

Revoke a session key from a wallet onchain. After confirmation, the session's next execute attempt reverts at validation. On the chain where the key is registered the effect is immediate, and no off-chain coordination is required.

If you have mirrored the key to an L2 cache, revocation does not reach that cache on its own. See Cross-chain revocation below.

// `client`, `wallet`, `admin`, and `session` from earlier
await client.revokeSession({ wallet, signer: admin, session });

You can also pass just the session's public key:

const sessionPublicKey = "0x04..." as `0x${string}`;
await client.revokeSession({ wallet, signer: admin, session: sessionPublicKey });

Keystore impact

Revocation calls Keystore directly, not the Controller. The call is gated onchain by onlyKeyOwnerOrValidator, so only the wallet itself (executing inside its own userOp) or a designated validator can revoke a key. A random caller reverts at the modifier.

Revocation is monotonic: once a key is revoked, it cannot be reactivated. To restore session access for a wallet, grant a new session with a fresh keypair.

Sessions granted with register: false (see grantSession) have no Keystore entry — for those, revokeSession skips the Keystore call automatically and revokes the account-level authority alone, which is what actually strips the session's power.

Parameters

client.revokeSession(opts: ClientRevokeSessionOptions): Promise<ExecuteResult>;
 
type ClientRevokeSessionOptions = {
  wallet: Wallet;
  signer: Signer;                 // the wallet's admin signer
  session: Session | Hex;         // the Session object or just its public key
  feeToken?: Address;
  chainId?: number;               // defaults to the client's default chain
};

What lands onchain

In a single userOp:

The session is revoked in Keystore (skipped if the session was never registered). From the next block onward, isValidKey returns false for that key and the key id is dropped from getKeys.
The session's authority on the wallet's smart account is pulled.

Both atomic. After the userOp confirms, the session is dead on that chain: there is no window in which one half has landed and the other has not.

Cross-chain revocation

revokeSession acts on one chain, the one you passed via chainId (or the client's default). It does not touch any other chain's state.

An L2 cache keeps reporting the old answer until you prove otherwise

If the session was mirrored to an L2 cache with ensureKeyCached, that cache still returns isValidKey == true after you revoke on L1. Anyone verifying against the cache, such as a counterparty checking whether your agent is authorized, sees a live key until a post-revocation proof lands.

Call syncKeyToL2 explicitly after revokeSession:

import { syncKeyToL2, ETHEREUM, BASE } from "@altananetwork/sdk";
 
await client.revokeSession({ wallet, signer: admin, session });
 
// Push the revocation to every L2 cache holding this key. The clients are the
// same ones ensureKeyCached takes — see /sdk/sync-to-l2 for how to build them.
await syncKeyToL2({
  l1Client, l2Client, l2WalletClient,
  l1KeyStore: ETHEREUM.keyStore,
  l2Cache: BASE.keyStoreCache,
  user: session.walletAddress,
  publicKey: session.publicKey,
});

ensureKeyCached will not do this for you. It returns early when the cache reports the key as valid, which is exactly the state a stale cache is in after a revocation. Use syncKeyToL2, which always submits a fresh proof.

Once the cache observes revoked=true it cannot be flipped back, even by a proof against an older L1 block. See ensureKeyCached for the full cross-chain model.

Notes

Revocation does not require the session signer, only the wallet's admin signer.
You can keep just the session's public key in your records for revocation purposes, then discard the rest of the Session object once granted.
A failed revocation returns status: "FAILED" rather than throwing. Check the returned status; do not assume success because nothing was raised. See Errors.