ERC-7715 is a draft Ethereum standard that defines a wallet RPC method, wallet_grantPermissions, for an application to request scoped session keys from a smart account. A session key is a short-lived signing key authorized to send transactions on behalf of the user, but only within explicit boundaries: a spend cap, an allowlist of contracts, a list of permitted function selectors, and an expiration timestamp. The wallet approves the request once, and the application can then submit transactions through that session key without prompting the user each time.
​

The standard is currently in Draft status on the Ethereum Improvement Proposals repository (EIP-7715). It pairs with ERC-7710 (a contract-side permission interface for delegators) and the related ERC-7679 draft for permission contract modules. Together these three drafts describe a complete onchain permissions stack: how the dapp asks (7715), how the wallet expresses approval onchain (7710), and how the smart account enforces the rules at execution time (7679 modules or equivalent).
​

Live implementations already exist in production wallets and infrastructure, even while the EIP itself is pre-Final. Coinbase Smart Wallet shipped Permissions in 2024 based on the 7715 draft. ZeroDev's Kernel account supports session keys through a permission validator module. Biconomy's Modular Smart Accounts and Safe Modules both expose session-key flows. The drafts are converging on a shared interface, but call shapes still vary across vendors.
​

ERC-7715 specifies a single JSON-RPC method that a dapp sends to the user's wallet: wallet_grantPermissions. The request body lists one or more permissions, each with a type (for example, native-token-transfer or erc20-token-transfer), a set of policies that constrain it (spend cap, allowlist, time window, rate limit), and a signer the dapp wants to authorize. The wallet returns a grantedPermissions object containing the context the dapp will attach to subsequent UserOperations or transactions.
​

The standard does not specify how the permission is enforced onchain. That is intentional. Different smart account architectures handle authorization differently: Safe uses modules, Kernel uses validators, Coinbase Smart Wallet uses a permissions manager contract. ERC-7715 only defines the request and response between dapp and wallet. The wallet is responsible for translating an approved permission into whatever onchain construct the underlying smart account understands.
​

This separation matters for adoption. An application built against ERC-7715 can request permissions from any wallet that implements the method, without knowing which smart account standard sits behind it. A user with a Safe sees Safe modules. A user with a Kernel account gets a Kernel validator. A user with a Coinbase Smart Wallet gets a Coinbase permission. The dapp code is identical.
​

The draft has been through multiple iterations since author Derek Rein's first version in mid-2024. The current draft, last updated in 2025, reflects feedback from MetaMask, Coinbase, Biconomy, and ZeroDev. It is not yet Final, and the request schema may still change before the EIP advances to Review and Last Call.
​

The protocol has three actors: the dapp, the user's wallet, and the smart account contract. The flow runs as follows.
​

First, the dapp sends a wallet_grantPermissions request to the wallet over the standard EIP-1193 provider interface. The request specifies the chain ID, an expiry timestamp, the address of a session signer the dapp controls (often an ephemeral keypair generated client-side), and an array of permission objects. Each permission has a type identifier and a policies array. A typical permission for a gaming dapp might request native-token-transfer capped at 0.05 ETH per day, valid for seven days, restricted to a single game contract address.
​

Second, the wallet shows the user a confirmation screen. The wallet expands the raw policy objects into readable language: "Acme Game wants permission to spend up to 0.05 ETH per day, only on the Acme Game contract, until June 1." The user approves or rejects in a single confirmation. If approved, the wallet provisions the permission onchain. For an ERC-4337 account, this typically means deploying or updating a permission module; for an EOA upgraded under ERC-7702, it means setting an authorization in code. The wallet returns a context blob the dapp will include in future operations.
​

Third, the dapp uses the granted session signer to author transactions or UserOperations on the user's behalf. Each operation carries the permission context. When the smart account executes the call, its onchain enforcement logic checks the operation against the policies: is the value below the cap, is the target on the allowlist, is the call inside the time window, is the rate limit honored. If any policy fails, the call reverts.
​

Revocation runs through a complementary RPC method, wallet_revokePermissions, which the wallet calls against the permission module to disable the session signer. Most implementations also expose a UI revoke path so a user can kill a session without dapp cooperation.
​

The signer the dapp authorizes need not be a single keypair. ERC-7715 supports multiple signer types in its current draft: a single account key, a multisig set, a passkey, or an account-bound signer derived from a smart contract. This flexibility lets a dapp request, for example, that a session is authorized by a 2-of-3 multisig held by the dapp's backend, not a single hot key.
​

The current draft enumerates a small starting set of permission types, with the explicit assumption that the registry will grow as wallets and dapps converge on common patterns.
​

The simplest permission: authorize the session signer to send the chain's native token (ETH on mainnet, MATIC on Polygon PoS, and so on) up to a cap. Policies attach a maximum amount per call, per day, or for the lifetime of the session.
​

