# [ERC7802] クロスチェーンブリッジでトークンをmint・burnするための標準インターフェースを理解しよう！

> 今回は「ERC7802によるクロスチェーントークンインターフェースの標準化」についてまとめてきました！いかがだったでしょうか？

- URL: https://cardene.dev/articles/f3781e115e73c6289633
- 公開日: 2026-02-05
- 更新日: 2026-02-05
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、クロスチェーンでトークンを転送する時にブリッジコントラクトが統一された方法でトークンを`mint` と `burn`できるようにする最小限のインターフェースを提案している**ERC7802**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

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

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

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

### 概要

**ERC7802**とは、クロスチェーン転送時にブリッジコントラクトがトークンを`mint`および`burn`するための最小限のインターフェース`IERC7802`を定義する規格です。

この規格では、2つの関数（`crosschainMint`と`crosschainBurn`）と2つのイベント（`CrosschainMint`と`CrosschainBurn`）を定義しています。
これにより、オフチェーンの監視ツールがクロスチェーン活動を決定論的にインデックス化できるようになります。

**ERC7802**は**ERC20**トークンと完全に互換性があり、既存のトークンにも適用可能です。

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

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

非アップグレード可能なトークンの場合は、ロックボックス（Lockbox）メカニズムを使用して移行できます。

### 動機

この提案が生まれた背景には以下のような課題がありました。

#### カノニカルブリッジの現状

すべてのロールアップと複数の重要なサイドチェーンは、ネットワークのコアアーキテクチャの一部としてセキュリティを組み込んだカノニカルブリッジを実装しています。
これらのブリッジはオリジナルトークンに対する`mint` と `burn`権限を持っていません。

:::message
**カノニカルブリッジ**とは、ロールアップやサイドチェーンが公式に提供する標準ブリッジのことです。
ネットワークのセキュリティモデルに直接組み込まれており、サードパーティのブリッジとは異なり、プロトコルレベルで信頼されています。
:::

そのため、通常はネイティブチェーンで流動性をロック（またはアンロック）し、別のチェーンでラップドトークン（Wrapped Token）を`mint`（または`burn`）するという方式を採用しています。

:::message
**ラップドトークン**とは、元のトークンを1対1で表現するために別のチェーンで発行されるトークンです。
例えば、EthereumのUSDCをOptimismにブリッジすると、Optimism上では「Bridged USDC」としてラップドトークンが発行されます。
元のUSDCとは異なるコントラクトアドレスを持ち、厳密には同一のトークンではありません。
:::

`mint` と `burn`が使用される理由は、ネイティブトークンがそのチェーンに存在しないため、新しいトークン表現を作成する必要があるからです。

#### インターフェースの断片化

各ブリッジが非ネイティブチェーンでの`mint` と `burn`に異なるインターフェースを実装しているという問題があります。
このインターフェースの断片化は、チェーン間のクロスチェーン通信において大きな問題となっています。

| 問題点 | 影響 |
|--------|------|
| 関数名の不統一 | トークンコントラクトが特定のブリッジに依存 |
| パラメータ形式の違い | 後から別のブリッジを追加することが困難 |
| イベント形式の不一致 | オフチェーンツールの追跡が複雑化 |

#### 過去の標準化の試み

過去にもトークンブリッジングインターフェースを標準化する試みがありました。
しかし、サードパーティプロバイダーも独自のクロスチェーントークンフレームワークを開発しています。

各フレームワークはレート制限や手数料スイッチなどの機能を定義し、独自の`mint` と `burn`バージョンを実装しています。
その結果、命名規則や構造に一貫性がなく、インターフェースは高度に特化したものになっています。

#### ERC7802による解決

**ERC7802**は、ほとんどの標準で使用されている最も関連性が高く最小限のアクションセットを提案しています。
これらのアクションはガバナンスやオーナーの参加を必要としません（例えばレート制限の設定とは異なります）。

| 解決策 | 効果 |
|--------|------|
| `mint` と `burn`の標準化 | 複数のブリッジと互換性のあるトークン発行が可能 |
| 標準化されたイベント | インデクサー、分析ツール、監査ツールが一貫した方法で追跡可能 |
| 最小限のインターフェース | 拡張機能の基盤として機能 |

### 仕様

#### インターフェース定義

`IERC7802`インターフェースの完全な定義は以下です。

