Delegations

A delegation hands out spending power without handing over custody. Under the hood it's a Smart Sessions session key, scoped to exactly what you allow and revocable at any time - the delegate never holds your account's own signer.

Two shapes, one build endpoint

There are two kinds of delegation, built from the same POST /delegations/build endpoint and told apart by a kind field in the request body:

• v1 delegations - kind is dApp, automation, or recurring. Bounded by budgets, a per-action max, an action count, a recipient allowlist, and a set of allowed (contract, function) pairs.
• v2 mandates - kind is mandate. Bounded by venues (a (contract, function) pair plus optional argument rules) and per-venue spend caps, and built for a hired agent or automation acting under its own executor. See Agents for how a mandate is used in practice, and Granting a delegation for how each shape is built.

The fidelity lock

The plain-language summary you're shown - "up to 50 USDC per week to this address," for example - is never generated from what you typed into a form. It's rendered from the policy the chain actually ends up enforcing: the EnforcedPolicy for a v1 delegation, or MandateEnforced for a mandate. If the chain didn't bind it, the summary can't claim it either.

Bounded by design

A delegation's budget is always a lifetime total, never a rate. That's not a product choice - it's a constraint of ERC-4337 itself: a session's policy is checked in the validation phase, and validation-phase code is forbidden from reading block.timestamp (ERC-7562 rule OP-011), so "50 USDC per week" simply isn't something a delegation's policy can express. The same is true of an action count limit (maxActions) - it's a lifetime count, never "3 per day." Rolling windows like "per week" exist only on the account's own rules; see Rules & AgentGuard.

Every allowed action is bound to a specific (contract, function selector) pair - there's no way to grant "any function on this contract."

Status and lifecycle

A delegation's status is one of active, frozen, expired, or revoked. Once you sign and relay the enable operation, the delegation materializes as active immediately - but that's an optimistic read. The actual authority lives entirely in the on-chain Smart Sessions hook; the backend's record of a delegation is a reflection of that, never the source of truth for it.

Every delegation also carries an immutable snapshot of the policy it was built with (a PolicySnapshot), captured at build time and listable independently of the delegation record itself - a permanent, unedited history of exactly what was granted and when.

Using a delegation

A delegated action is built as a raw execute call under the Smart Sessions validator lane, not the owner's own lane. If it's out of scope - the wrong recipient, over the per-action max, or over the remaining budget - Smart Sessions rejects it in ERC-4337 validation, before the operation is ever included on-chain. Nothing gets a chance to half-execute.

See Granting a delegation for how a delegation gets built and signed, and Revoking a delegation for how to cut one off.