ERC-7715: Requesting and Revoking Wallet Permissions for an Agent

A research agent needs to buy a few data calls while its user is away. Requiring a signature for every purchase interrupts the task; giving the agent a broadly usable key creates a different problem. The useful question is what limited authority the user can approve in advance, and how that authority is checked when the agent returns to spend.

Research boundary: official specifications and implementation documentation reviewed November 1, 2026. ERC-7715 is a draft. The example below is a design exercise; we did not connect a wallet, grant a permission or make a payment.

Start with the permission the task actually needs

Imagine a seven-day research job with a hypothetical allowance of 10 USDC per day. Before building the request, decide which account and chain hold the funds, which session account will act, and what the allowance covers. A transfer allowance alone may be too broad for a task that should only purchase from two approved providers.

ERC-7715 describes wallet-facing methods for requesting permissions, discovering supported permission and rule types, inspecting grants and revoking them. Support has to be discovered for the chosen wallet and network. There is no universal catalogue of spending rules that every implementation must offer.

That changes the integration order: first establish whether the wallet can express the task’s boundaries, then ask the user to approve them. If a required merchant restriction is unavailable, the product needs another enforced control or a narrower workflow, rather than silently dropping that requirement.

The approval and execution paths are separate

Conceptual permission flow, not an observed wallet test. Payment verification and delivery by the data provider are separate steps.

The wallet’s response can differ from the request when adjustment is allowed. Read the returned account, scope, rules and expiry before continuing. The response also carries permission context and execution information; treating the original request as the approved grant can produce incorrect budget displays or rejected calls.

Execution then uses the associated delegation machinery. ERC-7710 describes a delegation manager validating authority before invoking the delegating account. Its interface leaves the original permission-granting process to other mechanisms, including ERC-7715. In an integration review, identify the particular contracts and versions that enforce the limits, rather than stopping at the wallet confirmation screen.

What a real implementation adds

MetaMask’s request workflow demonstrates a session account and a periodic token permission. It asks the user to review the request through the wallet, then retains the returned grant for later redemption. This is evidence of a documented implementation path, not proof that every ERC-7715 wallet accepts the same permission types.

For a product team, a session account is another operational responsibility. Decide where its signing material lives, which service can use it, how jobs share or separate it, and who can stop it. Keeping the user’s main key out of the agent does not remove the need to protect the capability the agent receives.

Check the lifecycle, not just the first successful call

Situation in the research job	Acceptance question
The user lowers the proposed daily allowance	Does the application display and obey the returned grant?
Two workers try to spend the last available allowance	Where is cumulative usage enforced across concurrent requests?
A permission expires while a job is queued	Does the job stop and ask for a new decision rather than broaden authority?
The user revokes access	How does the application learn the result and prevent additional submissions?
A purchase was already submitted	Can the team distinguish pending execution from an already completed payment?

These are proposed checks, not reported results. A request error, a failed simulation and an onchain rejection need different handling. Do not hide all three behind a generic “payment failed” label.

MetaMask documents a user-facing Permissions screen for revocation. The delegation specification also warns that past grants may later become invalid and that state can change between simulation and execution. A useful application therefore keeps both a user-visible grant record and current execution checks. Revocation should not be presented as a refund button for a completed purchase.

When this is a useful building block

ERC-7715 is relevant when users want bounded recurring or background activity from an application that can use a supported wallet implementation. The strongest product experience makes the purpose, exposure and stop control understandable before approval, and explains a refusal without asking for unlimited access as the default repair.

For our hypothetical data buyer, the next design decision is how a permitted wallet action maps to a particular invoice and delivered resource. Continue with spending-limit design, payment idempotency and the ERC-7715 reference.