ERC-7715 Wallet Execution Permissions: Scoped Authority, Expiry, and Revocation
ERC-7715 wallet permissions change the security model of a wallet interaction by allowing an application to request bounded authority that can later be exercised on the user's behalf instead of requiring the user to approve every individual transaction. The proposal is designed for experiences such as subscriptions, automated strategies, games, limit orders, passive actions, agents, and persistent application sessions. The benefit is reduced signing friction. The security cost is that authorization can survive beyond the moment in which the user clicks approve. A secure implementation therefore depends on precise scope, the correct account and chain, an appropriate session account, clear wallet rendering, reasonable expiry, reliable enforcement, accessible revocation, simulation before execution, and independent confirmation of what actually happened on-chain.
TL;DR
- ERC-7715 is a draft wallet interface for requesting execution permissions, not a conventional wallet connection or ordinary ERC-20 approval.
- The permission request identifies a chain, target user account, DApp session account, permission type, permission data, and optional rules such as expiry.
- The wallet's returned permission is not guaranteed to be identical to the original request, so users and applications must treat the final granted scope as authoritative.
- Closing a browser tab or disconnecting a site should not be assumed to revoke a granted execution permission. Explicit expiry and revocation matter.
- The DApp session account becomes a security-critical credential because it can redeem the delegated authority while the permission remains valid.
- Least privilege, short lifetimes, simulation, revocation, post-execution transaction decoding, and allowance checks are the practical defenses against persistent delegated-authority risk.
Wallet and DApp implementations can therefore evolve as the proposal develops. Security analysis should be based on the actual wallet implementation, permission type, delegation manager, and application flow rather than assuming that every product labeled "ERC-7715" behaves identically.
What ERC-7715 actually changes
The conventional wallet model asks a user to authorize an action at the moment that action is executed.
A DApp prepares a transaction.
The wallet displays it.
The user approves or rejects it.
The transaction is submitted.
The next action usually requires another approval.
That model provides repeated user checkpoints, but it also creates friction. A user cannot conveniently authorize a subscription to run later without being online. An automated strategy cannot rebalance when conditions are met if every transaction requires the user to return and sign. A game requiring dozens of low-risk actions can become unusable if every interaction opens a wallet prompt.
ERC-7715 introduces the JSON-RPC method wallet_requestExecutionPermissions so a DApp can ask a wallet for authority to execute transactions on the user's behalf under specified restrictions.
The security model becomes:
That is a significant change.
The user is no longer reviewing only a single future state transition.
The user is approving a policy describing a class of state transitions that another account may initiate later.
Permission design therefore becomes as important as transaction decoding.
ERC-7715 is not just a wallet connection
A wallet connection commonly allows a site to learn the user's selected address and request wallet operations.
Connection alone does not normally mean the website can autonomously make the account send ETH, swap tokens, or call arbitrary contracts whenever it wants.
The user still authorizes transactions or signatures when requested.
An ERC-7715 execution permission is different because the wallet can grant a DApp-associated account authority that is intentionally reusable under the approved policy.
| Authorization | What is granted | Who exercises it | Typical lifetime | Main security question |
|---|---|---|---|---|
| Wallet connection | Access to selected account information and ability to request wallet actions. | User remains involved when wallet approval is required. | Session or wallet-dependent. | What information and RPC capabilities does the site receive? |
| Ordinary transaction | Authorization for one state transition. | The signed transaction executes once. | Single transaction. | What exactly will this transaction do? |
| ERC-20 allowance | A spender may use transferFrom up to the token allowance under ERC-20 semantics. | Approved spender. | Until consumed, changed, or revoked. | Which token, spender, and amount are approved? |
| Permit2-style authorization | Token-spending capability through a specialized allowance or signature framework. | Authorized spender through the framework. | Defined by relevant allowance and signature terms. | What token authority survives after the immediate transaction? |
| ERC-7715 execution permission | Wallet-enforced authority for a DApp session account to execute defined behavior on the user's behalf. | The account identified by the permission's to field through the delegation mechanism. | Until expiry, revocation, invalidation, or another enforced condition ends authority. | What complete class of account actions is being delegated? |
This distinction matters because users have learned to treat "Connect Wallet" as relatively low authority compared with "Approve Token."
Execution permissions create another category that needs its own recognizable user interface.
ERC-7715 is also not an ERC-20 allowance
A traditional ERC-20 allowance exists inside a token contract.
The token holder approves a spender for an amount.
The spender can later invoke the token's allowance-based transfer functionality subject to the remaining allowance.
Execution permissions operate at the wallet-account authorization layer.
A permission type could be designed around token spending, but ERC-7715 itself is broader. It defines the wallet-facing framework for requesting execution permissions and leaves permission and rule types extensible through additional ERCs.
That means a wallet security review should ask two separate questions:
For the second question, TokenToolHub's token approval and allowance guide explains conventional ERC-20 spender risk, while the Permit2 and allowances guide covers persistent token authorization through specialized approval infrastructure.
One mechanism does not automatically replace the other.
An ERC-7715-authorized execution could itself interact with a contract that creates a separate token allowance. That allowance can potentially remain after the execution permission expires unless it is separately removed.
The ERC-7715 authorization surface
The proposal's request object contains several security-relevant fields.
Each one should be understandable before the user approves anything.
DApp requests authority
The request identifies the chain, user account where specified, DApp session account, permission type, permission data, and optional rules.
Wallet evaluates the request
The wallet determines whether the permission is supported and should render the effective authority clearly for the user.
User grants bounded scope
The user approves a class of future account actions rather than one isolated transaction.
Permission context is returned
The response includes an opaque context, delegation manager, and any dependencies required for undeployed accounts.
DApp redeems authority
The DApp-associated account later attempts an action through the delegation manager while the permission remains valid.
User verifies and revokes
Review completed transactions, persistent token approvals, remaining permissions, expiry, and revocation status.
What each ERC-7715 permission field means
The standard's request is intentionally extensible, but its top-level fields form the basic security envelope.
chainId is a security boundary, not cosmetic metadata
ERC-7715 includes a chain identifier directly in the permission request.
This matters because the same address can exist on multiple EVM networks while representing completely different balances and contract environments.
A permission intended for Ethereum mainnet should not silently become permission for another network merely because account addresses are syntactically identical.
Wallets should display the chain in familiar terms rather than presenting only a hexadecimal chain identifier.
Users should see the actual network
"Ethereum Mainnet" is safer than an unexplained "0x1."
"Base" is safer than expecting the user to recognize a chain ID manually.
Builders should enforce chain binding
Displaying the chain without enforcing it does not provide security.
The permission implementation and redemption path must ensure the authority is valid only where intended.
Cross-chain permission interfaces need explicit consent
A DApp needing equivalent permission on five networks should present five understandable scopes rather than visually collapsing them into one vague "Enable automation" button.
The from account is the authority source
The from field identifies the account being targeted for the permission request when specified.
This is important for wallets exposing multiple accounts.
A user might keep a low-value trading account and a separate long-term vault in the same wallet application.
A permission that is reasonable for the trading account can be unacceptable for the vault.
The approval screen should therefore make the source account visually prominent.
Truncated addresses are useful for readability but should be accompanied by account labels and an easy way to view or verify the full address.
If the request does not specify from, the wallet should make the account choice deliberate rather than inheriting whichever account happened to be active in the previous browser session.
The to account is a new credential surface
One of the most important ERC-7715 fields is to.
The specification describes it as the DApp session account associated with the permission.
The permission response is redeemable by the account identified by this field through the ERC-7710 delegation mechanism.
This means the session account is not merely an analytics identifier.
It is part of the authorization boundary.
A compromised session account can become a compromised permission
Suppose a user grants a trading application authority to spend up to 0.2 ETH over the next 24 hours.
If an attacker steals the DApp session account's key during that period, the attacker may be able to exercise whichever actions the granted permission allows.
The main wallet key can remain completely uncompromised.
The damage comes through delegated authority.
Permission scope determines the blast radius
If the session credential can transfer only 0.02 ETH to one specific contract for ten minutes, compromise is constrained.
If it can execute arbitrary calls against many assets for 30 days, compromise is much more serious.
Session credentials need lifecycle security
DApps should protect session accounts as security-sensitive keys.
They need secure generation, storage, rotation where appropriate, deletion, telemetry, compromise response, and a path for users to revoke permissions associated with them.
ERC-7715 does not standardize one universal permission vocabulary
The core ERC intentionally does not define an exhaustive list of permission and rule types.
The proposal expects additional permission types to develop as wallets become more capable.
This gives the ecosystem flexibility.
It also creates a wallet-display challenge.
A permission type is safe only when the wallet and DApp agree on exactly what that type means and the wallet enforces those semantics correctly.
Names must not collide semantically
The ERC explicitly recognizes the risk that two different permissions could share a type name while being interpreted differently.
Permission and rule types therefore need unambiguous definitions.
Raw type strings are not sufficient consent
A normal user should not have to interpret a developer-facing permission identifier.
A wallet should translate it into effects.
For example:
A useful permission display should answer
- What assets can be affected?
- How much value can move?
- Which contracts or recipients can be called?
- Which methods or action categories are permitted?
- Can native ETH be transferred?
- Can new token approvals be created?
- Can existing approvals be changed?
- Can arbitrary calldata be executed?
- Can actions be batched?
- Which chain does the authority cover?
- Which account grants the authority?
- Which DApp session account receives it?
- When does the permission expire?
- How can it be revoked before expiry?
The final permission can differ from the original request
This is one of the most important details in the ERC-7715 specification.
The response contains the request information plus response-specific data, but the standard explicitly says the values returned are not guaranteed to be equivalent to those originally requested.
That means software must distinguish three concepts:
Requested permission
The authority the DApp initially asks the wallet to grant.
User-approved permission
The terms the wallet presents and the user actually consents to.
Returned permission
The effective permission object returned to the DApp and used for later redemption.
A wallet implementation must keep these aligned.
The DApp must not continue displaying the original request as though it were necessarily the final authority.
The user should be able to inspect the permission actually granted after approval.
Expiry converts persistent authority into time-bounded authority
The ERC defines an expiry rule containing a Unix timestamp after which the permission becomes invalid.
Expiry is one of the strongest and simplest safeguards against forgotten delegated authority.
Without expiry, a permission can remain usable until explicit revocation or another invalidating condition occurs.
Short tasks deserve short permissions
A game action needed for a 20-minute play session should not automatically receive a 30-day permission.
A limit order that expires tonight does not need authorization valid next month.
A one-time automated claim may need minutes rather than days.
Longer automation needs narrower scope
Some legitimate workflows require extended authority.
A subscription may recur monthly.
A savings strategy may rebalance for weeks.
If lifetime increases, scope should generally shrink elsewhere through amount limits, target restrictions, asset restrictions, execution frequency, or other enforceable conditions.
Expiry is not the same as revocation
An expired permission becomes invalid because its time condition has passed.
Revocation intentionally invalidates permission before its planned end.
Users need both.
How ERC-7715 revocation works
The proposal defines wallet_revokeExecutionPermission.
The request identifies the permission through its permission context.
When revocation succeeds, the wallet responds successfully without needing to return a new permission object.
The simple API is useful, but the user experience around it is more important than the method name.
Revocation must be discoverable
A user should not need to revisit the original DApp to remove its authority.
If the DApp was compromised, disappeared, or became malicious, forcing the user to return to it would undermine the purpose of wallet-controlled permissions.
Revocation must identify what is being removed
A permissions dashboard should show application identity, account, chain, scope, session account, time granted, expiry, and current status.
Revocation should be testable
After revocation, the same permission redemption should fail.
Applications should not assume a successful UI click is sufficient if the underlying authorization mechanism requires an on-chain state change that has not yet finalized.
Emergency revocation should prioritize certainty
During suspected compromise, it can be appropriate to remove every active permission for the affected DApp or session account rather than attempting to preserve convenience.
Disconnecting a website is not the same as revoking authority
This distinction is likely to become one of the most important wallet-education problems as execution permissions become more common.
Users already assume that disconnecting a DApp makes the DApp harmless.
That assumption is already incomplete when token allowances persist.
It becomes more dangerous with reusable execution permissions.
A browser connection can disappear while a previously granted delegated capability remains valid under the wallet's permission system.
Therefore:
A secure wallet should avoid presenting one generic "Disconnect" control as though it invalidates every form of persistent authority unless it actually does so.
Where does an ERC-7715 permission live?
ERC-7715 standardizes wallet and DApp interactions but does not mandate one universal internal storage model for every wallet.
The response includes a context field that acts as an opaque representation used for permission redemption and revocation.
The specification describes this context as intentionally flexible because different permission schemes can encode authority differently.
That design means users should not expect to read a hexadecimal permission context and understand the authority themselves.
The wallet is responsible for interpretation
The wallet knows what it granted and should retain enough structured information to render the permission later.
The DApp receives a redeemable permission context
The DApp uses that context when interacting with the relevant delegation manager.
The enforcement mechanism can involve on-chain state, signed authority, or implementation-specific logic
The exact architecture depends on the wallet and delegation framework.
Users should therefore ask whether revocation requires an on-chain transaction, a wallet-local state update, invalidation in a delegation contract, or a combination.
The delegation manager is a high-value security component
ERC-7715 works with ERC-7710's delegation redemption model.
The wallet's permission response includes a delegation manager.
When the DApp wants to exercise authority, the relevant account calls the delegation manager with the permission context and the intended execution.
The manager validates authority and, where valid, causes the delegated action to be executed through the user's account architecture.
A buggy manager can misinterpret scope
If a permission says "spend up to 0.1 ETH" but the manager's validation logic checks the amount incorrectly, the written policy has not provided real protection.
An upgradeable manager creates upgrade risk
If implementation logic can change after permission issuance, a user should understand which governance authority controls that upgrade and whether existing permissions retain the same semantics afterward.
Wallets should bind permissions to expected managers
A malicious DApp should not be able to substitute an untrusted delegation manager after the user approves a permission.
Independent contract verification matters
Users managing significant value may want to know whether the delegation infrastructure is verified, audited, upgradeable, paused, or administratively controlled.
Undeployed account dependencies add another step to the permission flow
The ERC-7715 response includes a dependencies array.
This is relevant when accounts involved in redeeming the permission are not yet deployed.
The response can provide a factory and factory data so the DApp can deploy the required account before permission redemption.
From a user-experience perspective, this may be invisible.
From a security perspective, it should not be ignored.
The factory is part of the trust path
The deployed account must have the behavior the wallet expected when it granted authority.
Initialization data matters
Incorrect initialization could create an account with different ownership or execution properties.
Substitution should fail
The DApp should not be able to replace a wallet-approved dependency with another deployment path that changes the authority model.
How a granted permission is exercised
ERC-7715 relies on ERC-7710 for redemption.
At a high level, the DApp-associated account forms an execution and sends it to the returned delegation manager together with the permission context.
The execution describes what the user's account is being asked to do.
The delegation manager verifies whether the permission context authorizes that execution.
If valid, the action proceeds through the account.
If invalid, it should fail.
Execution can be more expressive than a basic transfer
ERC-7710 uses execution concepts aligned with modular smart-account infrastructure rather than limiting every delegation to one fixed transfer structure.
That flexibility supports advanced use cases.
It also reinforces the need for precise permission types.
A user should never interpret "automated transaction" as synonymous with "simple transfer."
Simulation is part of permission verification
ERC-7710 recommends that DApps simulate delegation redemption before submitting an execution.
This is important because a permission that existed yesterday may no longer be executable today.
The user may revoke it
The permission context can no longer represent valid authority.
The permission may expire
A time rule can make execution invalid.
Relevant account state may change
Contract state can make a previously valid action fail.
The delegation can become invalid for implementation-specific reasons
Modules, account configuration, managers, dependencies, or other state can change.
Simulation validates the intended execution against current conditions.
It does not create a permanent guarantee because state can change after simulation and before inclusion.
Simulation still has a time-of-check problem
Suppose a DApp simulates a transaction at block N.
The permission is valid.
Before the DApp transaction reaches the next block, the user revokes the permission.
The real execution should fail.
This is desirable.
The application should treat it as an authorization change, not as an excuse to silently request or grant broader authority.
Do not automatically escalate
If a narrow permission fails, the DApp should not automatically replace it with a broader permission without clear user approval.
Retry logic should preserve least privilege
A retry should revalidate state and, when new permission is necessary, request only the authority actually needed.
Batch execution and partial-failure risk
Delegated execution can involve more than one operation.
ERC-7710 requires implementations to enforce atomicity for the batch tuples passed through its delegation-redemption interface.
That means a properly implemented single batch should not leave half of that batch applied when another tuple in the same atomic operation fails.
However, application workflows can still span several separate transactions.
Transaction one can succeed while transaction two fails
A strategy can swap an asset successfully and then fail to deposit the output into another protocol.
An approval can persist after a later action fails
The application can create an ERC-20 allowance in one transaction and fail before the intended use or cleanup step.
Off-chain state can disagree with on-chain completion
A DApp can mark an automation completed while the final transaction reverted.
Verification should examine final state
Users and builders should not infer success from the fact that the permission was valid or that one transaction succeeded.
A realistic ERC-7715 authorization sequence
Consider an automated DEX strategy.
A user wants a DApp to execute one swap if ETH falls below a chosen threshold.
The user does not want to remain online.
Step 1: DApp checks support
The application can query the wallet's supported execution-permission and rule types.
If the wallet does not support the required permission, the DApp should use another user-consented flow rather than disguising a different authorization as equivalent.
Step 2: DApp creates a permission request
The request identifies the intended chain, user's account, DApp session account, permission type, relevant amount or action limits, and an expiry suitable for the order.
Step 3: wallet interprets the request
The wallet should independently understand the permission type and rule semantics rather than rendering arbitrary text supplied by the website.
Step 4: wallet presents effective authority
The approval might say:
Example of meaningful wallet disclosure
- Account: Trading Account 1
- Network: Ethereum Mainnet
- Application: Example Exchange
- Authorized session account: full address available for verification
- Action: execute the supported swap permission
- Maximum authorized value: 0.25 ETH
- Expiration: September 10, 2026 at 18:00 local time
- Revocation: available from Wallet → Permissions
- Warning: the application can exercise this authority while you are offline until it expires or is revoked
Step 5: user approves
The wallet creates the permission according to its enforcement model and returns the effective permission response.
Step 6: DApp stores only what it needs
The DApp obtains the permission context and other information required for redemption.
The session credential should be protected like a scoped signing key.
Step 7: trigger condition occurs
The DApp prepares the intended execution.
Step 8: DApp simulates redemption
The system verifies that permission remains valid and the exact action is currently authorized.
Step 9: DApp executes
The DApp-associated account submits the delegation redemption.
Step 10: user independently verifies
The user can review the transaction, resulting balances, any generated token approvals, and whether the permission remains active.
What a wallet should display before approval
The ERC's security considerations explicitly require wallets to display permissions clearly and warn users about dangerous permissions.
A safe UI should go beyond showing a permission type string.
The authority source
Which user account is granting permission?
The authority recipient
Which DApp session account can exercise it?
The chain
Where is the authority valid?
The actions
What behavior can the DApp cause?
The assets
Which ETH, tokens, NFTs, protocols, or account capabilities can be affected?
The maximum economic exposure
What is the most value the permission could move or put at risk?
The allowed targets
Can the permission call only one known contract or any address?
The allowed duration
When does authority become invalid?
The revocation path
How can the user remove it immediately?
The offline-execution warning
If the application can act while the user is disconnected or asleep, the UI should say so explicitly.
Least privilege is the core ERC-7715 safety principle
The official ERC security considerations say DApps should request only the permissions they need and use reasonable expiration times.
That principle needs to be translated into actual design decisions.
Limit what can move
A DApp trading one token does not need authority over every token in the account.
Limit the amount
Bound spending or transfer authority to the maximum genuinely required by the workflow.
Limit destinations
Prefer known contracts or recipient sets over unrestricted arbitrary-call authority.
Limit duration
Expire authority when the task, order, session, subscription, or strategy no longer requires it.
Least privilege is not simply a wallet feature.
The permission type must be capable of expressing useful restrictions.
The wallet must enforce them correctly.
The DApp must request them honestly.
The user interface must communicate them clearly.
Overbroad permission is the ERC-7715 equivalent of unlimited approval risk
The most obvious abuse pattern is to request more authority than the DApp needs.
Unlimited value
A DApp handling a $50 transaction requests authority effectively covering the account's entire ETH balance.
Any target
A strategy that needs one router receives permission to call arbitrary contracts.
Any asset
An application managing one stablecoin receives broad wallet execution capability affecting unrelated assets.
No practical expiry
A one-time operation requests a permission valid for years.
Broad batch capability
A permission intended for one predictable action can construct sequences with side effects the user never anticipated.
This does not mean broad permissions are universally invalid.
Some sophisticated automation genuinely needs expressive authority.
It means the wallet should communicate the maximum consequence rather than only the expected normal use.
Permission phishing changes what a malicious website asks users to sign
Traditional phishing often asks for an asset transfer, malicious approval, Permit signature, or wallet-draining transaction.
An execution-permission phishing flow can look less alarming.
The wallet may show no immediate outgoing transfer.
The user can approve the request and see no balance change.
The attacker can exercise delegated authority later.
The absence of an immediate transfer is not proof of safety
A permission request should be evaluated according to what future actions it enables.
Brand impersonation becomes dangerous
The ERC security considerations explicitly identify malicious DApps posing as legitimate applications and requesting broad permissions.
Wallet-rendered scope matters more than DApp copy
The website can say "Enable notifications."
The wallet should independently say "This site is requesting authority to execute transactions from Account X."
A compromised legitimate frontend is another major threat
Users can reach the correct domain and still receive a malicious request if the site's frontend, deployment pipeline, dependency, DNS, or content-delivery infrastructure has been compromised.
A strong wallet should therefore avoid treating domain reputation as sufficient authorization.
Compare request with historical behavior
If a DApp that normally requests small one-hour permissions suddenly requests broad month-long authority, the wallet can warn the user.
Use wallet-side policy
A wallet can cap certain permission categories or require stronger confirmation for dangerous scope.
Make recipient account visible
A frontend compromise can substitute the attacker's session account into the to field. The wallet must treat that address as part of the authorization, not hidden metadata.
Stale permissions are a long-tail security problem
Users tend to accumulate persistent authority.
Old token allowances already demonstrate this pattern.
Execution permissions can create a similar inventory of dormant access.
A user tries a DApp once.
Months pass.
The application is forgotten.
The session credential is later compromised.
If the permission remains valid, old trust becomes a new attack path.
Reasonable expiry is preventive security
The safest forgotten permission is one that has already expired.
Wallets should surface inactive relationships
A permission unused for months can be flagged for review even before its formal expiry.
DApps should relinquish unnecessary authority
Applications should revoke or encourage revocation when users disable automation, cancel a subscription, delete an account, or conclude a strategy.
Replay and reuse must be considered at the permission layer
Traditional transaction replay concerns reusing signed authorization in a context where it was not intended.
Execution permissions deliberately support reuse, so the security question becomes narrower:
Chain scope should be enforced
The request contains chainId for this reason.
Redeemer identity should be enforced
The account associated with the to field should not be substitutable by an arbitrary caller.
Usage limits belong in permission semantics where required
If a permission is intended for one execution only, its enforcement should make a second redemption invalid rather than relying on the DApp voluntarily stopping.
Context interpretation is implementation-sensitive
Because ERC-7715 treats permission context as opaque and relies on the delegation implementation for enforcement, developers should not assume replay resistance from the existence of the context field alone.
Wallet and delegation upgrades can change the meaning of existing permissions
Smart-account systems are often upgradeable or modular.
That flexibility is useful for fixing vulnerabilities and adding functionality.
It can create a difficult question for long-lived permissions.
A user approves permission under implementation version A.
The wallet or delegation manager upgrades to version B.
Does the exact same permission context still mean the exact same thing?
Safe upgrades preserve or deliberately invalidate old semantics
Existing permissions should not silently become broader because a validator changed.
High-risk upgrades can invalidate active permissions
Requiring users or DApps to reauthorize after a material security-model change can be safer than carrying ambiguous authority forward.
Governance matters
Users should understand who can upgrade critical wallet modules and delegation managers.
Delegated authority changes the role of the root signing key
A major benefit of programmable wallets is that users can avoid exposing their highest-authority credential to every routine interaction.
The root owner can approve narrowly scoped delegated authority while routine execution uses lower-privilege credentials.
That can improve operational security.
It only works if delegated permissions are genuinely constrained.
For users keeping the wallet's root signing authority offline or behind a hardware signing layer, devices such as Ledger can reduce exposure of the primary private key during ordinary custody. That protection does not cancel a dangerous permission the user has already authorized.
The same separation principle applies to hardware-isolated signing through devices such as Keystone. A protected root key and an overbroad live delegation are two different security problems, so both must be managed.
Independent verification after permission execution
Execution permissions reduce how often the user reviews transactions before they happen.
That makes post-execution visibility more important.
Decode the actual transaction
Do not rely only on the automation dashboard saying "Swap completed."
Inspect the transaction target, value, calldata, token transfers, approvals, nested calls, and final execution status.
TokenToolHub's Transaction Decoder can help reconstruct EVM transaction behavior and identify token transfers, approval changes, nested execution, traces, and revert information.
Inspect token allowances separately
A delegated execution can create or increase an ERC-20 approval.
The execution permission expiring does not necessarily remove that token allowance.
Persistent allowance state should therefore be checked independently.
Confirm final balances
Compare the expected outcome with actual token and native-asset balances.
Review counterparties
If execution interacted with unfamiliar routers, bridges, vaults, or intermediary contracts, inspect those relationships rather than assuming every nested target belongs to the advertised DApp.
Review the wallet's active permissions
The original permission may remain valid after successful execution.
If the task is complete, revocation can reduce future attack surface.
When a wallet-wide risk review is useful
A suspected delegated-permission incident should not stop with one transaction.
An attacker with temporary authority can create durable changes.
They can move assets.
They can potentially establish token approvals where scope permits.
They can interact with protocols that create new positions.
They can send assets to another account.
They can leave the original wallet looking normal after extracting future rights elsewhere.
TokenToolHub's Wallet Risk Scanner can help widen the investigation to recent activity, approvals, counterparties, contract interactions, and other address-level risk signals.
Incident response for a suspicious ERC-7715 permission
If a permission appears broader than expected or a DApp session account may be compromised, the response should focus on removing reusable authority first.
Identify the permission
Record the account, chain, application, session account, permission context, effective scope, and expiry.
Revoke execution authority
Use the wallet's trusted permission-management interface or supported revocation path.
Check conventional approvals
Inspect ERC-20 allowances, Permit2 relationships, NFT operators, and other persistent approvals created before or during the incident.
Decode recent activity
Identify every execution made through the permission and the downstream contracts it touched.
Review wallet exposure
Check balances, positions, new approvals, bridges, vault deposits, loans, and counterparties.
Rotate affected session credentials
If the DApp continues to be trusted, establish a new narrowly scoped session only after the cause of compromise is resolved.
Revoking the permission does not undo earlier effects
Revocation prevents future use of the revoked authority according to the implementation.
It does not reverse transactions already finalized.
Transferred assets stay transferred
Revocation does not automatically return ETH or tokens already sent.
Created allowances can remain
If a delegated execution approved another spender, that allowance can require separate revocation.
Protocol positions can remain open
A delegated action could borrow, stake, bridge, supply liquidity, or enter another on-chain position.
Downstream authorization can persist
The DApp may have interacted with a protocol that maintains its own account permissions.
Incident response must therefore trace effects, not just remove the initial delegation.
User checklist before approving ERC-7715 wallet permissions
Before approval
- Confirm the wallet is actually presenting an execution permission rather than an ordinary connection.
- Confirm which wallet account is granting the authority.
- Confirm the full blockchain network.
- Confirm the identity of the DApp.
- Inspect the DApp session account where the wallet exposes it.
- Understand what action class is being authorized.
- Identify every asset the permission can affect.
- Identify the maximum economic value that can move.
- Check whether the permission can transfer native ETH.
- Check whether it can interact with arbitrary contracts.
- Check whether contract targets are restricted.
- Check whether recipient addresses are restricted.
- Check whether token approvals can be created.
- Check whether existing approvals can be changed.
- Check whether the permission supports batch execution.
- Check whether the wallet can adjust the requested scope.
- Review the final permission rather than relying on the site's original description.
- Check the exact expiry time.
- Reject unnecessarily long permission lifetimes.
- Confirm where the wallet lets you revoke the permission.
- Do not assume disconnecting the DApp revokes the permission.
- Do not assume closing the browser revokes the permission.
- Do not approve because there is no immediate asset transfer.
- Treat unattended execution as persistent access.
- Use a lower-value account for experimental automation where practical.
- Revoke permission when the automation is no longer needed.
- Review completed transactions independently.
- Check token allowances created by those transactions.
- Investigate unfamiliar session accounts or delegation managers.
- Revoke immediately if the DApp frontend appears compromised.
Wallet-builder checklist for least-privilege ERC-7715 support
Wallet and smart-account implementation controls
- Implement only permission types whose semantics the wallet can enforce correctly.
- Maintain an unambiguous mapping between permission type identifiers and actual behavior.
- Render permission effects in user language rather than exposing only raw type identifiers.
- Display the source account prominently.
- Display the destination DApp session account prominently.
- Display the network in human-readable form.
- Display maximum spend or transfer values where relevant.
- Display asset restrictions.
- Display target and recipient restrictions.
- Display whether arbitrary calldata is permitted.
- Display whether batching is possible.
- Display expiry as an understandable date and time.
- Warn clearly when permission has no short expiry.
- Warn when a request is unusually broad for the application.
- Do not rely on DApp-provided explanatory text for critical scope descriptions.
- Present the effective granted scope after any adjustment.
- Do not let a DApp silently substitute the approved session account.
- Bind permissions to the intended chain.
- Validate dependency factories and initialization data.
- Bind the permission to the intended delegation manager.
- Protect permission records against tampering.
- Provide a wallet-native active-permissions dashboard.
- Show granted time, expiry, DApp, chain and status.
- Make revocation available even when the original DApp is offline.
- Provide bulk revocation for compromised applications where practical.
- Clearly distinguish expired, revoked and active permissions.
- Consider warning about long-unused permissions.
- Make revocation completion state explicit when an on-chain action is required.
- Prevent expired permissions from executing.
- Prevent revoked permissions from executing.
- Prevent executions outside amount limits.
- Prevent executions against unauthorized targets.
- Prevent unauthorized session accounts from redeeming authority.
- Test cross-chain replay and context substitution attacks.
- Test permission type collision and semantic mismatch cases.
- Test contract upgrades against previously issued permission contexts.
- Test partial workflow failure and downstream approvals.
- Test revocation during pending execution.
- Test expiry between simulation and inclusion.
- Test session-key compromise scenarios.
- Audit delegation-manager validation logic.
- Audit permission-context parsing and interpretation.
- Monitor permission redemption anomalies.
- Give users post-execution notifications for meaningful delegated actions.
DApp-builder checklist
Application-side controls
- Query wallet-supported permission types before requesting authority.
- Request the narrowest permission type capable of completing the user-selected workflow.
- Use the shortest practical expiry.
- Do not request unrelated asset authority for convenience.
- Do not request arbitrary targets when a known contract list is sufficient.
- Protect the DApp session account as a security credential.
- Separate session credentials between users where the architecture requires it.
- Rotate session credentials after suspected compromise.
- Do not expose session private keys in frontend storage unnecessarily.
- Verify the wallet's returned permission rather than assuming it matches the original request.
- Preserve the exact returned permission context required for redemption.
- Validate expected delegation manager addresses.
- Deploy only approved dependencies returned by the wallet.
- Simulate permission redemption before execution.
- Handle expiry and revocation failures without broadening authority automatically.
- Re-request permission only with explicit user consent.
- Do not interpret a past successful redemption as proof that the permission remains valid.
- Do not bypass wallet enforcement with a parallel unrestricted authorization flow.
- Keep an auditable log of delegated executions.
- Notify users of materially important unattended actions.
- Provide a clear application-side control for disabling automation.
- Encourage wallet-side revocation when an automation relationship ends.
- Test what happens when revocation occurs while a transaction is in flight.
- Test expiry boundaries across local time, UTC and block timestamps.
- Test failed multi-transaction workflows for leftover approvals.
- Test compromised-frontend substitution of session account and scope fields.
ERC-7715 permission risk matrix
Worked security scenarios
Scenario 1: useful one-hour game permission
A blockchain game needs to execute frequent low-value actions for one play session.
The user grants a permission scoped to the game contract, a small maximum native-token value, and a one-hour expiry.
The DApp session account is compromised two days later.
The permission is already invalid.
The short expiry converted a later credential compromise into a non-event.
Scenario 2: excessive one-year permission
A DApp needs to complete one scheduled transaction tomorrow.
It requests authority valid for a year.
The user approves because no funds leave immediately.
Six months later, the site's session infrastructure is breached.
The stale permission remains usable.
The security failure was created at approval time even though exploitation occurred months later.
Scenario 3: disconnect confusion
A user approves a persistent execution permission.
They later click "Disconnect" on the website.
The browser no longer exposes the connected account.
The previously granted permission remains valid under the wallet's delegation system.
The user falsely believes the site can no longer act.
Wallets should make persistent permission state separate and visible.
Scenario 4: session-account substitution
A legitimate DApp frontend is compromised.
The attacker changes the to field to a session account they control.
The website still displays the familiar brand and normal automation settings.
The wallet shows an unfamiliar authorized account, but the user ignores it.
After approval, the attacker possesses the account capable of redeeming the granted authority.
Scenario 5: chain confusion
A user intends to enable a strategy on Base.
A malicious request targets Ethereum mainnet instead.
The same user address exists on both networks.
If the wallet UI obscures chain scope, the user can delegate authority over assets they did not intend to expose.
Scenario 6: token allowance survives permission expiry
A valid ERC-7715 permission authorizes a sequence that includes approving a DEX router for a token.
The execution succeeds.
Several hours later, the wallet execution permission expires.
The ERC-20 router allowance remains because it is separate token-contract state.
The user must review and revoke that allowance independently if it is no longer needed.
Scenario 7: valid simulation, revoked execution
The DApp simulates permission redemption successfully.
The user notices suspicious activity and revokes the permission seconds later.
The DApp then submits the transaction it previously simulated.
A correct implementation rejects it because authorization changed after simulation.
The DApp should report the failure and request fresh consent only if the user intentionally wants to continue.
Scenario 8: permission expires in the mempool
A permission expires at 14:00:00.
The DApp submits a redemption at 13:59:50.
Network congestion delays inclusion until 14:00:15.
If expiry is correctly enforced at execution time, the transaction fails.
DApps should avoid timing critical operations so close to expiry that ordinary inclusion delay causes failure.
Scenario 9: manager upgrade broadens behavior
A user grants a narrow permission while Delegation Manager version 1 enforces target restrictions correctly.
The manager is later upgraded.
A bug in version 2 fails to enforce the target list.
Existing permission contexts become more dangerous without the user granting new authority.
Upgrade testing must include previously issued permissions.
Scenario 10: broad permission phishing
A fake application copies the interface of a popular DEX.
Instead of asking for a one-time swap, it requests broad reusable wallet authority.
No token transfer appears in the approval screen.
The user approves because they believe they are enabling a gasless trading feature.
The attacker redeems the permission later.
The wallet's independent scope rendering is the primary defense.
Scenario 11: partial workflow creates residual approval
An automated strategy uses two transactions.
The first approves a vault to spend USDC.
The second deposits USDC and is supposed to reset the approval afterward.
The second transaction reverts.
The ERC-7715 permission remains correctly scoped, but the newly created token allowance survives.
Post-execution verification must consider downstream authorization changes.
Scenario 12: account-selection mistake
A user normally trades from a hot wallet but has their long-term vault selected when the permission prompt opens.
The permission request leaves from optional.
The wallet defaults silently to the selected vault.
The user approves without noticing.
A secure UI would make the granting account unmistakable and require deliberate confirmation for high-value accounts.
Scenario 13: permission response differs from request
A DApp requests one permission configuration.
The wallet adjusts terms under the permission type's supported behavior.
The DApp UI continues displaying the original requested amount instead of the effective returned permission.
The user and DApp now have inconsistent mental models.
Applications should store and display the actual granted response.
Scenario 14: unsupported wallet fallback
A DApp calls ERC-7715 on a wallet that does not support the RPC method.
The standard says unsupported wallets should return an error.
The application should explain that the automation feature is unavailable or offer a clearly different authorization path.
It should not silently substitute an unlimited token approval and label the result as equivalent permission security.
Scenario 15: root key remains safe but funds are lost
A user keeps their main account owner key on a hardware device.
The root key never leaves the device.
The user nevertheless grants an overbroad delegated permission to a compromised DApp session account.
The attacker uses that authorized session capability.
No root-key theft is required.
This illustrates the central security shift created by delegation: protecting the master key is necessary, but not sufficient.
Wallets should treat permissions as continuously monitorable security objects
Permission security should not end when the user clicks approve.
Notify on first use
A wallet can notify the user when a newly granted permission is redeemed for the first time.
Notify on unusual use
A permission normally used once per day suddenly executes ten times in five minutes.
That can merit an alert even if each individual call remains technically within scope.
Warn before long-lived expiry
A user can receive a reminder that a 30-day automation remains active.
Highlight dormant permission
A permission granted months ago and unused since can be surfaced for cleanup.
Expose cumulative usage
If a permission has an amount-based budget, the wallet should show how much has been consumed and how much remains.
ERC-7715 fits the broader move toward programmable accounts
Ethereum's account-abstraction direction aims to make wallet security and account behavior programmable rather than binding every account to one all-powerful private key.
Smart accounts can support recovery, batched execution, flexible authentication, gas sponsorship, spending controls, and delegated authority.
ERC-7715 addresses one part of that UX: how applications ask wallets for execution permissions in a standardized way.
ERC-7710 addresses the redemption side of delegated capability.
ERC-4337 provides infrastructure for smart-account execution through UserOperations without requiring the base protocol to natively treat every smart account exactly like an EOA.
Ethereum's broader roadmap has also moved account programmability forward through upgrades such as EIP-7702, while work on more native account abstraction continues.
The direction is important:
That can make wallets safer when permissions are genuinely narrow.
It can make wallets more dangerous when complex authority is presented as a simple convenience toggle.
What a mature wallet permission dashboard should look like
Persistent execution permissions need a management surface comparable to operating-system application permissions.
| Dashboard field | What the user should learn | Why it matters |
|---|---|---|
| Application | Which DApp relationship created the permission. | Users need recognizable trust context. |
| Granting account | Which wallet account delegated authority. | Multiple accounts can have different risk profiles. |
| Network | Where authority is valid. | Prevents cross-chain confusion. |
| Session account | Which account can redeem the permission. | Identifies the delegated credential. |
| Scope | Assets, amounts, targets and permitted behavior. | Defines maximum blast radius. |
| Granted time | When trust relationship began. | Helps identify forgotten authority. |
| Expiry | When permission automatically becomes invalid. | Shows remaining exposure window. |
| Usage | Recent or cumulative delegated executions. | Helps detect unexpected behavior. |
| Status | Active, expired, revoked, invalid or otherwise unusable. | A granted object is not necessarily currently executable. |
| Revoke | Trusted wallet-native way to terminate authority. | Essential incident-response control. |
The correct mental model for ERC-7715
A useful way to think about ERC-7715 is as a temporary employee badge for part of your wallet.
The badge should not open every door.
It should work only in the building where it is needed.
It should belong to an identifiable holder.
It should stop working after the shift ends.
Security should be able to cancel it immediately.
Every use should leave an auditable record.
Replacing a master key with delegated authority is secure only if that authority behaves like the bounded badge rather than a copy of the master key.
Common ERC-7715 misconceptions
ERC-7715 is just another wallet connect standard
No. It concerns execution permissions that allow a DApp-associated account to act on the user's behalf under granted conditions.
Nothing leaves my wallet when I approve, so the request is safe
No. The permission can authorize future execution rather than an immediate transfer.
Disconnecting the website removes the permission
Do not assume this. Persistent execution authority and browser connection state are different concepts.
Expiry and revocation are the same
No. Expiry ends permission automatically at a specified time. Revocation intentionally terminates it before then.
A permission that expired can never appear in wallet history
Permission storage and display are wallet implementation details. An expired object can remain visible as historical or granted-but-invalid state even though it should no longer execute.
If I protect my seed phrase, delegated permission cannot hurt me
Incorrect. A valid delegated account can act without stealing the wallet's root private key if the approved scope permits the action.
Hardware wallets automatically make delegated permissions safe
No. Hardware devices protect signing keys. They do not automatically make an overbroad permission narrow after the user authorizes it.
ERC-7715 replaces ERC-20 allowances
No. They operate at different authorization layers and can coexist.
When an execution permission expires, every approval created under it disappears
No. Persistent approvals or protocol positions created by earlier transactions can survive independently.
The DApp's permission request is exactly what the wallet grants
Not necessarily. The ERC explicitly permits the returned permission to differ from the requested values, so the effective granted response matters.
Permission context is a human-readable permission description
No. The standard intentionally treats the context as opaque and flexible for different permission schemes.
Anyone holding the context can necessarily use the permission
The permission is associated with the relevant account and enforcement mechanism. Actual redemption rights depend on the delegation implementation, including who is authorized to redeem it.
Simulation guarantees execution
No. State can change between simulation and execution. A permission can be revoked or expire before inclusion.
If a transaction fails, nothing persistent can remain
If the entire relevant operation is atomic and reverts, its state changes revert. But a broader workflow can span separate transactions, allowing an earlier approval or action to succeed before a later transaction fails.
A broad permission is acceptable if the DApp promises not to misuse it
That relies on application honesty and infrastructure security instead of enforceable least privilege. The safer design is to restrict what the DApp can do even when it is compromised.
A practical verification framework
Users do not need to understand every delegation-manager implementation to apply a strong verification process.
Use six questions.
Then verify what happened after use.
Did the transaction call the expected contract?
Did the expected amount move?
Were new token approvals created?
Did a bridge, vault, lending market, or router receive assets?
Is the permission still active?
Does it still need to be active?
This workflow does not eliminate implementation risk, but it keeps the user focused on actual authority rather than branding or wallet prompt familiarity.
Conclusion: ERC-7715 makes wallet convenience depend on permission quality
ERC-7715 wallet permissions address a real usability limitation in Ethereum wallets.
Requiring a user to approve every interaction is secure in one sense but incompatible with many modern applications.
Subscriptions need to run when the user is offline.
Automated strategies need to respond to conditions without waiting for a manual signature.
Games need fluid interactions.
Agents need constrained authority.
Persistent sessions need a way to perform approved actions without repeatedly interrupting the user.
The right answer is not to give applications the wallet's unrestricted master key.
It is to delegate less authority.
ERC-7715 creates a standardized request layer for that direction.
The permission request establishes the chain, the account granting authority, the DApp session account receiving it, the permission type, permission-specific data, and optional rules.
An expiry rule can place a hard time boundary around the authorization.
The wallet decides whether it supports and grants the request.
The effective permission response can differ from what the DApp originally requested.
The response includes a permission context and delegation manager used for later redemption through the ERC-7710 model.
The DApp-associated account can then exercise valid authority without asking the user to sign every transaction individually.
That convenience is exactly why permission review matters.
The user must think about a future action surface rather than one immediate transaction.
How much can move?
Which assets can move?
Which contracts can be called?
Can arbitrary calldata be executed?
Can approvals be created?
Can transactions be batched?
Which network is affected?
Which account is exposed?
Which session account controls the delegated capability?
How long does that authority survive?
Can it be revoked independently of the DApp?
Those are now wallet-security questions.
Expiry should be treated as a primary risk control rather than a decorative field.
A permission that naturally expires shortly after the required task gives an attacker less opportunity to exploit forgotten authority.
Long-running automation can still be supported, but broader time should normally be balanced by narrower value, asset, target, frequency, or action restrictions.
Revocation must remain separate from website disconnection.
A user should be able to terminate authority from the wallet itself even when the original application is unavailable or compromised.
The wallet should make persistent permissions visible in one management surface rather than expecting users to remember which DApps may still possess reusable capabilities.
The session account also deserves more attention than most users will initially give it.
It is a delegated credential.
A compromised session account does not need the root private key if it already possesses authority granted by the root account.
This is why least privilege is not only about protecting seed phrases.
It is about ensuring every secondary credential can do as little as possible.
Hardware-protected root keys remain valuable because they reduce exposure of the highest-authority credential.
They do not eliminate the need to manage subordinate authority carefully.
ERC-7715 also does not replace older authorization mechanisms.
A delegated execution can create an ERC-20 allowance.
It can interact with Permit2.
It can enter a lending position.
It can deposit into a vault.
It can potentially interact with contracts that create additional durable state.
When the execution permission expires or is revoked, those independent consequences do not necessarily disappear.
That is why post-execution verification matters.
TokenToolHub's Transaction Decoder can help inspect what a delegated execution actually called and which token movements or approval changes resulted.
The approval and allowance guide provides the next layer when the question becomes whether a transaction created lasting ERC-20 spender authority.
For Permit2-specific authorization, use the Permit2 security guide.
And when suspicious delegated execution may have affected more than one transaction, the Wallet Risk Scanner can widen the review to the wallet's broader activity and counterparty exposure.
The standard's security principle can be reduced to one rule:
That is the difference between programmable wallet security and simply moving unlimited trust from a private key into another credential.
ERC-7715 has the potential to make wallet interactions dramatically smoother.
Its success should therefore be judged not only by how many signing prompts it removes, but by whether users can still understand, constrain, inspect, expire, and revoke the authority that replaces those prompts.
Verify the authority and the transaction separately
A delegated permission tells you what an application may be able to do. The resulting blockchain transactions tell you what it actually did. Review both layers, then check whether any persistent token approvals or wallet permissions remain after the automation finishes.
FAQs
What is ERC-7715?
ERC-7715 is a draft Ethereum Standards Track ERC defining wallet JSON-RPC methods for requesting execution permissions that allow DApps to execute transactions on a user's behalf under wallet-enforced conditions.
Is ERC-7715 finalized?
No. The official Ethereum Improvement Proposal lists ERC-7715 as Draft as of September 2026, so developers should expect implementation details and ecosystem conventions to continue evolving.
What problem does ERC-7715 solve?
It reduces the need for users to approve every individual transaction and enables use cases such as subscriptions, automated trading, persistent sessions, passive strategies and other actions that may execute while the user is offline.
Is ERC-7715 the same as connecting a wallet?
No. A normal wallet connection generally allows an application to identify an account and request actions. An execution permission can grant reusable authority to execute specified actions on the user's behalf.
Is ERC-7715 an ERC-20 approval?
No. ERC-20 allowances exist in token contracts and authorize a spender under token allowance rules. ERC-7715 operates at the wallet execution-permission layer, although delegated executions can themselves interact with token approvals.
Can ERC-7715 permissions be used while my wallet is disconnected?
The proposal is specifically intended to support transactions on a user's behalf without requiring an active wallet connection, subject to the granted permission and its implementation.
Can a DApp execute transactions while I am offline?
Yes, where the wallet has granted appropriate execution permission and the DApp-associated account can redeem that authority under the approved conditions.
What is wallet_requestExecutionPermissions?
It is the ERC-7715 JSON-RPC method a DApp uses to request one or more execution permissions from a wallet.
What does chainId do in ERC-7715?
It identifies the EIP-155 network to which a permission request applies, helping scope authority to the intended blockchain environment.
What is the from field?
The optional from field identifies the account targeted by the permission request. If it is omitted, the wallet can allow the user to choose the account that grants permission.
What is the to field?
The to field identifies the DApp session account associated with the permission. Under the ERC-7715 and ERC-7710 flow, this account can later redeem the granted authority.
Why is the DApp session account important?
It is part of the authorization boundary. If a session account is compromised while a permission remains valid, an attacker may be able to exercise whatever authority that permission grants.
Can the to account be an EOA?
The ERC-7715 and ERC-7710 flow is designed so the permission recipient can use compatible account types, including EOAs or contract accounts, subject to the implementation.
What is a permission type?
A permission type defines the behavior a DApp-associated account is allowed to perform. ERC-7715 does not provide one exhaustive universal list and expects additional permission types to be specified through compatible standards.
What does permission.data contain?
It contains permission-specific parameters defined by the relevant permission type, such as amounts, assets, targets or other authorization details.
What does isAdjustmentAllowed mean?
It indicates whether the wallet may adjust the requested permission terms when forming an authority the user can approve, according to the permission type and wallet implementation.
Can the permission returned by my wallet differ from what the DApp requested?
Yes. ERC-7715 explicitly states that values in the returned permission response are not guaranteed to be equivalent to the original request, so the effective granted permission must be reviewed.
What are ERC-7715 rules?
Rules apply additional conditions that the permission recipient must satisfy when exercising delegated authority. The standard defines an expiry rule and allows other rule types to be developed.
What is the ERC-7715 expiry rule?
It contains a Unix timestamp after which the permission becomes invalid.
Should every ERC-7715 permission expire?
The right lifetime depends on the workflow, but the standard's security guidance recommends reasonable expiration times. Shorter permissions reduce risk from forgotten or later-compromised authority.
What is the difference between expiry and revocation?
Expiry automatically invalidates permission after a specified time. Revocation deliberately ends permission before its scheduled expiration.
How do I revoke an ERC-7715 permission?
The proposal defines wallet_revokeExecutionPermission, which identifies the relevant permission using its permission context. Actual wallet interfaces should provide an understandable user-facing revocation control.
Does disconnecting a DApp revoke ERC-7715 permission?
Users should not assume it does. Browser connection state and reusable execution authority are distinct. Use the wallet's explicit permission-management or revocation interface.
Does closing my browser revoke an execution permission?
Not necessarily. ERC-7715 is designed to support actions without an active wallet connection, so a granted permission can intentionally outlive the browser session.
What is permissionsContext?
It is an opaque context returned with the permission and used in the delegation framework for permission redemption and revocation. Its internal encoding can vary between implementations.
Should users decode permissionsContext manually?
No. The context is intentionally opaque. Wallets should retain and display a human-readable representation of the effective permission instead of expecting users to interpret raw bytes.
What is the delegation manager?
The delegation manager is the contract component that validates delegation authority and coordinates execution of permitted actions through the user's account architecture under ERC-7710.
Why does the delegation manager matter for security?
It enforces whether a requested action is actually authorized. Bugs, unsafe upgrades or incorrect permission interpretation can therefore undermine the intended scope.
What are ERC-7715 dependencies?
The permission response can include factory and factoryData information for accounts that are not yet deployed but must be deployed before permission redemption can succeed.
Can undeployed smart accounts receive ERC-7715-related permissions?
The proposal includes dependency information specifically to support flows where required accounts have not yet been deployed, subject to the wallet and implementation.
How does a DApp use an ERC-7715 permission?
The DApp-associated account uses the permission context through the delegation manager and ERC-7710 execution interface to attempt an action authorized by the permission.
Does the user sign every delegated transaction?
The purpose of the permission model is to allow authorized execution without requiring the user to approve every individual transaction while the permission remains valid.
Should a DApp simulate permission redemption?
Yes. ERC-7710 recommends simulation before execution because permissions can expire, be revoked or become invalid due to state changes.
Does successful simulation guarantee execution?
No. Permission or blockchain state can change after simulation and before the transaction is executed.
What happens if the user revokes permission after simulation?
A correct implementation should reject the later execution because the authorization is no longer valid.
Can a permission expire while a transaction is pending?
Yes. If the permission is valid when submitted but invalid by the time execution is evaluated, correct expiry enforcement can cause the transaction to fail.
Can ERC-7715 permissions be replayed?
Permissions are intentionally reusable where their terms allow. Security therefore depends on correct enforcement of chain, redeemer, action, amount, lifetime, usage and other restrictions defined by the permission implementation.
Does chainId prevent every replay problem?
No. Chain binding is one important scope control. Implementations must also enforce the correct permission context, redeemer, actions and other restrictions.
Can a permission be limited to one execution?
A permission type or rule system can potentially support such semantics, but the one-time restriction must be enforced by the actual permission implementation rather than relying on the DApp's promise not to reuse authority.
Can ERC-7715 authorize arbitrary contract calls?
The core ERC is extensible and does not require every permission to have the same scope. Whether arbitrary calls are possible depends on the permission type and wallet implementation. Broad arbitrary-call permissions should receive strong warnings.
Can a delegated transaction create an ERC-20 allowance?
It can if the granted execution scope permits the relevant token approval call. Any resulting ERC-20 allowance becomes separate token-contract state.
Does revoking ERC-7715 remove token allowances created earlier?
Not automatically. ERC-20 allowances, Permit2 permissions and other downstream authorization can require separate review and revocation.
Can ERC-7715 permissions be dangerous even if my seed phrase is safe?
Yes. Delegated authority is intentionally usable without possessing the wallet's root private key, so compromise of an authorized session credential can still cause loss within the granted scope.
Does a hardware wallet prevent ERC-7715 abuse?
A hardware wallet can protect the root signing key, but it cannot make a permission safe after the user has approved overly broad delegated authority. Root-key security and permission security are separate layers.
What is permission phishing?
It is an attack in which a malicious or impersonated DApp tricks a user into granting reusable wallet authority that the attacker later exercises.
Why can permission phishing be harder to notice than a malicious transfer?
The permission grant itself may not transfer assets immediately. The harmful execution can occur later, making the initial approval appear less alarming.
What should a wallet show for ERC-7715?
At minimum, users should understand the granting account, chain, receiving session account, action scope, affected assets, value limits, permitted targets, duration, and revocation path.
What is least privilege for wallet permissions?
It means granting only the minimum assets, amounts, targets, actions and lifetime required for the user's chosen workflow.
Why is a long expiry dangerous?
It increases the time during which a forgotten DApp relationship or later-compromised session credential can exercise authority.
Can wallet upgrades affect existing permissions?
Potentially. If permission enforcement depends on upgradeable wallet modules or delegation infrastructure, upgrades must preserve or deliberately invalidate existing semantics safely.
What is a stale wallet permission?
It is persistent authority that is no longer needed but remains active. Forgotten permissions increase long-term attack surface.
How should wallets handle unused permissions?
Wallets can surface long-unused authority for review, show clear expiry information, and make one-click revocation easy.
How should I verify a delegated execution?
Inspect the transaction target, calldata, value, token transfers, nested calls, approvals and final balances rather than relying only on the DApp's success message.
What should I do after an automated task finishes?
If future delegated execution is no longer needed, revoke the permission and review whether the task created persistent token approvals or protocol positions that also need attention.
What should I do if I approved a suspicious ERC-7715 permission?
Identify and revoke the execution permission, inspect recent delegated transactions, review ERC-20 and Permit2 approvals, check wallet balances and protocol positions, and investigate the associated DApp session account and counterparties.
Does revoking permission undo previous transactions?
No. Transactions already finalized remain effective. Revocation is primarily a control against future use of the revoked authority.
What is the biggest ERC-7715 security risk?
The central risk is granting reusable authority that is broader or longer-lived than the intended task, especially when users do not understand that a DApp-associated account may exercise the permission later without another wallet prompt.
What is the simplest ERC-7715 safety rule?
Approve only the smallest authority needed for the shortest reasonable time, verify which account and chain are affected, and revoke the permission when the automation is no longer required.
References and further reading
These official Ethereum resources provide the standards and account-security context for execution permissions, delegation and programmable wallet infrastructure.
- ERC-7715: Request Permissions from Wallets
- ERC-7710: Smart Contract Delegation
- ERC-4337: Account Abstraction Using Alt Mempool
- ERC-7579: Minimal Modular Smart Accounts
- Ethereum Improvement Proposals and ERC Standards
- Ethereum.org: Account Abstraction
- Ethereum.org: Ethereum Security Roadmap
ERC-7715 and ERC-7710 remain draft proposals and can change before finalization. Wallets can also use different permission types, enforcement mechanisms, delegation managers, account architectures, upgrade models and user interfaces. Evaluate the exact implementation in use. This guide is educational security research and is not financial, legal, or software-audit advice.
