Session Policy

A session policy defines a precise authorization scope, limiting a third-party service's actions to specific functions, token amounts, and timeframes. This is a fundamental shift from all-or-nothing key custody.

• Function Limits: Can restrict actions to only transfer, swap, or stake on pre-approved contracts.
• Asset Caps: Sets maximum spendable amounts per token (e.g., max 100 USDC).
• Contract Allowlists: Operations are confined to a predefined list of whitelisted smart contract addresses.

Every session policy has a validity window, defined by a start time and an expiration block or timestamp. This creates a non-custodial, temporary delegation.

• Fixed Duration: A session can be valid for a specific period (e.g., 24 hours) or until a certain block height.
• Revocable: The user or a designated guardian can revoke the session at any time, invalidating it immediately.
• One-Time Use: Policies can be configured as single-use, expiring automatically after the authorized action is executed.

Policies are not static allowlists; they can encode complex business logic using if-then rules that must evaluate to true for a user operation to be valid.

• Transaction Limits: "Spend up to 1 ETH, but only if the DAI/USDC exchange rate is above 0.99."
• Frequency Caps: "Allow up to 5 transactions per day from this session."
• Co-Signing Requirements: "This session can only submit transactions that are also signed by a designated guardian address."

Session policies enable gasless transactions for users by allowing a paymaster to sponsor gas fees. The policy can specify which paymaster is authorized and under what conditions.

• Sponsored Sessions: A dApp can pre-approve a session where it pays the gas for user actions within the policy's scope.
• Gas Token Rules: The policy can dictate which ERC-20 token (e.g., USDC) can be used to pay for gas, abstracting away the need for native ETH.

Session policies are a modular component of the ERC-4337 account abstraction stack. They interact with other core smart account features to create a secure system.

• Validation Function: The policy's logic is executed in the account's validateUserOp function.
• Plugin Architecture: Policies can be installed, updated, or removed as modular plugins without changing the core account logic.
• Social Recovery Integration: Policy revocation can be tied to a smart account's social recovery mechanism.

Session policies unlock specific user experiences that are risky or impossible with traditional Externally Owned Accounts (EOAs).

• Automated Trading: Grant a bot a 1-hour session to execute DCA (Dollar-Cost Averaging) orders up to $500.
• Gaming Sessions: Allow a game contract to mint items and manage in-game assets for the duration of a play session.
• Subscription Services: Enable a streaming service to charge a recurring 10 USDC fee each month without requiring a new signature.

A session policy allows a user to grant a dApp or third party temporary, limited authority to act on their behalf without surrendering their private keys. This is crucial for enabling seamless user experiences in gaming, DeFi, and social applications where multiple on-chain actions are required in a short timeframe.

• Key Benefit: Eliminates the need for a wallet confirmation pop-up for every single transaction within an approved session.
• Analogy: Like giving a valet a specific car key that only works for 1 hour and cannot open the glove box.

Policies define the scope of delegated authority through specific, enforceable constraints. Common parameters include:

• Allowed Contracts: A whitelist of smart contract addresses the session can interact with.
• Allowed Functions: Specific function selectors (e.g., swap, deposit) that can be called.
• Spending Limits: Maximum token amounts or ETH value that can be transferred.
• Time Window: An expiration timestamp for the session (e.g., valid for 24 hours).
• Nonce: A unique identifier to prevent replay attacks.

ERC-7579 is a proposed standard for modular session keys in smart accounts. It provides a formal specification for how session policies should be structured, validated, and revoked, promoting interoperability across different wallet implementations. Key components include:

• Policy Data Structure: A standardized format for encoding the constraints.
• Policy Validator Module: A smart contract that checks if a given transaction complies with an active policy.
• Revocation Mechanisms: Methods for users to invalidate a session before its expiration.

The security of session policies hinges on their constrained nature and user-centric controls.

• Principle of Least Privilege: Policies grant the minimum permissions necessary for a specific task.
• Explicit User Signing: The user must cryptographically sign the policy terms to activate it.
• Transparent Revocation: Users can view and revoke active sessions at any time via their wallet interface.
• Isolation: A breach of a dApp's frontend does not compromise the user's main account or assets outside the policy's scope.

In blockchain gaming, session policies enable fluid gameplay by allowing a game client to perform predefined on-chain actions without constant interruptions. For example, a player could approve a session that allows a game contract to:

• Mint a new in-game item after achieving a quest.
• Equip items from the player's inventory.
• Spend up to 100 units of in-game currency for potions.

This session would automatically expire after 4 hours, limiting exposure.

Session policies are often used in conjunction with batched transactions (or multicalls). While a batch allows multiple calls to be bundled into one on-chain transaction, a session policy defines the rules for what can be included in those batches over a period of time. This combination is powerful for complex DeFi strategies where a user might want a dApp to execute a sequence of swaps, deposits, and stakes across several contracts within a single, user-pre-approved security context.

In blockchain gaming and NFT marketplaces, session policies allow players to engage without constant wallet pop-ups or surrendering custody. A policy can be configured to:

• Grant item usage rights for a single gaming session.
• Delegate specific NFT actions, like listing or staking, to a marketplace contract for a limited time.
• Set transaction caps to prevent unexpected high-fee operations. This creates a seamless user experience while maintaining security, as the policy auto-revokes after the game session or listing period ends.

