ERC-7715 is an Ethereum standard that introduces a JSON-RPC method called wallet_grantPermissions, letting a dApp request a scoped, time-bounded delegation from a wallet so that subsequent actions can run without a per-transaction popup. Instead of asking the user to sign every swap, transfer, or game move, the application asks once for permission to spend up to a defined value, against a defined contract, until a defined expiry. Once granted, the dApp executes within that envelope while the wallet enforces the limits. The standard sits at the intersection of account abstraction (ERC-4337) and modular smart accounts (ERC-7579), and it pairs with ERC-7710 on the contract side to describe the granted permissions interface.
​

This article explains how ERC-7715 works in detail, walks through the request flow, contrasts it with ERC-7710 and the SIWE/OAuth analogies people reach for, lists the wallets and stacks shipping support today, and shows a concrete code example for a 24-hour Uniswap session key with a $50 swap cap. It closes with the security model and where ERC-7715 connects to cross-chain stablecoin orchestration on Eco.
​

ERC-7715 is an Ethereum Request for Comments draft titled "Grant Permissions from Wallets," authored by Derek Chiang, Lukas Rosario, Wilson Cusack, Dror Tirosh, and Jake Moxey. The proposal lives at eips.ethereum.org/EIPS/eip-7715 and the canonical reference repo is ethereum/ERCs. The standard adds one JSON-RPC method, wallet_grantPermissions, to the wallet interface. A dApp calls it with a structured permission object. The wallet asks the user to confirm. On approval, the wallet returns a permissionsContext string that downstream code uses to execute calls under the granted scope.
​

The proposal is deliberately minimal. It does not specify how a wallet stores or enforces permissions, only the request and response shapes. That choice matters: a wallet implementing ERC-7715 might enforce permissions through a MetaMask Snap, through a Rhinestone session module on a smart account, through a 7579-compliant validator, or through a custom signer the wallet trusts. The interface is the contract; enforcement is the implementation.
​

ERC-7715 entered draft status in May 2024 and is still draft as of April 2026. It has been referenced in production stacks from Coinbase, MetaMask, Biconomy, and Rhinestone, all building toward the same shape: scoped, expiring, attenuable permissions over EOAs and smart accounts.
​

The request flow has four steps. A dApp calls wallet_grantPermissions with a permission request. The wallet displays a confirmation UI. The user approves, denies, or modifies the scope. If approved, the wallet returns a permissionsContext the dApp uses to authorize subsequent actions.
​

The permission request itself is structured. Each entry in the permissions array names a type, an optional data payload describing what is allowed, and any policies that constrain it. A typical type is native-token-transfer, where data includes a recipient and amount, and policies include an expiry timestamp and a value cap. Other types in the wild include erc20-token-transfer, contract-call (target address plus function selector list), and custom types defined by specific wallets or modules.
​

Three pieces of information together define the scope:

The response includes a permissionsContext hex string the dApp passes to the bundler or executor. With ERC-4337 account abstraction, that context flows through the UserOperation's signature field, where the smart account's validator checks it. Without 4337, the wallet uses a session key the dApp signs with directly, and the smart account validates the session key against the stored permission record.
​

Signer resolution is one of the more interesting design choices. ERC-7715 supports an optional signer object in the request, which says "this permission is for this signer to use." The signer can be the dApp's own keypair (a session key generated locally), a multisig, a contract account, or a chain of attenuation. Attenuation means a permission can be re-issued under tighter scope: a parent grant of "$500 daily on Uniswap" can be attenuated to "$50 on this single swap" before passing to a sub-component. The standard does not invent a delegation framework; it expects the underlying smart account standards (7579, MetaMask's Delegation Framework) to handle it.
​

ERC-7715 and ERC-7710 are two halves of the same picture, and the difference matters when reading specs.
​

ERC-7715 covers the wallet-facing JSON-RPC: how a dApp asks for a permission, what the request shape looks like, what the response contains. It is a request standard. ERC-7710 covers the contract-facing interface: how a smart account exposes its granted permissions, how those permissions can be queried, and how attenuation chains are represented onchain. It is a delegation standard.
​

