Are session keys the same as delegations?

No—they describe different layers of the same pattern. Session keys are the broader concept of temporary or scoped authority. Delegation frameworks such as ERC-7710 and MetaMask Advanced Permissions are one way to request, grant, and redeem that authority with enforceable onchain or wallet-level boundaries.

What is the difference between session keys and gas abstraction?

Session keys address authorization—who may act and within what limits. Gas abstraction addresses execution—how transactions get submitted without the user holding native gas tokens or returning to the wallet for every action. Relayers and paymasters handle the transaction path without expanding the session's authority.

How do ERC-4337 session keys relate to ERC-7710 delegations?

Both implement scoped authority: a sub-key or module that can act within limits. ERC-4337 session keys are native to smart accounts; ERC-7715 and ERC-7710 standardize how wallets request permissions and how relayers redeem them onchain, including for EOAs upgraded via EIP-7702.

Can ERC-7710 delegations support multi-agent systems?

Yes. Through redelegation chains, a coordinator agent that received user permission can pass narrower authority to sub-agents. Each hop can only reduce scope, so the user grants once and task-specific agents operate within attenuated budgets enforced onchain.

What should enterprises evaluate before granting session authority?

Ask whether authority can be limited by asset, destination, amount, frequency, chain, and time; whether the user can inspect, revoke, or allow the session to expire; whether the user retains custody; whether gas can be sponsored without broadening the permission; and whether each action can be proven to have stayed within policy.

How does 1Shot support constrained session delegation?

1Shot Wallet lets users approve periodic transfer permissions via EIP-7715-compatible RPC. If the account is already a smart account on that chain, the signed delegation is returned to the host application; otherwise the wallet upgrades the EOA via EIP-7702 through the public relayer. Later, the host sends the ERC-7710 delegation payload to the relayer to redeem the bundle without prompting the user again.

Technical

Embedded Wallets: What Are Session Keys?

Session keys let embedded wallets act without repeated user approval—but their value is bounded, revocable authority, not fewer prompts alone. Learn how delegations, ERC-7710, and ERC-7715 scope that authority.

By The 1Shot API TeamAugust 25, 2026

Session keys and delegation boundaries for embedded wallets

Session keys let embedded wallets act without asking the user to approve every transaction. Their value, however, is not merely fewer prompts.

Our embedded-wallet overview explains the category; this article focuses on how scoped automation works once a wallet is embedded.

A well-designed session key gives an application less authority than the user's primary wallet and makes that boundary enforceable.

Session keys and delegations are therefore not competing approaches. Session keys describe the broader pattern of temporary or scoped authority, while delegation frameworks are one way to request, grant, and redeem that authority.

What is a session key?

A session key is a temporary key or account that can act for a user's wallet within defined limits. It lets an application approve later transactions without exposing the wallet's primary key or interrupting the user for every action.

Session keys are a design pattern rather than one settled Ethereum standard, so implementations vary. A useful session should define both how long the authority lasts and what the delegated key can do.

How delegations scope session-key authority

Delegation frameworks can express those limits as enforceable permissions. In MetaMask's Advanced Permissions model, for example, a user grants a session account authority that can be redeemed through a Delegation Manager. Useful boundaries include:

approved assets;
approved counterparties and contract targets;
per-transaction and aggregate spending limits;
permitted frequency;
expiration and revocation;
permitted calls, chains, or outcomes.

These controls turn a session from a temporary credential into bounded authority. An application, service, or AI agent can act inside the policy without taking custody or receiving the user's root authority.

ERC-7710 also supports redelegation. A delegate that already received permission can create a child delegation for another account, forming delegation chains where each link may only maintain or reduce scope. Caveats stack: a child delegation inherits every restriction from its parent and may add tighter ones.

ERC-7710 redelegation chain

One parent delegation, multiple narrower child permissions

Delegator

User

Approves once

Parent delegate

Orchestrator agent

$2,000/mo USDC

Child delegate
Research sub-agent
$200/wk
Child delegate
Vendor payments sub-agent
$500/wk
Child delegate
Scheduling sub-agent
$100/wk

The orchestrator derives each child redelegation from the user-approved parent. Every child inherits the parent's caveats and may add tighter restrictions.

That pattern is especially useful for sub-agent architectures. A user might approve one orchestrator agent with a bounded monthly USDC budget, and the orchestrator redelegates narrower slices to specialized sub-agents for research, vendor payments, or scheduling. The user signs once; each sub-agent operates within an attenuated budget without separate wallet prompts.

Smart accounts under ERC-4337 have used session keys for years; delegation frameworks extend that idea to permission objects wallets and relayers can inspect, revoke, and enforce onchain, including for EOAs upgraded via EIP-7702.

How a session flows from approval to enforcement

Session flow

From one informed approval to enforced onchain action

User approves
Wallet prompts for execution permission (ERC-7715)
Delegation created
Signed permission with caveats stored
App or agent acts
Submits work within granted bounds
Relayer executes
Gas abstraction without broadening authority
Policy enforced
Onchain redemption checks delegation + caveats

Authorization (session key / delegation) and execution (relayer) remain separate layers—the relayer submits transactions without expanding the granted permission.

