ERC-2981は、イーサリアム上で動作する非代替性トークン(NFT)におけるロイヤリティ支払いを標準化するためのイーサリアム改善提案(EIP)であり、2020年9月に導入されました[1]。この標準は、ERC-721やERC-1155といった既存のNFT規格と互換性を持ち、スマートコントラクトが二次販売時のロイヤリティの受取人アドレスと金額を一貫して伝達できるようにします。ERC-2981の中心となる関数royaltyInfoは、tokenIdsalePriceを入力として受け取り、支払い先とロイヤリティ額を返すことで、マーケットプレイスが自動的にロイヤリティ情報を取得できる仕組みを提供します[2]。ただし、ERC-2981は強制メカニズムではなく、あくまで「シグナリング標準」であるため、実際の支払いの履行はOpenSeaやRaribleなどのマーケットプレイスのポリシーに依存します[3]。この標準は、OpenZeppelinのライブラリを通じて広く実装されており、開発者が簡単に導入できるようになっています[4]。また、EVM互換チェーン上での利用も可能で、PolygonやArbitrumなどでも採用が進んでいます。一方で、Blurのようなロイヤリティフリーのマーケットプレイスの台頭により、実際の支払い履行が不透明になるという課題も抱えています[5]。ERC-2981は、NFTエコシステムにおけるクリエイターの持続可能な収益化を支援する基盤技術として位置付けられていますが、その効果はマーケットプレイスの協力に大きく左右されます。

概要と目的

ERC-2981は、イーサリアム上で動作する非代替性トークン(NFT)におけるロイヤリティ支払いを標準化するためのイーサリアム改善提案(EIP)であり、2020年9月に導入されました[1]。この標準は、ERC-721やERC-1155といった既存のNFT規格と互換性を持ち、スマートコントラクトが二次販売時のロイヤリティの受取人アドレスと金額を一貫して伝達できるようにします。ERC-2981の中心となる関数royaltyInfoは、tokenIdsalePriceを入力として受け取り、支払い先とロイヤリティ額を返すことで、マーケットプレイスが自動的にロイヤリティ情報を取得できる仕組みを提供します[2]

問題解決の目的

ERC-2981が目指す主な目的は、NFTエコシステムにおけるロイヤリティ支払いの断片化を解消することです。導入以前、NFTの二次販売時にクリエイターに支払われるロイヤリティの額や支払い先を決定する統一的な方法が存在せず、各プロジェクトが独自の実装を採用していました。これにより、マーケットプレイス間での互換性が失われ、クリエイターが確実に収益を得ることが困難になっていました[8]。ERC-2981は、すべてのNFTコントラクトやマーケットプレイスが採用可能な単一の相互運用可能な標準を提供することで、この問題を解決します。これにより、ロイヤリティ情報が透明性を持ち、容易にアクセス可能で、一貫した形式で提供されるようになり、イーサリアムエコシステム全体での整合性が向上します[3]

標準化の意義

ERC-2981は、ロイヤリティ支払いの「シグナリング標準」として機能します。これは、マーケットプレイスがロイヤリティの条件を知ることができる一方で、その支払いを強制するメカニズムではないことを意味します。代わりに、支払いの履行はOpenSeaやRaribleなどのマーケットプレイスのポリシーに委ねられます[10]。このシグナリング機能により、異なるマーケットプレイス間での統合がシームレスになり、各プロジェクトごとにカスタムロジックを実装する必要がなくなります[11]。その結果、クリエイターはコントラクトレベルでロイヤリティの条件を定義でき、それ以降のすべての販売で継続的に収益を得られるようになります[12]

技術的特徴と利点

ERC-2981の主な特徴の一つは、そのシンプルさと相互運用性です。royaltyInfo関数は、ERC-721やERC-1155を含む、さまざまなNFT標準に統合可能であり、開発者が既存のコントラクトにロイヤリティ機能を追加しやすくしています[2]。また、OpenZeppelinのような信頼できるライブラリがIERC2981インターフェースとヘルパー契約を提供しているため、実装はさらに容易になります[4]。この標準は、EVM互換チェーン上での利用も可能で、PolygonやArbitrumなどでも採用が進んでいます。ERC-2981は、NFTエコシステムにおけるクリエイターの持続可能な収益化を支援する基盤技術として位置付けられていますが、その効果はマーケットプレイスの協力に大きく左右されます。

核心機能と技術仕様

ERC-2981は、イーサリアム上で動作する非代替性トークン(NFT)におけるロイヤリティ支払いを標準化するための技術仕様であり、その中心となるのはroyaltyInfo関数である[1]。この関数は、NFTの二次販売時にマーケットプレイスがロイヤリティ情報を自動的に取得できるように設計されており、スマートコントラクトがtokenId(トークン識別子)とsalePrice(販売価格)を入力として受け取ると、支払い先アドレスとロイヤリティ額を返す仕組みになっている[2]。この標準化により、ERC-721やERC-1155といった異なるNFT規格間での互換性が確保され、開発者やマーケットプレイスが一貫した方法でロイヤリティ情報を扱えるようになる。

