Enter FxParams: Customisable Blockchain Art

It's only been a couple of days since FxParams launched, but we've already seen quite a few tokens hit the market that make use of it, as well as some discussion and brainstorming sessions in the discord on potential future improvements. Let's see what FxParams is all about!

Enter FxParams: Customisable Blockchain Art
Daze Maze, my first FxParams token on FxHash.

It's only been a couple of days since FxParams launched, but we've already seen quite a few tokens hit the market that make use of it, as well as some discussion and brainstorming sessions in the discord on potential future improvements. Overall it's been an exciting couple of days!

Let's see what FxParams is all about!

What is FxParams?

Generative tokens (GTs) on fxhash consist of html/css/javascript files that are stored on ipfs (inter-planetary file system); when someone mints an iteration of your token a hash is created, stored on the Tezos blockchain and subsequently injected into your token to seed it's randomness and generate a unique artwork for the collector.

In this setting, the coder needs to make sure that this specific hash always generates the same output for the collector.

The way that this has worked, up until now, is that the collector usually has no knowledge in advance of what the token that they will receive looks like, because the seeding hash is chosen at random. In the early days of FxHash, the only indicator of what a token looks like was the token's preview that had it's own hash assigned. Later on, a 'variations' button was added that allowed the exploration of different hashes and their resulting artworks.

FxParams changes this formula.

FxParams essentially is a new, alternative way to minting tokens on FxHash, both for the artist and the collector. Using FxParams, the artist can decide to expose certain variables that influence and steer the final aesthetic of the generated artwork. Through an interface provided by fxhash, these 'public' parameters are intended to be tweaked by the collector, essentially allowing them to model a unique iteration to their liking and personal preference, before they hit the mint button.

Sounds cool, right? It's worth mentioning here that this concept has been pioneered by Crayon Codes, which is has sadly been frozen for a while.

There's still a little bit of randomness involved though: the final hash is still randomly assigned, meaning that the parameters that aren't exposed to the collector will still end up having random values assigned. This has been a little bit of a controversial and confusing point among artists and collectors, and we'll go into more detail on that in just a bit.

This is already a lot to take in and brings up a ton of questions. Firstly, what implications does this have for the traditional method of minting tokens? Will it fall out of fashion, or will both methods be able to coexist harmoniously? What creative shenanigans are artists going to do with FxParams? How is this going to affect final collections? Will they naturally balance themself out or will collectors gravitate towards specific aesthetics? Additionally, what does that mean for the secondary market and market dynamics? Collecting FxParams pieces happens via a new ticketing system, which we'll also have a look at!

A closer look at FxLens

First things first, what changes on the artist's side of things with FxParams?

Creating an FxParams piece changes the workflow a little bit, but FxHash has also thought about that and created a tool to make this process easier. I've tried FxLens out for myself over the past couple of days, in an attempt to get my token ready for the hash, and found that it was relatively easy to get into!

FxLens is essentially a node project, that you can run locally in your browser and use as a sort of wrapper around your token. When you run this node project you'll see a neat sidebar with toggles, sliders, and drop-down menus for the different parameters, as well as your sketch in the main content area:

My favorite part about it so far is the live-reload (or auto-apply) feature. When I save my code or change the parameters in the side-bar I can immediately see the changes being applied. So you don't necessarily need to use it for FxParams pieces but can also use just use it for regular GTs.

