How a Chain puzzle is made

Every Chain puzzle begins as a date and ends as a row in a database, and in between it gets thrown away several times. Nobody picks the target, nobody places the decoy tiles, and nobody sits down and decides that today's puzzle feels about right. Here is what happens instead. If you have not played one yet, the rules are the shorter read.

The date is the seed

The generator never looks at a clock. It is given a string — for the puzzle of 7 September 2026 that string is 2026-09-07:chain — and everything else follows from it.

That string is hashed with FNV-1a, a small 32-bit hash that walks the characters one at a time. 2026-09-07:chain comes out as 3844008438. That number seeds a generator called mulberry32, which turns it into a stream of numbers that look random and are not: the same seed always produces the same stream, in the same order, on any machine. The whole thing is deliberately written in 32-bit integer arithmetic, because that is the part of floating-point maths that every browser, every Node version and every processor agrees on exactly. A date does not merely tend to produce the same puzzle. It produces the same puzzle.

Each attempt at building a puzzle also gets its own sub-stream, named after the attempt: 2026-09-07:chain:attempt:0, then :attempt:1, and so on. That matters more than it sounds. It means the fourth attempt does not depend on how many numbers the first three happened to consume, so a change in one part of the process cannot silently shift everything after it.

The puzzle is walked, not searched for

The obvious way to build one of these is to pick a start and a target and then hunt for a route between them. That is not what happens, because hunting can fail and because it tends to produce targets that no route reaches neatly.

Instead the generator takes a walk. It draws a start between 10 and 99, then plays moves at random — weighted roughly 30% add, 25% subtract, 20% multiply, 15% divide, 10% swap digits — until it has played as many as the day's budget: three on an easy day, four on medium, five on hard. Wherever it lands is the target.

The walk is fussy about what it accepts. A divide is only ever drawn from the numbers that divide the current value exactly, so an impossible division can never end up inside a solution. No two tiles may share an operation and an operand. Only one swap tile is allowed in a hand. The walk refuses to revisit a value it has already stood on, so the chain never doubles back. And the last step has to land between 100 and 999 and must not land on the start. If the walk cannot find a legal step within a dozen draws, the whole attempt is abandoned and the next one begins.

The real walk behind 7 September went 79, then +54 to 133, then +55 to 188, then −28 to 160. Target 160, three moves. Because the solution is the walk, an unsolvable puzzle is not something that can be generated and then missed. It is something that cannot exist.

The spare tiles are built to be wrong convincingly

A hand holds more tiles than the budget: five tiles for a three-move easy day, five for a four-move medium, six for a five-move hard. So there are two spares on easy days and one on the others.

Most of the time — about seven times in ten — a spare is a solution tile nudged. The generator takes one of the additions or subtractions the walk actually used and shifts its number by somewhere between one and ten. On 7 September the solution used +55 and −28; the spares are +65 and −36. Ten more, and eight more. The rest of the time a spare is drawn fresh, tested against a value the walk really passed through, so that a spare divide is at least exact somewhere along the true route.

Then the whole hand is shuffled — a plain Fisher–Yates pass — and only afterwards labelled first tile, second tile and so on. The position of a tile on your board carries no information at all about whether it belongs to the answer.

The solver reads the entire tree

Now the candidate is handed to a solver that does the least clever thing possible: it plays every legal sequence of distinct tiles up to the move budget and writes down where each one ends. Six tiles and a five-move budget is 6 + 30 + 120 + 360 + 720 = 1,236 sequences. An easy board is 85. Nothing is cached and orderings are not collapsed together, because on this board the order genuinely is a separate thing.

That exhaustive list is what every rule is then checked against.

Is the budget honest? The solver notes the shallowest depth at which anything reaches the target. The walk guarantees that a full-length solution exists, so if the solver finds one shorter, the board would be asking for five moves when four would do. Rejected.

Is there exactly one answer? Every sequence that hits the target is reduced to the set of tiles it used. If two different sets both work, the candidate is rejected. Several orderings of the same set are not just permitted, they are normal: the hard puzzle of 11 September can be played in eighteen different orders. The uniqueness that matters is the set, which is why the strategy guide is about ruling tiles in and out rather than about shuffling.

Are the spares believable? Each spare must be legal from at least one position you could actually reach, and it must appear in at least one full-length chain that ends within ten of the target. A spare you could eliminate by noticing it can never be played is not a decoy, it is a typo. If any spare fails this, the whole candidate goes.

Is it typical for its length? Last, a feature score is computed and checked against a calibrated band, which is the subject of the difficulty guide.

What gets thrown away

Over the sixty days from 1 September 2026, the generator built 187 candidates to keep 60. The 127 rejects break down like this: 13 walks dead-ended, 16 had a shortcut, 5 had a second solving set, 62 had a spare that could not be made to look plausible, and 31 scored outside their band.

Two things in that list are worth noticing. The rejection everyone expects — more than one answer — is the rarest, five in 187. And the decoys are the bottleneck by a wide margin. Easy days need the most attempts (a median of four, against two for medium and hard) precisely because an easy hand has two spares to justify rather than one.

The loop gives up after 500 attempts and raises an error rather than serving something unchecked. Across 3,000 test seeds, that has never happened.

Why the puzzle is stored rather than remembered

The obvious economy would be to store the date and regenerate the puzzle whenever someone asks for it. We store the whole thing instead: start, target, hand, solution, score, engine version, and a precomputed walkthrough.

The reason is that the puzzle is a function of the seed and of the code. Change one operation weight, one rejection rule, one line of the scorer, and 2026-09-07:chain yields a different puzzle — a perfectly good one that is not the one people played. Storing the row means past days on the archive stay exactly as they were, each stamped with the engine version that made it, while the generator stays free to improve for future days.

The days are filled in ahead: a nightly run keeps a month of them in place, the container fills the range at start-up if the next week is missing, and the health check refuses to look healthy unless tomorrow already exists. Every day is re-verified as it is written — one solving set, the budget equal to the shortest solution, the score inside its band — and a day that fails any of those is recorded by its failure code and skipped rather than published.

One last thing the storage does: your browser is never sent the solution or the score. It receives the start, the target, the hand and the move count, and nothing else. The solver runs on our side of the wire, and its output stays there.