Minters for Hic Et Nunc

6 min readOct 14, 2021

The HicEtNunc developer shut down the hicetnunc.xyz site. You can use one of the alternative marketplaces such as https://teia.art/.

Hic Et Nunc (HEN) is the largest NFT marketplace on Tezos and is growing rapidly.

A HEN NFT, token symbol OBJKT, is created on the HEN web marketplace through minting. Interestingly, there are many tools and alternate marketplaces for OBJKTs but not many alternate minters. Other marketplaces for HEN OBJKTs like objkt.com and henext.xyz don’t provide their own minters but rely on the artist using the one provided by the HEN marketplace.

Why aren’t there many decentralized minters for HEN, each potentially customized to the requirements of different kinds of media, the needs of various artists, and the capabilities of different client devices?

I thought it would be an interesting challenge to make my own minter for HEN, which I’ve published on Github as The Hic Et Nunc Minter Project. In this article, I cover the high-level features and improvements I’ve made with the minter.

Minting

So how is it even possible to create your own minter for HEN? Firstly, store the following files on Interplanetary File System (IPFS) for each OBJKT:

The original artifact file.
The cover image.
The thumbnail image.
The metadata file that describes various information about the OBJKT.

These files can be stored on IPFS by anybody, and you only need to track the address or content identifier (CID) for each of the files.

Secondly, the HEN minting smart contract doesn’t include any access controls. Any Tezos address can invoke the HEN minting contract to create an OBJKT. Also, HEN doesn’t charge any platform fee for doing the minting.

This feature allows artists to mint OBJKTs and transfer them directly to a collector using any Tezos wallet.

Artists can take their minted OBJKTs to other marketplaces like objkt.com and put them on sale differently than what the HEN marketplace supports (objkt.com provides auctions that HEN doesn’t).

This also opens up the opportunity for other developers to create their minters for OBJKTs.

Two examples of alternate minters are hic et nunc storefront and Art-O-Matic. Both provide their own GUI and user flow for creating OBJKTs.

Usability

Based on my own experience minting art on HEN and also feedback from other artists in the HEN Discord, there is room for improvement in the user experience for HEN, especially when things go wrong.

HEN is dependent on various third-party APIs and services. Whenever these services experience any issues or struggle to keep up with HEN traffic, the user experience breaks down very quickly. For example, if there is an issue during minting, it’s not clear from the HEN UI what went wrong and how to recover. Artists need to look at the browser console to see very technical errors.

For the minter project, the code now handles errors wherever they can occur and provides feedback to the user about what went wrong. Logging in the browser console is also much more descriptive and detailed. The UI now also shows more details about the steps of the minting process, especially for uploading files.

HEN experiences daily spikes in traffic, usually around 6–11 am EDT and 4–9 pm EDT. At those times, the Tezos RPC nodes used to communicate with the blockchain can get overloaded. So, the minter project allows the user to change the node from a dropdown of alternate nodes.

Any data entered previously for the title, description, rights, tags, editions, and royalties default for the following mint.

Images

For image-based OBJKTs, HEN will generate a cover image (1024x1024) using the image library compressor.js. This library supports a limited number of image types that can be displayed by the browser directly. So if you wanted to create an NFT using BMP or TIFF, HEN doesn’t support it. These are older file formats, but there might be good reasons to keep the original file format. Also, the library cannot resize animated GIFs, so it doesn’t generate a cover version.

The minter project uses wasm-imagemagick to support a more comprehensive range of image types, including animated GIFs. Also, the minter project generates a thumbnail version (350x350) compared with HEN, which uses the same static thumbnail image for all mints.

For interactive OBJKTs, HEN uses the HTML meta image tag to extract the cover image, but I’ve decided instead to allow the artist to upload a cover image directly.

Once I had this working, I decided to make this an option for all OBJKs; rather than automatically generating a cover image, allow the artist to specify their own cover image. A custom cover image will enable artists to use cover images differently from a smaller version of the original artifact image.

Unfortunately, the HEN marketplace uses the original artifact image for displaying the OBJKT, so the accepted file formats are still limited to what the browser can display (JPG, GIF, PNG, and SVG). A better option would be to use the cover and thumbnail images for the marketplace and let the collector download the original artifact file if needed. Alternately, HEN might consider supporting downloadable content for each OBJKT separate from the images used in the mint.

Metadata