royaltyInfo関数の詳細な動作

royaltyInfo関数は、ERC-2981の唯一の必須関数であり、そのインターフェースは以下のように定義されている[17]

function royaltyInfo(uint256 tokenId, uint256 salePrice)
    external view returns (address receiver, uint256 royaltyAmount);

この関数は、tokenIdによって特定されるNFTと、そのsalePriceに基づいて、ロイヤリティの受取人receiverと支払額royaltyAmountを返す。例えば、ロイヤリティ率が5%(500ベーシスポイント)に設定されており、NFTが1 ETH で取引された場合、royaltyAmountは0.05 ETH(50,000,000,000,000,000 wei)となる[1]。この計算は、コントラクト内部でroyaltyBasisPoints(ベーシスポイント)とroyaltyRecipient(受取人アドレス)として事前に定義された値に基づいて行われる。関数はview型であり、ブロックチェーンの状態を変更しないため、呼び出しにガスがほとんどかからず、マーケットプレイスがオフチェーンで簡単にクエリできる点が利点である[19]

ERC-165によるインターフェース検出

ERC-2981は、ERC-165標準を基盤としており、スマートコントラクトが自身がサポートするインターフェースを広告できる仕組みを提供している[1]。ERC-2981準拠のコントラクトは、supportsInterface関数を実装し、ERC-2981のインターフェース識別子0x2a55205aが渡された場合にtrueを返す必要がある。これにより、OpenSeaやRaribleなどのマーケットプレイスは、特定のNFTコントラクトがロイヤリティ情報を提供可能かどうかをプログラムで検出できる。この仕組みは、エコシステム全体の相互運用性を確保する上で極めて重要であり、royaltyInfo関数が実装されていてもsupportsInterfaceが正しく設定されていなければ、マーケットプレイスはそのコントラクトをロイヤリティ対応として認識しない可能性がある[21]

実装パターンと開発者向け考慮事項

開発者は、OpenZeppelinが提供するIERC2981インターフェースやERC721Royalty拡張機能を利用することで、ERC-2981を簡単に実装できる[4]。代表的な実装パターンとして、グローバルなロイヤリティ(すべてのトークンに共通)や、トークンごとの個別ロイヤリティ(マッピングで管理)が存在する。また、ロイヤリティ率は通常、10,000ベーシスポイント(100%)を最大値として、整数で定義されるため、1%は100、5%は500として表現される[23]。ガス効率を高めるため、計算は単純な整数演算(royaltyAmount = (salePrice * royaltyBasisPoints) / 10000)で行われるべきであり、ループや外部コールを避けることで、予測可能な低コストな実行が可能となる[24]。セキュリティ上、ロイヤリティ設定の変更はOwnableAccessControlなどのアクセス制御メカニズムで保護され、不正な変更を防ぐ必要がある[2]

ERC-721およびERC-1155との統合

ERC-2981は、既存の非代替性トークン(NFT)標準であるERC-721およびERC-1155と完全に互換性を持つように設計されたインターフェースであり、これらの規格にロイヤリティ支払いのシグナリング機能を追加することで、クリエイターの収益化を支援します[1]。この統合により、異なる種類のEVM互換チェーン上で動作するNFTが、二次販売時のロイヤリティ情報を一貫して伝達できるようになります。

ERC-721との統合

ERC-2981は、ERC-721標準にシームレスに統合されるよう設計されています。開発者は、ERC-721ベースのスマートコントラクトにIERC2981インターフェースを実装し、royaltyInfo関数をオーバーライドすることで、ロイヤリティ情報を提供できます[17]。この関数は、tokenIdsalePriceを入力として受け取り、支払い先のアドレスとロイヤリティ額を返します。これにより、OpenSeaやRaribleなどのマーケットプレイスは、取引前にロイヤリティ情報を自動的に取得できます[2]

統合には、ERC-2981のインターフェースID(0x2a55205a)を正しく宣言するため、supportsInterface関数を適切にオーバーライドする必要があります。これは、EIP-165に準拠したインターフェース検出メカニズムであり、マーケットプレイスがコントラクトがロイヤリティをサポートしているかどうかを判断するために使用します[1]。OpenZeppelinのライブラリには、ERC721Royaltyのような参照実装が含まれており、開発者が簡単に安全に統合できるようになっています[4]

ERC-1155との統合