```javascript
interface IERC7802 {
    /// @notice クロスチェーンmintが完了した時に発行されるイベント
    /// @param _to トークンを受け取るアドレス
    /// @param _amount mintされるトークン量
    /// @param _sender mint操作を開始したブリッジコントラクトのアドレス
    event CrosschainMint(address indexed _to, uint256 _amount, address indexed _sender);

    /// @notice クロスチェーンburnが完了した時に発行されるイベント
    /// @param _from トークンがburnされるアドレス
    /// @param _amount burnされるトークン量
    /// @param _sender burn操作を開始したブリッジコントラクトのアドレス
    event CrosschainBurn(address indexed _from, uint256 _amount, address indexed _sender);

    /// @notice クロスチェーン転送でトークンをmintするためにブリッジが呼び出す関数
    /// @param _account トークンを受け取るアドレス
    /// @param _amount mintするトークン量
    function crosschainMint(address _account, uint256 _amount) external;

    /// @notice クロスチェーン転送でトークンをburnするためにブリッジが呼び出す関数
    /// @param _account トークンがburnされるアドレス
    /// @param _amount burnするトークン量
    function crosschainBurn(address _account, uint256 _amount) external;
}
```

このインターフェースは、クロスチェーン転送に必要な最小限の機能のみを定義しています。
ブリッジ固有のロジックはブリッジコントラクト側に実装され、トークンコントラクトはシンプルに保たれます。

#### インターフェースID

**ERC165**に準拠したインターフェースIDは`0x33331994`です。
このIDは、2つの関数セレクタのXOR演算によって計算されます。

```
crosschainMint(address,uint256) XOR crosschainBurn(address,uint256) = 0x33331994
```

トークンコントラクトは`supportsInterface`関数でこのIDを返すことで、**ERC7802**への対応を示すことができます。

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

[\[ERC165\] コントラクトが特定のインターフェースをサポートしているか確認する仕組みを理解しよう！](/articles/541184977a5cba51b759)

#### 関数

##### `crosschainMint`

```javascript
function crosschainMint(address _account, uint256 _amount) external;
```

ブリッジコントラクトがクロスチェーン転送時にトークンを`mint`するためのエントリーポイントです。

この関数が呼び出されると、指定されたアドレスに指定された量のトークンが`mint`されます。
実装では、標準的な**ERC20**の`Transfer`イベントを`address(0)`から発行する必要があります。
また、`CrosschainMint`イベントも発行する必要があります。

| パラメータ | 型 | 説明 |
|-----------|-----|------|
| `_account` | address | トークンを受け取るアドレス |
| `_amount` | uint256 | `mint`するトークン量 |

---

##### `crosschainBurn`

```javascript
function crosschainBurn(address _account, uint256 _amount) external;
```

ブリッジコントラクトがクロスチェーン転送時にトークンを`burn`するためのエントリーポイントです。

この関数が呼び出されると、指定されたアドレスから指定された量のトークンが`burn`されます。
**ERC5679**に従い、`Transfer`イベントを`address(0)`へ発行することが推奨されます。
また、`CrosschainBurn`イベントも発行する必要があります。

| パラメータ | 型 | 説明 |
|-----------|-----|------|
| `_account` | address | トークンが`burn`されるアドレス |
| `_amount` | uint256 | `burn`するトークン量 |

#### イベント

##### `CrosschainMint`

```javascript
event CrosschainMint(address indexed _to, uint256 _amount, address indexed _sender);
```

クロスチェーン`mint`操作が成功した時に発行されるイベントです。

このイベントにより、オフチェーンのインデクサーや分析ツールがクロスチェーンでの`mint`操作を追跡できます。
`_sender`パラメータにより、どのブリッジが`mint`操作を実行したかを特定できます。

| パラメータ | 型 | indexed | 説明 |
|-----------|-----|---------|------|
| `_to` | address | yes | トークンを受け取るアドレス |
| `_amount` | uint256 | no | `mint`されたトークン量 |
| `_sender` | address | yes | `mint`操作を実行したブリッジコントラクト |

---

##### `CrosschainBurn`

```javascript
event CrosschainBurn(address indexed _from, uint256 _amount, address indexed _sender);
```

クロスチェーン`burn`操作が成功した時に発行されるイベントです。

このイベントにより、オフチェーンのインデクサーや分析ツールがクロスチェーンでの`burn`操作を追跡できます。
`_sender`パラメータにより、どのブリッジが`burn`操作を実行したかを特定できます。

| パラメータ | 型 | indexed | 説明 |
|-----------|-----|---------|------|
| `_from` | address | yes | トークンが`burn`されたアドレス |
| `_amount` | uint256 | no | `burn`されたトークン量 |
| `_sender` | address | yes | `burn`操作を実行したブリッジコントラクト |

### 補足

