ERC-7715 is an Ethereum standard that defines how decentralized applications request execution permissions from smart wallets. Instead of requiring a manual signature for every transaction, ERC-7715 lets users grant pre-approved, scoped authority to an app once. The app then executes transactions within those bounds automatically, without interrupting the user for each action.
​

The standard was proposed in May 2024 and introduces a JSON-RPC method called wallet_grantPermissions that any wallet can implement. Permission objects specify exactly what the app is allowed to do: which assets, what spending limits, which contract functions, and for how long. When the permission expires or is revoked, the app loses execution authority immediately.
​

ERC-7715 is formally tracked as EIP-7715 on eips.ethereum.org. The standard is part of the broader smart wallet ecosystem and builds directly on how Ethereum Request for Comments (ERCs) work as a process for standardizing wallet behavior.
​

Current Ethereum wallets require users to sign each transaction individually. For applications that need many small, sequential actions (a DeFi strategy rebalancing every hour, a game processing micro-payments, a recurring payment executing monthly) this becomes impractical. Users abandon flows; agents cannot execute without a human present.
​

Earlier workarounds like ERC-20's approve() function solve part of this problem for token transfers, but they lack time limits, cannot cover native ETH movements, and offer no mechanism to constrain which contract functions an approved address can call. ERC-7715 addresses all three gaps at the protocol level.
​

The wallet_grantPermissions JSON-RPC method lets a dapp request scoped execution authority from a wallet in a single call. The wallet shows the user a human-readable approval screen and returns a signed permission context. That context is the credential the dapp passes to an onchain delegation contract each time it executes a permitted action. The contract validates the context and executes only if the action falls within the granted scope.
​

A permission request includes at minimum: the target chain ID, the account being authorized, the address receiving permission (the session signer), one or more permission objects defining allowed behavior, and an optional expiry timestamp. The wallet may allow the user to tighten the parameters before approving. If the dapp sets isAdjustmentAllowed: false on a permission, the wallet must present it exactly as written or reject the request entirely.
​

On approval, the wallet returns a permissionContext string. Revoking a permission means the wallet invalidates that context onchain, after which any attempt to redeem it reverts.
​

Each permission object carries three fields:

Rules, which are separate from permissions, add constraints that apply across the entire grant. The most common rule is an expiry rule carrying a Unix timestamp after which all permissions in the grant become invalid.
​

ERC-7715 introduces the concept of a session account: a temporary, limited-authority identity the dapp creates solely to request and redeem permissions. The session account holds no user funds. It receives permission to act on the user's main smart wallet account through the delegation manager contract.
​

Session accounts can be externally owned accounts (EOAs) or smart accounts. For high-security use cases, wallets can require multi-sig session signers. For lightweight app integrations, a single-key EOA session account is typical. The separation between the session account and the user's main account is the core of ERC-7715's security model: even if a session key is compromised, the attacker is constrained to whatever the permission allowed.
​

This design has implications for keystore wallets, which store keys separately from the smart wallet contract. ERC-7715 is compatible with keystore architectures because permissions are enforced by the onchain delegation contract, not by the key itself.
​

ERC-7715 defines a naming convention for permission types and provides reference implementations for three common categories: native token transfers, ERC-20 token operations, and contract call restrictions. The specification expects additional types to be standardized in future ERCs rather than fixing a closed list, which keeps the framework extensible as new use cases emerge.
​