ERC-2981は、複数のトークンタイプを単一のコントラクト内で管理するERC-1155標準にも適用可能です。ERC-1155コントラクトは、グローバルまたはトークンごとのロイヤリティ設定を実装し、royaltyInfo関数を通じて情報を提供できます[21]。特に、safeBatchTransferFromのような一括転送操作をサポートするERC-1155では、マーケットプレイスがバンドル販売の各トークンに対してroyaltyInfoを個別にクエリして、合計ロイヤリティを正確に計算する必要があります[32]

ERC-1155との統合では、インターフェースのサポートを正しく宣言することが特に重要です。supportsInterface関数がERC-2981のインターフェースIDに対してtrueを返さないと、マーケットプレイスはロイヤリティ情報を認識できず、支払いが行われない可能性があります[33]。GitHub上には、ERC-1155とERC-2981を統合した実装例が公開されており、OpenSeaとの互換性を確保するための具体的なパターンを示しています。

統合における実装上の考慮事項

ERC-721およびERC-1155との統合においては、以下の点に注意する必要があります。まず、royaltyInfo関数はview関数として実装され、ガス効率が高く、ストレージ読み取りや複雑なロジックを避けるべきです。これは、マーケットプレイスがオフチェーンで頻繁に呼び出すため、高コストな実行は統合を妨げる可能性があります[5]。また、ロイヤリティの計算は通常、10,000基点(100%)を分母とする固定のロイヤリティ率(ベーシスポイント)に基づいて行われます。

セキュリティの観点から、ロイヤリティの受取人や率を変更する関数には、OpenZeppelinのOwnableAccessControlのようなロールベースのアクセス制御を適用し、不正な変更を防ぐ必要があります[2]。さらに、ERC-2981はアップグレード可能なコントラクトとも互換性があり、プロキシパターンを使用して既存のERC-721やERC-1155コントラクトにロイヤリティ機能を追加することが可能です[36]

マーケットプレイスにおける採用状況

NFTマーケットプレイスにおけるERC-2981の採用は、業界全体での標準化の動きを反映しつつも、一貫性に欠ける状況にあります。ERC-2981は、スマートコントラクトがロイヤリティの受取人アドレスと金額を一貫して伝達できる「シグナリング標準」[1]として設計されており、OpenSeaやRaribleといった主要プラットフォームがその信号を認識することが可能になっています。しかし、ERC-2981は強制メカニズムではなく、あくまで「シグナリング」に留まるため、実際にロイヤリティが支払われるかどうかは、各マーケットプレイスのポリシーに大きく依存します[3]

主要マーケットプレイスの対応

主要なマーケットプレイスの対応は分かれています。OpenSeaはERC-2981をサポートしており、スマートコントラクトとの統合を通じてロイヤリティ情報を認識できるようになっています[39]。しかし、2023年に「Operator Filter」を廃止したことで、実質的にロイヤリティの支払いを任意とし、ユーザーがロイヤリティを回避できる環境を容認しています[5]。これにより、ERC-2981で信号されたロイヤリティであっても、支払いが保証されない状況が生じています。

一方、Raribleは、Community Marketplace Program (CMP)を通じてロイヤリティの強制執行を明確に掲げており、外部のリストから取引された場合でもロイヤリティを適用しています[41]。Art BlocksやKnownOriginもERC-2981を公式に採用し、クリエイターの収益化を支援する方針を示しています[11]Nifty GatewayやReservoirもERC-2981を明示的にサポートしており、ロイヤリティ信号のインフラとして機能しています[43]

ロイヤリティフリー・マーケットプレイスの台頭

ERC-2981の効果を大きく損なう要因として、Blurを代表とする「ロイヤリティフリー」マーケットプレイスの台頭があります。Blurはプロのトレーダーをターゲットに、ゼロロイヤリティでの取引を可能にし、OpenSeaのOperator Filterを回避することで、ロイヤリティ支払いを強制しようとする仕組みを無効化しています[44]。この戦略により、取引手数料を抑えた競争力のある環境を提供し、多くの取引量を獲得しています。その結果、クリエイターの二次販売収益が大幅に減少し、Yuga Labsなどの大手プロジェクトでも収益への影響が報告されています[45]

採用率と業界トレンド

ERC-2981の採用率は、2026年初頭時点で、新設されるNFTマーケットプレイスの約73%がサポートしていると報告されています[24]。また、約43%のNFTクリエイターがこの標準を用いて動的なロイヤリティを埋め込んでいるとされています。これは、ERC-2981がデジタルアートやコレクティブルの分野でクリエイター補償のための主要なメカニズムとして認識されていることを示しています。

しかし、この採用率と実際の支払い履行率の間には大きなギャップがあります。マーケットプレイスのポリシーが変化することで、信号されたロイヤリティが無視される「ロイヤリティ・ウォッシング(Royalty Washing)」の問題が生じており、クリエイターの信頼を損なう要因となっています[47]。この状況は、ERC-2981が技術的には成功を収めても、経済的・倫理的な観点からその効果が不確実であることを示しています。

