x402-erc7710

# x402 + ERC-7710

Use this skill when a user wants a payment or subscription demo where an agent pays for HTTP resources through x402 and spends only within a bounded delegated permission.

## Core Model

- x402 is the per-request payment rail. A protected resource can respond with HTTP `402 Payment Required`, payment requirements, and a retry path where the client submits a signed payment payload. A facilitator can verify and settle the payment before the server returns the resource.
- ERC-7710 is the capability redemption interface. It standardizes how a delegation manager validates permission context and executes delegated actions on behalf of a delegator.
- ERC-7715 is the wallet permission request layer that can be used to obtain scoped permissions for ERC-7710-style delegation.

Use x402 for "pay now for this HTTP request." Use ERC-7710/7715 for "this agent may keep paying under these constraints."

## Discovery-First Boundary

When the user has only asked to use or inspect a paid HTTP service, stay in discovery mode:

1. Identify the relevant endpoint or resource.
2. Confirm whether it returns `402 Payment Required`.
3. Summarize the advertised x402 requirements: network, token, amount, payee, route, and `extra.assetTransferMethod` when present.
4. State that no paid request has been made.
5. Ask whether the user wants to set up bounded payment authority.

Do not draft a subscription, mandate, cadence, schedule, spend cap, expiration, or wallet permission until the user asks for setup or confirms they want to continue. Do not infer "daily", "weekly", or "recurring" authority from a product objective alone; wait for the user to approve delegation design.

Good discovery response shape:

```text
I found the paid endpoint and its x402 requirements.

- Endpoint: GET /path
- Network: ...
- Token: ...
- Price: ...
- Payee: ...

I have not made a paid request. Do you want me to help set up bounded payment authority for this task?
```

## Trust Objection Mode

When the user objects to trusting the agent with money, keep the options distinct:

- **Basic:** an agent-controlled funded wallet. This is not a scoped x402/ERC-7710 permission unless another component enforces it. The main limit is the wallet balance.
- **Guarded:** a user-approved smart-account or wallet permission that limits service, route, token, payee, amount, budget period, request count, and expiry.
- **Adjudicated:** guarded permission plus signed intent/receipt evidence and a review path that can continue, constrain, or revoke future use.

Do not assign exact route, price, cadence, or expiry values to the Basic option. Those constraints belong in Guarded or Adjudicated setup after the user chooses that path.

## Adjudicated Setup Mode

When the user selects adjudicated authority, proceed to setup instead of drafting a final mandate artifact immediately.

The right response is operational:

1. confirm adjudicated mode;
2. state that setup may take a while;
3. list the steps to create an agent session key, prepare the bounded wallet permission request, open user wallet approval, store the permission artifact, verify the x402 requirements, configure signed evidence, and prepare the review path;
4. ask the user to approve the guarded wallet permission in their wallet UI;
5. wait for the user's approval message.

Do not ask for arbitrary expiration, schedule, or spend-cap choices in this beat unless the previous conversation lacks enough facts to create a safe testnet permission request. Do not claim the permission is ready before the user approves it.

## Subscription Pattern

For subscriptions, do not make x402 stateful. Keep x402 as the request payment protocol and put recurrence in the delegated spend policy.

Recommended policy fields:

```ts
type AgentSpendPolicy = {
  delegator: `0x${string}`;
  delegate: `0x${string}`;
  token: `0x${string}`;
  allowedPayTo: `0x${string}`;
  allowedResourcePattern: string;
  maxPerRequest: bigint;
  maxPerPeriod: bigint;
  periodSeconds: number;
  validAfter: number;
  validUntil: number;
  chainId: number;
  revocable: boolean;
};
```

Execution flow:

1. User grants a scoped permission through wallet UX, ideally ERC-7715 when available.
2. The returned permission context is stored by the agent or subscription manager.
3. Agent requests an x402-protected endpoint.
4. Server returns payment requirements.
5. Agent verifies requirements against the policy: network, token, amount, merchant, route, expiry, and remaining budget.
6. Agent redeems the ERC-7710 delegation or otherwise executes through the user's smart account to produce the payment authorization.
7. Agent retries the HTTP request with the x402 payment payload.
8. Server or facilitator verifies and settles payment.
9. Subscription manager records spend and receipt for audit, revocation, and disputes.
10. For supervised wallets, a reporter contract or watcher submits spend snapshots to GenLayer on the review cadence.

## Default Demo

Build **Agent Research Pass** unless the user asks otherwise:

- Resource: `/api/evidence/report`.
- Price: 0.05 USDC per report over x402.
- Delegation: agent can spend up to 5 USDC per week, max 0.25 USDC per request, only to the provider wallet, only on Base Sepolia or another agreed testnet, expiring in seven days.
- Result: the provider returns a signed evidence report with sources and timestamp.
- Dispute: if the report is missing, malformed, late, or source-incompatible, route the receipt and report to Internet Court, Arkhai, or GenLayer for refund/release.

## Browser Lab Pattern

When building an exploratory dashboard, use this shape:

- The user connects their wallet on Base Sepolia and requests ERC-7715 execution permissions.
- The page generates a real agent EOA for the demo and exports a JSON package containing the agent private key, ERC-7710 permission context, permission manager, x402 policy, and GenLayer control metadata.
- Keep the first asset to Base Sepolia USDC unless the user