#### 設計哲学

**ERC7802**の設計における核心的な決定事項は「ブリッジ非依存性」と「拡張性」です。

##### ブリッジ非依存性

このインターフェースは、トークンではなくブリッジがクロスチェーンアクションを処理するロジックを含むように設計されています。
この関心の分離を維持することで、トークンコントラクトはシンプルに保たれ、攻撃対象面（Attack Surface）が削減され、監査やアップグレードが容易になります。

提案されたインターフェースを実装することで、トークンはさまざまなブリッジ設計でサポートできるようになります。

| ブリッジタイプ | 動作 |
|--------------|------|
| Lock/Unlockブリッジ | 従来通り動作可能、トークン変更不要 |
| `burn` と `mint`ブリッジ | 汎用的で最小限のインターフェースを使用可能、ブリッジ固有の表現が不要 |

##### 拡張性

この最小限のインターフェースは、他の標準を構築するための基盤レイヤーとして機能します。
トークン発行者やブリッジコントラクトは、コアインターフェースを変更することなく、`mint` と `burn`制限、クロスチェーン転送手数料などの機能を追加できます。

このインターフェースは意図的に中立であり、以下の条件を課していません。

| 項目 | 説明 |
|------|------|
| アクセス制御 | `crosschainMint`と`crosschainBurn`を呼び出す権限者はトークン発行者が決定 |
| ゼロ額の呼び出し | ゼロ額での呼び出しを許可するかリバートするかはトークン発行者が決定 |

#### ローカルとクロスチェーンの`mint` と `burn`の分離

##### 異なるアクション

ローカルの`mint` と `burn`とクロスチェーンの`mint` と `burn`は根本的に異なります。

| 種類 | 特徴 |
|------|------|
| ローカル`mint` と `burn` | トークンの作成または破棄により総供給量が変化 |
| クロスチェーン`mint` と `burn` | 全チェーンの総流通量は一定を維持（チェーン間で転送されるため） |

クロスチェーン転送でトークンを`mint` と `burn`するエージェントは、トークンオーナーとは根本的に異なります。
したがって、2つのアクターが異なる権限を持つことは理にかなっています。
クロスチェーンアクションには異なるチェック、アクセス制御、ロジック（`mint` と `burn`制限など）を持たせることが合理的です。

##### 関心の分離

ローカルとクロスチェーンの`mint` と `burn`を同じ関数に統合すると、異なる運用ロジックが絡み合った複雑な実装になる可能性があります。
2つに分割することで、関心が分離され、コードベースがクリーンで保守しやすくなります。

この関心の分離は以下の点で特に重要です。

| 観点 | 効果 |
|------|------|
| アップグレード | アクセス制御、制限、ロジックの変更は、標準のローカル`mint` と `burn`実装を変更せずに、分離されたクロスチェーン関数のみに影響 |
| 異なるチェーンとの統合 | **ERC20**をクロスチェーン互換にするには、各チェーンに対応するアクセス制御で**ERC7802**拡張を実装するだけでよい |

例えば、Optimismと統合する場合、**ERC20**はOptimismブリッジにアクセス権を付与します。
Arbitrumと統合する場合、Arbitrumブリッジにアクセス権を付与します。
ローカルの`mint` と `burn`関数は変更されません。
クロスチェーン操作に専用の関数を使用することで、各チェーンのベース実装を変更する必要がなく、よりモジュラーなアプローチが可能になります。

##### 専用イベント

クロスチェーン専用のイベントを持つことにも同様の理由があります。
この分離により、インデクサー、分析ツール、監査者の作業が大幅に容易になります。
クロスチェーンアクティビティの直接的な追跡、異常の検出、ブリッジ操作の監視が可能になります。

クロスチェーンイベントとローカルイベントが区別できない場合、オフチェーンエージェントはそれらを区別するための複雑なロジックを実装する必要があり、エラーや非効率性の可能性が高まります。

#### ERC-165インターフェース

**ERC165**の組み込みは、インテグレーターに追加のセキュリティチェックを提供します。
`supportsInterface`メソッドでインターフェース識別子を提供することで、呼び出し元はトークンが`IERC7802`インターフェースに準拠していることをプログラム的に確認できます。

この検証により、トークンが`crosschainMint`と`crosschainBurn`の両方の関数をサポートしていることが保証されます。
一方の関数のみが実装されているような不完全な実装を防ぎます。
そのような不完全な実装は、ユーザーがトークンを`burn`してブリッジアウトしたが、戻ってきたときに`mint`できないといった問題につながり、クロスチェーンアクションの失敗を引き起こす可能性があります。