将来の展望と補完的ソリューション

このような課題に対応するため、ERC-2981を補完する新たな試みが進んでいます。OpenSeaは2024年に、新しいオンチェーンツールを導入し、新規コレクションに対してロイヤリティの強制執行を再び開始しています[48]。また、ERC-2981の信号をもとに、取引決済時にロイヤリティを正規化して適用するミドルウェアとして、Reservoirのようなインフラプロバイダーが注目されています[49]

さらに、ERC-2981の「信号のみ」の限界を克服するため、転送時にロイヤリティ支払いを強制するERC-721Cや、階層的なロイヤリティ構造を可能にするERC-4910といった、オンチェーンで強制可能な新しい標準の開発も進んでいます[50]。これらの技術的進化は、マーケットプレイスの任意のポリシーに頼らず、クリエイターの持続可能な収益化を実現するための次のステップとして期待されています。

実装上の課題と制限

ERC-2981は、非代替性トークン(NFT)におけるロイヤリティ支払いのシグナリングを標準化する重要な仕様である一方で、実際の導入には多くの技術的・経済的課題が伴います。この標準はあくまで「シグナリング」に留まり、支払いの強制力を持たないため、その効果は外部の要因に大きく依存します。以下に、ERC-2981の実装における主な制限と課題を詳細に説明します。

強制力の不在と任意の遵守

ERC-2981最大の課題は、それが強制メカニズムではなく、シグナリング標準である点です。標準はroyaltyInfo関数を通じて、ロイヤリティの受取人アドレスと金額を伝える仕組みを提供しますが、マーケットプレイスが実際に支払いを行うかどうかは、そのポリシーに委ねられます [23]。このため、ERC-2981を実装したNFTであっても、OpenSeaやBlurのような「ロイヤリティフリー」のマーケットプレイスで取引されれば、クリエイターは二次販売時の収益を得られない可能性があります [5]。特に2023年にOpenSeaが「Operator Filter」を廃止したことで、ロイヤリティの遵守はさらに任意のものとなり、クリエイターの期待される収益モデルに深刻な影響を及ぼしています [53]

マーケットプレイス間の不一致と断片化

マーケットプレイス間でのERC-2981のサポート状況は一貫していません。一部のプラットフォーム(Rarible、KnownOrigin、Nifty Gateway)は積極的にこの標準を採用し、ロイヤリティの支払いを尊重していますが、他のプラットフォームは部分的にしか実装していなかったり、完全に無視したりするケースもあります [54]。この断片化は、クリエイターにとって予測不可能な収益環境を生み出します。また、ERC-2981を正しく実装していても、マーケットプレイス側の統合が不十分な場合、ロイヤリティ情報が正しく読み取られず、支払いが行われないという技術的な問題も発生します [24]

ロイヤリティ構造の柔軟性の欠如

ERC-2981は静的かつ単一受取人モデルに限定されており、複雑な収益分配には対応できません。標準は、販売価格の固定割合を一つのアドレスに送金するというシンプルな構造を前提としています。これにより、以下のような高度な要件を満たすことが困難です:

  • 段階的ロイヤリティ(販売価格に応じて変動するレート)
  • 時間経過によるレート変更
  • 複数当事者への収益分配(例:アーティスト、開発者、投資家間の分割)
  • 所有期間や販売量に基づく動的条件

この制限は、知的財産ライセンスや協働プロジェクトのような複雑な収益化戦略を必要とするプロジェクトにとって大きな障壁となります [23]。一部のプロジェクトは、0xSplitsのようなサードパーティサービスを組み合わせることで、多様な分配を実現していますが、これは標準外のカスタム実装であり、互換性が損なわれる可能性があります [57]

技術的実装の複雑さとセキュリティリスク

ERC-2981を正しく実装するには、技術的な正確さが求められます。特に以下の点に注意が必要です:

  • royaltyInfo関数が有効な受取人アドレスとロイヤリティ額を正確に返すよう実装されていること。
  • supportsInterface関数が、ERC-2981のインターフェースID(0x2a55205a)を正しく認識し、trueを返すよう設定されていること [19]
  • ERC-721やERC-1155といった既存のトークン標準との統合が、既存の機能を損なわないよう設計されていること。

これらの実装に失敗すると、マーケットプレイスがロイヤリティデータを認識できず、たとえ論理的に正しくても支払いが行われない事態が発生します [59]。また、スマートコントラクトの性質上、ロイヤリティ額の計算ミスや資金のロック、機密関数の公開など、セキュリティ上の脆弱性が生じるリスクがあります [2]。開発者は、OpenZeppelinが提供する十分に監査されたライブラリを使用することで、これらのリスクを軽減することが推奨されます [17]

既存のコントラクトとの後方互換性