Session policies are foundational for gas abstraction and batched operations. A user can sign a single policy that allows a relayer or bundler to execute a sequence of actions on their behalf, paying gas fees in the network's native token or an ERC-20. This enables:

• Sponsored transactions where dApps cover user gas costs.
• Atomic multi-step operations (e.g., approve, swap, and stake) as a single user experience.
• Session-based gas management, where a prepaid gas budget is depleted over multiple interactions without re-signing.

For institutions with compliance and operational security requirements, session policies provide granular, audit-trail-friendly controls. A treasury manager can delegate trading authority with strict parameters:

• Multi-signature integration, requiring policy approval from several keys.
• Amount limits per counterparty or dApp to manage counterparty risk.
• Time-of-day restrictions aligning with market hours.
• Automated revocation after trade settlement for clean permission states. This brings necessary operational security and compliance guardrails to on-chain finance.

In multi-chain environments, session policies manage the complexity of bridging and interacting across networks. A user can create a policy that:

• Authorizes a bridge contract to move a specific asset amount from Ethereum to an L2 like Arbitrum.
• Grants permissions on the destination chain for subsequent actions (e.g., providing liquidity), all defined in the initial session setup.
• Uses generalized message passing to enforce the policy's rules across different virtual machines. This simplifies the user journey in a fragmented ecosystem.

The primary security benefit of a session policy is principle of least privilege. Instead of granting unlimited spending authority, a user delegates a specific, bounded set of permissions. This can include:

• Allow-lists: Only specific token contracts or NFT collections.
• Spending Caps: Maximum amount per transaction or per session.
• Time Locks: The policy is only valid for a defined block height or timestamp range. This containment drastically reduces the attack surface if the delegated key is compromised.

A session key, authorized by the policy, must be kept secure, but its compromise is less catastrophic. Critical practices include:

• Ephemeral Keys: Generate a new key pair for each session and discard the private key after use.
• Explicit Revocation: The policy owner (the user) must be able to revoke the session key's permissions at any time, typically by calling a function on the policy manager contract.
• Monitoring: Integrate alerts for when a session key is used, to detect unauthorized activity early. Never store the session private key in a persistent, insecure manner.

Smart contract vulnerabilities within the policy logic are the greatest risk. Auditors should check for:

• Reentrancy: Can a malicious contract called by the session key re-enter the policy to bypass limits?
• Logic Flaws: Incorrect validation of parameters (e.g., off-by-one errors in time locks) or improper access control that allows non-owners to modify policies.
• Signature Malleability: Ensure the EIP-712 typed data signing standard is used correctly to prevent replay attacks across chains or contracts.
• Upgrade Risks: If the policy contract is upgradeable, a malicious upgrade could change all active permissions.

For developers building or integrating session policies:

• Use Audited Standards: Leverage well-audited implementations like those from OpenZeppelin or established dApp frameworks rather than writing custom logic from scratch.
• Comprehensive Testing: Simulate edge cases: policy expiration mid-transaction, revocation during a batch of operations, and maximum limit testing.
• Clear User Interfaces: Wallets and dApps must display the policy's permissions in a human-readable format before a user signs, preventing signature phishing.
• Fallback Mechanisms: Design systems where expired or revoked policies cause transactions to fail safely, not get stuck.

Session policies shift security considerations to the application layer. Key architectural points:

• Policy Granularity: Balance between usability (fewer prompts) and security (tighter constraints). A policy for a trading dApp might differ from one for a game.
• Gas Considerations: Complex policy validation increases gas overhead. Optimize checks to remain cost-effective.
• Cross-Contract Security: Ensure the policy correctly interfaces with other contracts (e.g., ERC-20, ERC-721, marketplaces). A policy allowing NFT sales should also validate the receiving marketplace contract.

Traditional mechanisms for granting limited permissions, which Session Policies generalize and make more secure.

• ERC-20 Approve/Allowance: Grants a spender the right to move a specific token up to a set amount. It is perpetual until revoked.
• Delegation (e.g., Compound, Uniswap): Grants voting rights or other powers.

Key Difference: A Session Policy is more expressive, combining multiple token allowances, function calls, and time limits into a single, revocable, and auditable package.

A core capability enabled by Session Policies. Instead of signing each transaction individually, a user can pre-authorize a session where a dApp can bundle multiple actions into a single, efficient flow.

Example Use Case:

• A gaming dApp can, in one session, claim rewards, swap tokens, and stake the proceeds without requiring a signature for each step.
• This reduces friction while maintaining strict policy constraints on which contracts can be called and the maximum values involved.

The technical process of checking a Session Policy. When a transaction is submitted under a session, the user's smart contract wallet executes validation logic:

1. Signature Verification: Confirms the session was signed by the user.
2. Time Window Check: Ensures the current block timestamp is within the session's validAfter and validUntil.
3. Policy Rules Check: Validates the transaction against the session's allowed contracts (targets), function selectors (selectors), and value/spend limits.

Only if all checks pass is the transaction executed.

Methods to terminate a Session Policy before its expiration, which is critical for security.

• Explicit Revocation: The user sends a transaction to their wallet to invalidate the session's root hash or nonce, immediately revoking all permissions.
• Implicit Expiration: The policy becomes inert after its validUntil timestamp.
• Security Model: This is safer than ERC-20 allowances because revocation is immediate and applies to the entire policy, not just a single token balance. It confines risk to the pre-defined rules of the session.