Why embedded wallets and AI agents need both permission and execution layers

Session keys address authorization, while gas abstraction addresses execution. Removing repeated approval prompts does not help if every automated action still depends on the user holding a native gas token or returning to the wallet. Relayers, paymasters, and similar infrastructure can handle that transaction path without expanding the session's authority.

For agentic finance, the permission must also describe the intended result. An agent authorized to “sign for the next hour” has a clock, not a financial policy. An agent authorized to pay one vendor up to $500 per week in USDC for 30 days has an instruction the user can understand, the infrastructure can enforce, and the enterprise can review.

In short: 7715 is the ask, 7710 is the enforce, 7702 is the account shape. Draft ERC-7715 defines wallet methods for requesting, inspecting, and revoking execution permissions. Draft ERC-7710 defines an onchain interface for redeeming them, and EIP-7702 can give an existing Externally Owned Account (EOA) smart-account capabilities without changing its address. EIP-7702 standardized account shape, but portable session permissions across apps remain fragmented—teams should verify which wallet interfaces and redemption paths their stack actually supports.

What enterprises should evaluate

1Shot supports constrained account delegation using draft ERC-7710 and ERC-7715 with EIP-7702-compatible account capabilities. Before giving software recurring authority over an embedded wallet, enterprises should ask:

A failure mode teams miss

An application requests a session authorized only by time (“sign for the next hour”) with no limits on assets, destinations, or spend. Until expiry, the agent can send value anywhere. The permission records when authority ends, but nothing about what the agent may do with it. That is exactly the kind of over-broad grant enterprises should reject.

Can authority be limited by asset, destination, amount, frequency, chain, and time?
Can the user inspect, revoke, or allow the session to expire?
Does the user retain custody of the wallet and funds?
Can the application sponsor or abstract gas without broadening the permission?
Can the application prove that each action stayed within policy and recover cleanly when a permission becomes invalid?

The best session-key architecture does more than hide wallet prompts. It turns one informed approval into limited, revocable, and verifiable authority that remains tied to the user's intended outcome.

What 1Shot does in practice

In 1Shot Wallet, a user can approve a periodic transfer permission through EIP-7715-compatible wallet RPC methods. If the account is already upgraded to a smart account on that chain, the signed delegation is returned to the host application. If it is not, the wallet upgrades the user's Externally Owned Account (EOA) automatically by submitting an EIP-7702 authorization to the chain through the public relayer.

When the application or agent later executes a transaction on the user's behalf, the host sends the ERC-7710 delegation payload to the public relayer. The relayer redeems the bundle onchain without asking the user for another approval. See the 1Shot Wallet quickstart to embed the wallet and the permission context guide for how signed delegations are formatted for redemption.

Onchain contracts enforce the delegation signatures and caveats during redemption. Gas sponsorship covers submission, but the granted permission still defines what may be executed.

Learn more about 1Shot Wallet

1Shot Wallet is a permissionless embedded wallet with programmable permissions for assets, counterparties, amounts, frequency, and duration.

Explore the 1Shot Wallet

Frequently asked questions

What is a session key in an embedded wallet?: A session key is a temporary key or account that can act for a user's wallet within defined limits. It lets an application approve later transactions without exposing the wallet's primary key or interrupting the user for every action. A useful session defines both how long the authority lasts and what the delegated key can do.
Are session keys the same as delegations?: No—they describe different layers of the same pattern. Session keys are the broader concept of temporary or scoped authority. Delegation frameworks such as ERC-7710 and MetaMask Advanced Permissions are one way to request, grant, and redeem that authority with enforceable onchain or wallet-level boundaries.
What is the difference between session keys and gas abstraction?: Session keys address authorization—who may act and within what limits. Gas abstraction addresses execution—how transactions get submitted without the user holding native gas tokens or returning to the wallet for every action. Relayers and paymasters handle the transaction path without expanding the session's authority.
How do ERC-4337 session keys relate to ERC-7710 delegations?: Both implement scoped authority: a sub-key or module that can act within limits. ERC-4337 session keys are native to smart accounts; ERC-7715 and ERC-7710 standardize how wallets request permissions and how relayers redeem them onchain, including for EOAs upgraded via EIP-7702.
Can ERC-7710 delegations support multi-agent systems?: Yes. Through redelegation chains, a coordinator agent that received user permission can pass narrower authority to sub-agents. Each hop can only reduce scope, so the user grants once and task-specific agents operate within attenuated budgets enforced onchain.
What should enterprises evaluate before granting session authority?: Ask whether authority can be limited by asset, destination, amount, frequency, chain, and time; whether the user can inspect, revoke, or allow the session to expire; whether the user retains custody; whether gas can be sponsored without broadening the permission; and whether each action can be proven to have stayed within policy.
How does 1Shot support constrained session delegation?: 1Shot Wallet lets users approve periodic transfer permissions via EIP-7715-compatible RPC. If the account is already a smart account on that chain, the signed delegation is returned to the host application; otherwise the wallet upgrades the EOA via EIP-7702 through the public relayer. Later, the host sends the ERC-7710 delegation payload to the relayer to redeem the bundle without prompting the user again.