A clean implementation uses both. The dApp speaks 7715 to the wallet. The wallet, internally, holds 7710-shaped permission objects on the smart account. When the dApp executes under a granted permission, the smart account's validator reads the 7710 record to authorize the call. Wallets that ship 7715 without 7710 typically use a session key model where the wallet stores permission state offchain or in a dedicated module, not on the account itself.
​

For developers building dApps, the practical takeaway is: target 7715 in the request layer; do not assume a specific 7710 layout in the contract layer, because wallets vary.
​

The mental model people reach for is OAuth, and the comparison is useful but partial.
​

OAuth is a token-based authorization protocol where a resource server (Google, GitHub) issues a bearer token with scopes (read:user, repo:write) and an expiry. A client uses the token without re-prompting until it expires. Sign-In with Ethereum (ERC-4361) ports this to wallets for authentication: the user signs a structured message proving wallet ownership, the dApp gets a session for off-chain authentication, and onchain actions still require per-transaction signatures.
​

ERC-7715 fills the gap SIWE leaves open: scoped delegation for onchain actions. Where OAuth says "this app may call my GitHub API up to these limits," ERC-7715 says "this app may move tokens from my smart account up to these limits." The scope language is similar (target, action, expiry, value cap). The enforcement substrate is different: OAuth tokens are checked by the resource server; ERC-7715 permissions are checked by the smart account validator before each transaction settles.
​

The closest Web2 analogy in spirit is not OAuth alone but the credit-card preauth: a merchant can charge up to $X over Y days against your card without re-prompting, and the card network enforces the cap. Onchain, the smart account is the network, the validator is the enforcement, and the permission record is the preauth.
​

Four categories explain why teams are pushing ERC-7715 forward.
​

Session keys for games. Onchain games like Primodium, Treasure DAO titles, and many of the Argus and Caldera-stacked games in production cannot tolerate a wallet popup on every move. ERC-7715 lets a player grant the game contract permission to call a defined set of selectors (move, attack, build) for a session of N hours, with a per-call gas cap. The session key signs the moves locally; the smart account enforces the scope.
​

Auto-pay subscriptions. Recurring stablecoin payments — SaaS, payroll, vendor invoicing — have been an awkward fit onchain because every charge needs a signature. With ERC-7715, a user grants a subscription dApp permission to transfer up to $200 in USDC monthly to a specific address, expiring after twelve months. The dApp settles each cycle without contacting the user, and the user can revoke at any time. Stripe-style ACH preauthorization, but onchain.
​

Agent wallets. An AI agent that trades, hedges, or rebalances on behalf of a user needs scoped, attenuated authority — not the user's full keys. ERC-7715 lets the user grant the agent a permission like "swap up to $500 on Uniswap V3 against USDC, expires in 24 hours." The agent operates inside the box. Routing infrastructure for agent-driven flows is being built on this assumption: agents need delegated authority, not custody.
​

Scoped DEX trading. Power users running automated strategies (limit orders, DCAs, MEV-aware routing) want to authorize a strategy contract once, not on every fill. ERC-7715 with a target of the strategy contract and a value cap matching their trading book size is the cleanest fit. Some teams previously used unbounded ERC-20 approvals to achieve this; that approach is being replaced because unbounded approvals are exactly the attack surface ERC-7715 was designed to remove.
​

Implementation is partial and evolving. As of April 2026:
​

MetaMask ships ERC-7715 support through its Delegation Toolkit, which uses a MetaMask Snap to handle the permission request UI and a Delegation Framework on the smart account side. The Snap surfaces in MetaMask Flask and is rolling toward stable. Documentation at docs.metamask.io/delegation-toolkit covers both 7715 (request) and 7710-style delegation (contract).
​

