# [ERC5553] IPの管理やロイヤリティの設定を行う仕組みを理解しよう！

> ERC5553は、「知的財産（IP）」をブロックチェーン上で汎用的に表現する提案しています。対象とするIPの種類は特定されておらず、音楽、動画、本、画像など、さまざまなタイプのIPに対応できます。

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

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、IPの管理やロイヤリティの設定の仕組みを提案している**ERC5553**についてまとめていきます！

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

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

他にも様々なEIPについてまとめています。

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

## 概要

**ERC5553**は、「**知的財産（IP）**」をブロックチェーン上で汎用的に表現する提案しています。
対象とするIPの種類は特定されておらず、音楽、動画、本、画像など、さまざまなタイプのIPに対応できます。
また、ロイヤリティ（使用料）に関する情報の表現方法や、それに紐づくメタデータへのリンクについても標準化します。

業界が今後新しいIP関連エコシステムを自由に構築していけるよう、柔軟かつ共通の基盤となる仕組みを用意することが目的です。

**ERC5553**では以下を可能にします。

- そのIPの“正式な”オンチェーン上の存在を確認できる。
- 関連するメタデータにアクセスできる。
- ロイヤリティの構造を確認できる。

この仕組みを使えばIP資産に関する登録やライセンス発行、支払い処理の仕組みを将来的に構築しやすくなります。

## 動機

現在、IPをオンチェーンでライセンスを発行するための共通の仕組みは存在しません。
NFTを使ってIPを表現することはできますが、これはあくまで「**コレクションアイテム**」としての用途に限られています。

例えば、ある音楽や画像を商用利用するためにライセンスを購入するような複雑なケースには適していません。
このようなユースケースに対応するためには以下の2つが必要です。

- 知的財産がオンチェーン上で正式に登録・記録されていることを示せる。
- 複数の関係者に対して、ロイヤリティを分配できること

