Smart Sessions Explained: How ERC-7579 Lets Bots Trade Without Your Keys

The Problem Smart Sessions Solve

Automated trading needs a key that can sign transactions without human input. Self-custody needs every key to be controlled by the user. These goals look incompatible — and they were, for years. The compromise users settled for was bad: hand a CEX an API key, hand a bot platform a private key, hand a custodial wallet a seed phrase. Each of these placed the entire balance at risk in exchange for automation.

Smart Sessions fix the asymmetry. They let a smart account contract enforce, at the EVM level, a tightly-bounded permission for a third-party signer. The bot gets a key. The key works. The key cannot do anything outside the policy. The blockchain itself is the enforcer.

The cryptographic guarantee is precise: even if the bot’s server is fully compromised, the attacker can only execute transactions that match the on-chain session policy. Anything else reverts before it touches the user’s funds.

ERC-7579 in One Page

ERC-7579 is a standard for modular smart accounts. Where ERC-4337 defined how smart accounts validate and execute transactions through a bundler, ERC-7579 defines how those accounts compose features as installable modules. Three module types matter:

• Validators — contracts that validate UserOps. They answer the question: “is this signature authorized to act on this account?”
• Executors — contracts that can execute calls from the account. They answer: “run this on my behalf with these constraints.”
• Hooks — contracts that run before or after every execution. They enforce invariants: rate limits, spending caps, blacklists.

A 7579 account can install any number of each type. The Smart Sessions module is a validator: it checks whether an incoming UserOp signed by a session key matches the policies the account owner has installed for that session. Read the spec at eips.ethereum.org/EIPS/eip-7579.

Anatomy of a Smart Session

A session, conceptually, is a tuple stored in the account’s contract storage:

• Session signer (public key). The address whose signatures this session accepts.
• Session validator. The contract that interprets the signer’s signatures (typically OwnableValidator, but extensible).
• Action policies. An array of (target contract, function selector) tuples the session is allowed to call.
• ERC-1271 policies (optional). Constraints on off-chain message signing, if the session needs to sign typed data.
• User-op policies. Constraints on UserOps as a whole (max gas, max calls per UserOp).
• Spending limits. Per-token caps and aggregate caps over time windows.
• Validity period. Start and expiry timestamps.

Together these make a complete, granular permission. A trading-bot session might look like:

Any UserOp signed by the bot is checked against every field. If the bot tries to call any function other than exactInputSingle on any contract other than SwapRouter02, validation fails and the transaction reverts before any state change.

Permission Policies and Validators

The policy system in Smart Sessions is composable. Each policy is a separate contract implementing the IPolicy interface, and a session can stack multiple policies that all must pass.

Common policies in the wild:

• SudoPolicy — no restrictions. Useful for trusted sessions like delegated signers within an organization. Almost never appropriate for external bots.
• UsageLimitPolicy — max number of calls during the session lifetime.
• ValueLimitPolicy — max ETH value across calls.
• ERC20SpendingLimitPolicy — max token amount across calls, per token.
• UniswapPolicy / CallerPolicy — specialized policies for specific protocols.
• TimeFramePolicy — only valid between two timestamps.

The Rhinestone module SDK provides ready-made policy contracts and tools to compose them. See docs.rhinestone.wtf for the canonical reference.

Session Lifecycle: Grant, Use, Revoke

Grant

Granting a session is a single transaction signed by the account owner (your MetaMask). The transaction encodes the full policy and installs it into the Smart Sessions module on your Safe. From this point on, the bot’s signing key is recognized by your account — within the limits you set.

The grant transaction is reviewable in your wallet. Before signing, the wallet shows the encoded calldata; advanced users can decode it to verify the policy parameters match what the dapp claims. Tools like Tenderly can simulate the transaction and decode parameter names.

Use

Each time the bot acts, it builds an ERC-4337 UserOp, signs it with the session key, and submits it to a bundler. The bundler forwards to the EntryPoint contract, which calls your Safe’s validation function. The Smart Sessions module checks the UserOp against the active session’s policies. If everything passes, execution proceeds. If anything fails, the transaction reverts before fees are deducted.

Revoke

Revocation calls removeSession(sessionId) on the Smart Sessions module. This deletes the session’s storage entry. Any subsequent UserOp signed by that session key fails validation immediately. There is no grace period and no off-chain coordination — the bot’s signing key effectively becomes worthless to your account the moment the revocation transaction is mined.

How It Plugs into ERC-4337