:::message alert
このチェックはトークンコントラクトが存在するチェーン上でのみローカルに実行できることに注意してください。
受信側チェーンのトークンも`IERC7802`インターフェースをサポートしているという固有の保証はありません。
インターフェースサポートのクロスチェーン一貫性を確保することは、ブリッジ実装の責任です。
:::

#### クロスチェーン転送フロー

クロスチェーン転送の典型的なフローは以下です。

```mermaid
sequenceDiagram
    participant User as ユーザー
    participant TokenA as トークン（チェーンA）
    participant BridgeA as ブリッジ（チェーンA）
    participant BridgeB as ブリッジ（チェーンB）
    participant TokenB as トークン（チェーンB）

    User->>BridgeA: 転送リクエスト
    BridgeA->>TokenA: crosschainBurn(user, amount)
    TokenA-->>BridgeA: CrosschainBurnイベント発行
    BridgeA->>BridgeB: クロスチェーンメッセージ
    BridgeB->>TokenB: crosschainMint(user, amount)
    TokenB-->>BridgeB: CrosschainMintイベント発行
    TokenB-->>User: トークン受け取り
```

このフローでは、ユーザーがチェーンAでブリッジにトークン転送をリクエストすると、ブリッジがトークンコントラクトの`crosschainBurn`を呼び出します。
burn完了後、ブリッジはクロスチェーンメッセージをチェーンBに送信し、チェーンB側のブリッジが`crosschainMint`を呼び出してトークンを発行します。

### 後方互換性

**ERC7802**は**ERC20**と完全に互換性があります。
この規格は既存の**ERC20**機能を拡張するものであり、既存のトークンの動作を変更しません。

動機セクションで説明したように、最小限で柔軟なクロスチェーン標準インターフェースが必要です。
標準化されたフォーマットなしでより多くのトークンがデプロイされるにつれて、問題は大きくなります。

#### トークンタイプ別の対応

| トークンタイプ | 対応方法 |
|--------------|---------|
| アップグレード可能なトークン | 新しいインターフェースを実装するようにアップグレード可能 |
| 非アップグレード可能なトークン | トークン自体にインターフェースを実装できない |

#### 非アップグレード可能なトークンの移行

非アップグレード可能なトークンの場合、xERC-20で提案されているロックボックスメカニズムを使用して標準準拠バージョンに移行できます。

ロックボックスの仕組みは以下の通りです。

1. `mint`不可能なトークンをロックする
2. 同量のインターフェース準拠トークンを`mint`する
3. ブリッジコントラクトがネイティブチェーンでロックボックスとして機能できる

この方法により、既存のトークンを変更することなく、クロスチェーン機能を追加できます。

#### ブリッジコントラクトの更新

ブリッジコントラクトもインターフェースと統合するためにアップグレードが必要になります。

### セキュリティ

#### セキュリティ考慮事項

:::message alert
**ERC7802**を実装する時は、以下のセキュリティ考慮事項に注意してください。
:::

##### アクセス制御（パーミッション）

トークン発行者は、`crosschainMint`と`crosschainBurn`関数を呼び出す権限のあるコントラクトを制御する責任があります。
バグのある、または悪意のある認可された呼び出し元は、トークンを不適切に`mint`または`burn`し、トークン保有者に損害を与え、統合を妨害する可能性があります。

| リスク | 影響 |
|--------|------|
| 悪意のある呼び出し元の認可 | 無制限のトークン発行が可能 |
| バグのあるコントラクトの認可 | ユーザー資産の不正な`burn` |

##### 損失の最小化

潜在的な損失を最小限に抑える1つの方法は、xERC-20で提案されているような`mint` と `burn`制限を導入することです。
これらの機能は提案されたインターフェースと完全に互換性があります。

| 緩和策 | 効果 |
|--------|------|
| `mint` と `burn`制限 | 一定期間内の`mint` と `burn`量を制限し、被害を抑制 |
| レート制限 | 異常な大量操作を検出・防止 |

##### ラップドネイティブトークン

この規格は、WETHのようなラップドネイティブトークンには使用すべきではありません。
ブリッジが原資産を制御しない場合、担保なしの`mint`につながる可能性があります。

唯一の安全な例外は、ブリッジが両チェーンでネイティブトークンを対称的に`burn` と `mint`でき、適切な担保化を確保できる場合です。
例えば、チェーンBで`crosschainMint`によりWETHが発行される場合、チェーンAで対応するETHがロックされている必要があります。

### 参考実装

**ERC7802**の参考実装は以下です。

#### IERC7802インターフェース