Coinbase Smart Wallet implements wallet_grantPermissions through its Wallet SDK and exposes it via the Smart Wallet popup. Coinbase's smartwallet.dev reference shows session-key flows for Base apps. The implementation uses SpendPermissions, a 7710-aligned contract module on the Smart Wallet account.
​

Rhinestone provides 7579 modules and SDKs that other wallets and embedded-wallet providers compose into ERC-7715 implementations. Their module-sdk documents session-key validators, scheduled transfers, and permission policies. Rhinestone's modules are deployed on Base, Optimism, Arbitrum, and several other chains.
​

Biconomy ships permission management through its Smart Account v2 and its session key infrastructure, with native support for the 7715 request shape in its dApp SDK.
​

Safe exposes permission flows through its 4337 module and the broader Safe Modules ecosystem, where modules like ZeroDev's Kernel integrate session-key validators that match the 7715 model.
​

Wallet-by-wallet readiness is tracked in the ERC-7715 reference repo and in the erc7715.xyz tracker.
​

The clearest way to understand ERC-7715 is to look at a request payload. The example below grants a dApp permission to execute up to four exactInputSingle calls against the Uniswap V3 SwapRouter on Base, with a per-call value cap of $50 USDC and a session expiry 24 hours out.
​

The request is sent through the wallet provider:
​

const result = await window.ethereum.request({ method: 'wallet_grantPermissions', params: [permissionRequest] });
​

Where permissionRequest is a structured object:

The wallet returns a permissionsContext: an opaque hex string the dApp passes to the bundler. When the dApp later constructs a UserOperation calling SwapRouter.exactInputSingle, it includes the context in the operation's signature field. The bundler forwards the operation; the smart account's validator reads the context, looks up the granted permission, checks that the call target is the SwapRouter, the selector is exactInputSingle, and the USDC value being swapped is under $50; if all checks pass, the operation executes.
​

The Coinbase Smart Wallet quickstart at smartwallet.dev/guides/spend-permissions walks through this end-to-end with working TypeScript, including the Viem 7715 actions that wrap the JSON-RPC call. Viem exposes grantPermissions as a typed action, removing most of the manual JSON construction.
​

What this example hides: the wallet decides exactly how to enforce the cap. Coinbase's SpendPermissions tracks cumulative spend in a contract storage slot and reverts overspend in the validator. MetaMask's Snap holds the cap state in encrypted Snap storage and signs only when the proposed call satisfies it. Both honor the same request shape; both produce the same observable behavior. The standard works because the surface is the same.
​

ERC-7715 does not require ERC-4337, but it is most natural inside it. 4337 introduces a UserOperation pseudo-transaction that flows through bundlers to a smart account contract. The account's validateUserOp function decides whether to accept the operation. ERC-7715 plugs into that function: the operation's signature carries the permissionsContext, the validator parses it, the validator checks the call against the granted permission, and the operation either executes or reverts.
​

ERC-7579 is the modular smart account standard. It defines how a smart account composes validators, executors, and hooks as discrete modules. A 7579 account can install a session-key validator module that handles 7715-granted permissions, a separate validator for primary-key signatures, and a hook that emits events on every permission use. The composition is what makes 7715 enforceable across many wallet implementations: each wallet picks its module mix, but the request shape is the same.
​

The combined stack is: dApp speaks 7715 to the wallet; wallet packages a UserOperation per 4337; smart account validates per 7579 modules; bundler submits to the EntryPoint contract; the operation settles. This is the architecture stablecoin workflow engines use when delegating recurring transfers to a scheduling dApp, and it is the architecture intent settlement layers use when a solver executes user intents under a granted scope.
​

Every delegation primitive is a phishing surface, and ERC-7715 is no exception. The standard documents three structural mitigations and several implementation-level requirements.
​

Revocation. Wallets MUST support permission revocation. The companion method wallet_revokePermissions takes a permission identifier and tears down the granted scope. Some implementations also expose revoke flows in the wallet UI for users who want to clean up old grants without going through the originating dApp. Onchain, revocation translates to either deleting the permission record from the smart account's storage or marking it inactive in the validator module.
​

