Timeframe

Restrict when a session function can be called. Attach the policy at the function level. Examples on this page use @rhinestone/sdk, where rhinestone is the RhinestoneSDK instance from Create a session with a custom setup.

import { erc20Abi } from "viem";
import { base } from "viem/chains";

const session = await rhinestone.createSession({
  chain: base,
  owners: {
    type: "ecdsa",
    accounts: [sessionOwnerAccount],
  },
  permissions: [
    {
      abi: erc20Abi,
      address: usdcAddress,
      functions: {
        transfer: {
          validAfter: new Date(),
          validUntil: new Date(Date.now() + 1000 * 60 * 60 * 24),
        },
      },
    },
  ],
});

This limits the function to a 24-hour window.

Session windows

Several parts of a session take their own validAfter / validUntil window:

Window	Applies to
Permission function	Calls to that function
Cross-chain permit	Every action the permit adds. On `ACROSS`, also the Permit2 deadline.
Swap scope	The scope’s approve and swap calls
`oneTimeUse.validUntil`	When the one-time-use ID can be spent, and so every action in the session
`signing`	ERC-1271 signing

Each window is a separate policy. All of them use whole seconds and admit validAfter <= t < validUntil, with validAfter rounded up. validUntil must be a future Date (VALID_UNTIL_NOT_IN_FUTURE), and validAfter must be earlier than it (VALID_AFTER_EXCEEDS_VALID_UNTIL). Action windows use the action-enforcing TimeFramePolicy. On a chain without it, they are refused with TIME_FRAME_POLICY_UNAVAILABLE.

An intent sends no enable data for a permission ID that is already enabled. On a session with the default zero salt, which every unrestricted session uses, the window may therefore not be installed when an intent enables the session. validateSession warns with ACTION_WINDOW_SHARED_PERMISSION_ID. Use a fresh session key, or a restricted session with saltMode: "strict".

Embedded wallet

Custom setup

Session windows

​Session windows

Session windows