Seed handling: regenerate_token stores raw bytes in artifactUri (invalid JS/UTF-8); stored artifact seed differs from frontend render seed

[TheBenMeadows]

Hi — I published generator svg-js/407 ("essentialism") today and found two seed-handling issues while verifying my token's on-chain data. They are related but have different fixes, so both are here.

1. regenerate_token writes raw entropy bytes into the stored artifactUri

Token 5364 was minted, then regenerated after a generator update. Its token_metadata artifactUri now contains the seed as 32 raw bytes spliced directly into the JavaScript:

...CDATA%5Bconst%20SEED%3D<32 raw bytes: e9 fa 85 15 ca f8 23 a1 ...>n%3Bfunction%20splitmix64...

The bytes match token_extra.seed for that token exactly. As stored, the artifact is not valid UTF-8 (the URI declares utf8) and not valid JavaScript, so it cannot execute if rendered directly from chain. A token that was never regenerated (5360, from a different generator) has a decimal number in the same position and executes fine. It looks like the mint path converts the seed to a decimal string and the regenerate path splices the raw bytes.

Repro: pull token_metadata for KT1CB4MYiAViCuXWBU961x7LjQXGeA8SnQwt tokens 5364 and 5360 from TzKT, hex-decode artifactUri, and inspect the bytes after SEED%3D.

2. Stored artifact seed and frontend render seed disagree

GeneratorDetail.jsx derives the display seed as Number(entropyBigInt % BigInt(2**32)). The stored artifact embeds a different, longer decimal. Measured on token 5360:

• entropy (token_extra.seed): 0x18478c30bb481ebf1a6ee178...
• frontend render seed (entropy mod 2^32): 238430315
• seed in the stored artifact: 11255154335010276574979107168794546114640444480930463, which splitmix64's 64-bit mask reduces to 295956255023153823

Those two values produce different rnd streams, so the artwork inside the stored artifact and the artwork the site renders are different images for the same token. I confirmed on my own token that the site render corresponds to entropy mod 2^32.

If the stored artifact is meant to be canonical, the renderer could parse the seed out of the artifact; if the frontend derivation is canonical, the artifact assembly could embed that value. Either way they should agree.

Happy to share the verification scripts and side-by-side renders for both issues.

[TheBenMeadows]

Following up with stronger evidence on the second issue, because it turns out not to be caused by regeneration and not to be specific to my token.

The stored artifact and token_extra disagree on a token that was never regenerated

Vandal™ #10 (token 5360, generator svg-js/27, generator_version 1, no regeneration in its history) records two different 256-bit seeds:

token_extra.seed   0x18478c30bb481ebf1a6ee178df10d537ada908d375a0384d416e73f60e36286b
  as decimal       10981922065886716342289018237780084128379266314892284837173546116840879958123

seed inside its artifactUri
                   11255154335010276574979107168794546114640444480930463064937132140196960933078

Both are readable from the public API:

curl 'https://api.tzkt.io/v1/bigmaps/771409/keys/5360'
curl 'https://api.tzkt.io/v1/tokens?contract=KT1CB4MYiAViCuXWBU961x7LjQXGeA8SnQwt&tokenId=5360&select=metadata'

then pull the value between SEED%3D and n%3B out of artifactUri. Since the artifact is what actually executes, those two values produce different rnd streams, so the seed recorded for the token and the seed the token renders from are not the same number.

A third value in the viewer

On my own generator's token (5364) I also read the seed out of the data: iframe your token page builds, and it was neither of the above:

68468206326414033182208490206218027875160410067690517625730587478246395170456

stable across reloads, while the same page displayed e9fa8515… under "Seed". I could not derive that value from the token's on-chain seed by any transform I tried.

Why it matters

I built a page for my piece that shows collectors their editions. I had intended to render each token locally from its on-chain seed, which would have shown people something other than the artwork they own — so I now display your rendered images instead. Anyone reproducing bootloader tokens from chain data would hit the same wall.

The first issue (regenerate writing raw seed bytes into artifactUri) still reproduces on token 5364 as originally described.

Happy to share the scripts for any of the above. Thanks for building this — the byte budget and the code-on-the-mint-page are why I chose the platform.