Expiry. Every permission carries a required expiry timestamp. The EIP language is MUST: wallets reject permission requests without expiry. The intent is to prevent the unbounded-approval problem that plagued early ERC-20 design, where a forgotten grant from years ago becomes the entry point for a drainer years later. ERC-7715 sets a structural ceiling: even an ignored permission stops being dangerous when it expires.
​

Session-key compromise. A session key is a hot key, generated locally by the dApp, often kept in browser storage. It can be stolen. The mitigation is scope: a stolen session key for "$50 on Uniswap, expires in 24 hours" is a $50 loss at most, expiring on its own. This is the design rationale behind tight scopes — every permission should leak as little as the use case tolerates.
​

Phishing. A malicious dApp can ask for an over-broad permission. The wallet's job is to display the request clearly and warn on dangerous patterns: any contract, any selector, large value caps, long expiries. The MetaMask Snap and Coinbase Smart Wallet UIs both highlight these patterns. The user's job is the same as it has always been: read the request before approving.
​

Module bugs. Because enforcement lives in smart-contract modules, a bug in the validator is a vulnerability. The Rhinestone, ZeroDev, MetaMask, and Coinbase modules all carry security audits — links are in their respective docs. Production deployments should pin to audited module versions.
​

The aggregate security posture is better than the alternative. An infinite ERC-20 approval to a DEX is one signature with no ceiling and no expiry. An ERC-7715 grant for the same DEX is one signature with a value ceiling and a hard expiry. The risk surface shrinks even if the user behavior stays roughly the same.
​

Stablecoin payment apps and agentic commerce apps share a problem ERC-7715 helps solve: how to authorize automated, recurring, or cross-chain settlement without re-prompting on every operation. A subscription that charges $20 USDC monthly across whichever chain the merchant prefers, an agent that rebalances stablecoin holdings across Base and Solana on a schedule, a treasury app that settles vendor invoices in the cheapest available stablecoin — each of these benefits from a scoped, expiring delegation that the wallet enforces.
​

Eco runs the cross-chain execution side of that picture. A dApp granted ERC-7715 permission to spend USDC under defined limits can route through Eco Routes when the destination is on a different chain than the user's funds, without composing a separate bridge step or asking the user to sign again. The permission scope describes what is allowed; the routing layer figures out where the liquidity sits and how to settle. For application teams building delegated payment products, the pairing is natural: ERC-7715 governs the user's authorization, Eco handles the cross-chain execution. The result is one onchain primitive for "the agent has permission to pay" and one orchestration layer for "the payment lands on the right chain."
​

ERC-7715 is in draft status as of April 2026. The standard has multiple production implementations (MetaMask Delegation Toolkit, Coinbase Smart Wallet, Rhinestone, Biconomy) but the EIP itself has not moved to Final. The request shape is stable enough that the major stacks ship against it, and breaking changes at this stage would be coordinated.
​

In practice, yes. EOAs (externally owned accounts) sign per-transaction by definition; there is no validator to enforce a granted permission. ERC-7715 implementations target smart accounts, typically via ERC-4337 plus a 7579-style modular account. Coinbase Smart Wallet, MetaMask Smart Account, and Safe are the common substrates.
​

An unlimited ERC-20 approval is a single bit: this contract can move any amount of this token, forever. ERC-7715 is structured: which contract, which selectors, which value cap, which expiry, with revocation and attenuation primitives. The risk surface is bounded by design.
​

The standard is per-chain: a permission request includes a chainId and applies on that chain. Multi-chain delegated apps stack multiple permissions, one per chain, and an orchestration layer like Eco Routes handles the cross-chain settlement under whichever permission applies on the destination chain.
​

The Coinbase Smart Wallet docs at smartwallet.dev/guides/spend-permissions have a working TypeScript example. MetaMask's Delegation Toolkit at docs.metamask.io/delegation-toolkit covers Snap-based flows. Viem's 7715 actions wrap the JSON-RPC call with typed helpers.
​