Session limits - Rhinestone

Session limits define the maximum authority an app-held key can exercise. Choose the narrowest scope that supports the workflow, then pass it to the session grant.

Contract and function scope

definePermissions() binds each entry to one contract address and the selectors derived from its ABI. Listing one function does not authorize other functions on that contract. Examples on this page use @rhinestone/1auth. vault and vaultAbi are your own contract’s address and ABI.

import { definePermissions } from "@rhinestone/1auth";

const permission = definePermissions({
  address: vault,
  name: "USDC vault",
  abi: vaultAbi,
  functions: {
    deposit: {},
  },
});

An empty function configuration leaves that function’s parameters unconstrained. Add explicit rules for recipients, spenders, asset addresses, and amounts that must not vary.

Parameter and value limits

Use parameter names from the ABI. This example fixes the vault receiver and caps each deposit:

const maxDeposit = parseUnits("500", 6);

const permission = definePermissions({
  address: vault,
  name: "USDC vault",
  abi: vaultAbi,
  functions: {
    deposit: {
      params: {
        assets: {
          condition: "lessThanOrEqual",
          value: maxDeposit,
        },
        receiver: {
          condition: "equal",
          value: accountAddress,
        },
      },
    },
  },
});

For payable functions, cap the native token sent with each call:

functions: {
  deposit: {
    valueLimitPerUse: parseEther("0.1"),
  },
}

Parameter rules are calldata constraints. They do not infer business meaning from an ABI. For a token workflow, constrain every relevant leg—for example, both the spender and amount on approve, then the receiver and amount on deposit.

Chain scope

Pass every destination execution chain explicitly in targetChains:

await oneAuth.grantPermissions({
  accountAddress,
  targetChains: [8453, 42161],
  sessionKeyAddress,
  ...permission,
});

The same reviewed permission is installed on each listed target chain. Embedded wallets return chainIds and permissionIdsByChain in the session handle; use the entry for the chain that executes each operation. Do not treat a chain’s presence in a wallet, quote, or token request as session authority. Only the session-key configuration installed for that chain can authorize the session signer there.

Time and usage limits

Set limits in the grant or on individual function configurations. Grant-level values are copied onto every listed function that does not override them. They do not create one shared session-wide counter.

Limit	Value	Enforcement
Start time	`validAfter`	Rejects use before this Unix timestamp in seconds.
Expiry	`validUntil`	Rejects use after this Unix timestamp in seconds.
Usage count	`maxUses`	Caps accepted calls independently for each function on each installed chain.
Native value	`valueLimitPerUse`	Caps native value for each matching function call.

const validAfter = Math.floor(Date.now() / 1000);

await oneAuth.grantPermissions({
  accountAddress,
  targetChains: [8453],
  sessionKeyAddress,
  validAfter,
  validUntil: validAfter + 24 * 60 * 60,
  maxUses: 25,
  ...permission,
});

Use seconds, not JavaScript milliseconds. Expiry applies to every function receiving the default. Usage exhaustion is narrower: exhausting one function’s counter on one chain blocks that function on that chain, while other function and chain counters can remain usable. Treat the whole grant as exhausted only after checking every installed policy that matters to your workflow.

Source-chain claim authority

A destination selector does not authorize a settlement layer to claim assets on a funding chain. For a crosschain intent, configure both:

targetChains and normal permissions for calls on the destination chain.
sourceChains and crossChainPermits for Permit2 claim signatures on funding chains.

import {
  createCrossChainPermission,
  definePermissions,
} from "@rhinestone/1auth";
import { parseUnits } from "viem";
import { arbitrumSepolia, baseSepolia } from "viem/chains";

const maxBridgeSpend = parseUnits("100", 6);
const validAfter = Math.floor(Date.now() / 1000);
const validUntil = validAfter + 24 * 60 * 60;

const destination = definePermissions({
  address: vaultOnArbitrum,
  name: "Vault",
  abi: vaultAbi,
  functions: {
    deposit: {
      params: {
        assets: {
          condition: "lessThanOrEqual",
          value: maxBridgeSpend,
        },
        receiver: { condition: "equal", value: accountAddress },
      },
    },
  },
});

const claim = createCrossChainPermission({
  from: {
    chain: baseSepolia,
    token: tokenOnBase,
    maxAmount: maxBridgeSpend,
  },
  to: {
    chain: arbitrumSepolia,
    token: tokenOnArbitrum,
    recipient: accountAddress,
  },
  validAfter: BigInt(validAfter),
  validUntil: BigInt(validUntil),
  settlementLayers: ["ACROSS"],
});

await oneAuth.grantPermissions({
  accountAddress,
  targetChains: [arbitrumSepolia.id],
  sourceChains: [baseSepolia.id],
  sessionKeyAddress,
  validAfter,
  validUntil,
  maxUses: 25,
  permissions: destination.permissions,
  contracts: destination.contracts,
  crossChainPermits: [claim],
});

The source-chain configuration authorizes only the structured claim. Selector permissions are not copied onto a source-only chain. The claim binds the source token and cap, destination token and recipient, time window, and allowed settlement layer. Omitting sourceChains and crossChainPermits grants no Permit2 claim authority. Adding only sourceAssets to prepareIntent() can constrain route selection, but it does not create onchain session authority.

Review checklist

Before opening the grant dialog, confirm:

every contract address belongs to the intended chain;
every function has only the parameter freedom the workflow needs;
approvals bind a spender and amount;
recipients are fixed where possible;
time windows and use counts have finite bounds;
each funding chain has a matching crosschain permit;
app-supplied names and ABI metadata are treated as display hints, not verified policy.

​Contract and function scope

​Parameter and value limits

​Chain scope

​Time and usage limits

​Source-chain claim authority

​Review checklist