Abstract

This EIP standardizes a JSON format for storing off-chain information about NFT authors. Specifically, it adds a new field which provides a list of author names, addresses, and proofs of authorship consent: proofs that the authors have agreed to be named as authors. Note that a proof of authorship consent is not a proof of authorship: an address can consent without having authored the NFT.

Motivation

There is currently no standard to identify authors of an NFT, and existing techniques have issues:

• Using the mint tx.origin or msg.sender
  • Assumes that the minter and the author are the same
  • Does not support multiple authors
• Using the first Transfer event for a given ID
  • Contract/minter can claim that someone else is the author without their consent
  • Does not support multiple authors
• Using a custom method/custom JSON field
  • Requires per-contract support by NFT platforms
  • Contract/minter can claim that someone else is the author without their consent

The first practice is the most common. However, there are several situations where the minter and the author might not be the same, such as:

• NFTs minted by a contract
• Lazy minting
• NFTs minted by an intermediary (which can be particularly useful when the author is not tech-savvy and/or the minting process is convoluted)

This document thus defines a standard which allows the minter to provide authorship information, while also preventing authorship claims without the author's consent.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

All addresses used in this standard MUST follow the casing rules described in EIP-55.

Definitions

• Authors: creators of an NFT
• Minter: entity responsible for the actual minting transaction; the minter and the authors MAY be the same
• Verifier: entity that wants to verify the authorship of an NFT (e.g. a user or an NFT marketplace)
• Author Consent Proof (ACP): a signed message that proves that the signer agrees to be considered the author of the NFT

Authorship Support

The standard introduces a new JSON field, named authorInfo. It provides a REQUIRED interface for authorship claiming, as well as an OPTIONAL interface for author consent proofs.

authorInfo is a top-level field of the NFT metadata. Specifically:

• If a contract supports the metadata extension for EIP-721, the JSON document pointed by tokenURI(uint256 _tokenId) MUST include the top-level field authorInfo
• If a contract supports the metadata extension for EIP-1155, the JSON document pointed by uri(uint256 _id) MUST include a top-level field authorInfo

The JSON schema of authorInfo (named ERC5375AuthorInfoSchema) is defined as follows:

{
    "type": "object",
    "properties": {
        "consentInfo": {
            "type": "object",
            "description": "Helper fields for consent verification",
            "properties": {
                "chainId": {
                    "type": "integer",
                    "description": "EIP-155 chain id"
                },
                "id": {
                    "type": "string",
                    "description": "NFT id"
                },
                "contractAddress": {
                    "type": "string",
                    "description": "0x-prefixed address of the smart contract"
                }
            }
        },
        "authors": {
            "type": "array",
            "items": "ERC5375AuthorSchema"
        }
    },
    "required": [ "authors" ]
}

Note that authors MAY be an empty array.

ERC5375AuthorSchema is defined as follows:

{
    "type": "object",
    "properties": {
        "address": {
            "type": "string",
            "description": "0x-prefixed address of the author"
        },
        "consent": {
            "type": "ERC5375AuthorConsentSchema",
            "description": "Author consent information"
        }
    },
    "required": [ "address" ]
}

Moreover, if the consent field is present, the consentInfo field of authorInfo MUST be present.

ERC5375AuthorConsentSchema is defined as follows:

{
    "type": "object",
    "properties": {
        "consentData": {
            "type": "object",
            "properties": {
                "version": {
                    "type": "string",
                    "description": "NFT authorship consent schema version"
                },
                "issuer": {
                    "type": "string",
                    "description": "0x-prefixed address of the author"
                },
                "metadataFields": {
                    "type": "object"
                }
            },
            "required": ["version", "issuer", "metadataFields"]
        },
        "publicKey": {
            "type": "string",
            "description": "EVM public key of the author"
        },
        "signature": {
            "type": "string",
            "description": "EIP-712 signature of the consent message"
        }
    },
    "required": ["consentData", "publicKey", "signature"]
}

where metadataFields is an object containing the JSON top-level fields (excluding authorInfo) that the author will certify. Note that the keys of metadataFields MAY be a (potentially empty) subset of the set of fields.

consentData MAY support additional fields as defined by other EIPs. consentData MUST contain all the information (which is not already present in other fields) required to verify the validity of an authorship consent proof.

Author Consent

Consent is obtained by signing an EIP-712 compatible message. Specifically, the structure is defined as follows:

struct Author {
    address subject;
    uint256 tokenId;
    string metadata;
}

where subject is the address of the NFT contract, tokenId is the id of the NFT and metadata is the JSON encoding of the fields listed in metadataFields. metadata:

• MUST contain exactly the same fields as the ones listed in metadataFields, in the same order
• MUST escape all non-ASCII characters. If the escaped character contains hexadecimal letters, they MUST be uppercase
• MUST not contain any whitespace that is not part of a field name or value

For example, if the top-level JSON fields are:

{
    "name": "The Holy Hand Grenade of Antioch",
    "description": "Throw in the general direction of your favorite rabbit, et voilà",
    "damage": 500,
    "authors": [...],
    ...
}

and the content of metadataFields is ["name", "description"], the content of metadata is:

{
    "name": "The Holy Hand Grenade of Antioch",
    "description": "Throw in the general direction of your favorite rabbit, et voil\u00E0"
}

Similarly to consentData, this structure MAY support additional fields as defined by other EIPs.

The domain separator structure is

struct EIP712Domain {
    string name;
    string version;
    uint256 chainId;
}

where name and version are the same fields described in consentData

This structure MAY support additional fields as defined by other EIPs.

Author Consent Verification

Verification is performed using EIP-712 on an author-by-author basis. Specifically, given a JSON document D1, a consent proof is valid if all of the following statements are true:

• D1 has a top-level authorInfo field that matches ERC5375AuthorInfoSchema
• consent exists and matches ERC5375AuthorConsentSchema;
• If calling tokenURI (for EIP-721) or uri (for EIP-1155) returns the URI of a JSON document D2, all the top-level fields listed in metadataFields MUST exist and have the same value;
• The EIP-712 signature in signature (computed using the fields specified in the JSON document) is valid;

Verifiers MUST NOT assume that an NFT with a valid consent proof from address X means that X is the actual author. On the other hand, verifiers MAY assume that if an NFT does not provide a valid consent proof for address X, then X is not the actual author.

Rationale

Why provide only an author consent proof?

Adding support for full authorship proofs (i.e. Alice is the author and no one else is the author) requires a protocol to prove that someone is the only author of an NFT. In other words, we need to answer the question: "Given an NFT Y and a user X claiming to be the author, is X the original author of Y?".

For the sake of the argument, assume that there exists a protocol that, given an NFT Y, can determine the original author of Y. Even if such method existed, an attacker could slightly modify Y, thus obtaining a new NFT Y', and rightfully claim to be the author of Y', despite the fact that it is not an original work. Real-world examples include changing some pixels of an image or replacing some words of a text with synonyms. Preventing this behavior would require a general formal definition of when two NFTs are semantically equivalent. Even if defining such a concept were possible, it would still be beyond the scope of this EIP.

Note that this issue is also present when using the minter's address as a proxy for the author.

Why off-chain?

There are three reasons:

• Adding off-chain support does not require modifications to existing smart contracts;
• Off-chain storage is usually much cheaper than on-chain storage, thus reducing the implementation barrier;
• While there may be some use cases for full on-chain authorship proofs (e.g. a marketplace providing special features for authors), there are limited applications for on-chain author consent, due to the fact that it is mostly used by users to determine the subjective value of an NFT.

Why repeat id, chainId and contractAddress?

In many cases, this data can be derived from contextual information. However, requiring their inclusion in the JSON document ensures that author consent can be verified using only the JSON document.

Why not implement a revocation system?

Authorship is usually final: either someone created an NFT or they didn't. Moreover, a revocation system would impose additional implementation requirements on smart contracts and increase the complexity of verification. Smart contracts MAY implement a revocation system, such as the one defined in other EIPs.

Why escape non-ASCII characters in the signature message?

EIP-712 is designed with the possibility of on-chain verification in mind; while on-chain verification is not a priority for this EIP, non-ASCII characters are escaped due to the high complexity of dealing with non-ASCII strings in smart contracts.

Usability Improvements for Authors

Since the author only needs to sign an EIP-712 message, this protocol allows minters to handle the technical aspects of minting while still preserving the secrecy of the author's wallet. Specifically, the author only needs to:

• Obtain an EVM wallet;
• Learn how to read and sign a EIP-712 message (which can often be simplified by using a Dapp)

without needing to:

• Obtain the chain's native token (e.g. through trading or bridging);
• Sign a transaction;
• Understand the pricing mechanism of transactions;
• Verify if a transaction has been included in a block

This reduces the technical barrier for authors, thus increasing the usability of NFTs, without requiring authors to hand over their keys to a tech-savvy intermediary.

Limitations of Address-Based Consent

The standard defines a protocol to verify that a certain address provided consent. However, it does not guarantee that the address corresponds to the expected author (such as the one provided in the name field). Proving a link between an address and the entity behind it is beyond the scope of this document.

Backwards Compatibility

No backward compatibility issues were found.

Security Considerations

Attacks

A potential attack that exploits this EIP involves tricking authors into signing authorship consent messages against their wishes. For this reason, authors MUST verify that all signature fields match the required ones.

A more subtle approach involves not adding important fields to metadataFields. By doing so, the author signature might be valid even if the minter changes critical information.

Deprecated Features

ERC5375AuthorInfoSchema also originally included a field to specify a human-readable name for the author (without any kind of verification). This was scrapped due to the high risk of author spoofing, i.e.:

• Alice mints an NFT using Bob's name and Alice's address
• Charlie does not check the address and instead relies on the provided name
• Charlie buys Alice's NFT while believing that it was created by Bob

For this reason, smart contract developers SHOULD NOT add support for unverifiable information to the JSON document. We believe that the most secure way to provide complex authorship information (e.g. the name of the author) is to prove that the information is associated with the author's address, instead of with the NFT itself.

Replay Attack Resistance

The chain id, the contract address and the token id uniquely identify an NFT; for this reason, there is no need to implement additional replay attack countermeasures (e.g. a nonce system).

Copyright

Copyright and related rights waived via CC0.