fxhash calls itself “the open generative art platform.” Artists publish code rather than images: the platform runs your program with a unique input hash for each mint, and the output of that run is the artwork a collector receives.
That design puts one engineering requirement above everything else, and the documentation states it in a sentence worth reading twice.
Determinism is the whole contract
From the fxhash documentation:
“the absolutely most important aspect of a GENTK is that it is entirely deterministic”
The same input hash must always produce the same output, “no matter the circumstances under which it is run.” That is not a style guideline. A collector owns a hash; the artwork is whatever your code produces from it. If your program produces something different tomorrow, or on a different machine, the thing they own has changed.
So the first rule is mechanical. The ordinary JavaScript random number generator is out:
“This RNG is not seeded and will produce different random numbers each time that we run our code.”
Instead, fxhash injects the hash into your code and gives you a seeded generator:
“all random number generation, or random selection processes in our code need to be done with the
$fx.rand()function”
Other generators are permitted provided they are seeded from it — p5’s randomSeed() is named as an example, and you may write your own PRNG if you seed it correctly.
The three ways people break determinism anyway
This is the part the documentation is unusually good on, and it is where real projects fail. Swapping Math.random() for $fx.rand() is easy. Keeping the sequence identical is the hard part:
“The important notion here is that the number of random calls in the GENTKs code needs to be consistent.”
A seeded PRNG produces a fixed sequence. Draw from it a different number of times and everything after that point shifts. The documented hazards:
Loops whose iteration count depends on the window. Basing anything on browser dimensions is a trap, because those “might vary on different devices.” A loop that runs 40 times on your monitor and 52 times on a phone consumes a different number of random values, and the artwork diverges. Hard-coded loop counts are fine; responsive ones are not — at least not if they gate random calls.
Floating-point imprecision. Named explicitly as a cause. A comparison that lands on one side of a threshold on one platform and the other side elsewhere changes a branch, which changes the call count.
Anything conditional on the environment. The general form of both of the above.
The practical discipline: draw all your random values up front, into an array, before any layout logic touches them. Then responsive rendering cannot change what was drawn. It is a small architectural habit that makes the whole class of bug impossible, and it is worth adopting on your first project rather than your third.
The tooling is better than people expect
fxhash ships real development tooling, which is unusual for an art platform:
- A CLI and a project template (“the fx(hash) boilerplate”) so a new project starts from a working structure.
- fxlens, an interactive project viewer, for stepping through hashes locally instead of minting to find out.
- fxparams, a module that lets collectors set parameters at mint time, with a documented set of parameter types.
- A testnet path, documented as its own step in the release flow.
Use fxlens and the testnet. The failure mode this category is known for — an edition that renders wrongly for a fraction of collectors — is almost always a determinism bug that would have surfaced by cycling a few hundred hashes locally.
Also worth knowing: the platform is no longer Tezos-only. The documentation covers withdrawing earnings on ETH and Base through a splits contract, so a release involves choosing a chain, with different fee and withdrawal mechanics attached.
Two things to decide before you mint
Your licence. The documentation has a dedicated page on licensing a project, and the choice is yours rather than the platform’s. For generative art the question is sharper than for a static image, because what you are licensing is code plus outputs. Decide explicitly what a collector may do with the rendering and whether anyone may reuse the program. Deciding by default is still deciding.
Pricing, supply, reserves and splits. These are separate documented steps in the mint flow — supply and pricing method, primary and secondary splits, reserves and allow lists. They are configured once, at release, and they shape the edition permanently.
There is also a newer financial layer — $FXH and “art coins,” described in the documentation as “project native currencies linked at the contract level.” That exists, it is optional, and whether it belongs in your release is a judgement outside the scope of a technical review. Read the mechanics page before opting in, not after.
Who this is for
Programmers who make visual work, or visual artists willing to become programmers. The barrier is not the blockchain; it is writing a program whose output is both interesting across thousands of seeds and bit-identical for each one. That is a genuine craft, and the platform’s tooling respects it.
If your interest is collecting or trading rather than publishing, objkt is the broader Tezos marketplace and indexes contracts across platforms. The rest of our coverage of this area sits in the media and design archive.
The finding: fxhash’s one hard requirement is that your code be entirely deterministic, and the documented failure mode is not using the wrong random function — it is letting the number of random calls vary with window size or floating-point edges. Draw every random value up front, verify across hundreds of hashes in fxlens and on testnet, and settle your licence before the mint rather than after.
Primary link
Learn more at: https://www.fxhash.xyz/
