# [ERC7649] NFTに流動性を組み込む仕組みを理解しよう！

> ERC7649は、ERC721（NFT）の仕様を変更せずに、ボンディングカーブ型の流動性をNFTに組み込むための標準を提案しています。

- URL: https://cardene.dev/articles/207e550f9e482dd971c0
- 公開日: 2025-12-20
- 更新日: 2025-12-20
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、NFTに対して、ボンディングカーブを用いた流動性コントラクトを外付けで紐づけることで、**ERC721**を変更せずに価格形成と継続的な取引を可能にする仕組みを提案している**ERC7649**についてまとめていきます！

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

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

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

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

## 概要

**ERC7649**は、**ERC721**（NFT）の仕様を変更せずに、ボンディングカーブ型の流動性をNFTに組み込むための標準を提案しています。

#### 用語

* **NFT（Non-Fungible Token）**
    それぞれが固有の価値や識別子を持つトークンです。
    **ERC721**はNFTの代表的な標準規格です。
* **ボンディングカーブ（Bonding Curve）**
    トークンの供給量に応じて価格が数式で決まる仕組みです。
    一般的に、需要が高まり供給が増えるほど価格が上昇します。自動マーケットメイカーの一種として使われます。
* **流動性（Liquidity）**
    資産をどれだけ簡単に売買できるかを示す性質です。
    流動性が高いほど、取引が活発で価格が安定しやすくなります。

#### Tradable Sharesによる流動性の埋め込み

この標準では、NFTそのものに直接ロジックを追加するのではなく、NFTに紐づく専用の流動性コントラクトを外付けで接続します。
この外部コントラクトを**Tradable Shares**（取引可能なシェア）と呼びます。

Tradable Sharesは、以下の特徴を持ちます。

* **ERC721**形式のNFTに紐づいて存在する独立したコントラクトです。
* NFTの所有権とは別に、シェアという形で分割可能な価値を提供します。
* シェアの価格はボンディングカーブの数式により自動的に決まります。

これにより、1つのNFTに対して以下のような状態が実現されます。

| 要素              | 役割                  |
| --------------- | ------------------- |
| **ERC721**形式のNFT     | 資産・権利・コンテンツの本体      |
| **Tradable Shares** | NFTに紐づく流動性と価格形成の仕組み |
| ボンディングカーブ       | シェア価格を供給量に応じて自動決定   |

NFT自体は従来どおり**ERC721**のままですが、その価値の一部をシェアとして売買できるため、NFTに継続的な流動性を持たせられます。

## 動機

#### ERC721が抱える課題

**ERC721**はNFTの所有権や転送を定義する標準として非常に優れていますが、以下のような制約があります。

* NFTに価格形成ロジックを持たせる仕組みがありません。
* ボンディングカーブのような自動的な流動性供給機構を内包できません。
* そのため、NFTは基本的に「**一度作ってあとは売買されるのを待つ**」資産になりがちです。

この制約により、NFTを活用した新しい経済モデルや継続的な収益構造を作ることが難しい状況が続いています。

#### 標準化による解決アプローチ

**ERC7649**では、**ERC721**自体を変更せずに、**外部コントラクトとしてボンディングカーブ型の流動性を接続する枠組み**を定義します。

このアプローチの重要な点は以下です。

* **ERC721**の互換性を維持したまま機能拡張ができます。
* プロジェクトごとに異なるボンディングカーブを設計できます。
* NFTマーケットプレイスや既存ツールとの互換性を壊しません。

つまり、既存のNFTエコシステムを壊さずに、表現力と経済設計の自由度を大きく広げることが目的です。

#### クリエイターへの継続的な報酬設計

この標準では、**Tradable Shares**の売買に対して、クリエイターに必ず手数料（クリエイティブフィー）が支払われる設計を想定しています。

これにより以下が実現されます。

* NFTが二次流通され続けても、制作者が継続的に報酬を得られます。
* 単発の販売に依存しないビジネスモデルを構築できます。
* 流動性が高まるほど、制作者のインセンティブも強化されます。

NFTを「**売って終わり**」の資産ではなく、「**成長し続ける経済単位**」として扱えるようになります。

### 想定されるユースケース：分散型AIサービス領域

この標準は汎用的ですが、特に分散型AIサービスとの相性が非常に良いとされています。

#### AIモデルのマーケットプレイス

AIモデルそのものをNFTとして表現し、そのNFTに**Tradable Shares**を紐づけることで、AIモデルに流動性を持たせます。
この構成では、1つのAIモデルが1つのNFTとして発行され、そのNFT専用の**Tradable Shares**コントラクトが作成されます。

