### Risk Disclosure

NOTE: This guide is unofficial, has no endorsement or support from any organization, and is simply a proposal. It is not a source of advice of any kind. All actions taken following this guide are solely at your risk. Remember, standards are subject to change, particularly during the proposal stage. If changes occur, old tokens may lack support. Minting or deploying during the proposal phase carries risk that can lead to losses of value, gas, or time. Your responsibility is to understand that all consequences resulting from using this guide rest on your shoulders. Approach with due care.

## ESC-721 Specifications

### Inspirations:

[BRC-721](https://github.com/adshao/brc-721)
[ERC-721](https://eips.ethereum.org/EIPS/eip-721)

### Ethscriptions Definition and Resources

[Ethscriptions Documentation](https://ethscriptions.com/about)

Any successful Ethereum transaction whose input data (when interpreted as UTF-8) is a valid data URI creates an Ethscription, provided the data URI is unique. All valid mimetypes are supported.

For the URI to be unique, no Ethscription from a previous block or a transaction earlier in the block can have the same content.

Any Ethereum transaction whose input data is the transaction hash of a valid Ethscription is a valid Ethscription transfer, provided the transaction sender is the Ethscription’s owner.

The recipient of the creation transaction is the Ethscription’s initial owner. The sender of the creation transaction is the Ethscription's creator.

### Goals:

The goals of ESC-721 are the following:

#### Allowing cheaper ethscriptions that have high quality art attached to them.
This solution can allow an artist to create an NFT collection without having to deploy a smart contract, and allow people to mint for cheaper than with a traditional smart contract.

#### Combine Ethscriptions with an Existing Standard

This solution leverages the unique features of ethscriptions (inherit non-fungibility, cost savings, etc) while still maintaining some compatibility to the existing ERC-721 smart contract standard to better allow for marketplaces to utilize it with their existing infrastructure.

### Ethscription Formatting:

Each valid ESC-721 ethscription must be a valid json data-uri. How to construct this is discussed below. There are going to be some changes to the core Ethscriptions protocol on how JSON is handled, so the JSON specific formatting recommendations are left in, but may not be relevant in the future.

This means it must begin with `data:application/vnd.esc.core.esc-721.mint+json` followed by valid JSON with no spaces in the formatting (spaces are permissible inside of the quotation marks, i.e., the JSON value). The entire line must be standard ASCII.

All JSON keys must be lowercase. This is done to avoid potential duplication issues.

All integer values in the JSON are strings, this is due to potential issues with very large numbers if using the non-quoted JSON integer values.

A valid ethscription might look like this: `data:application/vnd.esc.core.esc-721.mint+json,{"dh":"0x183e263cf7207d4a061d79cc00274ab6d230cbe9c277ffbe7213010a238de7a1","id":"1"}`

What a valid mint operation looks like is dependent on the corresponding deploy ethscription.

The rationale for this is based off how data URLs are formatted, from [Mozilla Developer Network Documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs) the proper syntax is `data:[<mediatype>][;base64],<data>`.

* data: is a requirement.
* All ESC-721 transactions are formatted in JSON, so `application/json` is included.
* ; is optional and needed when encoding the data in base64. However, JSON is not encoded in base64, so both ; and ;base64 are not included.
* The entire ethscription ends up being encoded in hex already, therefore there's no need to URL-encode the JSON.

### Mint Operation

The mint operation is used to create new ethscriptions for a valid ESC-721 deploy. Here's how a mint operation is represented in JSON format:

{
    "p": "esc-721",
    "op": "mint",
    "dh": "0x183e263cf7207d4a061d79cc00274ab6d230cbe9c277ffbe7213010a238de7a1",
    "id": "Token_ID"
}

Parameters:

`p`: Indicates the protocol being used (should be esc-721).
`op`: Specifies the operation being performed (for minting, use mint).
`dh`: - Represents Deploy Hash - a valid ethscription ESC-721 deploy transaction hash.
`id`: - Refers to Token ID - A value representing 1 through max supply of the tick. There are no 0 tokens.

To be ethscribed, the operation must be unique, so only the first instance of each ID ethscribed is valid.

### Deploy Operation

The deploy operation is used to deploy a new ESC-721 project. Here's how a deploy operation is represented in JSON format:

{
    "p": "esc-721",
    "op": "deploy",
    "name": "Project Name",
    "symbol": "tick"
    "totalsupply": "10000",
    "baseuri": "ipfs://url/"
}

Parameters:

`p`: Indicates the protocol being used (should be esc-721).
`op`: Defines the operation being performed (for deployment, use deploy).
`name`: The external facing project name of the token you're deploying.
`symbol`: An internal facing symbol name, mostly for marketplaces to use.
`totalSupply`: The maximum supply for the token being deployed.
`baseURI`: The base URI for the token's metadata, hosted on IPFS.

For the tokenuri link, the link will have [id].json appended to the end. So, ipfs://url/1.json. For maxiumum compatibility, it is recommended that indexers and marketplaces check for both 1 and 1.json, but 1.json is what we are expecting and will be used in cases where both appear.

It is recommeneded to use ipfs, but any link is fine.

All json keys are left lowercase here to avoid confusion or esc-duplication.

You'll notice that some of the keys in this deploy op are spelled out longer - in cases where ERC-721 variables overlapped with ESC-721, the longer form was kept to enable more compatiability.

A valid deploy might look like this: `data:application/json,{"p":"esc-721","op":"deploy","name":"Jon HQ","symbol":"JON","totalsupply":"420","baseuri":"ipfs://url/"}`

### Token Metadata

Follow the largest NFT marketplace's guide here: https://docs.opensea.io/docs/metadata-standards

Following these guidelines means you can use any tools already created for artists to generate valid JSON files.

One thing that will likely be implemented, and is recommended for viewers to implement, is options to link to ethscriptions for imagedata. It is not yet clear at the protocol level what an ethscription link will look like. It might be esc://234561 linking to an ethscription #, or esc://0x183e263cf7207d4a061d79cc00274ab6d230cbe9c277ffbe7213010a238de7a1 linking to a txn hash. The protocol scheme (esc://) part of the url isn't known yet either.

{
  "description": "Friendly OpenSea Creature that enjoys long swims in the ocean.", 
  "external_url": "https://openseacreatures.io/3", 
  "image": "https://storage.googleapis.com/opensea-prod.appspot.com/puffs/3.png", 
  "name": "Dave Starbelly",
  "attributes": [
    {
      "trait_type": "Base", 
      "value": "Starfish"
    }, 
    {
      "trait_type": "Eyes", 
      "value": "Big"
    }, 
    {
      "trait_type": "Mouth", 
      "value": "Surprised"
    }, 
    {
      "trait_type": "Level", 
      "value": 5
    }, 
    {
      "trait_type": "Stamina", 
      "value": 1.4
    }, 
    {
      "trait_type": "Personality", 
      "value": "Sad"
    }, 
    {
      "display_type": "boost_number", 
      "trait_type": "Aqua Power", 
      "value": 40
    }, 
    {
      "display_type": "boost_percentage", 
      "trait_type": "Stamina Increase", 
      "value": 10
    }, 
    {
      "display_type": "number", 
      "trait_type": "Generation", 
      "value": 2
    }
  ]
}

### Transfer Operations

A specific ESC-721 'transfer op' is not needed for ESC-721. NFTs are not divisible and as such, no fractional transfers need to occur.

To transfer an ESC-721 NFT, simply transfer the mint ethscription, using standard ethscriptions protocol rules, which currently means sending a transaction to another address with the transaction hash of the ethscription you wish to transfer in the calldata.

### Author Comments

I don't think name and symbol both are necessary, symbol seems duplicative and a short hand ticker is both likely to cause collisions with other projects. It has been left in if for whatever reason existing tools use it with the existing erc-721 standard. Which they shouldn't. I hate the inclusion of this in erc-721.

### To Do

~~1. How to handle transfer events~~
2. How to handle deploy updates
~~3. Proper 1.json formatting (hint, follow the ERC721 metadata schema https://eips.ethereum.org/EIPS/eip-721#specification)~~
4. Inline ethscribed traits?
5. Reserved minting (for fair mints)
6. Helper contract/how to do whitelists
7. Do we handle charsets? Leaning towards no. Unique characters can be located in 1.json files