{"id":"ERC-7715","name":"Execution Permissions","status":"Draft","chain":"both","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"approving","name":"Approving & Permissioning","description":"Granting permissions for actions"},{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"}],"uxImpact":"ERC-7715 requests execution permissions for a designated account. A wallet or account implementation may return a bounded permission, but the standard does not itself create a session key; supported rule types, the returned scope, and revocation behavior are integration-specific.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-7715","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-7715","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7715","type":"official-spec"},{"label":"ERC-7710 official specification","url":"https://ercs.ethereum.org/ERCS/erc-7710","type":"official-spec"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","specConstraints":[{"id":"permission-rule-type-identity","constraint":"Permission and rule type names must not collide, and new types must inherit from BasePermission or BaseRule.","appliesTo":"account-implementation","normativity":"normative","specQuote":"However, if two permissions or two rules share the same type name, a DApp could request with one type of permission, or rule while the wallet grants another. Therefore, it’s important that no two permissions, or two rules share the same type. Furthermore, new permission types or rule types should be specified in addition ERCs. In all cases, these new types MUST inherit from the `BasePermission` or `BaseRule` scheme.","specSection":"Specification / Permission Types, Rule Types","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#permission-types-rule-types","designImplication":"Display the returned permission and rule type identifiers exactly, reject ambiguous collisions, and do not present an unsupported custom type as an interchangeable standard permission."},{"id":"permission-rule-scope","constraint":"Rules define restrictions or conditions that the to account must obey when acting for an account.","appliesTo":"application","normativity":"normative","specQuote":"`rules` define the restrictions or conditions that a `to` account MUST abide by when using a permission to act on behalf of an account. See the “Rule” section for details.","specSection":"Specification / wallet_requestExecutionPermissions / Request Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#request-specification","designImplication":"Show rule limits alongside the account and permission they constrain, and explain when an action falls outside the returned scope."},{"id":"permission-context","constraint":"A permission response must include a context as defined by ERC-7710 for revocation or redemption identification.","appliesTo":"wallet","normativity":"normative","specQuote":"`context` is a catch-all to identify a permission for revoking permissions or redeeming permissions, and can contain non-identifying data as well. The `context` is required as defined in [ERC-7710](./eip-7710.md). See “Rationale” for details.","specSection":"Specification / wallet_requestExecutionPermissions / Response Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#response-specification","designImplication":"Persist and display the permission context needed for known revoke and redeem flows; do not claim a permission is revocable if its context is unavailable."},{"id":"permission-dependencies","constraint":"Wallet responses must report undeployed account dependencies, use empty dependencies when all involved accounts are deployed, and let the DApp deploy reported accounts through each factory and factoryData pair.","appliesTo":"application","normativity":"normative","specQuote":"`dependencies` is an array of objects, each containing fields for `factory` and `factoryData` as defined in [ERC-4337](./eip-4337.md). Either both `factory` and `factoryData` must be specified in an entry, or neither. This array is used describe accounts that are not yet deployed but MUST be deployed in order for a permission to be successfully redeemed. If any of the involved accounts have not yet been deployed, the wallet MUST return the corresponding `dependencies`. If all accounts have already been deployed, the wallet MUST return an empty `dependencies` array. The DApp MUST deploy each account by calling the `factory` contract with `factoryData` as the calldata.","specSection":"Specification / wallet_requestExecutionPermissions / Response Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#response-specification","designImplication":"Show deployment prerequisites before enabling redemption and keep permission status pending until each reported dependency is deployed successfully."},{"id":"permission-delegation-manager","constraint":"A permission response must include the delegationManager required by ERC-7710.","appliesTo":"wallet","normativity":"normative","specQuote":"`delegationManager` is required as defined in [ERC-7710](./eip-7710.md).","specSection":"Specification / wallet_requestExecutionPermissions / Response Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#response-specification","designImplication":"Identify the manager used for redemption and block silent execution when the returned response lacks a usable manager address."},{"id":"permission-request-error","constraint":"A malformed request or a wallet refusal must return an ERC-1193-coded error.","appliesTo":"wallet","normativity":"normative","specQuote":"If the request is malformed or the wallet is unable/unwilling to grant permissions, wallet MUST return an error with a code as defined in [ERC-1193](./eip-1193.md).","specSection":"Specification / wallet_requestExecutionPermissions / Response Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#response-specification","designImplication":"Map the returned error code to a clear request or refusal state and keep per-action confirmation available instead of treating every failure as an unavailable wallet."},{"id":"granted-permissions-inventory","constraint":"The wallet must include every granted permission that has not been revoked in the getGranted response.","appliesTo":"wallet","normativity":"normative","specQuote":"The wallet MUST include all granted permissions that are not yet revoked.","specSection":"Specification / wallet_getGrantedExecutionPermissions / Response Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#wallet_getgrantedexecutionpermissions","designImplication":"Build the active-permission view from the wallet response and do not silently omit still-granted scopes from the revoke or status UI."},{"id":"permission-redeem-account-context","constraint":"DApps must submit redemption transactions with the account in the to field and the permission context as delegation-manager calldata.","appliesTo":"application","normativity":"rationale","specQuote":"DApps must submit transactions with the `account` specified in the `to` field, using the `permissionsContext` as the `_data` when interacting with the delegation manager.","specSection":"Rationale / permissionsContext","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#permissionscontext","designImplication":"Keep the target account and opaque permission context bound together in redeem previews and transaction construction, while labeling this source guidance as rationale."},{"id":"unsupported-permission-method-error","constraint":"A wallet that does not support wallet_requestExecutionPermissions should return an error when the method is called.","appliesTo":"wallet","normativity":"backwards-compatibility","specQuote":"Wallets that don’t support `wallet_requestExecutionPermissions` SHOULD return an error message if the JSON-RPC method is called.","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#backwards-compatibility","designImplication":"Detect unsupported method errors and return users to an explicit per-action approval path instead of leaving a silent-permission spinner."},{"id":"permission-request-minimization","constraint":"DApps should request only needed permissions and use a reasonable expiration time.","appliesTo":"application","normativity":"security-considerations","specQuote":"DApps should only request the permissions they need, with a reasonable expiration time.","specSection":"Security Considerations / Limited Permission Scope","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#limited-permission-scope","designImplication":"Make scope and expiry legible before approval and avoid bundling unrelated capabilities into one permission request."},{"id":"wallet-permission-enforcement","constraint":"Wallets must correctly enforce granted permissions as part of the wallet implementation.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Wallets MUST correctly enforce permissions. Ultimately, users must trust that their wallet software is implemented correctly, and permissions should be considered a part of the wallet implementation.","specSection":"Security Considerations / Limited Permission Scope","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#limited-permission-scope","designImplication":"Do not imply that a DApp UI can enforce the permission boundary by itself; show the wallet/account as the authority and stop when enforcement is unavailable."},{"id":"permission-display-warning","constraint":"Wallets must clearly display requested permissions and warn users about dangerous permissions.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Malicious DApps could pose as legitimate applications and trick users into granting broad permissions. Wallets MUST clearly display the permissions to users and warn them against granting dangerous permissions.","specSection":"Security Considerations / Phishing Attacks","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#phishing-attacks","designImplication":"Show the account, actions, limits, expiry, and dangerous capabilities in the approval surface, with a warning before granting broad authority."},{"id":"permission-adjustment-control","constraint":"A DApp can declare whether a wallet may attenuate or increase the authority of a requested permission.","appliesTo":"application","normativity":"normative","specQuote":"`isAdjustmentAllowed` defines a boolean value that allows DApp to define whether the Wallet MAY attenuate(reduce or increase) the authority of a \"permission\" to meet the user’s terms for approval.","specSection":"Specification / Permission Types, Rule Types / Permissions","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#permissions","designImplication":"Show whether the wallet may narrow or broaden the requested authority, and make any returned adjustment visible before approval."},{"id":"permission-account-selection","constraint":"The optional from field lets the user choose which exposed account receives the permission.","appliesTo":"wallet","normativity":"normative","specQuote":"`from` identifies the account being targeted for this permission request which is useful when a connection has been established and multiple accounts have been exposed. It is optional to let the user choose which account to grant permission for.","specSection":"Specification / wallet_requestExecutionPermissions / Request Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#request-specification","designImplication":"Make the targeted account explicit and let the user choose among exposed accounts before granting permission."},{"id":"permission-rule-capability-advertising","constraint":"Wallets should report supported permission rule types so DApps can explain available conditions.","appliesTo":"wallet","normativity":"normative","specQuote":"The wallet SHOULD include an object keyed on supported permission types including `ruleTypes` (`string[]`) that can be applied to the permission.","specSection":"Specification / wallet_getSupportedExecutionPermissions / Response Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-7715#wallet_getsupportedexecutionpermissions","designImplication":"Use capability metadata to explain which rule conditions are supported. Do not show a rule as selectable when the wallet cannot apply it."}],"summary":"ERC-7715 requests execution permissions for a designated account. A wallet or account implementation may return a bounded permission, but the standard does not itself create a session key; supported rule types, the returned scope, and revocation behavior are integration-specific.","partialDeployment":{"body":"ERC-7715 is Draft. Treat requested permissions, rule types, silent execution, and revocation as conditional on the wallet/account implementation and returned permission."},"designerTakeaways":["Show the targeted from account, DApp/session to account, requested actions, limits, and the permission the wallet actually returns.","Describe silent execution as conditional on the returned permission and account integration, with a per-action fallback.","Revoke each known permission context and report completion only after its revocation succeeds."],"applicability":{"whenToUse":["The target wallet/account implementation supports the Draft permission request and returns a scope the product can display.","Actions fit clear scopes such as in-game moves or limit orders, with a per-action fallback.","Users understand upfront what the app may do without prompts and how to revoke known permission contexts."],"whenToAvoid":["Every action is high-value and needs individual confirmation.","The wallet/account or target chain lacks the execution-permission support needed by the integration.","Scopes cannot be explained simply to non-technical users."]},"prototypeFirst":[{"screen":"Permission request and returned scope","why":"Show the bounded permission only when the Draft request is supported and the wallet returns a scope.","covers":["Requested actions","Returned scope"],"include":["Limits and expiry","Approval result","Per-action fallback"]},{"screen":"Unsupported or narrowed permission","why":"Draft support and wallet policy may return no permission or a narrower scope than requested.","covers":["Unsupported rule type","Returned scope differs"],"include":["Plain-language reason","Fallback action"]},{"screen":"Permission expiry or revocation","why":"A silent action path must stop cleanly when its returned permission no longer applies.","covers":["Expiry","Revocation or action rejection"],"include":["Retry path","Support context"]},{"screen":"Permission detail","why":"Users need a durable view of the account, rules, limits, and known revocation contexts.","covers":["Designated account","Rule and spend scope","Expiry/revocation status"],"include":["Expandable section","Copy buttons","Explorer link"]}],"mentalModel":[{"label":"Scope request","description":"The app asks for a bounded permission on a targeted from account for a DApp/session to account: allowed actions, spend cap, and duration. Frame it like app permissions, not cryptographic jargon."},{"label":"User approval","description":"The user grants an execution permission for the DApp/session to account to act on behalf of the targeted from account. The response is a wallet/account permission, not necessarily a newly generated session key."},{"label":"Silent actions","description":"Actions may execute without a prompt only when the returned permission and account integration authorize them. Show the active scope and keep a per-action signing fallback."},{"label":"Limit enforcement","description":"When spend or time limits are hit, the app must re-prompt or stop. Never let the UI imply unlimited authority."},{"label":"Revoke","description":"Users can revoke known permission contexts when the integration supports it. A revoke-all control is an app workflow over those contexts, not a universal ERC-7715 method."}],"statesToDesign":[{"state":"Permission requested","trigger":"The app requests a bounded execution permission from a compatible wallet/account.","userNeed":"Understand what actions and limits they are approving.","designResponse":"Show chain, targeted from account, DApp/session to account, rule types, spend/time limits, and the requested permission."},{"state":"Permission adjusted or declined","trigger":"The wallet returns a modified scope—possibly attenuated or increased when adjustment is allowed—no permission, or a rejection.","userNeed":"Know what remains available.","designResponse":"Show requested versus returned scope or decline and return to per-action confirmation."},{"state":"Within permission","trigger":"An action matches the returned permission and account integration.","userNeed":"Know why no prompt appears and how to stop it.","designResponse":"Show active scope and keep a visible known-context revoke path."},{"state":"Permission expired or revoked","trigger":"The returned limits no longer apply or a known permission context is revoked.","userNeed":"Avoid an unexplained failure.","designResponse":"Stop silent execution, explain the boundary, and offer a new request or ordinary confirmation."},{"state":"Action outside scope","trigger":"The action exceeds a rule, spend cap, account, or time limit.","userNeed":"Know why a prompt or block occurred.","designResponse":"Name the exceeded limit and offer per-action signing or a revised permission request."}],"designDecisions":[{"question":"How much protocol detail do users see?","recommendation":"Lead with outcomes; tuck identifiers behind review.","rationale":"Users decide on consequences, not function selectors."},{"question":"What happens when support is missing?","recommendation":"Block with explanation and fallback path.","rationale":"Silent failure feels like a broken product."},{"question":"How do you communicate Draft-stage permission support?","recommendation":"Show the returned scope and label unsupported or narrowed permissions before enabling silent actions.","rationale":"ERC-7715 does not guarantee rule types, session keys, silent execution, or universal revocation."}],"problemsSolved":[{"problem":"Repeated prompts can interrupt bounded, low-risk actions","oldWay":"Every eligible action requires an individual wallet prompt","newWay":"A compatible wallet/account may return a bounded permission for matching actions","impact":"high"},{"problem":"Users may not understand silent execution authority","oldWay":"The app requests a broad permission or hides its returned scope","newWay":"The UI shows designated account, rule types, limits, expiry, and per-action fallback","impact":"high"},{"problem":"Expiry, scope mismatch, and revocation failures are easy to conflate","oldWay":"A generic action error hides whether the permission or contract action failed","newWay":"Mapped permission and execution states explain what to do next","impact":"medium"}],"uxPatterns":[{"name":"Execution Permission Card","description":"Plain-language scope for a designated account before requesting execution permission.","components":["ScopeList","SpendCap","ExpiryTimer"],"userFlow":["App requests an execution permission","User reviews scope","Approves once","Actions proceed without per-action prompts only within the returned scope"]},{"name":"Active Permission Badge","description":"Persistent indicator of ongoing authorization.","components":["SessionBadge","RevokeButton"],"userFlow":["Permission active","Badge shows limits","User revokes each known permission context when supported","App returns to per-action signing"]}],"antiPatterns":[{"pattern":"Presenting a Draft permission as universal session-key support","why":"The wallet may return no permission, a narrower rule, or no silent execution path","instead":"Show the returned scope, limits, expiry, and ordinary per-action fallback","severity":"critical"},{"pattern":"Hiding permission scope or designated account","why":"Users cannot tell which actions may run without prompts","instead":"Use outcome language with persistent account, rule, and limit disclosure","severity":"high"},{"pattern":"No fallback when permission support is missing","why":"An unsupported or declined permission should not strand the user","instead":"Explain the limitation and offer per-action confirmation or another supported path","severity":"high"}],"vocabulary":[{"use":"Permission scope","avoid":"Unlimited access","why":"The returned permission is bounded and should be shown with its limits."},{"use":"Outside permission scope","avoid":"Wallet failed","why":"Name whether a rule, limit, expiry, or action caused the fallback."},{"use":"Allow selected actions","avoid":"Auto-approve everything","why":"Keep user control and the bounded permission visible."}],"technicalNotes":"ERC-7715 requests execution permissions for a targeted from account and a DApp/session to account; the permission defines what the to account may do on behalf of the from account, while rules constrain that use. The wallet response can differ from the request, including attenuation or increased authority when adjustment is allowed, and includes context, dependencies, and delegationManager for the integration. The ERC specifies wallet–DApp request/response, not how every wallet enforces permission; redeeming and enforcement remain account/delegation integration. The response is not a newly generated key. Revocation is per permission context unless an application builds a broader workflow.","relatedStandards":[{"id":"EIP-7702","relationship":"EOA delegation enables session patterns"},{"id":"ERC-4337","relationship":"Smart accounts can hold session keys"}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-7715","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-7715","type":"discussion"},{"label":"ERC-7710 official specification","url":"https://ercs.ethereum.org/ERCS/erc-7710","type":"official-spec"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-7715","markdown":"https://www.eipsfordesigners.com/standards/ERC-7715/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-7715/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-7715","official":"https://ercs.ethereum.org/ERCS/erc-7715","discussion":"https://ethereum-magicians.org/search?q=ERC-7715"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}