ユーザーは、**Tradable Shares**を売買することで、そのAIモデルに対する期待値や需要を経済的に表現できます。
単に使われているかどうかではなく、将来どれだけ価値が高まると考えられているかが、価格として即座に反映されます。

ここで重要な役割を果たすのがボンディングカーブです。
AIモデルの性能が高く評価されたり、利用が増えたりすると、シェアの購入需要が高まります。
需要の増加に応じて、ボンディングカーブの数式に基づきシェア価格が自動的に上昇します。
その結果、市場参加者の評価がオンチェーンの価格として可視化されます。

また、ボンディングカーブの設計は固定ではありません。
AIモデルの制作者は、価格の上昇速度や初期価格などのパラメータを調整できます。
成熟した安定モデルには緩やかな価格曲線を、実験的で成長余地の大きいモデルには急な価格曲線を設定するなど、モデルの性質に応じた設計が可能です。

この仕組みにより、流動性提供者、AIモデルの利用者、そしてAI開発者の三者が、それぞれの立場で利益を得られる市場が形成されます。

#### 分散型GPU・ストレージリソースの割り当て

GPUやストレージといった計算資源をNFTとして表現し、それぞれに**Tradable Shares**を紐づけることで、分散型のリソース市場を構築できます。
GPUプールやストレージプールはNFTとして発行され、そのNFTに対応するシェアが流動的に取引されます。

シェア価格は、リソースの需要と供給を直接反映します。
利用希望者が増えるとシェアの需要が高まり、ボンディングカーブにより価格が上昇します。
一方で需要が落ち着けば、価格もそれに応じて調整されます。

リソース提供者は、ボンディングカーブの設計を通じて競争力を高められます。
提供可能な計算量、パフォーマンス、稼働実績などを踏まえ、価格曲線を最適化することで、他のリソースプールとの差別化が可能です。

さらに、シェア取引から発生する手数料は、リソース提供者に継続的な収益として還元されます。
これにより、より高品質で安定したリソースを提供し続けるインセンティブが生まれます。

この構成によって、需要変動に柔軟に対応できる、競争的で自己調整的な分散型リソース市場が実現されます。

## 仕様

### ボンディングカーブ埋め込み流動性の基本設計

#### ERC721との関係性

**ERC721**はNFTの所有権と転送を定義する標準ですが、**ERC7649**では以下の点が厳格に定められています。

* ボンディングカーブ型の流動性は必ず別コントラクトとして実装する
* ERC721の仕様や実装を変更してはいけない
* 流動性管理は、NFT本体ではなく外部コントラクトが責務を持つ

この設計により、既存のNFTマーケットプレイスやツールとの互換性が保たれます。

#### Tradable Sharesの役割

**Tradable Shares**は、NFTに紐づいた売買可能なシェア型アセットです。

* **ERC20**のように振る舞うが、自由に送付はできない
* 売買は必ずボンディングカーブ価格で行われる
* シェアの流動性はNFT単位で独立する

NFTそのものは唯一性を保ちつつ、その価値の経済的側面だけを分割して扱える点が特徴です。

### ボンディングカーブの仕組み

#### 価格決定モデル

ボンディングカーブは、現在の供給量と取引量を入力として価格を計算する関数です。

* シェアの供給量が増えるほど価格が上昇する
* 売却時は供給量が減るため価格が下がる
* 価格は人ではなく数式で決まる

これにより、常にオンチェーンで一貫した価格形成が行われます。

#### カスタマイズ可能な要素

実装によって、以下の要素をNFT制作者が設定できます。

* 価格上昇の速さ（スロープ）
* 初期価格（切片）
* 線形・指数・その他任意の数式形状

これにより、成長性の高いNFT、安定志向のNFTなど、性質に応じた設計が可能です。

### クリエイター報酬

#### 保証される仕組み

**ERC7649**では、以下の点が必須要件として定められています。

* シェアの売買ごとに手数料が発生する
* その一部は必ずNFT制作者に支払われる
* この仕組みは実装から削除できない

NFTの二次流通が活発になるほど、制作者の収益も増えます。

#### 手数料の柔軟性

* 手数料率は実装によって制作者が設定できる
* プロトコル手数料やホルダー手数料と組み合わせられる

単なるロイヤリティではなく、流動性そのものに紐づく報酬設計です。

### 支払い手段

#### 対応通貨

埋め込み流動性コントラクトは、以下の支払い方式に対応する必要があります。

