はじめに
『DApps開発入門』という本や色々記事を書いているかるでねです。
今回は、ERC20に名前・説明・画像といった視覚的メタデータをURIとJSONスキーマで標準的に取得できるようにする仕組みを提案しているERC7729についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。
概要
ERC7729は、既存のERC20規格を拡張し、トークンに「メタデータ」を標準化された方法で付与できるようにする規格です。 具体的には、トークンが持つメタデータを取得するための関数インターフェースと、そのメタデータの構造を定義するJSONスキーマ（JSON形式でどの項目をどのような形で持つかを定めた設計図）を規定しています。
ERC20については以下の記事を参考にして下さい。
ERC20は、送金や残高管理といった基本的な機能に特化した非常にシンプルな規格です。 そのため、トークンの見た目、アイコン画像、説明文、外部リンクといった「人が見て理解するための情報」は、標準としては定義されていませんでした。 各プロジェクトが独自の方法でメタデータを用意することはできましたが、取得方法や形式が統一されていないため、ウォレットやDApp（分散型アプリケーション）が汎用的に扱うことが難しいという課題がありました。
ERC7729はこの問題を解決するために、「この関数を呼び出せばメタデータが取得できる」、「そのメタデータはこのJSON構造に従う」という共通ルールを定めています。 これにより、ウォレットやフロントエンドは、トークンの種類に依存せず同じ手順でメタデータを読み取り、アイコン表示や説明文の表示などを一貫した方法で行えるようになります。
要するに、ERC7729はERC20トークンに対して「見た目や説明といった情報を標準仕様として持たせる仕組み」を追加する拡張規格です。
動機
ミームコインの流行により、トークンが「単なる数値の残高」ではなく、「キャラクター性や世界観を持つデジタルオブジェクト」として認識されるようになりました。 ロゴ画像、キャラクターイラスト、ストーリー性のある説明文などの視覚的・表現的な要素が、コミュニティの盛り上がりや拡散力に大きく貢献していることが実証されています。
しかし、現状のERC20では、こうした視覚的メタデータをどこにどの形式で置くかが統一されていません。その結果、
- あるウォレットではロゴが表示されるが、別のウォレットでは表示されない
- 同じトークンでもアプリごとに説明文の取得方法が異なる
といった不整合が発生します。これは開発者にとっても利用者にとっても扱いづらい状況です。
ERC7729は、メタデータの取得方法と構造を標準化することで、こうした分断を解消しようとしています。 標準化されたメタデータを持つことで、トークンは以下のような性質を獲得します。
- どのウォレットやDAppでも同じ形式でロゴや説明が表示される
- トークンの世界観やブランド性を一貫して表現できる
- コミュニティ向けの演出やインタラクティブな体験を実装しやすくなる
つまり、ERC7729は、ミームコインが示した「視覚的メタデータが価値やコミュニティ形成に与える影響」を、特定のプロジェクト依存ではなく、ERC20全体で再利用可能な標準仕様として取り込むための規格です。 これにより、開発者はトークンを単なる決済単位としてではなく、表現力を持つデジタルアセットとして設計でき、結果としてユーザー参加型で魅力のあるトークンエコシステムを構築しやすくなります。
仕様
実装要件
ERC7729に準拠するスマートコントラクトは、必ず以下の2つのインターフェースを実装する必要があります。
- ERC20（基本的なトークン機能）
- IERC7729（メタデータ拡張用インターフェース）
つまり、ERC7729トークンは「通常のERC20として完全に振る舞える」ことを前提にしつつ、そこへメタデータ取得機能を追加した構造になります。
メタデータ取得用インターフェース
ERC7729では、トークンに紐づくメタデータの参照先を返すために、以下のインターフェースを定義しています。
pragma solidity ^0.8.0;
interface IERC20Metadata is IERC20 {
/// @dev Returns the metadata URI associated with the token.
/// The URI may point to a JSON file that conforms to the "ERCX Metadata JSON Schema".
function metadata() external view returns (string memory);
}ここで定義されている metadata() 関数は、文字列型のURIを返します。
このURIは、トークンのメタデータを表すJSONファイルの場所を指します。IPFS、HTTPS、Arweaveなど、一般的なURIスキームが利用可能です。
重要なのは、単に文字列を返すだけではなく、「その先にあるJSONが、決められた構造（スキーマ）に従っている」ことが前提になっている点です。 これにより、ウォレットやDAppは、同じ項目名で安全にメタデータを読み取れます。
ERC7729メタデータJSONスキーマ
ERC7729が参照するJSONの構造は、以下のスキーマで定義されています。
{
"title": "Token Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset to which this token represents"
},
"description": {
"type": "string",
"description": "Describes the asset to which this token represents"
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents."
}
}
}このJSONは「トークンが表している対象（アセット）」を人間に分かりやすく伝えるための最小構成になっています。 各フィールドの意味は以下です。
| 項目名 | 型 | 内容 |
|---|---|---|
name |
string | トークンが表すアセットの名前です。表示名として使われます。 |
description |
string | トークンの説明文です。世界観や用途、背景などを文章で表現します。 |
image |
string | 画像へのURIです。mime type が image/* のリソースを指し、ロゴやキャラクター画像など視覚表現に使われます。 |
この構造は、ERC721やERC1155で広く使われているメタデータ形式と思想が近く、フロントエンド側がそのまま流用しやすい設計になっています。
全体構造の整理
ERC7729の仕様を構造としてまとめると、以下の流れになります。
- コントラクトはERC20としての機能を持ちます。
- 追加で
metadata()関数を実装します。 metadata()はメタデータJSONのURIを返します。- そのJSONは、名前・説明・画像URIを持つ標準スキーマに従います。
- ウォレットやDAppは、このルールに従って一貫した表示ができます。
つまり、ERC7729は「ERC20にNFT的なメタデータ表現を安全に持たせるための標準インターフェースとJSON設計」をセットで定義した仕様です。 これにより、トークンの視覚表現と説明情報を、エコシステム全体で共通フォーマットとして扱えるようになります。
補足
ERC7729で metadata() という関数名と構造が採用された理由は、既存のトークン規格やDApp、ウォレット実装で広く使われている設計と整合性を取るためです。
ERC721やERC1155では、トークンのメタデータをURIで参照し、その先にJSON形式の情報を置くという構成が事実上の標準になっています。 ウォレットやマーケットプレイスも、この形式を前提に表示機能を実装しています。
ERC7729は、この実績のある設計をERC20にも持ち込むことで、以下のメリットを得ています。
- 新しい独自仕様を増やさない
- 既存のフロントエンド資産を流用できる
- 開発者とツール側の学習コストを下げる
そのため、メタデータ取得用に metadata() という単純な関数を追加し、返り値はURI、実体はJSONスキーマ準拠、という構成になっています。
互換性
ERC7729はERC20を拡張する形で設計されています。 既存の関数を変更したり、挙動を上書きしたりすることはありません。
構造としては以下の関係になります。
- すべてのERC7729トークンはERC20として完全に動作します。
- 追加されるのは
metadata()という新しい読み取り専用関数だけです。 - 既存のウォレットやDAppは、ERC7729を知らなくても、通常のERC20として問題なく扱えます。
つまり、ERC7729は壊さずに足す拡張です。 これにより、エコシステム全体を分断せずに、段階的にメタデータ対応を広げられる設計になっています。
参考実装
以下は、OpenZeppelinのERC20実装を基に、ERC7729のメタデータ機能を追加した最小構成のサンプルです。
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
interface IERC7729 is IERC20 {
function metadata() external view returns (string memory);
}
contract ERC7729 is ERC20, IERCX {
string _metadata = "ipfs://QmakTsyRRmvihYwiAstYPYAeHBfaPYz3v9z2mkA1tYLA4w";
function metadata() external view returns (string memory) {
return _metadata;
}
}このコードが示している構成は非常にシンプルです。
- ERC20を継承したトークンコントラクトを作成します。
IERC7729インターフェースでmetadata()関数を定義します。- コントラクト内にメタデータURIを保持する文字列変数
_metadataを置きます。 metadata()関数は、そのURIをそのまま返します。
URIの例として ipfs://... が使われており、実際にはこの先に、名前・説明・画像URIを含むJSONファイルが配置されます。
なお、サンプルコードでは contract ERC7729 is ERC20, IERCX となっていますが、インターフェース名の整合性から正しくは IERC7729 を継承する形になります。
実装上は以下が正しい構成です。
contract ERC7729 is ERC20, IERC7729 {
...
}セキュリティ
ERC7729のメタデータは、オンチェーンではなくオフチェーンのURIを参照します。この設計は柔軟で拡張性が高い一方、セキュリティ上の注意点も生まれます。
最大のリスクは、URIが次のような不正なコンテンツを指す可能性があることです。
- フィッシングサイト
- 悪意のあるスクリプトを含むページ
- なりすまし用の偽ロゴや偽説明文
スマートコントラクト自体は、URIの中身の安全性を検証できません。 そのため、ユーザーに情報を表示するウォレットやインデクサ（オフチェーンでトークン情報を収集・整理するサービス）は、次のような対策を行うことが前提になります。
- スキーマに準拠しているかの構造検証
- 不正なプロトコルや危険なドメインのブロック
- 既知のフィッシングリストとの照合
- 画像やJSONのmime type検証
ERC7729は「メタデータの取得方法」を標準化しますが、「その中身が安全かどうか」はオフチェーン側の責務になります。 これはERC721やERC1155と同じ設計思想であり、トークンの表現力を高める代わりに、表示レイヤー側でのセキュリティ検証が不可欠であることを明確にしています。
ERC721については以下の記事を参考にして下さい。
ERC1155については以下の記事を参考にして下さい。
引用
msfew (@fewwwww), "ERC-7729: Token with Metadata [DRAFT]," Ethereum Improvement Proposals, no. 7729, June 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7729.
最後に
今回は「」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！
