Skip to content

Commit

Permalink
Review EIP-5553 : Representing IP and its Royalty Structure (ethereum…
Browse files Browse the repository at this point in the history 
…#5611)

* wording "intellectual property"

* change magicians link

* grammar

* ignore .vscode directory

* fix

* rename work to IP

* use "portion" instead of "rights" for tokens.

* Switch to Review

* back to Draft
  • Loading branch information
@royosherove @nachomazzara
royosherove authored and nachomazzara committed Jan 13, 2023
1 parent 1b89eef commit 62f5c56
Showing 1 changed file with 26 additions and 26 deletions.
52 changes: 26 additions & 26 deletions EIPS/eip-5553.md
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
eip: 5553
title: Representing IP and its Royalty Structure
description: A way of representing intellectual property and its respective royalty rights on chain
description: A way of representing intellectual property and its respective royalty structure on chain
author: Roy Osherove (@royosherove)
discussions-to: https://ethereum-magicians.org/t/eip-5553-representing-intellectual-property-on-chain-with-royalty-rights/10551
status: Draft
Expand All @@ -12,21 +12,21 @@ requires: 20, 721
---

## Abstract
This proposal introduces a generic way to represent intellectual property on chain, along with a refined royalty representation mechanism and associated metadata link. This standard is not associated with a specific type of work and could represent many types of IP such as musical works and recordings, videos, books, images, and more.
This proposal introduces a generic way to represent intellectual property on chain, along with a refined royalty representation mechanism and associated metadata link. This standard is not associated with a specific type of IP and could represent many types of IP such as musical IP, videos, books, images, and more.
The standard is kept very generic on purpose to allow the industry to evolve new ecosystems that can all rely on the same basic standard at their core.

This standard allows market participants to:
1) Observe the canonical on-chain representation of an intellectual property
2) Discover its attached metadata
3) Discover its related royalty rights holders
3) Discover its related royalty structure
4) In the future, this will enable building registration, licensing, and payout mechanisms for intellectual property assets.

## Motivation

There is no accepted standard mechanism to license intellectual property or to represent it, except using traditional NFTs. But regular NFTs only represent a collectible item use case, and cannot easily represent more complicated use cases of licensing IP for different types of uses.
To enable such mechanisms, a more robust mechanism is needed to:
1) Declare that IP exists, SEPARATELY from its purchase ability
2) Declare possibly multiple interested parties to be paid for such work
2) Declare possibly multiple interested parties to be paid for such IP

For 1, no standard exists today.

Expand All @@ -43,19 +43,19 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
This standard extends [EIP-721](./eip-721.md) with the following `IIPRepresentation` (IPR for short) interface.
Implementers of this standard **MUST** have all of the following functions:

### royaltyRightsTokens() function
This function MUST return an array of addresses related to [EIP-20](./eip-20.md) tokens that MUST represent royalty rights to different types of interested parties. These royalty rights tokens represent a more granular and streamlined way to declare royalty splits for multiple collaboration participants for the creation of the work.
### royaltyPortionTokens() function
This function MUST return an array of addresses related to [EIP-20](./eip-20.md) tokens that MUST represent royalty portions to different types of interested parties. These royalty portion tokens represent a more granular and streamlined way to declare royalty splits for multiple collaboration participants for the creation of the IP.

For example, for a musical work, we might have two tokens representing the composition/writing/publishing royalty rights side, and the recording/master side. These royalty rights tokens are distributed to the collaboration participants and can later be queried by the various holders, for purposes of distribution of royalties - i.e if you hold 10% of a royalty rights token, you will get 10% of financial distribution related to that type of royalty.
For example, for a musical IP, we might have two tokens representing the composition/writing/publishing royalty portion side, and the recording/master side. These royalty portion tokens are distributed to the collaboration participants and can later be queried by the various holders, for purposes of distribution of royalties - i.e if you hold 10% of a royalty portion token, you will get 10% of financial distribution related to that type of royalty.

### metadataURI() function
This function MUST return the URI to a metadata file containing any required metadata for the work, or an empty string. Each work type MAY implement its metadata standard, defined separately. The file MUST be hosted in IPFS or Arweave or other decentralized content-addressable systems in which the file's contents are not changeable without changing the URI.
This function MUST return the URI to a metadata file containing any required metadata for the IP, or an empty string. Each IP type MAY implement its metadata standard, defined separately. The file MUST be hosted in IPFS or Arweave or other decentralized content-addressable systems in which the file's contents are not changeable without changing the URI.

### changeMetadataURI() function
This function allows changing the metadata URI to point to a new version of the metadata file. Calling this function MUST trigger the event `MetadataChanged` in case of success.

### ledger() function
This function MUST return the address of the registry or registrar contract, or an EOA account that initialized the work and associated royalty tokens. A work MAY be registered in multiple places by different actors for different purposes. This enables market participants to discover which registry mechanism is the parent of the work and might have special access rights to manage the work.
This function MUST return the address of the registry or registrar contract, or an EOA account that initialized the IP and associated royalty tokens. An IP representation MAY be registered in multiple places by different actors for different purposes. This enables market participants to discover which registry mechanism is the parent of the IP and might have special access rights to manage the IP.