I saw that a couple of people in the discord had trouble getting set up, so here's what I did to run my p5.js sketches with fxlens:

  1. Make sure you have node installed (on mac easily done with homebrew, no idea on windows - sorry windows people). I already had node updated to the last version since I needed it for some other stuff, hence I was already good to go.
  2. Run the commands described in the fxlens documentation to get your project file set up. You should already be able to run this, but there isn't going to be any sketch there yet.
  3. If you're not using any external libraries you can skip to step #6, otherwise download the p5.min.js file and drop it in the public folder.
  4. Make sure to link the scripts in the index.html file.
  5. Rinse and repeat for other libraries that you want to include or need for your project. Also make sure to link them!
  6. If you're not using p5 you can just run all of your stuff in the index.js file. If you do, create your sketch.js file (also in the public directory) that will contain your p5 code, link it in the index.html as well, and then you can just go about business as usual.
  7. When you feel ready for testing your sketch locally, pull up the terminal, navigate to the fxlens directory and run the following command: 'npm start'. A browser window should open, and if you did everything correctly you should see a sidebar with the parameters and your sketch in the main content area.
  8. Having the browser's dev console open can help you figure out if there's other problems.
  9. When you feel ready for minting your project, you can interrupt the project from your console (ctrl + c) and use the command 'npm run build' to create a zip file of your project. In the folder 'dist-zipped' you should find this zip file which you then can simply drag into fxhash's sandbox for testing purposes or minting it when it's ready.

Note - you should always be careful downloading random npm packages, because there is never a guarantee that they aren't malicious malware. With fxhash though I have no such worries.

Alternatively, if you don't want to use fxlens you can also just use the fxparams boilerplate (the script file that handles adding the parameters to the url), and perhaps build your own tool to explore these parameters. Otherwise you can always try out your zipped project in the fxhash sandbox.

As for the params themself, similarly to features, they should be declared inside an array of the following form:

$fx.params([
  {
    id: "parameter_1",
    name: "This is the first parameter",
    type: "number",
    options: {
      min: 0,
      max: 100,
      step: 1
    },
  },
  {
    id: "parameter_2",
    name: "This is the second parameter",
    type: "number",
    options: {
      min: 0,
      max: 10,
      step: 1
    },
  },
  {
    id: "option_list",
    name: "These are options",
    type: "select",
    //default: "pear",
    options: {
      options: ["ONE", "TWO", "THREE"],
    }
  }
])

For you to use them inside of your code you need to get them out of this array, which can be done with another fx flavored function:

parameter_1 = $fx.getParam("parameter_1") // get the parameter by it's id

There's a bunch of stuff to play with, so I recommend getting it set up and experimenting for yourself, for instance you can lock parameters with the small lock icon next to each one, which makes them remain the same if you hit randomize parameters.

Hash Override Ideas

Here's another important point to address! Once I got to the point where my token was ready for minting, I realized that my collectors would still end up with a different token than what they had dialed in. Now you're probably going to say "Wait what? What's the point of the parameters then?"

What's important to understand here, is that the parameters that were chosen stay the same when the collector mints the piece, but the overall randomness would ultimately be different because a different hash than the example hash will be assigned to the minted token. While dialing in the parameters to your liking you're just working with a tentative example hash that you can also refresh. Meaning that the random() and noise() calls that aren't controlled by any sort of parameters would end up generating different values.

I felt that this behaviour would be a bit odd in my case, since my token was all about the patterns that collectors could come up with. I wanted the collector to get EXACTLY what they see after dialing in the parameters. After brainstorming a bit with folks in the fxhash discord, there's actually a couple of tricks to lock in the exact artwork that the collector has created, essentially overriding the operation hash that is injected at mint time.

Locking in the seeds with P5

If you're working with p5js you can seed the piece with the inbuilt randomSeed() and noiseSeed() and make the seed numbers available as parameters. So before dialing in the parameters of their choosing, they can lock in the seed numbers that ensure that they will get exactly what they see!

But there's a couple of problems with this approach, in this manner duplicate mints become possible. For one, it might just happen by coincidence that two collectors choose the same seed numbers as well as the same parameters, resulting in the exact same mint. I think it's unlikely though that two collectors would set the seeds to the same numbers, making the range of the seed numbers something very large would probably also disincentive people from choosing popular numbers like 7, 33, 42, etc. which was a suggestion by Liam Egan in the discord:

A second problem here, is that the chosen parameters become public after minting, they are appended to the hash and can be seen in the address bar of the browser. Which makes it possible for someone to copy these values and recreate the exact same token. But I don't see a reason why collectors would want to do this, except if they wanted to purposefully be malicious, or disrupt the composition of the overall collection.