| 支払い方法     | 必須 / 任意 |
| --------- | ------- |
| ETH       | 対応必須    |
| **ERC20**トークン | 任意      |

ETHのみ、**ERC20**のみ、または両対応のいずれも実装可能です。

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

#### 関数

##### `getPrice`

```javascript
function getPrice(uint256 supply, uint256 amount) external pure returns(uint256);
```

指定された供給量と取引量からシェア価格を計算する関数。
現在のシェア供給量と、購入または売却するシェア数を入力として受け取り、ボンディングカーブの数式に基づいて合計価格を返します。

**引数**

* `supply`
  * 現在のシェア総供給量。
* `amount`
  * 売買するシェアの数量。

**戻り値**

* 価格
  * 指定数量分のシェアの合計価格。

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

#### 構造体

##### `SharesSubject`

```javascript
struct SharesSubject {
	address tokenAddress;
	uint256 tokenId;
}
```

シェアが紐づくNFTを表す構造体。
どのNFTに対して流動性が埋め込まれているかを示します。
**ERC721**コントラクトのアドレスとトークンIDの組み合わせで一意に定義されます。

**パラメータ**

* `tokenAddress`
  * **ERC721**コントラクトのアドレス。
* `tokenId`
  * NFTのトークンID。

#### イベント

##### `Trade`

```javascript
event Trade(
	address indexed beneficiary,
	address indexed issuer,
	bool indexed isBuy,
	uint256 sharesAmount,
	uint256 paidAmount,
	uint256 feeAmount,
	uint256 supply
);
```

シェアの売買が行われた時に発行されるイベント。
購入・売却のどちらの場合も発行され、取引内容・支払額・手数料・取引後の供給量を記録します。
インデックス付きパラメータにより、分析やUI表示が容易になります。

**パラメータ**

* `beneficiary`
  * シェアまたは資金を受け取るアドレス。
* `issuer`
  * NFTの所有者。
* `isBuy`
  * 購入の場合は `true`、売却の場合は `false`。
* `sharesAmount`
  * 売買されたシェア数。
* `paidAmount`
  * 支払われた、または受け取った金額。
* `feeAmount`
  * 支払われた手数料総額。
* `supply`
  * 取引後の総シェア供給量。

#### 関数

##### `getSharesSubject`

```javascript
function getSharesSubject() external view returns(SharesSubject calldata);
```

シェアが紐づくNFTを取得する関数。
この値は不変であり、クライアントは安全にキャッシュできます。

##### `getSharesIssuer`

```javascript
function getSharesIssuer() external view returns(address nftOwner);
```

NFTの現在の所有者を取得する関数。
NFTの転送により動的に変化します。
フロントラン攻撃の可能性があるため、オフチェーンでの依存は推奨されません。

##### `buyShares`

```javascript
function buyShares(uint256 amount) external payable;
```

指定数量のシェアを購入する関数。
支払いはETHまたは**ERC20**で行われます。
最初の1シェアは必ずNFT所有者のみが購入できます。

**引数**

* `amount`
  * 購入するシェア数。

##### `sellShares`

```javascript
function sellShares(uint256 amount) external;
```

指定数量のシェアを売却する関数。
売却後の総供給量がゼロになることは禁止されています。
最後の1シェアは売却できません。

**引数**

* `amount`
  * 売却するシェア数。

##### `getTradeVolume`

```javascript
function getTradeVolume() external view returns(uint256);
```

累積取引量を取得する関数。
過去すべての売買の合計値を返します。
この値は減少せず、分析や手数料計算に利用できます。

## 補足

#### ボンディングカーブ埋め込み流動性 / Tradable Shares コントラクト

##### ERC721とのシームレスな統合

**ERC721**は広く普及している標準であり互換性は重要です。
そこで、流動性の仕組みをNFT本体に直接組み込むのではなく、外部コントラクトとして接続する設計が採用されています。

この設計により、NFT開発者は以下の利点を得られます。

| 観点   | 内容                                   |
| ---- | ------------------------------------ |
| 互換性  | 既存の**ERC721**対応ツールやマーケットプレイスがそのまま利用できます。 |
| 実装負荷 | **ERC721**を再実装したり拡張したりする必要がありません。 |
| 安定性  | 標準規格の変更リスクを避けられます。                   |

NFTはあくまでNFTのまま、流動性だけを後付けできる点が重要です。

##### 流動性管理を専用コントラクトに分離する理由

