Rate Limit Policy
Limit how frequently a session key can send UserOps.
For the complete documentation index, see llms.txt.
What this policy does
The rate limit policy throttles how often a session key can send UserOps. It enforces one UserOp per interval, for up to count intervals. This is ideal for recurring actions like subscriptions, periodic trades, or scheduled maintenance.
If the session key tries to send more than one UserOp within the same interval, the additional UserOps are rejected.
Code examples
Monthly subscription style limit
Allow one UserOp every 30 days.
import { toRateLimitPolicy } from "@namera-ai/sdk/policy";
const secondsInDay = 60 * 60 * 24;
const interval = 30 * secondsInDay;
const rateLimitPolicy = toRateLimitPolicy({
count: 1,
interval,
});Start in the future
Block usage until a specific start time, then allow one UserOp per hour.
import { toRateLimitPolicy } from "@namera-ai/sdk/policy";
const startAt = Math.floor(Date.parse("2026-01-01T00:00:00Z") / 1000);
const oneHour = 60 * 60;
const rateLimitPolicy = toRateLimitPolicy({
count: 1,
interval: oneHour,
startAt,
});Add the policy to the policies array when creating a session key. See Create Session Key or Create Passkey Session Key for the full flow.
Argument behavior:
countis the number of intervals available (one UserOp per interval).intervalis the length of each interval in seconds.startAtsets when the limit starts. If omitted, the policy is active immediately.
Real-world use cases
- Subscriptions: one payment per month for a SaaS plan.
- DCA bots: one swap per day to average into a position.
- Maintenance jobs: one cleanup call per hour on a vault or pool.
When to use and when not to use
Use when:
- You need predictable, periodic execution.
- You want to throttle an agent and prevent spamming.
Avoid when:
- The workflow needs bursty or high frequency execution.
- You already enforce strict call limits and rate limiting is unnecessary.