ERC-7715 overview · Wallet Permissions and AI Agent auto-payment
Wiki route
This entry sits under AI Agent payment protocols overview · a 7-protocol survey. Read it against payments index for peer / contrast context and systems index for the broader system / regulatory boundary.
Key facts
- A 2024 proposal · implemented in 2025 major wallets
- Core RPC:
wallet_grantPermissions - Permission types are extensible: native-token-recurring-allowance / erc20-token-transfer / contract-call / nft-transfer
- The signer can be an EOA / passkey / AI agent service key
- Analogy to OAuth 2.0 : not “handing the app your password” but “handing the app a scope-limited access token”
Mechanism / How it works
Core RPC: wallet_grantPermissions
{
"chainId": "0x2105",
"expiry": 1735689600,
"signer": { "type": "key", "data": { "id": "0xagent..." } },
"permissions": [
{
"type": "native-token-recurring-allowance",
"data": { "amount": "0x...", "period": 86400 }
},
{
"type": "erc20-token-transfer",
"data": { "token": "0xUSDC...", "limit": "10000000", "to": "0xmerchant..." }
}
]
}
Permission types (extensible):
native-token-recurring-allowance— periodic ETH/SOL limiterc20-token-transfer— restricted token + limit + recipientcontract-call— restricted contract + selectornft-transfer— restricted collection + tokenId range- Any dapp can define a custom permission type
**Coordination with 4337 / 7702 **:
- ERC-4337(SCW): the permission is stored as a module configuration inside the SCW · validated by ERC-4337 UserOp/Bundler/EntryPoint Flow Explained at UserOp execution
- ERC-7702(EOA): the permission is validated by the contract logic that the EOA temporarily bound · EOA users can also use it (for the difference, see ERC-7702 vs ERC-4337 · Ethereum AA dual-track comparison)
- EOA without AA: not usable · this is the primary force by which 7715 pushes “the necessity of AA” into the mainstream
Signer flexibility: the signer can be another EOA, a passkey, or an AI agent’s service key — any entity capable of signing can be chosen. This means an AI agent having a “scope-limited child account” is supported at the protocol level.
Origin & evolution
The origin of the 7715 draft lies in coordination discussions between the MetaMask Snaps team and the Coinbase Smart Wallet team in 2024 年 — both had independently implemented session keys, but the formats could not interoperate. Referencing the OAuth 2.0 scope model · it was defined as a unified permission-request protocol.
It was implemented successively on MetaMask, Coinbase Smart Wallet, and Safe in 2025 年. Around the same time it combined with ERC-4337 / 7702 to form the complete “AA + Permissions” stack, and alongside AP2 / x402 it is regarded as important infrastructure for the AI agent economy.
Related
- Wiki Index
- ERC-7715 + agent payment stack
- ERC-4337 Overview · Application-Layer Implementation of Account Abstraction
- ERC-7702 Overview · The Pectra Upgrade Where EOAs Temporarily Gain SCW Functionality
- AP2(agent payment)
Sources
- ERC-7715「Request Permissions from Wallets」(draft) — https://eips.ethereum.org/EIPS/eip-7715