Authorize transfers of a specific ERC-20 token, identified by its contract address. A subscription dapp might request permission to transfer 10 USDC per month from the user's smart account to a recipient. The wallet's onchain enforcement reads the ERC-20 transfer call data and validates the amount and recipient.
​

Authorize calls to a specific contract address and an allowlist of function selectors. A gaming dapp might request permission to call play() and claimReward() on its game contract, but nothing else. This is the most flexible permission type and the most error-prone to specify, because the dapp must enumerate every selector the session signer needs.
​

Each permission carries a list of policy constraints. Common policies in the draft:

Policies stack: a permission can carry several policies, all of which must hold for an operation to pass. A dapp request that says "spend up to 1 USDC per call, max 10 calls per day, on contract X, function Y, until July 1" is a legitimate ERC-7715 permission with five stacked policies.
​

Consider an onchain card game that wants players to take 20 to 30 actions per match without signing each one. The flow:
​

The game client generates an ephemeral keypair at session start. It sends a wallet_grantPermissions request to the user's wallet. The request asks for a contract-call permission targeting the game contract at 0xGAME, with the function allowlist [playCard, drawCard, endTurn, claimReward], a gas cap of 5 million gas, a rate limit of 60 calls per hour, and an expiry of 2 hours from now. The signer is the ephemeral public key the client just generated.
​

The wallet renders the request: "Acme Card Game wants to play actions on your behalf for 2 hours, up to 60 actions per hour, only on the Acme contract. No token transfers." The user approves once. The wallet provisions a session module on the user's smart account (or sets an authorization on an EOA running ERC-7702) and returns the granted context to the dapp.
​

For the next 2 hours, the game client signs UserOperations with the ephemeral key and submits them through an ERC-4337 bundler. Each UserOp targets the game contract. The smart account's permission module validates each one against the granted policies before allowing execution. If the user closes the browser tab, the session signer key is discarded; if the dapp is compromised within the 2-hour window, the attacker can only spend gas on game functions, not transfer the user's funds.
​

After 2 hours, the permission expires automatically. If the player wants to keep playing, the dapp requests a new permission. The user can revoke early through the wallet UI at any point.
​

This pattern generalizes to agentic apps, recurring payments, dollar-cost averaging into a stablecoin, automated trading bots, and any flow where a dapp needs to take many small actions without disrupting the user. The threat model shrinks from "the dapp can sign anything" to "the dapp can sign these actions, capped, with expiry."
​

The core security claim of ERC-7715 is that an attacker who fully compromises the dapp during an active session can only spend within the granted policies. The smart account's onchain enforcement logic, not the dapp's runtime, is the source of truth for what the session signer is allowed to do.
​

This claim depends on three things being correct.
​

The first is the wallet's translation from a 7715 policy object into onchain enforcement. If the wallet provisions a module that fails to check the spend cap correctly, the policy is decorative. Wallets implementing 7715 must either reuse audited permission modules (Safe's allowance modules, Kernel's permission validators, Coinbase's permissions manager) or ship their own with equivalent audit coverage.
​

The second is the user's understanding of the request. A wallet that displays "Acme Game wants to call playCard, drawCard, endTurn, claimReward, sweepUserFunds on the Acme contract" still puts the burden on the user to notice that sweepUserFunds does not belong. Wallets implementing 7715 are starting to add human-readable annotations and selector-name verification, but the security boundary at the wallet UI is real.
​

The third is operational hygiene around the session signer. If the dapp persists the ephemeral key to a server and that server is breached, the attacker inherits the session for its remaining lifetime. Best practice is to generate the session key client-side, keep it in memory, and rotate the session on a short timer rather than asking for a 30-day grant.
​

Revocation is the safety valve. ERC-7715 wallets surface a session manager in the wallet UI: a user who suspects compromise revokes the session, the wallet calls the underlying module's revoke function, and the session signer is dead onchain. Revocation latency is bounded by block time, not by the dapp.
​

Several smart account stacks ship session keys today, with varying levels of conformance to the current 7715 draft.
​

Coinbase Smart Wallet launched Permissions in 2024, built on the 7715 draft. The implementation supports wallet_grantPermissions and wallet_getPermissions over the standard provider interface and uses a dedicated permissions manager contract for enforcement. Coinbase has been one of the most vocal authors and reviewers of the draft and tracks revisions closely. See smartwallet.dev/guides/permissions for the current API.
​

ZeroDev's Kernel smart account uses a permission validator architecture. A session key in Kernel is a validator attached to the account with a policy set: spend caps, allowlists, time windows. ZeroDev's SDK exposes a builder interface that constructs Kernel-native session keys and a wrapper that maps 7715-style requests to that interface. See docs.zerodev.app/sdk/permissions.
​