A native-token-transfer permission sets a maximum cumulative amount of ETH (or the chain's native gas token) that the session account can transfer out of the user's wallet during the permission's validity window. The delegation manager tracks each execution against this limit and reverts any transaction that would exceed it.
​

MetaMask's implementation extends this with a native-token-periodic type that resets the spending limit on a configurable period, and a native-token-stream type that models a continuous linear allowance accruing over time. Streaming permissions enable use cases like vesting schedules and subscription-style payments where the authorized amount grows incrementally.
​

The erc20-token-allowance permission type specifies a token contract address and a maximum transfer amount. Unlike the existing ERC-20 approve() function, which is open-ended by default, ERC-7715 allowances are time-bounded by the grant's expiry rule and are enforced onchain by the delegation contract rather than relying on the token contract's allowance slot.
​

This matters for ERC-20 tokens used in automated workflows: a traditional unlimited approval sitting onchain is a permanent attack surface. An ERC-7715 allowance disappears when the grant expires or is revoked, eliminating the stale approval problem that has led to wallet drains across DeFi.
​

A companion erc20-revocation type lets dapps request permission to clean up old, unused token approvals in the user's wallet as part of a broader security hygiene flow.
​

The contract call permission type bounds what the session account can call: it can restrict execution to a specific contract address, a specific function selector, or a combination of both with calldata constraints. This is important for DeFi integrations where a dapp should be able to call deposit() on a specific vault but nothing else.
​

The ERC-7715 specification notes that four-byte function selectors alone are insufficient for security, since selectors are not globally unique. Sound implementations bind permissions to a contract address plus selector plus calldata range, rejecting any call that does not match all three constraints.
​

ERC-7715 uses an expiry rule, a standardized constraint type carrying a Unix timestamp, to time-bound any permission grant. After that timestamp, the delegation contract rejects all executions referencing the expired context, even if the permission amounts have not been fully consumed. Apps must call wallet_grantPermissions again to renew, triggering a fresh user approval each time.
​

Revocation is separate from expiry. A user can revoke an active permission at any time by calling wallet_revokePermissions with the permission context identifier. The delegation contract records the revocation onchain; subsequent redemption attempts fail immediately. Wallets that implement ERC-7715 must provide a UI for users to see and revoke active grants, similar to how ERC-20 token allowances can be reviewed and canceled today.
​

The combination of expiry and revocation gives users two safety mechanisms. Expiry handles the normal case: the user knew the authorization was temporary and it ends automatically. Revocation handles the unexpected case: the user wants to cancel before the term ends, perhaps because they stopped using the app or suspect a session key was exposed.
​

Apps can request permission renewal proactively before expiry. The user sees a fresh approval prompt and can review whether the requested scope still matches what they expect the app to do. This is structurally different from an unlimited approve() that never asks for renewal.
​

These mechanics are relevant to social recovery wallets, where multiple guardians may need to co-approve sensitive operations. ERC-7715 is compatible with multi-sig session signers that require guardian quorum before a permission grant takes effect.
​

Agentic transactions are blockchain operations initiated by software acting on a user's behalf, with no human present at the moment of execution. ERC-7715 gives AI agents and automated systems a safe, scoped onchain credential to hold. Before this standard, agentic systems had to either hold private keys (exposing the full wallet) or use custodial intermediaries that reintroduced centralized trust.
​

With ERC-7715, a user can authorize an agent with a specific, bounded permission: "spend up to 50 USDC per day buying ETH, for the next 30 days." The agent holds a session account and a permission context. It calls the delegation manager to execute trades within that scope. If the 50 USDC daily limit is hit, further transactions revert until the next period. When 30 days pass, the permission expires. At no point does the agent hold the user's private key or have unrestricted wallet access.
​

This model extends naturally to several categories of automated use cases:

The agentic commerce opportunity also connects to stablecoin automation platforms that coordinate recurring stablecoin payments across protocols. ERC-7715 provides the wallet-layer credential those platforms need to execute without holding custody of user funds.
​

Cross-chain agentic use cases are also in scope. When an agent needs to move assets across networks as part of an automated strategy, it can hold permissions across multiple chains within a single grant. For context on how cross-chain execution fits into the broader architecture, see the leading cross-chain intent protocols that already coordinate multi-chain execution.
​

Three models exist for delegating transaction authority to an app or automated system. Each differs significantly in how much it constrains the authorized party and whether that constraint is standardized across wallets. The table below compares them across the dimensions that matter most for security and usability.
​

The key difference between session keys and ERC-7715 is standardization. Session keys as a concept have existed in account abstraction for several years, and wallets like Argent and ZeroDev implemented proprietary versions. ERC-7715 replaces those bespoke interfaces with a single JSON-RPC method and permission object schema that any wallet or dapp can use without custom integration work.
​

ERC-7715 is at the experimental-to-production stage across several major wallet and infrastructure teams. MetaMask, Coinbase Smart Wallet, Pimlico, and Safe have each shipped or announced support, covering extension wallets, passkey-native consumer wallets, bundler infrastructure, and multisig treasury accounts.
​

MetaMask ships ERC-7715 as Advanced Permissions inside the MetaMask Smart Accounts Kit (also known as the Delegation Toolkit). MetaMask's implementation supports native-token-periodic, native-token-stream, erc20-token-allowance, erc20-token-periodic, erc20-token-stream, and erc20-revocation permission types. The wallet extension renders a human-readable approval card showing asset, amount, duration, and constraints. The MetaMask Gator 7715 Permissions Snap received an independent security review from Consensys Diligence in August 2025. Documentation is at MetaMask's advanced permissions docs.
​

Coinbase Smart Wallet is a passkey-native ERC-4337 account implementation that has added support for the ERC-7715 wallet_grantPermissions method. It targets consumer apps where users authenticate via biometric rather than a browser extension. Because Coinbase Smart Wallet is backed by Coinbase's paymaster infrastructure, it supports gasless permission redemptions where the app sponsors execution fees within the permitted scope. The Coinbase Smart Wallet contracts are open source on GitHub.
​

Pimlico ships the permissionless.js SDK alongside a bundler and paymaster stack that is agnostic to account type. Permissionless.js integrates with Viem and Wagmi and provides helpers for constructing ERC-7715-compatible permission requests against any ERC-4337 smart account. Pimlico's infrastructure handles the UserOperation submission and paymaster signing that makes permission redemption economically viable for apps that sponsor user gas.
​

Safe has added ERC-7715 compatibility through its modular plugin system. Safe's multisig-first architecture means permissions can require guardian quorum before taking effect, which is relevant for treasury and DAO tooling where a single session key approver is insufficient. Safe's account abstraction team collaborates actively on the ERC-7715 and ERC-7710 specification development.
​

ERC-7715 and ERC-7710 are complementary standards that solve different parts of the permissions problem. ERC-7715 is the request layer, covering how a dapp asks a wallet for permission and how the wallet communicates its answer. ERC-7710 is the execution layer, defining the onchain delegation manager contract interface that enforces permissions when a session account tries to act. Both standards are needed for a complete permissions system.
​

ERC-7715 governs the user's approval experience and the format of the permission credential. The standard specifies the JSON-RPC methods, the permission object schema, and the data the wallet returns. ERC-7710 governs how permissions are redeemed and enforced onchain: the delegation manager validates that the action falls within the granted scope, checks that the permission has not expired or been revoked, and then calls the user's account to execute.
​

A dapp using ERC-7715 to request permissions will receive a permissionContext and a delegationManager address in the response. When the dapp wants to execute, it constructs an Execution struct specifying the target contract, the ETH value, and the calldata, encodes it, and passes it to the delegation manager's redeemDelegations() function along with the permission context. The delegation manager applies its caveat enforcers, and if everything validates, the user's smart wallet executes the call.
​

Beyond ERC-7710, ERC-7715 also references ERC-4337 for account deployment. If the user's smart wallet has not yet been deployed onchain, the permission response includes factory and factoryData fields in the standard ERC-4337 format. The dapp deploys the account before redeeming the permission. This ensures ERC-7715 works for users whose smart wallet accounts are counterfactual until their first transaction.
​

The broader smart wallet standards stack also includes ERC-1271 (signature validation) and ERC-4337 (account abstraction execution). ERC-7715 sits at the UX and API layer of this stack, providing the standardized request format that ties the other components together into a coherent permission system a dapp developer can implement once and expect to work across compliant wallets. Details on the ERC-7710 delegation manager interface are in the corresponding EIP.
​

ERC-20 approve() lets a spender transfer tokens from a user's wallet up to a set allowance, but it applies only to ERC-20 tokens, carries no expiry, and cannot restrict which functions the spender calls. ERC-7715 covers native token transfers and contract call restrictions in addition to ERC-20 allowances, adds mandatory expiry rules, and provides a standard revocation interface. Stale ERC-20 approvals are a known DeFi attack vector; ERC-7715 permissions expire automatically and must be renewed.
​

Yes. ERC (Ethereum Request for Comment) and EIP (Ethereum Improvement Proposal) refer to the same document at different stages and in different contexts. EIP-7715 is the proposal as filed in the Ethereum improvement process at eips.ethereum.org. ERC-7715 is the same standard referred to by its application layer designation. Both terms point to the same specification and the same wallet_grantPermissions JSON-RPC interface.
​

ERC-7715 permission responses include ERC-4337 factory data and reference a delegation manager contract. This makes them compatible with ERC-4337 paymasters, which are contracts that pay gas on behalf of users. A dapp can sponsor the gas cost of permission redemptions by including a paymaster and paymasterData field in the UserOperation it submits. The permission itself does not mandate sponsorship, but the architecture supports it natively when the smart wallet and bundler infrastructure allow it.
​

The delegation manager contract applies onchain caveat enforcers before any execution. If the session account attempts an action outside the granted scope, such as transferring more than the permitted token amount or calling a function not covered by the permission, the transaction reverts. The revert happens at the contract level, so no partial execution occurs. This enforcement is trustless: it does not depend on the app behaving honestly.
​

ERC-7715 is designed for smart wallet accounts because permission enforcement requires an onchain delegation contract and a smart account that can validate and execute through it. Standard externally owned accounts (EOAs) cannot natively support ERC-7715 because they lack the programmable execution layer needed to check permission contexts at the contract level. However, the session signer (the entity holding the permission credential) can be an EOA. The user's main account must be a smart wallet to function as the delegator in the ERC-7710 delegation framework.
​

Related reading

Sources: EIP-7715 specification | MetaMask Advanced Permissions documentation | EIP-7710 specification | Ethereum Magicians ERC-7715 discussion. Last updated April 2026.
​