ERC-2981は2020年に導入されたため、それ以前にリリースされた多くのNFTプロジェクトはこの標準をサポートしていません。これらの「レガシー」コントラクトにERC-2981を導入するには、新しいコントラクトをデプロイするか、プロキシパターンを使用する必要がありますが、これらはコストがかかり、技術的にも複雑です [62]。さらに、既存のコントラクトをアップグレードしても、supportsInterface関数が正しく更新されていなければ、マーケットプレイスは依然としてロイヤリティを認識しない可能性があります。

セキュリティとテストの懸念

ERC-2981の実装には、ゼロ価格の販売、高精度な計算、クロスチェーン転送など、さまざまなシナリオでのテストが不可欠です [63]。これらのエッジケースを適切に処理できていないと、予期せぬバグや資金損失につながる可能性があります。開発者は、HardhatやEthersなどのツールを用いて、包括的なテストを実施する必要があります。

ガス効率と最適化手法

ERC-2981は、イーサリアム上の非代替性トークン(NFT)におけるロイヤリティ支払いのシグナリングを標準化するための仕様であり、その実装にはガス効率が重要な課題となる。スマートコントラクトのガス消費量は、トランザクションコストに直接影響するため、特に二次販売時のロイヤリティ計算を伴うroyaltyInfo関数の設計には、効率的な実装が求められる。この関数は、tokenIdsalePriceを入力として受け取り、受取人アドレスとロイヤリティ額を返すview関数であるが、その内部処理に複雑な計算やストレージ読み取りが含まれると、ガスコストが不必要に上昇する可能性がある[1]

ガス効率の課題と最適化戦略

ERC-2981を実装する際の主なガス効率の課題は、royaltyInfo関数の呼び出しに伴う追加の計算負荷にある。この関数は、マーケットプレイスが二次販売を処理する際にクエリされるため、ガス効率が低い実装では、取引全体のコストが上昇し、ユーザー体験を損なう可能性がある。特に、ロイヤリティ率の計算に動的なロジックや複数のストレージ変数へのアクセスが含まれる場合、ガス消費量が増加する[65]

これを回避するための最適化手法として、まず、ロイヤリティ率を固定値としてストレージに保存することが挙げられる。例えば、ロイヤリティ率を「10,000基点」(100%)を最大とする整数(uint96uint16)で保持することで、毎回の計算を避けることができる。また、計算式において分母を定数(例: 10000)として定義することで、計算の複雑さを軽減し、ガスコストを削減できる。以下は最適化された実装の例である。

function royaltyInfo(uint256, uint256 salePrice)
    external view override
    returns (address receiver, uint256 royaltyAmount)
{
    receiver = royaltyReceiver;
    uint256 royalty = (salePrice * royaltyBasisPoints) / 10000;
    return (receiver, royalty);
}

このように、ロジックをシンプルに保ち、ループや外部コール、条件分岐を避けることで、ガスの予測可能性と効率性を高めることができる[4]

バックワード互換性とインターフェース検出

ERC-2981の実装には、ガス効率だけでなく、既存のエコシステムとの互換性も重要である。特に、ERC-165によるインターフェース検出は、マーケットプレイスがERC-2981をサポートしているかどうかを判別するために不可欠である。コントラクトは、supportsInterface(bytes4 interfaceId)関数を正しく実装し、ERC-2981のインターフェースIDである0x2a55205aに対してtrueを返さなければならない。この検出が失敗すると、OpenSeaやRaribleなどのマーケットプレイスはロイヤリティ情報を認識できず、結果として支払いが行われない[1]

function supportsInterface(bytes4 interfaceId)
    public view virtual override returns (bool)
{
    return super.supportsInterface(interfaceId) ||
           interfaceId == type(IERC2981).interfaceId;
}

この実装は、ガス効率にも寄与する。supportsInterfaceは通常、トランザクションの一部としてではなく、オフチェーンで呼び出されるため、シンプルな論理演算に留めることで、全体のガス負荷を最小限に抑えることができる[68]

アップグレード可能なコントラクトとの統合

多くのプロジェクトでは、アップグレード可能なスマートコントラクトを採用しており、ERC-2981の統合もこのパターンに対応する必要がある。OpenZeppelinが提供するERC2981Upgradeable.solは、アップグレード可能な環境での安全な実装を可能にする。この場合、コンストラクタの代わりにイニシャライザ関数を使用し、ストレージレイアウトを維持することが、ガス効率とセキュリティの両面で重要となる[69]

ガス効率とエコシステムの調和

ERC-2981は、EVM互換チェーン上でも同様に動作するため、PolygonやArbitrumなどのレイヤー2ネットワークにおいても、ガス効率が重要な設計指針となる。これらのチェーンではガス手数料が低くなる傾向にあるが、依然として効率的なコードはスケーラビリティとユーザーアクセスの向上に寄与する。開発者は、Solidityの最適化機能や、OpenZeppelinの監査済みライブラリを活用することで、ガス効率とセキュリティの両立を図ることができる[70]