A call these things 'problems', but they aren't really. What's important here is being transparent and making the collectors understand that duplicates are a possibility and could occur.

Using your own prng function

Besides locking in the randomness seed as a parameter, an alternative approach would be by doing it under the hood and seeding the randomness with your own prng function:

For example you could reuse the fxhash code itself to reseed yourself based off of one of the parameters, or you could do something more intricate that combines multiple parameter values obtain a seed. If you have thoughts on this, leave a comment!

I guess, it boils down to creating parameters, and coding your token in such a manner that that the parameters have a strong enough influence on the aesthetic, where the random hash isn't of concern anymore. We'll see how this changes in the future!

Other Considerations

Some other unrelated consideration and thoughts I had while creating my token:

  1. How many parameters are too many parameters?
  2. How to choose a preview?

For the first point, a big portion of collectors aren't programmers themself, which you should keep in mind when creating ย your parameters. You should try to make it as easy as possible for the user to understand what specific parameters do, and probably make these parameters have a strong visual impact on the piece.

For the second point, in the case of a regular fxhash token, choosing a preview boiled down to selecting an honest hash that is representative of the average output of your code. With 'honest' I mean purposefully not choosing an outlier that is rare to occur, because the collector doesn't have the option for rerolling their hash multiple times. Later on this became less of a problem once the 'variations' button was added that allowed to explore different iterations.

As for previews in fxparams I feel like you can purposefully go for a fancier iteration to showcase what your token generator is capable of.

Collecting FxParams Pieces

From the collector's POV, the issue of the hash changing has caused some confusion and some clarifications had to be made:

Revdancat even wrote a guide for collectors to help them understand how collecting fxparams pieces works and to help them increase their chances at getting a mint that they will enjoy (GTs where the seed isn't manually fixed) ย One cool tip presented in his article is rerolling the example hash several times to get a feel for what the mint will potentially look like

Additionally, collecting fxparams tokens is a little bit different from collecting a normal token. When you collect a params piece, you essentially collect a mint ticket. Once obtained, you can use this ticket to mint your iteration.

This mechanism is in place to avoid unecessary stress at mint time. Things can get a bit crazy on fxhash, whenever there's a new hot drop there's often only a couple of minutes or less before it's completely sold out. It would be insane to expect anyone to play with the parameters in such a short amount of time.

This ticketing system also introduces a couple of new mechanisms that are related to the sale, purchase and holding of these tickets. When the artists creates their FxParams token, they also need to set a grace period for these tickets. What is this grace period and what is it for?

Theoretically, with the ticketing system in place, collectors could simply never exchange these tickets for an artwork and just hold on to them for whatever reason. Maybe it's a really sought after drop, and a ticket for this drop could potentially be of significant financial value. To disincentivise these tickets never being converted into art, after a certain amount of time, a grace period, a tax is applied to the holding of this ticket:

If the owner of this ticket fails to pay the tax or fails to list it on the marketplace, this ticket will be foreclosed. Meaning that it cannot be used anymore. More details about mint tickets.

I think this is cool (question mark), and I'm not sure if traders would actually opt to hold on to tickets when they could just create the artwork and and list it? What implications this will have on market dynamics is outside my field of expertise, but I'm sure it's gonna have some effects on that as well.

FxParams Token so Far

OK enough tech talk, let's have a look at some FxParams pieces that have been minted so far:

The first FxParams drop by revdancatt:

A surprise drop by Tyler Boswell:

These cute pico punks by Aebrer:

This is my blog, so here's literally shameless plug:

Some stuff that hasn't been released yet:

Closing Thoughts

It's been fun looking into all of this and be a bit more involved with the fxhash community again. I'm looking forward to see how FxParams will develop in the future and how things will be refined with time. Until then, happy collecting! If you liked this post consider sharing it with your FxHash friends, sharing it on social media and maybe subscribing to the newsletter for future updates! Cheers!