前者については、今のところ標準は存在しません。
後者については、例えば「[**0xsplits**](https://github.com/0xSplits)」などの既存のロイヤリティ分配サービスがありますが、これもあくまでNFTの売買を前提とした設計です。
さらに、複数のコラボレーター（作詞者、作曲者、ディレクターなど）を細かく区別して記録する機能は十分とは言えないです。

:::message

:::

## 仕様

**ERC5553**を実装するコントラクトは、**ERC721**を実装する必要があります。  

### インターフェース

```js:IIPRepresentation.sol
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.9;
import '@openzeppelin/contracts/interfaces/IERC165.sol';


///
/// @dev Interface for Intellectual Property Representation
///
interface IIPRepresentation is IERC165 {
    
    /// @notice Called with the new URI to an updated metadata file
    /// @param _newUri - the URI pointing to a metadata file (file standard is up to the implementer)
    /// @param _newFileHash - The hash of the new metadata file for future reference and verification
    function changeMetadataURI(string memory _newUri, string memory _newFileHash) external ;

    /// @return array of addresses of ERC20 tokens representing royalty portion in the IP
    /// @dev i.e implementing ERC5501 (IRoyaltyInterestToken interface)
    function royaltyPortionTokens() external view returns (address[] memory) ;

    /// @return the address of the contract or EOA that initialized the IP registration
    /// @dev i.e., a registry or registrar, to be implemented in the future
    function ledger() external view returns (address) ;

    /// @return the URI of the current metadata file for the II P
    function metadataURI() external view returns (string memory) ;

    /// @dev event to be triggered whenever metadata URI is changed
    /// @param byAddress the addresses that triggered this operation
    /// @param oldURI the URI to the old metadata file before the change
    /// @param oldFileHash the hash of the old metadata file before the change
    /// @param newURI the URI to the new metadata file 
    /// @param newFileHash the hash of the new metadata file 
    event MetadaDataChanged(address byAddress, string oldURI, string oldFileHash, string newURI, string newFileHash);
}
```

### `royaltyPortionTokens`

IPに関係するロイヤリティを表す**ERC20**トークンのアドレス一覧を返す関数。

例えば、音楽作品であれば以下のように、複数の「権利の種類」ごとにトークンが分かれているイメージです。

- 作詞・作曲・出版の権利を表すトークン
- 録音・マスタリングの権利を表すトークン

これにより、関係者（作詞者、レーベル、演奏者など）にそれぞれ適切な割合でトークンを配布しておけば、後でそのトークン保有量に応じてロイヤリティを自動で分配できるようになります。

### `metadataURI`

IPの詳細情報が記載されたメタデータファイルのURI（場所）を返す関数。  
たとえば、曲名、作者、発行日、ライセンス内容などが入ったJSONファイルのIPFSリンクなどが対象です。

このファイルは**IPFSやArweaveなどの分散型ストレージに配置する必要があります**。これにより、改ざんされず、かつリンク切れもしづらくなります。

### `changeMetadataURI`

メタデータURIを別のファイルに更新する関数。

例えば、IPに関する情報が修正された場合（例：著作権の移転、補足情報の追加など）、新しいファイルに差し替えることができます。  
更新が成功すると `MetadataChanged` というイベントが発行され、変更履歴も確認できるようになっています。

### `ledger`

IP登録を最初に行った「発行元」（コントラクト or EOA）のアドレスを返す関数。

以下のようなケースで役立ちます。

- あるIPが複数のマーケットやレジストリに登録されている
- 特定のマーケットがIPに対して追加の操作権限を持っている

このようなときに「**元の管理者は誰なのか？**」を確認する手がかりになります。

### `MetadataChanged`

メタデータURIが変更されたときに発行されるイベント。

変更前と変更後のURIとファイルハッシュ、操作を行ったアドレスがログとして記録されます。  
これにより、いつ誰がどのようにメタデータを変更したのかを確認できるようになります。

## 補足

### ロイヤリティをERC20トークンで分ける利点

**ERC5553**では、複数の**ERC20**トークンを使ってロイヤリティの種類を表現します。
これは、従来のNFTのロイヤリティ設計よりも柔軟で現実的です。

現在主流のNFTのロイヤリティ仕様は、例えば「**販売額の10%をクリエイターに払う**」といった単一のシナリオだけに対応しています。
どんな状況でも、全ての関係者が一律にその割合で報酬を得る仕組みしかありません。

しかし実際の知的財産、特に音楽業界などでは、以下のように状況ごとに支払われるロイヤリティの種類や対象者が変わることが普通です。

#### 例：楽曲のカバーの場合

- 原曲の作詞・作曲者には、歌詞やメロディの使用料が発生する
- 原曲の歌手や演奏者は、録音が使われていないので報酬なし
- 新しいカバーを録音した新しい歌手・演奏者には報酬が発生する
- カバーの作者に作詞・作曲の報酬は発生しない

このように、シチュエーションに応じて報酬を振り分けるには、異なる種類のロイヤリティを個別に管理できる仕組みが必要です。

**ERC20**トークンを使えば、それぞれの権利（作詞、録音など）に対応したトークンを発行し、それを保有している人が自動的に収益を受け取れるようにできます。
加えて、0xsplitsなどのコントラクトに比べて`transfer`や管理が簡単というメリットもあります。

### IP本体とライセンス用途を分けることで拡張性が上がる

**ERC5553**では、IPそのものを表すNFT（IP Representation）と、ライセンスやコレクション用途のNFT（販売、配信、利用など）を別々に設計することを推奨しています。

例えば、ある楽曲をNFTとして販売したい場合、今までは「**音楽NFT**」としてひとつのNFTに全部の情報を詰め込むしかありませんでした。

しかし、**ERC5553**では、まずIPの元となる「本体NFT（IPR）」を作成し、そこから目的に応じて以下のようなNFTを派生させます。

- 商用ライセンス用のNFT
- ストリーミング権利NFT
- 収集用のアートNFT

こうすることで、IPごとにさまざまなユースケースに柔軟に対応できる構造を作れます。

### メタデータの一元的な管理ができる

**ERC5553**では、IPのメタデータ（詳細情報）をIPFSやArweaveのような分散ストレージに保存して、リンクを紐づけるだけで管理できます。

また、情報を更新したい場合はリンクを差し替えるだけでよく、履歴も追跡できるようになっています。

これまでのNFTの仕組みでもメタデータを持つことはできましたが、「どの形式で書かれているか」が曖昧でした。  

## 参考実装

```js:MusicalIP.sol
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.9;
import '@openzeppelin/contracts/token/ERC721/ERC721.sol';
import "./interfaces/IIPRepresentation.sol";
import "./interfaces/Structs.sol";


contract MusicalIP is ERC721, IIPRepresentation {
    address public songLedger;
    address public compToken;
    address public recToken;
    string public metadataURI;
    string public fileHash;
    uint256 public tokenId;
    bool public activated =false;

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

    function getInterfaceId() public pure returns (bytes4){
        return type(IIPRepresentation).interfaceId;
    }

    constructor (
        uint256 _tokenId,
        address _songLedger,
        SongMintingParams memory _params,
        address _compAddress,
        address _recAddress
        )
    ERC721(_params.shortName, _params.symbol){

        songLedger = _songLedger;
        compToken = _compAddress;
        recToken = _recAddress;
        metadataURI = _params.metadataUri;
        fileHash = _params.fileHash;
        tokenId = _tokenId;
        
        _safeMint(_songLedger, _tokenId);
        emit Minted(_params.shortName,_songLedger,_compAddress,_recAddress,_msgSender(),tokenId,_params.metadataUri);
    }

    function changeMetadataURI(string memory _newURI,string memory _newFileHash) public 
     {
        string memory oldURI = metadataURI;
        string memory oldHash = fileHash;
        metadataURI = _newURI; 
        fileHash = _newFileHash;
        
        emit MetadataChanged(oldURI, oldHash,_newURI,_newFileHash);
    }
    
    function royaltyPortionTokens() external view returns (address[] memory) {
        address[] memory items = new address[](2); 
        items[0] = compToken;
        items[1] = recToken;
        return items;
    }
    function ledger() external view returns (address) {
         return songLedger;
    }

    event MetadataChanged(
        string  oldUri, string oldFileHash,
        string  newUri, string newFileHash
        );
    event Minted(
        string  abbvName,
        address ledger,
        address compToken,
        address recToken,
        address creator,
        uint256 tokenId,
        string metadataUri
        );
}
```

## セキュリティ

### ロイヤリティトークンに関するリスク

**ERC5553**では、ロイヤリティの分配を**ERC20**トークンで行う仕組みになっていますが、それに伴っていくつかのリスクもあります。

例えば、悪意のある第三者が、ロイヤリティトークンの保有者をうまく言いくるめてトークンを送らせることで、本来受け取る権利のないロイヤリティを手に入れてしまう可能性があります。
これ自体は、この仕組みに特有のリスクではなく、**ERC20**トークン全般で共通して存在する問題です。

つまり、トークンを送ってしまった時点で、その人が受け取るはずだったロイヤリティの一部も、新たな持ち主に移ってしまうということです。

この問題を防ぐには、トークンを軽々しく他人に送らないよう啓発することや、ウォレットUIでの警告表示などの対策が重要になります。

### IP登録の所有権の扱いについて

「**IPの登録そのものの所有者（オーナーシップ）を誰に持たせるべきか？**」という疑問があります。

**ERC5553**では、IP登録を誰か個人ではなく、レジストリ用のコントラクト（＝IPを管理するコントラクト）に持たせるべきとしています。

さらに、その所有権は他人に譲渡できないようにして、そのIP登録は最初に登録したレジストリに紐付けられたままにすることが望ましいとされています。

このようにすることで、不正にIPの登録権を奪われたり、勝手に他のレジストリへ移されたりするのを防ぐことができます。

## 引用

Roy Osherove (@royosherove), "ERC-5553: Representing IP and its Royalty Structure [DRAFT]," Ethereum Improvement Proposals, no. 5553, August 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5553.

## 最後に

今回は「IPの管理やロイヤリティの設定の仕組みを提案している**ERC5553**」についてまとめてきました！
いかがだったでしょうか？

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

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

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

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

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