著作権および法的枠組みとの関係

ERC-2981は、イーサリアム上で動作する非代替性トークン(NFT)におけるロイヤリティ支払いの標準化を目的とした技術的仕様であり、その性質上、既存の知的財産権および著作権の法的枠組みとの関係において重要な位置を占めています。しかし、ERC-2981自体は法的拘束力を持つものではなく、あくまでロイヤリティの受取人アドレスと金額をマーケットプレイスに「通知」するためのシグナリング標準に過ぎません [1]。このため、ERC-2981が信号するロイヤリティが実際に支払われるかどうかは、OpenSeaやRaribleといったマーケットプレイスのポリシーに依存しており、法的義務としての強制力は持ちません [23]

ERC-2981と知的財産権の乖離

NFTの所有権と背後にある知的財産権(IP)の所有権は、法的に別個の概念です。ERC-2981はNFTの二次販売におけるロイヤリティの支払いを促進する技術的手段を提供しますが、NFTの購入者が自動的に著作権や商標権を取得するわけではありません [73]。通常、NFTの購入はそのデジタル資産の「所有」または「真正性の証明」を意味するに過ぎず、作品の複製、公衆送信、派生作品の作成といった権利は、明示的にライセンス契約を通じて移転されない限り、創作者が保持し続けます。ERC-2981はこのライセンスの内容を定義するものではなく、あくまで経済的報酬(ロイヤリティ)の流れを技術的に通知するに留まります。そのため、ERC-2981が信号するロイヤリティが法的な著作権使用料(ロイヤルティ)として位置づけられるかどうかは、別途の法的契約やライセンスに依存します。

EUの「ドワ・ド・シュイ」(droit de suite)との比較

欧州連合(EU)の「ドワ・ド・シュイ」(resale rights directive, 2001/84/EC)は、視覚芸術作品の原作が再販売された際に、その芸術家が売上価格の一定割合を受け取る権利を保障する法律です。この権利は、著作権が譲渡された後も存続し、売買の当事者がそれを放棄することはできません。ERC-2981は、この法的権利の目的と似た「二次販売からの継続的報酬」という理念を共有しています。しかし、決定的な違いがあります。ドワ・ド・シュイは、EU加盟国において法的に強制力を持つ「権利」ですが、ERC-2981は法的拘束力を持たない「技術的信号」です [74]。さらに、現行のドワ・ド・シュイは「物理的な芸術作品」に適用されるものであり、NFTのようなデジタル資産には明確に適用されていません [75]。この法的ギャップを埋めるため、ERC-2981はブロックチェーン上でのロイヤリティ支払いを標準化する「技術的インフラ」として機能し得ますが、法的義務を創出するものではありません。

法的執行可能性と規制の課題

ERC-2981によるロイヤリティ支払いの法的執行可能性は、未だに不透明です。スマートコントラクトに記述されたroyaltyInfo関数の出力が、法的に拘束力のある契約条項と見なされるかは、裁判所の判例や管轄区域の法律に大きく依存します [76]。特に、匿名性や国境を越えた取引が可能な分散型環境では、責任の所在や管轄権の特定が困難であり、法的執行が現実的に難しい場合があります。この問題に対処するため、ERC-5635(NFTライセンス契約)やERC-5553(知的財産権およびそのロイヤリティ構造の表現)といった、ブロックチェーン上にライセンス条項を明示的に記録する新しい標準の開発が進められています [77][78]。これらの標準は、ERC-2981の技術的信号と法的契約を統合し、スマートコントラクトの実行と法的責任の両立を目指す「ハイブリッド」アプローチを可能にします。

政策的含意と未来の展望

ERC-2981の存在は、既存の著作権法とデジタル資産の経済モデルの間に生じる「ギャップ」を浮き彫りにしています。ブロックチェーン技術は、再販時のロイヤリティを自動的に追跡・支払いするための理想的な技術基盤を提供していますが、その実効性を担保するためには、法律の整備や規制の進化が不可欠です。EUをはじめとする各国の規制当局は、NFT市場の成長に伴い、デジタル芸術作品に対する再販権の適用拡大について議論を始めています [79]。将来的には、ERC-2981のような技術的標準が、法的枠組みと連携し、集団管理組織(CMO)が二次販売データを監視・集計する仕組みと統合されることで、デジタル時代に適した、持続可能な創作者報酬システムが構築される可能性があります。ERC-2981は、法的解決を待つ間の「一時的な技術的緩衝材」としての役割を果たしているとも言えるでしょう。

新しいロイヤリティ標準との比較

