# [ERC7902] Wallet Call APIでアカウント抽象化向けの追加設定を受け渡す仕組みを理解しよう！

> ERC7902は、EIP5792のCapability機構を使って、アカウント抽象化で必要になる追加パラメータをdAppからウォレットへ渡すための提案です。

- URL: https://cardene.dev/articles/1b92b39d97ea7bf39730
- 公開日: 2026-05-09
- 更新日: 2026-05-09
- トピック: Blockchain
- タグ: smartcontract, ブロックチェーン, accountabstraction, erc

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、Wallet Call APIを拡張して、アカウント抽象化向けの追加設定をdAppとウォレットのあいだで受け渡せるようにする**ERC7902**についてまとめていきます！

:::message
以下にまとめられているものを解説しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-7902

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

https://twitter.com/cardene777

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

## 概要

**ERC7902**は、**EIP5792**のCapability機構を使って、アカウント抽象化で必要になる追加パラメータをdAppからウォレットへ渡すための提案です。

:::message
**EIP5792**については以下の記事を参考にしてください。
:::

[\[EIP5792\] 複数のオンチェーン呼び出しをバッチ送信するWallet Call APIの仕組みを理解しよう！](/articles/59d6b2ae4c64c1a6614d)

原文の副題は「EIP-5792 Capabilities allowing dApps and wallets to exchange all AA specific UserOp fields」です。
要するに、**UserOperation**を組み立てる時に必要なAA固有の値を、Wallet Call APIの拡張項目としてやり取りできるようにします。

**ERC4337**や**ERC7769**は、AAをどう動かし、bundlerへどう送るかを定義しています。
ただし、それだけではdAppが「このPaymaster設定を使ってほしい」「この時間帯だけ有効にしたい」「このnonceの枝を使いたい」といった細かい要求を、ウォレットへ標準的に伝えられません。

:::message
**ERC4337**については以下の記事を参考にしてください。
:::

[\[ERC4337\] プロトコルの変更をせずにAAを実装する仕組みを理解しよう！](/articles/8c97ca7c93c4557ebfc2)

:::message
**ERC7769**については以下の記事を参考にしてください。
:::

[\[ERC7769\] ERC4337に準拠したコントラクトアカウントのためのJSON-RPC APIを理解しよう！](/articles/0b6d631ed4363ba67d2a)

**ERC7902**は、この隙間を埋める規格です。
Capabilityの識別子と入力形式を共通化しておくことで、AA対応dAppはウォレットごとの独自拡張を前提にせず、必要な追加設定だけをWallet Call APIへ渡せるようになります。

2026年5月4日時点で、**ERC7902**のステータスは `Draft` です。
まだ確定規格ではないため、今後フィールド名や運用の細部が変わる可能性があります。

![ERC7902 の位置づけ](/images/qiita-6d91efca-ecac-443e-9e0f-7fbff07895ee.webp)

## 動機

#### 既存AA規格の役割分担

AAまわりの規格は、すでにいくつかの層に分かれています。

| 規格 | 役割 |
|------|------|
| **ERC4337** | スマートアカウントと**UserOperation**の基本モデルを定義します。 |
| **ERC7769** | **UserOperation**をbundlerへ送るJSON-RPCを定義します。 |
| **EIP5792** | dAppとウォレットのあいだで複数呼び出しを送るWallet Call APIを定義します。 |

この分担自体は自然です。
一方で、AAを理解したdAppがウォレットへ渡したい情報は、これよりもう少し細かいところにあります。

#### 未標準化のAA入力

原文で挙げられている論点は大きく5つです。

1. **EIP7702の委譲先を指定したい**
    どのEOAに、どの実装を委譲させるかをdAppが制御したい場合があります。
2. **固定的なPaymaster設定を渡したい**
    dApp側で `paymaster` と `paymasterData` を解決済みなら、その値をそのまま使ってほしい場合があります。
3. **有効時間を絞りたい**
    署名後すぐ有効にせず、ある時刻以降だけ有効にしたい、ある時刻までしか有効にしたくない、という要求があります。
4. **半抽象化nonceの枝を指定したい**
    多次元nonceを使うアカウントでは、どの枝の連番を使うかをdAppが選びたい場合があります。
5. **AA特有のガス値を上書きしたい**
    開発や特定プロトコル向けの実装では、ウォレットの自動見積もりではなくdApp側の値を使いたい場合があります。

これらは、**UserOperation**の世界では重要な値です。
しかし、dAppとウォレットの境界でどう渡すかが標準化されていないと、ウォレットごとの独自仕様に依存することになります。

#### **EIP5792**のCapability拡張

**EIP5792**は、もともとWallet Call APIをCapabilityで拡張できるように設計されています。
**ERC7902**はその拡張点を使い、AA向けの追加項目を「どの名前で」「どの型で」渡すかをそろえます。

この構成により、AA対応dAppは `wallet_getCapabilities` で対応状況を問い合わせ、`wallet_sendCalls` に必要なCapabilityだけを載せる、という流れで実装できます。
ウォレット側も、どの追加設定を受け付けるかを機械的に表明しやすくなります。