```solidity
// SPDX-License-Identifier: Apache-2.0
Expand All @@ -73,15 +73,15 @@ interface IIPRepresentation is IERC165 {
/// @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 rights in the work
/// @return array of addresses of ERC20 tokens representing royalty portion in the IP
/// @dev i.e implementing ERC5501 (IRoyaltyInterestToken interface)
function royaltyRightsTokens() external view returns (address[] memory) ;
function royaltyPortionTokens() external view returns (address[] memory) ;
/// @return the address of the contract or EOA that initialized the work registration
/// @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 work
/// @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
Expand All @@ -97,28 +97,28 @@ interface IIPRepresentation is IERC165 {

## Rationale

### Returning an array of EIP-20 tokens presents a more robust royalty rights structure/
### Returning an array of EIP-20 tokens presents a more robust royalty portions structure/

Current royalty implementations deal only with a single type of royalty payment: NFT sales. They also only allow a single type of royalty - i.e you cannot have different royalty rights owners receive a royalty based on different licensing types.
Current royalty implementations deal only with a single type of royalty payment: NFT sales. They also only allow a single type of royalty - i.e you cannot have different royalty portion owners receive a royalty based on different licensing types.
In other words, currently, a royalty split works the same way no matter what type of purchase or license deal has happened, for all parties involved.

With this proposal, multiple **types** of royalty rights are allowed. A classic case is the music industry in which you have writing/composition royalties, and recording/master royalties. Different licensing types will pay different percentages to different parties based on context.
With this proposal, multiple **types** of royalty scenarios are allowed. A classic case is the music industry in which you have writing/composition royalties, and recording/master royalties. Different licensing types will pay different percentages to different parties based on context.

In the case of a song cover, a license payment formula can be created so that that
a) Original work's writers get paid for using the lyrics or composition of the song
a) Original IP's writers get paid for using the lyrics or composition of the song
b) recording artists of the original song do not get paid since their recording is not used
c) recording artists of the new work will get paid
c) recording artists of the new IP will get paid
d) there are no writing royalties for the creators of the cover.

Moreover, this EIP has a single structure that connects to all types of royalty types and allows finding them more easily.
Lastly, moving EIP-20 tokens around is much easier than managing an 0xsplits contract.

### Separating the work from the sellable NFT enables scaling licensing types
By separating the canonical version of the work from its various licensed uses (NFT purchase, streaming, usage of art, etc..) this EIP introduces a path for an ecosystem of various license types and payment distributions to evolve.
### Separating the IP contract from the collectible and licensing NFTs enables scaling licensing types
By separating the canonical version of the IP from its various licensed uses (NFT purchase, streaming, usage of art, etc..) this EIP introduces a path for an ecosystem of various license types and payment distributions to evolve.
In other words, when people use this scheme, they won't start by creating a music NFT or art NFT, they start by creating the IP Representation and then create types of licenses or collectibles for it, each as its own sellable NFT, possibly in the form of [EIP-5218](./eip-5218.md) or other formats.

### A single pointer to the work's metadata
The IPR points to metadata housed in IPFS or Arweave and allows changing it and keeping track of the changes in a simple and standard way. Today the only metadata standard is NFT metadata extension, but we do not know which standard the document adheres to. With different work types, different metadata standards for different work types can be formulated and have a simple easy place to discover attached metadata.
### A single pointer to the IP's metadata
The IPR points to metadata housed in IPFS or Arweave and allows changing it and keeping track of the changes in a simple and standard way. Today the only metadata standard is NFT metadata extension, but we do not know which standard the document adheres to. With different IP types, different metadata standards for different IP types can be formulated and have a simple easy place to discover attached metadata.

## Reference Implementation

Expand Down Expand Up @@ -180,7 +180,7 @@ contract MusicalIP is ERC721, IIPRepresentation {
emit MetadataChanged(oldURI, oldHash,_newURI,_newFileHash);
}
function royaltyRightsTokens() external view returns (address[] memory) {
function royaltyPortionTokens() external view returns (address[] memory) {
address[] memory items = new address[](2);
items[0] = compToken;
items[1] = recToken;
Expand Down Expand Up @@ -209,7 +209,7 @@ contract MusicalIP is ERC721, IIPRepresentation {
```

#### Deploying a new work of music using a simple song registry contract
#### Deploying a new Musical IP using a simple song registry contract

```solidity
// SPDX-License-Identifier: Apache-2.0
Expand Down Expand Up @@ -246,9 +246,9 @@ contract SimpleSongLedger is IERC721Receiver {
```
## Security Considerations

There might be potential security challenges of attackers persuading holders of royalty rights tokens to send them those tokens and gaining royalty rights in various IPRs. However, these are not specific to royalties and are a common issue with EIP-20 tokens.
There might be potential security challenges of attackers persuading holders of royalty portion tokens to send them those tokens and gaining royalty portion in various IPRs. However, these are not specific to royalties and are a common issue with EIP-20 tokens.

In the case of the works registration ownership, it will be recommended that registry contracts will own the works registration and it will be non-transferrable (account bound to the registry that created it).
In the case of the IP registration ownership, it will be recommended that registry contracts will own the IP registration and it will be non-transferrable (account bound to the registry that created it).

## Copyright

Expand Down

0 comments on commit 62f5c56

Please sign in to comment.