ERC-2981は、非代替性トークン(NFT)におけるロイヤリティのシグナリングを標準化するための重要な基盤技術として広く採用されていますが、その「シグナリング標準」に留まる性質から、実際の支払い履行には限界があります。この課題を解決するために、ERC-2981の機能を補完または置き換える新たなロイヤリティ標準や技術的アプローチが登場しており、オンチェーンでの強制的なロイヤリティ支払いを実現する方向に進化しています。

ERC-721C:オンチェーンで強制可能なロイヤリティ

ERC-721Cは、Limit Break社が提唱した新しい標準であり、ERC-2981の最大の弱点である「非強制性」を直接解決することを目的としています[50]。ERC-2981が単にroyaltyInfo関数を通じてロイヤリティ情報を提供するだけなのに対し、ERC-721Cはロイヤリティ支払いをNFTの転送プロセスそのものに組み込みます。具体的には、NFTの転送が発生した際、スマートコントラクトが自動的にロイヤリティの支払いを要求し、支払いが完了しない限り転送を完了させない仕組みです。これにより、マーケットプレイスのポリシーに依存することなく、真正なオンチェーンでの強制が可能になります[5]。ERC-721Cは、OpenSeaを含む主要マーケットプレイスでの統合が進んでおり[48]、今後のロイヤリティ標準の有力候補となっています。

ERC-4910:階層的なロイヤリティ構造の実現

ERC-4910(Royalty Bearing NFTs)は、ERC-2981の機能を拡張し、より複雑なロイヤリティ構造をサポートすることを目指すEIPです[83]。ERC-2981が単一の受取人に対して静的なロイヤリティ率を定義するのに対し、ERC-4910は複数の当事者(例:アーティスト、コラボレーター、コミュニティ財団)に異なる割合でロイヤリティを自動分配する「階層的なロイヤリティ構造」を可能にします。これは、複数のクリエイターが関与するプロジェクトや、収益の一部を特定のDAOに還元するようなユースケースに適しています。ERC-4910は、ERC-2981と同様にシグナリング標準の側面を持ちつつ、より高度なロイヤリティ処理のためのオンチェーンロジックを提供することで、その適用範囲を広げています。

スマートコントラクトベースのロイヤリティ分割

ERC-2981やERC-4910とは異なるアプローチとして、ロイヤリティ分割をスマートコントラクトに直接組み込むカスタム実装があります。この方法では、NFTの売却取引自体の中にロイヤリティの分配ロジックをハードコードし、取引の一部として自動的に支払いを実行します。例えば、0xSplitsというプロトコルは、売却金額を複数のアドレスに事前に設定された割合で分配する機能を提供しており、Art Blocksなどのプロジェクトで採用されています[57]。このアプローチは非常に高い制御性と強制性を提供しますが、その代償として、標準化が進んでおらず、各プロジェクトが独自に開発する必要があるため、開発コストが高く、相互運用性(相互運用性)に課題があります[62]

プラットフォーム固有のロイヤリティシステム

技術標準とは別に、マーケットプレイスが独自のポリシーと技術でロイヤリティを強制するモデルも存在します。Raribleは、その代表例です。Raribleは、自社のマーケットプレイスやコミュニティマーケットプレイス(CMP)内で、ロイヤリティの支払いを契約レベルで強制しています[41]。さらに、OpenSeaやLooksRareのようにロイヤリティをバイパスできるマーケットプレイスからの注文を集約することを停止することで、ロイヤリティ保護を強化しています。このように、プラットフォーム固有のシステムは、そのエコシステム内では高い強制性を発揮できますが、他のマーケットプレイスやチェーンにまたがる取引では効力を発揮しません。

比較と今後の展望

特徴 ERC-2981 ERC-721C ERC-4910 スマートコントラクト分割 プラットフォーム固有
標準化 高い 中程度 中程度 低い 低い
強制性 なし(シグナリングのみ) 高い(オンチェーン強制) 中程度(拡張可能なロジック) 高い(カスタムロジック) 高い(ポリシー依存)
相互運用性 高い(全マーケットプレイス対応) 中程度 中程度 低い 低い(プラットフォーム限定)
開発難易度 低い 中程度 中程度 高い 中程度
柔軟性 低い(単一受取人、固定率) 中程度 高い(階層的構造) 非常に高い 中程度

ERC-2981は、ロイヤリティの標準化という点で画期的な役割を果たしましたが、その非強制性という本質的な欠点が、Blurのようなロイヤリティフリーのマーケットプレイスの台頭により露呈しました[45]。これにより、業界は「シグナリング」から「強制」へのパラダイムシフトを模索しており、ERC-721CやERC-4910といった新しい標準が注目されています。将来的には、ERC-2981の高い相互運用性と、ERC-721Cのようなオンチェーン強制性を組み合わせたハイブリッドモデルが、持続可能なクリエイター経済を支える基盤となる可能性があります[5]