Biconomy's Nexus account standard supports session keys through a modular validation interface. Each session is a validator module installed on the account with its own policy logic. Biconomy's session-key SDK predates the 7715 draft and uses its own request shape, but the team has signaled intent to align with the EIP as it stabilizes. See docs.biconomy.io/account/account-modules.
​

Safe (formerly Gnosis Safe) supports session keys through the modules system. The Safe Allowance Module, audited and live on multiple chains, enforces ERC-20 spend caps per signer. Custom modules can implement more complex policies. Safe does not expose a native wallet_grantPermissions RPC method today; integration with 7715 typically runs through a wallet layer (for example, a Safe-compatible wallet that translates 7715 requests into module deployments). See docs.safe.global/advanced/smart-account-modules.
​

MetaMask's Smart Account, based on Delegation Manager, supports a delegation primitive that is conceptually similar to a session key: an account delegates a scoped capability to a delegate address. MetaMask has been an active reviewer on the 7715 draft and is one of the wallets expected to ship the standard RPC method as the EIP nears Last Call. See docs.metamask.io/delegation-toolkit.
​

ERC-7715 and ERC-4337 paymasters solve different problems, and they compose rather than compete. Distinguishing them matters because dapps often conflate them.
​

An ERC-4337 paymaster sponsors gas. When a dapp wants to remove the "you need ETH to play" barrier, it points UserOperations at a paymaster contract that pays gas in exchange for some offchain or onchain reimbursement. The paymaster does not grant the dapp authority to move the user's funds; it just pays the gas bill. The user still signs each UserOperation. See the related ERC-4337 explainer for the full mechanism.
​

An ERC-7715 session key delegates signing. When a dapp wants the user to stop confirming every action, it requests a session with bounded authority. The user signs once at session start; subsequent actions are signed by the session signer the dapp holds. The session does not pay gas, but it does enable the dapp to author transactions.
​

The two pair naturally. A gaming dapp typically wants both: a paymaster so the user does not need to hold ETH, and a session key so the user does not confirm every move. The session signer authors UserOperations; the paymaster sponsors them. Two separate primitives, both required for a frictionless flow. See the cluster overview of the account abstraction stack for how these pieces fit together with bundlers and factories.
​

Without 7715, a dapp seeking session-key behavior had to roll its own with vendor-specific SDKs (Biconomy session keys, ZeroDev permission validators, custom Safe modules). The dapp's code was tied to one smart account family. With 7715, the dapp issues a single RPC request and the wallet handles the rest. That portability is the main reason the draft has attracted attention from every major smart account team.
​

Because EIP-7715 is Draft, several questions are still being negotiated in the EIP discussion thread and in implementer working groups.
​

The permission type registry is small and informal. The draft enumerates a few common types but does not specify a process for adding new ones. In practice, types are emerging through community convention. A permission type for ERC-721 transfers, for example, is widely implemented but not in the canonical EIP text.
​

Policy composability is under-specified. Stacking multiple policies on one permission works, but the semantics of, for example, two overlapping spend caps (per-call and per-day) are left to implementers. Conformance tests are not yet standardized.
​

The signer schema is evolving. Early drafts supported only a single key signer; the current draft adds multisig and passkey signers; further additions (account-abstracted signers, threshold signers) are being discussed.
​

Revocation semantics differ across implementations. Some wallets revoke instantly by toggling a flag in the permission module; others require a transaction with its own gas cost. ERC-7715 does not yet pin down which behavior is mandatory.
​

None of these gaps blocks production usage today, and several wallets have been running session keys in front of real users for over a year. But applications building against 7715 in 2026 should expect the request schema to tighten as the EIP advances. The smartwallet.dev and ZeroDev docs are good real-time references for what each implementation accepts.
​

Stablecoin payment flows are one of the clearest applications for session keys, because they often involve many small, predictable transfers. A subscription that debits 10 USDC per month, a recurring savings flow that converts ETH to USDC weekly, an agentic checkout that pays a merchant in USDC at the end of a shopping session: each of these benefits from a session permission that authorizes the specific token, the specific recipient, and the specific cap.
​

Eco Routes and Eco Portal handle the cross-chain stablecoin movement that sits underneath these flows. A dapp can request an ERC-7715 permission to spend USDC up to a cap, then use Eco Routes to deliver that USDC to the destination chain without the user signing a separate bridge transaction. The combination of a scoped session key, a paymaster for gas, and an intent-routing layer for cross-chain settlement is the path most production stablecoin apps are converging on. For the broader infrastructure picture, see the best ERC-4337 infrastructure overview.
​

EIP-7715 is in Draft status as of May 2026 and the request schema may change before the standard reaches Final.
​