Summary: ERC-7715 is best understood as wallet-mediated permission-request infrastructure for delegated execution rather than as a wallet UX tweak or a generic session-key library. Its core move is to standardize how a dapp asks a wallet to grant scoped permissions to a separate session account, which can later redeem those permissions through ERC-7710 instead of asking the user to sign every transaction in real time. The important categorization clue is that ERC-7715 shifts the authority negotiation boundary into the wallet: wallets disclose what permission types they support, may attenuate requested authority before approval, and become the main policy chokepoint between users and long-lived delegated automation.
What it does:
Defines wallet_requestExecutionPermissions so a dapp can request scoped permissions and optional rules from a wallet for a designated to session account
Defines wallet_revokeExecutionPermission, wallet_getSupportedExecutionPermissions, and wallet_getGrantedExecutionPermissions for revocation and introspection
Uses a generic permission-and-rule model so future ERCs can define specific permission types instead of hard-coding one canonical schema here
Returns a context, delegationManager, and possible undeployed-account dependencies, tying granted permissions to ERC-7710 redemption flows and ERC-4337-style deployment rails
Allows wallets to adjust requested permissions when isAdjustmentAllowed is true, making attenuation an explicit part of the permission handshake
Supports offline or semi-offline automation flows such as subscriptions, passive strategies, agents, and repeated in-app actions without giving the dapp full wallet custody
Key claims:
The draft ERC says wallet_requestExecutionPermissions lets a dapp request permissions so it can execute transactions on the user’s behalf, explicitly targeting both disconnected-user execution and scoped connected-user execution
The spec defines permissions and rules as extensible typed objects and warns that type-name collisions matter, which is a strong signal that ERC-7715 is building an authority namespace and negotiation layer rather than a one-off feature
The isAdjustmentAllowed field lets a wallet attenuate the requested authority to meet user approval terms, which makes the wallet an active policy intermediary rather than a passive signer
The response is not guaranteed to equal the request and may include modified permission values, opaque context, undeployed-account dependencies, and a delegationManager, showing that the standard is meant to bridge wallet UX into delegated execution plumbing rather than stop at consent collection
The redemption flow in the ERC routes granted permissions through ERC-7710 redeemDelegations, which reveals that ERC-7715 is not a standalone session-key system but the wallet-side request plane above a deeper delegation framework
The draft requires wallets to expose supported permission and rule types through wallet_getSupportedExecutionPermissions, making wallet vendors the discovery surface that shapes which delegated behaviors become portable across dapps
MetaMask’s Advanced Permissions launch says it is built on ERC-7715, uses a session account that never holds user funds, presents a human-readable approval screen, and lets users adjust or revoke permissions, which is strong evidence that ERC-7715 is already turning into implementation-facing wallet authority infrastructure
MetaMask also frames ERC-7715 as the standard path for subscriptions, DCA, AI agents, and other bounded automations, reinforcing that the important mechanism is scoped execution delegation rather than simple approval batching
Whitepaper: No standalone ERC-7715 whitepaper or litepaper surfaced in this pass. The clearest current sources were the draft ERC, the raw ERC markdown, and MetaMask’s implementation-facing Advanced Permissions materials; see ../../whitepapers/erc-7715-primary-sources-2026-05-07.md.