> For the complete documentation index, see [llms.txt](https://help.tokenpocket.pro/developer-en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tokenpocket.pro/developer-en/agentic-wallet/eip-7715-account-with-permissions.md).

# EIP-7715 Account with permissions

### What Is EIP-7715 <a href="#what-is-eip-7715" id="what-is-eip-7715"></a>

[EIP-7715](https://eips.ethereum.org/EIPS/eip-7715) defines a set of JSON-RPC methods that allow AI Agents / DApps to request **Execution Permissions** from a wallet. After the user grants authorization, the Agent / DApp can initiate on-chain operations on the user's behalf within defined limits.

### Use Cases <a href="#use-cases" id="use-cases"></a>

It addresses two typical problems:

1. **Poor UX for high-frequency interactions**: In scenarios such as gaming and subscriptions, users do not need to sign every individual operation.
2. **Offline / background execution**: After authorization, an Agent or DApp can execute automatically according to rules while the user is offline (e.g., recurring investments, limit orders, periodic payments).

### Basic Flow <a href="#basic-flow" id="basic-flow"></a>

* The DApp/Agent requests specific permissions from the user's wallet, such as spending 10 USDT per month as a subscription fee for a feature.
* The user reviews and signs, returning the corresponding permission content.
* The DApp/Agent can perform the corresponding on-chain operations based on the permission content, such as transferring 10 USDT from the user each month.

EIP-7715 works together with [EIP-7710](https://eips.ethereum.org/EIPS/eip-7710) (Delegation): after the wallet issues authorization, it returns `context` and `delegationManager`, and the authorization recipient (Session Account) calls `redeemDelegations` to perform the actual execution.

### Core Concepts <a href="#core-concepts" id="core-concepts"></a>

#### Permission <a href="#permission" id="permission"></a>

Describes the scope of actions that a **Session Account** (`to` address) may perform on behalf of the **user account** (`from` address).

```typescript
type BasePermission = {
  type: string; // permission type, e.g. erc20-token-periodic
  isAdjustmentAllowed: boolean; // whether the wallet lets the user adjust requested limits
  data: Record<string, unknown>; // type-specific parameters
};
```

#### Rule <a href="#rule" id="rule"></a>

Applies additional constraints to a permission. TokenPocket currently mainly supports the `expiry` rule (authorization expiration time).

```typescript
type ExpiryRule = {
  type: "expiry";
  data: { timestamp: number }; // Unix timestamp in seconds
};
```

The expiration time is passed via the `rules` array, not a top-level `expiry` field:

```typescript
rules: [{ type: "expiry", data: { timestamp: 1735689600 } }];
```

#### Session Account <a href="#session-account" id="session-account"></a>

* Corresponds to the **`to`** field in the request.
* Permissions are granted to this address; it (or its controlled Relayer) later calls `redeemDelegations`.
* Can be an EOA or a smart account

#### Key Fields in the Authorization Response <a href="#key-fields-in-the-authorization-response" id="key-fields-in-the-authorization-response"></a>

| Field               | Description                                                          |
| ------------------- | -------------------------------------------------------------------- |
| `context`           | Opaque permission context; must be passed when redeeming             |
| `delegationManager` | DelegationManager contract address                                   |
| `dependencies`      | Factory info for undeployed accounts; must be deployed before redeem |

### TokenPocket Support Overview <a href="#tokenpocket-support-overview" id="tokenpocket-support-overview"></a>

#### Supported Permission Types <a href="#supported-permission-types" id="supported-permission-types"></a>

| Type                    | Description                                     |
| ----------------------- | ----------------------------------------------- |
| `erc20-token-periodic`  | ERC-20 periodic allowance (resets each period)  |
| `native-token-periodic` | Native token periodic allowance                 |
| `erc20-token-stream`    | ERC-20 streaming allowance (linear accrual/sec) |
| `native-token-stream`   | Native token streaming allowance                |

#### Common Supported Chains <a href="#common-supported-chains" id="common-supported-chains"></a>

| Chain ID | hex      | Network          | Status      |
| -------- | -------- | ---------------- | ----------- |
| 56       | `0x38`   | BNB Chain        | online      |
| 1        | `0x1`    | Ethereum Mainnet | coming soon |
| 137      | `0x89`   | Polygon          | coming soon |
| 42161    | `0xa4b1` | Arbitrum One     | coming soon |
| 8453     | `0x2105` | Base             | coming soon |
| 10       | `0xa`    | Optimism         | coming soon |

The actual available chains are determined by the return value of `wallet_getSupportedExecutionPermissions`.

#### Supported Methods <a href="#supported-methods" id="supported-methods"></a>

```typescript
optionalMethods: [
  "wallet_requestExecutionPermissions",
  "wallet_getSupportedExecutionPermissions",
  "wallet_getGrantedExecutionPermissions",
];
```

### Security Recommendations <a href="#security-recommendations" id="security-recommendations"></a>

* Request only the minimum permissions and shortest validity period required for your use case.
* The private key corresponding to the `to` address must be securely managed by the DApp/Agent; do not expose it to unrelated parties.
* Clearly present the `justification` (authorization description) and spending limits to the user.
* In production, always call `wallet_getSupportedExecutionPermissions` before requesting permissions to probe wallet capabilities.