![5つのCapabilityの分類](/images/qiita-b60f3c5a-a3b0-4a23-8db3-b5c6b4f5f507.webp)

## 仕様

原文の仕様は短く、主眼はCapabilityの定義です。
最初に置かれている前提は1つだけで、**EIP5792**文脈で行うAAの操作は、**単一チェーン上で、かつアトミックに**実行しなければなりません。

#### 全体の前提

この制約があるのは、複数チェーンをまたぐ処理や、部分成功を前提にした処理をここで扱わないためです。
**ERC7902**は、Wallet Call APIの1回の呼び出しの中でAA用の追加設定を渡す規格なので、まず「同じチェーンでまとめて扱う」ことを前提にしています。

![単一チェーン前提と対象外](/images/qiita-8a58ea5e-957d-4b07-9559-94558d8064b1.webp)

#### `eip7702Auth`

`eip7702Auth` は、ウォレットに**EIP7702**の認可情報を作らせるためのCapabilityです。

:::message
**EIP7702**については以下の記事を参考にしてください。
:::

[\[EIP7702\] EOAをコントラクトアカウントに変換する仕組みを理解しよう！](/articles/13a828c97786aab953e4)

- **引数**

```ts
{
  account: `0x${string}`;
  delegation: `0x${string}`;
}
```

ウォレットがこのCapabilityに対応している場合、`account` のEOAへ `delegation` のコードを設定する**EIP7702**互換トランザクションを生成しなければなりません。
つまり、dAppは「どのEOAを」「どのアカウント実装へ切り替えたいか」を指定でき、ウォレットはその意図に沿って認可タプルを組み立てます。

![eip7702Auth の流れ](/images/qiita-7e6fe1f2-6b3a-48c9-9dda-a8eaac8d9ba4.webp)

#### `staticPaymasterConfiguration`

`staticPaymasterConfiguration` は、ウォレット側で追加の解決処理をしなくても使える、固定的なPaymaster設定を渡すCapabilityです。

- **引数**

```ts
{
  paymaster: string;
  paymasterData: string;
  paymasterValidationGasLimit: `0x${string}`;
  paymasterPostOpGasLimit: `0x${string}`;
}
```

ここで重要なのは、原文が「Wallet Application to resolve any dynamic configuration」を不要にする用途だと書いている点です。
つまり、ウォレットが都度Webサービスへ問い合わせて設定を取りにいくケースではなく、dApp側が先に解決済みの固定値を渡すケースを想定しています。

動的なPaymaster解決は、この規格ではなく**ERC7677**の守備範囲です。

![固定設定と動的設定の違い](/images/qiita-0aea8975-4c89-4e73-ab87-b61dc30e6751.webp)

:::message
**ERC7677**については以下の記事を参考にしてください。
:::

[\[ERC7677\] アプリが特定のPaymasterサービスと通信する仕組みを理解しよう！](/articles/0e7a75a5d98654b0f3d2)

#### `validityTimeRange`

`validityTimeRange` は、署名後にその操作が有効となる時間帯をdAppが明示するCapabilityです。

- **引数**

```ts
{
  validAfter: `0x${string}`;
  validUntil: `0x${string}`;
}
```

ウォレットは、この時間範囲が妥当かを確認し、人が読める形でユーザーへ提示しなければなりません。
さらに、スマートアカウント側も、この `validAfter` から `validUntil` までの範囲を、そのままトランザクションの有効期間として反映しなければなりません。

このCapabilityは、単に表示用の補足情報ではありません。
署名確認とオンチェーン実行の両方にまたがって守られる前提です。

![validityTimeRange の時間窓](/images/qiita-4990623b-8735-49b2-bde6-ff6795d2c7e2.webp)

#### `multiDimensionalNonce`

`multiDimensionalNonce` は、**ERC4337**で定義される半抽象化nonceの構成要素をdAppが指定するCapabilityです。

- **引数**

```ts
{
  nonceKey: `0x${string}`;
  nonceSequence: `0x${string}`;
}
```

原文では「semi-abstracted nonce as defined in ERC-4337」と書かれています。
つまり、単一の連番だけを渡すのではなく、「どの枝か」と「その枝の何番目か」を分けて伝える用途です。

多次元nonceをサポートするスマートアカウントでは、ウォレットは実際のオンチェーン実行時にこれらの値を使う必要があります。
これにより、dAppは用途別の枝を分けたり、並列実行に向いたnonce管理をしたりしやすくなります。

![multiDimensionalNonce の枝構造](/images/qiita-c08eaab9-7382-4fc0-bf2f-21d4d953824d.webp)

#### `accountAbstractionGasParamsOverride`

`accountAbstractionGasParamsOverride` は、AA特有のガス関連フィールドをdApp側で上書きするためのCapabilityです。

- **引数**

```ts
{
  preVerificationGas?: `0x${string}`;
  verificationGasLimit?: `0x${string}`;
  callGasLimit?: `0x${string}`;
  paymasterVerificationGasLimit?: `0x${string}`;
  paymasterPostOpGasLimit?: `0x${string}`;
  maxFeePerGas?: `0x${string}`;
  maxPriorityFeePerGas?: `0x${string}`;
}
```