The minting smart contract requires an IPFS metadata URI, resolving a JSON object describing the artwork. The HEN metadata schema follows the TZIP-21 proposal for rich metadata but only uses a subset of the fields.

The minter project uses more fields to provide helpful information for various indexers and dApps that want to use the metadata.

The metadata formats now list all of the files and their dimensions. Dimensions could be helpful for a client to decide what image to display in a GUI.

The attributes now list various metadata extracted from the original file using the mediainfo.js library. The attributes could help search or categorize the different kinds of media.

Here is an example of the metadata of an image OBJKT generated by the minter project:

{
    "name": "title",
    "description": "description",
    "rights": "rights",
    "minter": "KT1Hkg5qeNhfwpKW4fXvq7HGZB9z2EnmCCA9",
    "date": "2021-10-07T13:28:33.538Z",
    "tags": [
        "art",
        "3d"
    ],
    "symbol": "OBJKT",
    "artifactUri": "ipfs://baf...kwq",
    "displayUri": "ipfs://baf...ypi",
    "thumbnailUri": "ipfs://baf...eni",
    "creators": [
        "tz1XtjZTzEM6EQ3TnUPUQviCD6WfcsZRHXbj"
    ],
    "formats": [
        {
            "uri": "ipfs://baf...kwq",
            "mimeType": "image/jpeg",
            "fileSize": 308550,
            "fileName": "burn7.jpg",
            "dimensions": {
                "value": "1080x719",
                "unit": "px"
            }
        },
        {
            "uri": "ipfs://baf...ypi",
            "mimeType": "image/jpeg",
            "fileName": "cover-burn7.jpg",
            "fileSize": 298544,
            "dimensions": {
                "value": "1024x682",
                "unit": "px"
            }
        },
        {
            "uri": "ipfs://baf...eni",
            "mimeType": "image/jpeg",
            "fileName": "thumbnail-burn7.jpg",
            "fileSize": 42760,
            "dimensions": {
                "value": "350x233",
                "unit": "px"
            }
        }
    ],
    "attributes": [
        {
            "key": "ColorSpace",
            "value": "YUV"
        },
        {
            "key": "ChromaSubsampling",
            "value": "4:4:4"
        },
        {
            "key": "BitDepth",
            "value": "8"
        },
        {
            "key": "@minter",
            "value": "hen-minter v0.0.1"
        },
        {
            "key": "@mediaParser",
            "value": "mediainfo.js"
        }
    ],
    "decimals": 0,
    "isBooleanAmount": false,
    "shouldPreferSymbol": false
}

Metadata for other supported formats are listed here.

An essential aspect of ensuring that indexers, wallets, and dApps can parse the metadata is to follow the TZIP-21 specification. Unfortunately, there are several examples of developers who used their minters and uploaded invalid metadata that broke the indexing of OBJKTs. The minter project uses a JSON schema to ensure that the metadata validates before uploading to IPFS.

Pinning

The nodes that make up the IPFS network treat the files they store like a cache, which means there isn’t a guarantee that the files will continue to be stored. Since each node has finite storage, they regularly remove files from the cache using a process called garbage collection.

Pinning a file tells IPFS that the file is essential and should be retained. Pinned files are available all the time and globally by using servers tuned for high volume and reliability.

You can pin files on IPFS by creating an account with an IPFS service like Infura, NFT.Storage or Pinata. Typically these services provide a free level before charging for storing the pinned files. HEN uses Infura and NFT.Storage.

HEN doesn’t allow you to use your IPFS accounts. The minter project lets you configure the accounts to pin all of the files that make up an OBJKT. This will enable artists to ensure that their NFTs remain long-term.

Future goals

Now that the minter project is working, there are opportunities for exploring new ways to use HEN minters. I find it attractive to build new kinds of collector experiences and NFTs on top of the minter. The current user flow that HEN provides might just be one of many artists could pick from for selling their art and building a relationship with collectors.

Standardizing the metadata formats is something else that could be very helpful to the whole ecosystem around HEN. I’m planning on digging into what other artists and developers on Tezos and other blockchain are doing around NFT metadata.

If you have a bit of technical background, try out the minter project yourself; I’d love to get your feedback before hosting the minter for more artists to use.

If you are interested in HEN NFTs, read my introductory article. If you want to know more about the technical aspects, read my HEN smart contracts and indexer articles. You can follow my 3D art on HEN.