まず、`IERC7802`インターフェースの定義です。

```javascript
// SPDX-License-Identifier: CC0-1.0
pragma solidity 0.8.25;

import "@openzeppelin/contracts/utils/introspection/IERC165.sol";

/// @title IERC7802
/// @notice クロスチェーンERC20転送のためのインターフェースを定義
interface IERC7802 is IERC165 {
    /// @notice クロスチェーン転送でトークンがmintされた時に発行
    /// @param to トークンがmintされるアカウントのアドレス
    /// @param amount mintされるトークン量
    /// @param sender crosschainMintを呼び出した呼び出し元（msg.sender）のアドレス
    event CrosschainMint(address indexed to, uint256 amount, address indexed sender);

    /// @notice クロスチェーン転送でトークンがburnされた時に発行
    /// @param from トークンがburnされるアカウントのアドレス
    /// @param amount burnされるトークン量
    /// @param sender crosschainBurnを呼び出した呼び出し元（msg.sender）のアドレス
    event CrosschainBurn(address indexed from, uint256 amount, address indexed sender);

    /// @notice クロスチェーン転送でトークンをmint
    /// @param _to トークンをmintするアドレス
    /// @param _amount mintするトークン量
    function crosschainMint(address _to, uint256 _amount) external;

    /// @notice クロスチェーン転送でトークンをburn
    /// @param _from トークンをburnするアドレス
    /// @param _amount burnするトークン量
    function crosschainBurn(address _from, uint256 _amount) external;
}
```

このインターフェースは**IERC165**を継承しており、`supportsInterface`による検出が可能です。

#### CrosschainERC20実装

インターフェースを実装したトークンコントラクトの例です。

```javascript
// SPDX-License-Identifier: CC0-1.0
pragma solidity 0.8.25;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract CrosschainERC20 is ERC20, IERC7802 {
    /// @notice トークンのmint/burnが許可されたTOKEN_BRIDGEコントラクトのアドレス
    address public immutable TOKEN_BRIDGE;

    /// @notice 認可されていないアクセスに対するカスタムエラー
    error Unauthorized();

    /// @notice TOKEN_BRIDGEアドレスを設定するコンストラクタ
    /// @param _tokenBridge TOKEN_BRIDGEのアドレス
    constructor(address _tokenBridge, string memory name, string memory symbol) ERC20(name, symbol) {
        require(_tokenBridge != address(0), "Invalid TOKEN_BRIDGE address");
        TOKEN_BRIDGE = _tokenBridge;
    }

    /// @notice TOKEN_BRIDGEのみが呼び出せるようにする修飾子
    modifier onlyTokenBridge() {
        if (msg.sender != TOKEN_BRIDGE) revert Unauthorized();
        _;
    }

    /// @notice TOKEN_BRIDGEがトークンをmintできるようにする
    /// @param _to トークンをmintするアドレス
    /// @param _amount mintするトークン量
    function crosschainMint(address _to, uint256 _amount) external onlyTokenBridge {
        _mint(_to, _amount);
        emit CrosschainMint(_to, _amount, msg.sender);
    }

    /// @notice TOKEN_BRIDGEがトークンをburnできるようにする
    /// @param _from トークンをburnするアドレス
    /// @param _amount burnするトークン量
    function crosschainBurn(address _from, uint256 _amount) external onlyTokenBridge {
        _burn(_from, _amount);
        emit CrosschainBurn(_from, _amount, msg.sender);
    }

    function supportsInterface(bytes4 interfaceId) external pure override returns (bool) {
        return interfaceId == type(IERC7802).interfaceId || interfaceId == type(IERC165).interfaceId;
    }
}
```

この実装のポイントは以下の通りです。

| ポイント | 説明 |
|---------|------|
| `TOKEN_BRIDGE`のimmutable化 | デプロイ後の変更を防ぎ、セキュリティを強化 |
| `onlyTokenBridge`修飾子 | 認可されたブリッジのみが`mint` と `burn`可能 |
| カスタムエラー`Unauthorized` | ガス効率の良いエラーハンドリング |
| コンストラクタでのゼロアドレスチェック | 不正なブリッジアドレスの設定を防止 |

`_mint`と`_burn`はOpenZeppelinの`ERC20`から継承した内部関数を使用しており、標準的な`Transfer`イベントも発行されます。
`supportsInterface`関数は**ERC165**に準拠し、**ERC7802**のインターフェースIDを返します。

### 引用

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

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

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

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

## 最後に

今回は「**ERC7802**によるクロスチェーントークンインターフェースの標準化」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

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