原文で強調されているのは、このCapabilityがかなり低レイヤーだという点です。
特定プロトコルの特定バージョンに密結合した実装や、開発、デバッグでは有用になり得ますが、本番dAppではウォレットの高レイヤー機能に任せる方が一般的に望ましいとしています。

また、すべてのフィールドは任意です。
上書きしたい値だけを渡せます。

ウォレットは、dAppが上書き値を渡してきたことをユーザーへ警告し、それらの値を使う想定です。
さらに、設定どうしが衝突している場合、呼び出しを拒否してもよいとされています。

![ガス上書きの守備範囲](/images/qiita-24cc7a3b-98a2-427a-98d2-34ddf8b3e562.webp)

## 補足

#### 5つのCapabilityの役割分担

この提案の5つは、すべて「AAだから必要になる追加値」ですが、役割はかなり異なります。

| Capability | 解決したいこと |
|------------|----------------|
| `eip7702Auth` | EOAをどの実装へ委譲するかを決める。 |
| `staticPaymasterConfiguration` | どのPaymaster設定を使うかを固定値で渡す。 |
| `validityTimeRange` | いつ有効な操作かを制限する。 |
| `multiDimensionalNonce` | どのnonceの枝と連番を使うかを指定する。 |
| `accountAbstractionGasParamsOverride` | AA特有のガス値をdApp側で上書きする。 |

この表から分かるとおり、**ERC7902**は1つの大きな新機能を足す規格ではありません。
AAで必要になりやすい追加入力を、Capabilityごとに分解して整理する規格です。

#### **ERC7902**の対象外

この提案で標準化されるのは、dAppとウォレットの間で追加設定をどう渡すかです。
以下は別の層の話であり、この規格だけでは解決しません。

1. **bundlerとの低レイヤー通信**
    **UserOperation**をbundlerへ送るRPCの詳細は**ERC7769**の役割です。
2. **動的なPaymaster解決**
    Webサービス経由でPaymaster設定を受け取る流れは**ERC7677**の役割です。
3. **スマートアカウント実装そのもの**
    どの実装を採用するか、内部ロジックをどう書くかまでは決めません。

そのため、**ERC7902**はAA全体の中では「入力の受け渡し」を担う位置づけです。
低レイヤーの送信方式や、アカウント実装の正しさそのものを代替するわけではありません。

## セキュリティ

#### `eip7702Auth` の危険性

原文でも `This is by far the most sensitive capability in the document.` と書かれています。
誤ったCapabilityへ署名した時の損害に上限がなく、悪意ある `delegation` を許すと `account` の資産を丸ごと抜かれる恐れがあるためです。

ウォレットは、受け入れる `delegation` 実装を厳しく制限し、広く知られた公開監査済みの実装だけを許可しなければなりません。
dAppが渡してきたアドレスを、そのまま信じて署名させる実装では不十分です。

![eip7702Auth の危険箇所](/images/qiita-d04b48e7-371a-4671-9929-78a3c9d9633b.webp)

#### `staticPaymasterConfiguration` の攻撃面

原文では、誤った `paymaster` や `paymasterData` が攻撃ベクトルになり得ると述べています。
例として、Paymasterコントラクトが**ERC20**トークンの承認を保持している場合、それを悪用される余地があると書かれています。

:::message
**ERC20**については以下の記事を参考にしてください。
:::

[\[ERC20\] ERC20を1からわかりやすく解説](/articles/aeefe2d89dd5332c9f43)

つまり、ウォレットは通常のトランザクションの `calldata` を確認するのと同じように、このPaymaster設定が本当にユーザー意図と一致しているかを確認しなければなりません。

#### ガス上書きの運用リスク

`accountAbstractionGasParamsOverride` は、プロトコル実装の細部を知っているdAppには便利です。
一方で、値を誤ると実行失敗や過剰な手数料負担へつながります。

原文が「production dapps rely on higher-level features of Wallet Applications instead」と書いているのは、この危険があるためです。
普段はウォレットの見積もり機構に任せ、どうしても必要な場合だけ使う方が自然です。

## 最後に

今回は「**ERC7902**」についてまとめてきました。

**ERC7902**は、AAそのものを新しく定義する規格ではなく、**EIP5792**のCapabilityを使ってAA向けの追加設定を受け渡すための規格です。
`eip7702Auth`、`staticPaymasterConfiguration`、`validityTimeRange`、`multiDimensionalNonce`、`accountAbstractionGasParamsOverride` の5つを共通化することで、AA対応dAppとウォレットの相互運用性を高めようとしています。

一方で、`eip7702Auth` や `staticPaymasterConfiguration` は、そのまま強い攻撃面にもなります。
特にウォレット側は、どの実装へ委譲するか、どのPaymaster設定を受け入れるかを、通常の署名確認以上に慎重に扱う必要があります。

他でも色々記事を書いているのでぜひよろしければ読んでいってください！

https://amzn.asia/d/gxvJ0Pw

https://cardene.notion.site/EIP-2a03fa3ea33d43baa9ed82288f98d4a9

https://zenn.dev/heku

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://twitter.com/cardene777

https://cardene.substack.com/