Create a session with a custom setup

Installing the validation

You can install the validator during account deployment: Examples on this page use @rhinestone/sdk, where rhinestone is the RhinestoneSDK instance from the custom signer quickstart.

const rhinestoneAccount = await rhinestone.createAccount({
  owners: {
    type: "ecdsa",
    accounts: [ownerAccount],
  },
  sessions: {
    enabled: true,
  },
});

You can also install it when the account is already deployed:

import { enable } from "@rhinestone/sdk/actions/smart-sessions";

const transaction = await rhinestoneAccount.prepareTransaction({
  chain: base,
  calls: [enable()],
});

To uninstall the validator:

import { disable } from "@rhinestone/sdk/actions/smart-sessions";

const transaction = await rhinestoneAccount.prepareTransaction({
  chain: base,
  calls: [disable()],
});

Creating sessions

To create a session, use RhinestoneSDK.createSession:

const session = await rhinestone.createSession({
  chain: base,
  owners: {
    type: "ecdsa",
    accounts: [sessionOwnerAccount],
  },
});

To limit the session to specific calls, list the permissions and set restrictToActions:

const session = await rhinestone.createSession({
  chain: base,
  owners: {
    type: "ecdsa",
    accounts: [sessionOwnerAccount],
  },
  permissions: [
    {
      abi: erc20Abi,
      address: usdcAddress,
      functions: { transfer: {} },
    },
  ],
  restrictToActions: true,
  saltMode: "strict",
});

Permissions alone do not make a restrictive allowlist. Without restrictToActions, the session retains the wildcard intent-execution fallback for calls approved by the Orchestrator’s intent target allowlist. See Restrict a session for the behavior and tradeoffs. Keep saltMode: "strict" when creating a new restricted session. The SDK 2.16.1 default, "none", uses a zero salt, so sessions with the same signer reuse a permission ID even when their actions differ. Enabling another definition under that ID adds its policies to the on-chain sets instead of replacing earlier grants. Strict mode gives different restricted definitions distinct permission IDs, but it does not invalidate any permission ID that the signer already controls. Revoke the previous broader session before relying on the signer to have narrower authority. Permissions govern account calls, while cross-chain permits govern the separate Permit2 claim-signing surface for source-chain assets in cross-chain intents. Because those claims rely on fallback policies for spending and time bounds, the SDK does not allow restrictToActions with crossChainPermits or claimPolicies. Finally, you can constrain function parameters. The SDK derives the selector and parameter offsets from the ABI, so you reference parameters by name:

const session = await rhinestone.createSession({
  chain: base,
  owners: {
    type: "ecdsa",
    accounts: [sessionOwnerAccount],
  },
  permissions: [
    {
      abi: erc20Abi,
      address: usdcAddress,
      functions: {
        transfer: {
          params: {
            recipient: {
              condition: "equal",
              value: "0xd8da6bf26964af9d7eed9e03e53415d37aa96045",
            },
          },
        },
      },
    },
  ],
  restrictToActions: true,
  saltMode: "strict",
});

See the Call policy for the full set of parameter conditions, and Restrict a session to make the listed permissions the only calls the session can run.

Embedded wallet

Custom setup

Create a session with a custom setup

Installing the validation

Creating sessions

Next steps

Use a session

Session signing

​Installing the validation

​Creating sessions

​Next steps

Use a session

Session signing

Installing the validation

Creating sessions

Next steps