ERC-2981:NFTロイヤリティの定義と実装方法

キーストーン
• ERC-2981はNFTのロイヤリティを定義するEthereumの標準です。
• ロイヤリティは販売価格に基づいて計算され、受取人は柔軟に設定できます。
• マーケットプレイスはERC-2981を利用してロイヤリティ情報を取得しますが、支払いを強制するものではありません。
• 2023年以降、ロイヤリティの強制がオプションとなり、ERC-2981の重要性が増しています。
• クリエイターはハードウェアウォレットを使用してロイヤリティ設定を安全に管理することが推奨されます。
NFTのロイヤリティは、クリエイターとマーケットプレイス間の社会契約として始まりました。取引が成熟し、手数料モデルが進化するにつれて、業界は、どのマーケットプレイスでも読み取れる、ロイヤリティ情報を記述するための、一貫性のあるオンチェーンの方法を必要としました。まさにそれを実現するのがERC-2981です。これは、NFT販売に対してどれだけのロイヤリティが誰に支払われるべきかを問い合わせるための、最小限で相互運用可能なインターフェースです。この記事では、ERC-2981とは何か、その仕組み、実装上の考慮事項、そしてマーケットプレイスでの強制力とクリエイターの収益化の現状について説明します。
ERC-2981が標準化するもの
ERC-2981は、非代替性トークン(NFT)に対して単一の関数を定義するEthereum標準です。
royaltyInfo(tokenId, salePrice)→(receiver, royaltyAmount)
ロイヤリティを尊重するマーケットプレイスは、支払い計算のために、販売時にroyaltyInfoを呼び出します。この標準は支払いを強制するものではなく、インターフェースを記述するだけです。強制力はマーケットプレイスのポリシーの問題です。
主な設計上の選択:
- パーセンテージベース:ロイヤリティは販売価格の関数として計算され、通常は基点(例:500 = 5%)のような分数を使用します。
- 受取人の柔軟性:ロイヤリティの受取人は、クリエイターのアドレス、マルチシグ、分割コントラクト、またはアップグレード可能な支払いアドレスにすることができます。
- ERC-721およびERC-1155と連携:ERC-2981は一般的なNFT標準と互換性があり、インターフェース検出にはERC-165を利用します。
本番環境で利用可能な実装については、多くのチームがOpenZeppelinのERC2981を基盤として構築しています。
なぜ今重要なのか
2023年から、いくつかの主要なマーケットプレイスがロイヤリティの強制をオプションに変更しました。最も注目すべき変更は、OpenSeaがOperator Filterを廃止したことです。これにより、以前はクリエイターがロイヤリティを強制するプラットフォームへの取引を制限することができました。詳細はOpenSeaの発表をご覧ください。その結果、ERC-2981のようなオンチェーン標準が、強制力は様々であるものの、プラットフォーム全体でロイヤリティデータを表示するためのデフォルトの方法となりました。
それ以降、エコシステムは以下のような対応をしてきました。
- ロイヤリティロジックを統一的に解決するためのレジストリインフラストラクチャ。例:Royalty Registryとその関連仕様。
- オンチェーンでの強制や制限のためのプログラマブルな標準。特にERC-721C (Creator Token Standards)。
- プロトコルレベルの報酬やクリエイターインセンティブなどの代替収益モデル。例:ZoraのCreator Rewards。
2024年から2025年にかけて、ERC-2981の採用はL1およびL2ネットワーク全体で広く行われ続けるでしょう。ロイヤリティを尊重するマーケットプレイスは、取引決済時に一般的にこのインターフェースをクエリすることになります。
インターフェースの仕組み(驚きなし)
販売時に、準拠したマーケットプレイスは以下の手順を実行します。
- ERC-165(インターフェースID
0x2a55205a)を介して、トークンがIERC2981をサポートしているか確認します。 royaltyInfo(tokenId, salePrice)を呼び出して、以下を取得します。receiver: 支払いを受け取るアドレス。royaltyAmount:salePriceから計算された支払い金額。
通常、クリエイターまたはコレクション所有者は、「デフォルトロイヤリティ」と、オプションで「トークンごとのロイヤリティ」を設定します。多くの実装では、基点として10,000を分母として使用します。マーケットプレイスの会計処理は、販売収益を売り手、プロトコル手数料、ロイヤリティ受取人の間で分割します。
実装のヒント:
royaltyInfoでのリバート(revert)を避ける:呼び出しが失敗した場合、マーケットプレイスは支払いをスキップする可能性があります。- ロイヤリティ受取人をアップグレード可能にする(例:Ownableまたは管理者コントロール経由):キーのローテーションや分割コントラクトへの移行のため。
- ロイヤリティの上限を合理的な範囲(多くのプロジェクトは≤10%)に設定する:セカンダリマーケットの流動性を促進するため。
シンプルなSolidityの例
以下は、OpenZeppelinを使用した簡略化されたパターンです。デフォルトロイヤリティの設定方法と、ERC-165のサポートをオーバーライドする方法を示しています。本番環境では、アクセス制御、初期化ガード、堅牢なミントロジックを追加する必要があります。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC721/ERC721.[sol](https://onekey.so/blog/ja/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/token/common/ERC2981.[sol](https://onekey.so/blog/ja/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/access/Ownable.[sol](https://onekey.so/blog/ja/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
[contract](https://onekey.so/blog/ja/ecosystem/what-is-a-smart-contract/) MyNFT is ERC721, ERC2981, Ownable {
uint256 private _nextTokenId;
constructor([address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) defaultReceiver, uint96 defaultBps)
ERC721("MyNFT", "MYN")
{
// デフォルトロイヤリティを設定(例:500 = 5%)
_setDefaultRoyalty(defaultReceiver, defaultBps);
}
function mint([address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) to) external onlyOwner {
_safeMint(to, _nextTokenId);
_nextTokenId++;
}
// オプション:特別なアイテムのためにトークンごとのロイヤリティを設定
function setTokenRoyalty(uint256 tokenId, [address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) receiver, uint96 bps)
external
onlyOwner
{
_setTokenRoyalty(tokenId, receiver, bps);
}
// 必須:ERC-165 supportsInterface
function supportsInterface(bytes4 interfaceId)
public
view
override(ERC721, ERC2981)
returns (bool)
{
return super.supportsInterface(interfaceId);
}
}
より詳細なドキュメントについては、OpenZeppelinのERC2981ガイドを参照してください。
分割、アップグレード、エッジケースの処理
実際のロイヤリティの流れは、単一の受取人になることは稀です。以下を考慮してください。
- 分割コントラクト:0xSplitsのような実績のあるインフラストラクチャを使用して、収益を固定比率で複数の当事者にルーティングします。
- レジストリ検索:一部のマーケットプレイスは、最新のロイヤリティデータのためにレジストリを参照します(Royalty Registry)。
- アップグレード可能な受取人:キーのローテーションや組織変更の場合に、受取アドレスを更新できる機能を維持します。
- トークンごとのオーバーライド:特別なエディションは、デフォルトとは異なる独自のロイヤリティ率を持つことができます。
技術的な注意点:
- 一貫した分母:オフチェーン統合での明確さのために、基点(10,000)を使用します。
- トークンタイプの認識:ERC-1155の実装は、バンドル価格ではなく、トークンごとの販売価格に対してロイヤリティを計算する必要があります。
- 丁寧なフォールバック:ロイヤリティ受取人が設定されていない場合は、ゼロを返して、マーケットプレイスの呼び出し失敗を回避します。
マーケットプレイスの現実:シグナル vs. 強制
ERC-2981はクリエイターの意図を示しますが、支払いを強制するものではありません。様々なプラットフォームは:
- ERC-2981を完全に尊重する場合があります。
- 特定の条件下でロイヤリティを上限設定または削減する場合があります。
- ロイヤリティを完全に無視する場合があります。
このばらつきを考慮して、多くのクリエイターはハイブリッドモデルを試しています。
- ERC-721Cによるオンチェーン制限:ロイヤリティを尊重するオペレーターへの転送を制限します。
- プロトコルレベルの報酬:ZoraのCreator Rewardsなど。
- クリエイターの収益を尊重することに関するコミュニティの規範と社会的圧力。
OpenSeaの2023年のオペレーターフィルタリング終了の決定は、プロトコルレベルの強制よりも市場の選択への広範な傾向を反映しています。詳細は彼らの発表で説明されています。2024年から2025年にかけて、このバランスは続きます。ERC-2981はロイヤリティメタデータの標準的なインターフェースであり続けますが、強制力は断片化しています。
テスト、検証、監視
信頼性の高いロイヤリティ動作を確保するために:
- インターフェースサポートの検証:ERC-165に従って、コントラクトが
supportsInterface(0x2a55205a) == trueを報告していることを確認します。 - 呼び出しのシミュレーション:エッジケースの販売価格とトークン全体で
royaltyInfoをテストします。 - インデックス作成の互換性:マーケットプレイスパートナーが依存している場合、Royalty Registryなどの関連レジストリにコントラクトを登録します。
- 明確なドキュメント化:購入者やマーケットプレイスの誤解を最小限に抑えるために、ロイヤリティポリシー、上限、受取人ロジックを公開します。
- 標準の学習:ERC-2981に慣れていない場合は、Alchemyによるこの概要が役立ちます:What is ERC-2981?。
クリエイター向けのセキュリティとキー管理
ロイヤリティ設定は管理者が制御します。攻撃者がデプロイ担当者または管理者キーにアクセスできる場合、ロイヤリティをリダイレクトしたり無効にしたりできます。ベストプラクティス:
- デフォルトロイヤリティの設定、受取人の更新、分割コントラクトのデプロイなどの高権限アクションには、ハードウェアウォレットを使用します。
- チーム管理のコレクションには、マルチシグ設定を優先します。
- 署名フローを透明で監査可能に保ちます。
安全でポータブルな署名を、ユーザーエクスペリエンスを損なうことなく実現したいクリエイターおよびスタジオ向けに、OneKeyハードウェアウォレットは以下を提供します。
- オープンソースファームウェアと透明なセキュリティプラクティスを備えたオフライン秘密鍵ストレージ。
- コントラクトデプロイや管理操作のための一般的なEthereumツールとのスムーズな統合。
- クロスチェーンサポート。NFTがL2や複数のEVMネットワークでミントされる場合に役立ちます。
ハードウェアウォレットを使用してロイヤリティ設定を管理することで、侵害されたデバイスやホットウォレットによってオンチェーン収益シグナルが改ざんされないようにすることができます。
結論
ERC-2981はNFTロイヤリティの基盤レイヤーです。マーケットプレイスがクリエイターの支払い決定のために読み取ることができる、シンプルで普遍的なインターフェースです。強制を保証するものではありませんが(マーケットポリシーが保証します)、シグナルを標準化します。強制がオプションであり進化し続ける世界において、ERC-2981をレジストリ、分割コントラクト、およびERC-721Cのようなプログラマブルな制限と組み合わせることで、クリエイターは自身の活動を維持するための実用的なツールを得られます。
NFTコレクションまたはクリエイターインフラストラクチャを管理している場合は、ERC-2981をクリーンに実装し、徹底的にテストし、ハードウェアウォレットで管理者キーを保護してください。この組み合わせは、マーケットプレイス間の相互運用性を最大化すると同時に、プロジェクトが依存する収益の流れを保護します。