ERC-4337 is the account abstraction standard that lets smart contracts initiate transactions through a UserOp object processed by a bundler. ERC-7579 builds on top: a 7579-compatible account is also a 4337 account, with the modular validation logic 7579 specifies.

The flow when the bot acts:

1. Bot constructs a UserOp targeting the user’s Safe (sender = Safe address).
2. Bot signs the UserOp hash with the session signing key.
3. Bot submits the UserOp to a bundler (e.g., Voltaire, Pimlico, Stackup).
4. Bundler simulates and submits to the EntryPoint contract on-chain.
5. EntryPoint calls validateUserOp on the Safe.
6. Safe’s 7579 logic routes validation to the Smart Sessions module.
7. Smart Sessions checks the signature, then iterates policies.
8. If all policies pass, the Safe executes the action.
9. If any policy fails, the entire transaction reverts; the bundler doesn’t lose its bond because validation failure happens before the on-chain submission would charge gas to the user.

From the user’s perspective, none of this is visible — they just see a swap appear on Etherscan, originating from their Safe. From a security perspective, this layered design is what makes the system resilient: every step has a check, and a single broken assumption fails closed (i.e., the transaction reverts) rather than failing open.

A Concrete Walkthrough — Trading Bot Scope

Suppose DCA Bot wants to run a USDC → WETH DCA on Arbitrum for the user. The session needs:

1. Permission to call SwapRouter02 (0xE592427A0AEce92De3Edee1F18E0157C05861564 on Arbitrum), specifically the exactInputSingle function.
2. Pre-approval of USDC to the router (so the swap can pull tokens). This is encoded as an ERC20 approval inside the action policy.
3. Spending cap: max 500 USDC per swap, 5,000 USDC per week (set by user during grant flow).
4. Token whitelist: USDC and WETH (so the bot can’t accidentally swap into a different pair).
5. Expiry: 30 days.

When the user grants this session, MetaMask shows a transaction that:

• Installs the Smart Sessions module if not already installed.
• Encodes the policy bundle and registers the session.
• (Optionally) approves USDC to SwapRouter02 with a bounded allowance.

The user signs once. From then on, every weekly DCA the bot triggers builds a UserOp with the swap parameters, signs with the session key, and submits. The Safe verifies and executes. The on-chain trace shows: Safe (your address) → SwapRouter02 → exactInputSingle → Pool → Safe receives WETH. Funds never leave the Safe.

What Attacks This Defeats (and Doesn’t)

Defeats

• Server compromise of the bot platform. Attacker with the session key can only execute swaps within the policy. Cannot withdraw, transfer, or change ownership.
• Insider abuse at the platform. Same: insider with key access is bounded by the policy.
• Phishing attacks targeting the bot. A malicious dapp can’t pretend to be the bot and drain funds; the session key only signs UserOps the user authorized via the policy.
• Bot operator going rogue. Even if the company actively tries to drain users, they cannot exceed the on-chain policy. Worst case, they execute many small swaps within the cap — disruptive, but not destructive.
• Forgotten sessions. Time-bounded by default; expire automatically.

Does NOT defeat

• User signing a malicious grant transaction. If the user blindly signs a session that grants SudoPolicy to a malicious bot, the policy itself is the attacker. Wallet UX and review hygiene matter here.
• Smart contract bugs in Safe, Smart Sessions module, or specific policy contracts. Audited but not infinitely tested. Use established implementations.
• The user’s own EOA being stolen. The session is a child of the EOA’s authority. If the seed phrase is compromised, the attacker can revoke the session and drain the Safe directly. Hardware wallets exist for this reason.
• Strategy losses. The bot might lose money trading. That is a strategy risk, not a custody one.

Compared to Plain Multi-Sigs and EOAs

Building With Smart Sessions Today

For developers, the canonical stack in 2026:

• Safe + ERC-7579 Adapter — Safe singletons configured to behave as 7579 accounts. The Adapter contract bridges Safe’s execution model to the 7579 module interface.
• Rhinestone Module SDK — TypeScript library to construct, install, and use Smart Sessions and accompanying policies.
• ZeroDev Kernel — alternative 7579 account with native session-key support.
• Biconomy — paymaster and bundler infrastructure with 7579 module support.
• Bundlers: Pimlico, Voltaire, Stackup.

For a working reference implementation, DCA Bot’s codebase demonstrates the full stack: Safe + 7579 Adapter, Smart Sessions for trading scope, Voltaire bundler, and a paymaster-optional execution flow. The footer of the landing page lists the deployed contract addresses, all verified on Etherscan and deterministic across networks.