流動性管理は、価格計算・供給管理・手数料分配など、複雑な責務を持ちます。
これをNFTコントラクトに含めると、設計が肥大化し、保守性が低下します。

そのため、ボンディングカーブを扱う責務は**Tradable Shares**コントラクトに完全に委譲されています。

この分離により、

* 価格は常に数式で自動計算される
* 需要と供給に応じて価格が動的に変化する
* NFTシェアは常に売買可能な状態が保たれる

結果として、NFTに安定した流動性と取引可能性が生まれます。

#### ボンディングカーブの採用理由

##### 動的な価格形成

Tradable Sharesの価格は、固定価格やオークションではなく、ボンディングカーブによって決まります。

この方式を採用した理由は以下です。

* 需要が高まれば価格が上がる
* 需要が落ち着けば価格が下がる
* 人為的な価格調整が不要

これにより、市場は常に現在の状況を反映した価格を持ちます。
流動性提供者は、価格変動を前提として売買に参加できるため、市場参加の動機が生まれます。

##### クリエイターによるカスタマイズ性

NFTやプロジェクトの性質は一様ではありません。
そこで、ボンディングカーブのパラメータや数式そのものを 制作者が選択できる設計になっています。

例えば、以下の設計が可能です。

* 価格が緩やかに上がる安定型の曲線
* 初期は安く、需要増加で急上昇する成長型の曲線

この柔軟性が、NFT分野における実験的な経済設計や新しい表現を後押しします。

#### クリエイティブフィー（制作者報酬）を必須にした理由

##### 制作者インセンティブの明確化

**ERC721**を用いたNFTエコシステムが長く続くためには、制作者が継続的に報酬を得られる仕組みが不可欠です。

そのため、この標準では以下が前提として組み込まれています。

* シェアの売買ごとに手数料が発生する
* その一部は必ずNFT制作者に分配される
* 制作者は手数料率を定義できる

これにより、NFTが取引され続ける限り、制作者も経済的な恩恵を受け続けられます。
単なるロイヤリティではなく、流動性そのものに紐づいた報酬である点が特徴です。

#### 支払い手段に関する設計思想

##### 開発者の自由度を重視

この標準は、特定の支払い手段に縛られません。

* ETHを使う実装
* **ERC20**トークンを使う実装
* 両方に対応する実装

いずれも許容されます。

これは、プロジェクトごとに求められる要件が異なるためです。
ガスコスト、UX、既存トークンエコノミーなどを考慮し、開発者が最適な選択を行える余地を残しています。

#### 関連仕様との関係

##### Bonded Fungible Tokens（1671）

この標準は、**Bonded Fungible Tokens（EIP-1671）** と思想的に近い部分があります。
いずれもボンディングカーブを用いた価格形成を前提としていますが、**ERC7649**は **ERC721**形式のNFTに特化している点が異なります。

## セキュリティ

#### スマートコントラクトの安全性

**Tradable Shares**やボンディングカーブを実装するコントラクトは、資金を直接扱います。
そのため、十分なセキュリティ監査が前提となります。

* オーバーフロー・アンダーフロー対策
* 再入可能性（reentrancy）対策
* 不正な価格計算の防止

これらを怠ると、流動性全体が危険にさらされます。

#### クリエイティブフィーの分配処理

制作者報酬の分配は、特に注意が必要です。

* 手数料の計算が正確であること
* 送金先が正しく更新されること
* 不正な差し替えができないこと

透明で検証可能な実装が、信頼性の基盤になります。

#### ERC721との互換性

**ERC721**との互換性は、安全性の一部でもあります。

* NFTの所有権変更に正しく追従できること
* 既存の**ERC721**実装と衝突しないこと

これにより、導入時のトラブルや予期せぬ挙動を防げます。

#### ユーザー体験への配慮

セキュリティはUXとも密接に関係します。

* 操作が複雑すぎないこと
* 価格や手数料が分かりやすいこと
* 意図しない操作を防げること

これらが欠けると、技術的に正しくても実用的ではありません。

## 引用

Arif Khan <arif@alethea.ai>, Ahmad Matyana <ahmad@alethea.ai>, Basil Gorin (@vgorin), Vijay Bhayani (@unblocktechie), "ERC-7649: Bonding curve-embedded liquidity for NFTs [DRAFT]," Ethereum Improvement Proposals, no. 7649, February 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7649.

## 最後に

今回は「NFTに対して、ボンディングカーブを用いた流動性コントラクトを外付けで紐づけることで、**ERC721**を変更せずに価格形成と継続的な取引を可能にする仕組みを提案している**ERC7649**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下の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