コミュニティガバナンスと将来の展望

ERC-2981の採用と標準化は、イーサリアムエコシステムにおける分散型ガバナンスのプロセスを通じて推進されてきました。この標準は、2020年9月にZach Burks、James Morgan、Blaine Malone、James Seibelらによって提案され、GitHub上での公開な議論やイーサリアム・マジシャンズフォーラムでのコミュニティレビューを経て、イーサリアム改善提案として正式に採択されました[89]。このプロセスは、透明性、包括性、技術的厳密性を重視するイーサリアムのガバナンス理念を反映しており、NFTにおけるロイヤリティ支払いの断片化を解決するための中立的でエコシステム横断的なソリューションとしての地位を確立しました。当初から、強制的な支払いメカニズムではなく、あくまで「シグナリング標準」としての設計が選ばれたことは、検閲耐性やユーザーの自己所有権というイーサリアムの基本原則との整合性を重視したコミュニティ合意の結果でした[1]

開発者合意と実装支援の役割

ERC-2981の事実上の普及を支えたのは、開発者コミュニティの広範な合意と、主要な開発ツールへの統合でした。特に、OpenZeppelinが自社の監査済みスマートコントラクトライブラリにIERC2981.solインターフェースを組み込み、ERC721RoyaltyERC1155Royaltyといった使いやすい拡張機能を提供したことは、導入のハードルを劇的に下げました[17]。この信頼性の高い実装により、開発者はセキュリティリスクを最小限に抑えながら、容易にロイヤリティ機能をNFTプロジェクトに組み込むことが可能になりました。また、ERC-2981がroyaltyInfoという単一のシンプルな関数に焦点を当て、ERC-721やERC-1155といった既存のNFT標準との後方互換性を確保した設計は、モジュール性と相互運用性を高め、開発者からの支持を広く得る要因となりました。その結果、2024年から2025年にかけて、約43%のNFTクリエイターがERC-2981を用いて動的なロイヤリティを埋め込んでおり、これがロイヤリティシグナリングの事実上の標準(de facto standard)としての地位を確固たるものにしています[54]

マーケットプレイスのシグナリングと事実上の強制力

ERC-2981の最大の課題は、それがあくまでシグナリングメカニズムであり、実際の支払いの履行はOpenSeaやBlurといったマーケットプレイスのポリシーに依存する点にあります。ERC-2981は、スマートコントラクト内でのロイヤリティ条件の宣言を可能にしますが、取引の阻止や資金のエスクローは行わず、遵守は完全に任意です[1]。このため、OpenSeaが2023年にオペレーターフィルターのサポートを終了し、ロイヤリティを任意のものにしたことで、支払いの不履行が顕在化しました。同様に、プロフェッショナルトレーダー向けにゼロロイヤリティを謳うBlurの台頭は、エコシステムの断片化を加速させました。しかし、ERC-2981は、技術的強制力こそないものの、規範的・評判的な圧力によって「事実上の強制力(de facto enforceability)」を獲得しています。多くのマーケットプレイスは、クリエイターとの良好な関係を維持し、「クリエイターに優しい」プラットフォームとしての地位を確立するために、引き続きロイヤリティを尊重しています。逆に、ロイヤリティを無視するプラットフォームは、コミュニティからの反発や流動性の低下を招くリスクを負います。この社会的な強制メカニズムと、透明なオンチェーンでのシグナリングが組み合わさることで、NFTエコシステムの大部分でロイヤリティ支払いの文化的な期待が維持されています[94]

将来の展望:シグナリングから強制力へ

ERC-2981の将来は、単なるシグナリングから、より強固なオンチェーン強制力へと進化する方向に向かっています。ERC-2981の限界を補完する新たな標準が登場しており、その中でもERC-721CERC-4910が注目されています。ERC-721Cは、Limit Breakが提唱した標準で、転送機能に直接ロイヤリティ支払いのロジックを組み込むことで、マーケットプレイスのポリシーに関わらず、支払いを技術的に強制可能にします[50]。同様に、ERC-4910は階層的なロイヤリティ構造をサポートし、複数の関係者への自動分配を可能にします[83]。これらの新標準は、ERC-2981が提供する相互運用性の基盤の上に、強制力という新たなレイヤーを追加する形で進化しています。また、royaltyloyaltyのようなプロジェクトは、onRoyaltyReceivedといったコールバックフックをERC-2981に追加することで、支払いの検証やコンテンツのロック解除などの高度なロジックを可能にする拡張を提案しています[97]。将来的には、ERC-2981のような普遍的なシグナリングと、ERC-721Cのような強制力のあるプロトコルレベルのロジックを組み合わせたハイブリッドモデルが、クリエイターに公正な報酬を提供しつつ、分散化の原則を尊重する持続可能なNFT経済の基盤となる可能性があります[5]

参考文献