Minting Interface Walkthrough

Minting Interface Walkthrough

Minting Interface Walkthrough

This is an overview of the fxhash minting interface and a walkthrough of the minting process.

The minting interface is the portal that takes you through the necessary steps to upload your project to fxhash. The interface will guide you through some final checks to make sure that things are working properly, help you set up the appearance of the final project page on fxhash and allow you to set distribution options such as the edition size, pricing, royalties, reserves and allow lists.


Once you’ve made sure that your token works properly and created a zip file that contains all of your project files (either through the fxhash CLI or manually), then you’re ready to get started.


1. Author Selection

The first step in the minting process is indicating whether your project is created solely by you or is a collaboration with one or more other artists:


For now, let’s assume that you created the project by yourself - the subsequent steps won’t vary much when a project is a collaborative one. You can learn more about collaborations and collab contracts here:

2. Storage Selection

Next you’ll be asked how you’d like your project to be stored - either on IPFS or On-chain:


You can read more about the differences between IPFS and On-chain storage here:

3. Project Upload

Upload your project's .zip file that contains all of your project files. This zip file can be created manually or with the fxhash CLI via the fxhash build command:


Make sure to also include the license file in this project directory:

4. Determinism Check

After hitting the upload button, you’ll be taken to the next screen where you’ll go through a final check to ensure that your piece is deterministic. In this step you also decide on the preview that will front your project page by fixing a preview hash, here you can also set the iteration number and/or minter address if those influence some aspects of your artwork:


If your token implements parameters or features they should also show up here. If everything is working properly you can go ahead and check the two boxes to proceed to the next step. This will lock in the final preview iteration of your project.

5. Preview Capture Settings

In this step you’ll configure how fxhash generates the previews of the collected iterations via the capture module:


There’s two different manners in which the capture module can be triggered:

  • Programmatically with $fx.preview(): The capture module will wait until your code calls fxpreview(). As soon as the function is called, the capture will be triggered. You can call this function whenever your algorithm is ready to be captured. The capture module will automatically take a capture after 300 seconds have passed after your project was loaded in the browser. Generally the preview function should be placed at the very end of your code after all of the graphics have been generated. If the piece is animated you might want to trigger it after the initial frame has been drawn.
  • Automatically after a Fixed delay: a fixed time delay indicates that the capture module should trigger automatically after a certain amount of time after the project is loaded. Selecting this option will make a slider appear where you can set how many seconds the capture should wait before triggering.

In the case of our example token we’re using the programmatic trigger because it is a static artwork. After setting the timing of the capture you also need to indicate the target of this capture, this can be a canvas element, or the entire viewport of the window:


When you indicate a canvas element you also need to specific the identifier of this canvas element. Futhermore, there are 2 types of rendering instances to generate previews of tokens:

  • CPU only: those are the default, and most scalable instances. They rely on a CPU fallback implementation for WebGL. They are suited for the majority of projects
  • GPU-enabled: those are instances with a GPU. They can render with a GPU, but they are way slower to bootstrap and so the time it takes to generate a capture is longer because of the bootstrap time.

For most of the cases, even if your project uses WebGL, CPU instances are better because we can scale a very high amount of instances, and so it doesn't bloat the rendering queue. However, in some cases, your project may need a GPU to render properly. For now, we only have 4 instances available, and as a result the metadata assignation will be slower for projects using those GPU-enabled instances.

You should only use GPU-enabled instances if your project doesn't render properly using regular instances.

If you don't use WebGL and only the regular canvas API, it's also possible that your project doesn't render properly on the CPU instance because the canvas API uses GPU acceleration. If you observe differences between the capture and your live version, then try using GPU-enabled rendering.

If your project is loading asynchronous requests from the project's folder, always consider that one of those ressources may be slow to load. In that regard, if you load resources please always use fxpreview() to trigger the capture.

6. Preview Check

To verify that the capture actually works properly, the captured preview image should be identical to the generative artwork running in your browser:


Although the artwork is identical you can see a slight difference between the preview and the generative artwork - the CSS border that we applied to the canvas is actually not a part of the canvas graphics itself.

7. Distribution Settings

Next you need to set up how your project will be distributed, pricing your project and deciding on supply is a tricky topic:


Essentially here you need to specify the following:

  1. The Number of Editions that your project will have
  2. The pricing method:
    1. A fixed price for each iteration
    2. Dutch auction system, where the price is reduced over several time steps - here you need to provide some additional details
  3. For both pricing methods you can specify and opening date (release date)
  4. The primary splits
  5. Royalties
  6. Reserves

If you aren’t certain about how to choose these settings, we provide detailed information on all of this here:

8. Variation Settings

In this step you will configure the interface options for previewieng variations generated by you project:


As the artist, we want you to have control over the freedom viewers will have when exploring variations of your project on the token page. Under the display frame, a variations button can be used to explore different variations, if enabled when you minted the Generative Token:


For projects using fx(params), the explore params button allows users to navigate the parameter space of your Generative Token.


You can configure the following settings, for both during the mint period and after fully minted:

  • enabled: Determines if the variations and explore params buttons are active. If disabled, these buttons will be unclickable and visibly deactivated. Note that pre-mint exploration cannot be disabled for fx(params) projects.
  • number of variations:
    • infinite: viewers can explore any amount of variations and so randomly
    • limited set of hashes: define a list of hashes the viewers will cycle through when clicking on the button

These settings should give enough control to define a strategy during the lifetime of your token. You can for instance disabled infinite exploration after token is minted, so that the front end only display a finite number of states through the minted collection of the token.

Please note that the variation settings have no effect on the iterations which will be generated from your project.

9. Project Details

In the penultimate step you’ll add a quirky title, a description for the project, optionally a different description for the collected iterations, a list of tags that are geared towards discoverability of the project on the fxhash website and other 3rd party exploration tools, as well as some labels that can indicate a special behaviour of your project:


One step that many artists struggle with, is writing a description for the generative artwork. This description will live on the GENTKs project page and is frequently the first point of contact that collectors have with the artwork. In a way, it's your sales pitch in which you tell your potential collectors a little about the artwork and try to capture them.

This can be a romantic backstory, the discovery of a bug that led to an interesting visual composition, or even the recount of a quick coding session that led to a new algorithmic method. However, artists make art simply for the love of making art, it is often the case that there isn't a romantic backstory, especially in generative art that often ends up being a very exploratory endeavour. In this case it is also perfectly okay to reflect on the provide retrospective insights into the art-making process.

It is also a nice gesture to give a little shoutout to the libraries that you might have used and their creators, as well as the people that contributed and helped you in the ideation and development process of the code. And it is also a good idea to provide an overview of the different ways that users can interact with the GENTK, for instance the keys that map to certain user interactions.

To summarise, a good description provides:

  • A short backstory on the inspirations that led to the project
  • Highlights the primary/prominent techniques and methods used in the piece
  • Mentions the libraries and individuals that contributed to the process
  • Gives an overview of the interaction options

10. Final Preview

This is the final preview of your project, and essentially indicates what your project will look like once published:


Additionally if you selected that your project should be stored on-chain it will indicate how much this storage transaction will cost, and you’ll have to perform this operation to unlock the publish project button. If you chose IPFS you can directly go ahead and publish the project.