to September 2026. This is the complete internal write-up, translated
in full. It includes the work still in progress and the things currently
broken - we would rather be transparent than polished.

Overview

In seven months the project went from a local solver to the 466/480 record
and to a distributed computing setup running on three channels.

[pre]
First solver files 2 March 2026
Record reached 466/480, on 19 September at 13:27
Boards >=463 collected 63,577
of which 464 2,546
of which 465 67
of which 466 1
First board recorded 31 July 2026, 22:42
Fleet at peak ~3,300 threads, ~100 G nodes/s
Compute channels native Windows/Linux, browser, BOINC
Distinct participants 13
[/pre]

Every record was obtained on the five official clue board, the most
constrained variant. The 464 wall held from March to August; the 465 wall,
ten days in September.

March to July 2026: foundations and the 464 wall

Five months to build a solver at the state of the art, then to establish
that it plateaus at 464.

[*]2 March - first solver files
[*]5 March - project README
[*]20 March - first commit
[*]23 March - first GPU avenue opened
[*]15 June - GPU propagation benchmarks
[*]6 July - work resumes on the 464 wall
[*]31 July, 22:42 - first board >=463 recorded in the library

The DFS is calibrated against jwortmann's reference record, then tuned for
the strict five-clue variant.

The cause of the 464 wall is identified during this period: too few search
basins climb towards high scores, and boards at 464 are locally rigid
(Hamming diameter <= 3). In other words, you cannot climb from a 464 to a
465 - climbability is a demonstrated NO-GO.

Avenues closed during this period: cell-free relational backbone,
good-groups, macro-transitions and lineage, proof learning on UNSAT cores,
P4c reordering, multiseed recombination (ceiling at 433). The starter-only
solver at 471 is judged out of practical reach.

August 2026: the 465 falls, the fleet is born

The month the project stops being a single machine: 465 is reached on
11 August, the library opens, and outside contributors arrive.

[*]1 August, 05:45 - first 464 recorded
[*]5 August - "levers" campaign: every wall-breaker is null, the only
gain is fertility sorting (+15%)
[*]9-11 August - first 465, internally validated, distinct
from the known external record
[*]13 August - 72-hour GPU campaign; a second distinct 465
[*]13 August - GPU DFS-warp closed: correct but ~7,000x too slow
[*]19 August - LBdemSigma gated: +4.6%. Meta-lever found: gate an
expensive bound behind a cheap signal
[*]20 August - root allowlist audit: keep as is
[*]22 August - the board library becomes public
[*]26 August - first-discoverer dedup; PCs tab by physical machine
[*]27-28 August - four overnight mandates, all negative: Regin/Hall,
pair-conflict, finite fields, spatial sigma
[*]28 August - campaign hot-reload: rotate roots with no restart
[*]29 August - ledger incident resolved; verdict on the short cap
[*]31 August - 465 drought broken: two new 465s the same
evening, fleet at 100% on B1

The single most important lever of the whole project is found this month:
the LB-sigma parity cut in the tail solver, proven sound, measured at 615 to
677x on the part it touches.

Thirteen boards at 465 are found in August, including the first ones by
outside contributors.

1 to 18 September: scaling up

The fleet grows tenfold in a week, and the project finally learns to measure
where to put its power.

[*]3 Sept - Cloudflare cost incident: a full rebuild inside a cron
running every 2 minutes
[*]5 Sept - "exhaustion" refuted as the explanation for the drought
[*]7-12 Sept - Jef's machines arrive: the fleet reaches ~3,100
threads. 27 boards at 465 in six days
[*]13 Sept - recompute bug fixed: seven servers were redoing tickets
already done
[*]14 Sept - "hors1850" pass: the whole fleet for 24 hours on 1,850
fresh roots
[*]14 Sept - the big machines' "outages" explained: they were
computing without appearing, while re-uploading their boards
[*]14 Sept - integrated supervisor: no machine ever needs a manual
restart again
[*]16 Sept - orientations discovered: all 32 known 465 boards
have their defects on rows 0-4. Frames are deployed
[*]16 Sept - 465s land on young roots: 27 out of 29 below 37,500
tickets
[*]17 Sept - the ladder rungs (236/230/224) produce 74% of all 465s:
never cut them
[*]18 Sept - cell-preparation memoisation lever: +5.5% on Linux
[*]18 Sept - Cloudflare cost audit and three fixes; R2 ledger live
[*]18 Sept - measured law: a root's yield halves every 10,000
tickets

The orientations rollout of 16 September is the technical turning point: it
multiplies the volume of boards >=463 by 2.3 and the 464s by 1.8.

This is also when the project stops looking for levers inside the solver and
starts looking for them in allocation: which root, to whom, for how long.

19 September 2026: the 466

The record falls at 13:27 CEST, on one of Jef's machines, after five boards
at 465 in the preceding twelve hours.

[*]02:45 to 08:22 - four boards at 465 overnight
[*]13:25 - a 464 comes out on a root that had never produced anything
[*]13:27 - 466/480, from the same ticket as that 464
[*]15:19 - one more 465, same day

The 466 was validated twice independently, on the five official clue board.

Three lessons came out of it.

Its root skipped 465. It produced a 464 at 13:25 then the 466 at
13:27, from the same ticket. The implicit model - you climb one rung at a
time - is wrong.

We were in the unlucky 10%. The 466 arrived after 36 roots had
produced a 465, where the predicted median was 11. So the 466 wall was never
"proven": we had simply been wrong to expect it sooner.

Its root ranked 55th out of 3,084 in the shallow sweep, and was
unreachable under uniform allocation. Without fertility sorting it would
never have received enough effort.

The 467 is estimated at three to four months at September's effort level.

20 to 28 September: industrialisation and BOINC

With the record secured, effort shifts towards fine-grained allocation and
towards a second recruitment channel.

[*]20 Sept - the Linux engine never had PGO: x1.12 available, already
wired up
[*]20 Sept - "Complex Theory" as a root ranker: no better than
chance, closed
[*]21 Sept - the 10,000 tickets per root rule; a root's reachability
depends on slot mod gcd(nroots, 4096)
[*]21 Sept - short cap closed after 50,383 attempts
[*]22 Sept - root wear recomputed: the re-find rate goes from 33% to
72%
[*]22 Sept - 10% node protection for the 39 roots that produced a 465
or the 466
[*]22 Sept - BOINC project starts: the production solver stays
unchanged, BOINC is only a transport layer
[*]23 Sept - weighted auto-assignment deployed: a returning machine
goes where it is needed, and only where its slot can reach roots
[*]23-24 Sept - BOINC server stood up; full chain proven end to end
[*]24 Sept - BOINC discovery relay fixed: 57 boards recovered
[*]25 Sept - switch to the public URL through a Cloudflare tunnel
[*]28 Sept - BOINC/native display parity; 126 BOINC hosts registered
[*]28 Sept - Linux 2.24 withdrawn (empty archives); Windows 2.28
fixes efficiency-core throttling

The architectural rule for BOINC fits in one sentence: ticket ranges are
never allocated locally. The gateway receives an exclusive shard from
the control plane and partitions only that one, which makes any overlap with
the native fleet impossible by construction.

What worked, what did not

Over seven months, not one gain came from a new theoretical idea: they all
came from provably sound pruning, from measuring the hardware, or from
allocating the effort.

The real gains
[pre]
Lever Gain Nature
----------------------------- --------- -----------------
LB-sigma parity cut (tail) 615-677x sound pruning
Orientations / frames x2.3 new territory
Root sorting by fertility x1.6 allocation
Tail node-cost micro-levers x1.41 identical tree
Gated LBdemSigma +4.6% meta-lever
Linux engine PGO x1.12 never deployed
Cell-preparation memoisation +5.5% Linux only
[/pre]

Closed avenues

GPU (sound but ~7,000x too slow, two campaigns), climbing from a 464 (proven
NO-GO), Regin/Hall/all-different, finite-field placement codes,
pair-conflict, spatial sigma, proof learning on UNSAT cores, transposition
family, relational backbone, good-groups, short cap, attractor cutting
(0.16% of tickets), "Complex Theory" as a ranker, deep rewind r208,
depth-kernel extension, WASM PGO.

If you are working on this puzzle yourself, that list may save you months.
Ask and we will share the measurements behind any of them.

Method rules learned the hard way

[*]Always stratify by exposure. A ranker that looks good on
unstratified data turns out to be no better than chance.
[*]Never rule on a rare-event counter without a test. Below thirty
events, Poisson noise dominates everything.
[*]Reason in nodes, never in threads. A thread-based estimate was off
by a factor of two on a cohort's real share.
[*]A feature tested before the endgame predicts nothing. One hundred
percent of the score gap is decided in the last twelve cells.
[*]Measure before believing an impression. Several "obvious" facts -
we are finding fewer, that machine is faster - turned out to be false once
measured.

State as of 28 September 2026

The record stands at 466/480 and the project runs on three channels, one of
them open to outside volunteers.

The native fleet has around fifty active machines for ~2,400 productive
threads, plus 126 registered BOINC hosts. The current campaign runs on
Frame 2, with 3,084 roots in the catalogue.

Open work

[*]Public BOINC launch - domain verified, tunnel live; still to do
are the mail sender, reCAPTCHA, terms of use, testing an invited account,
and auditing the code-signing key.
[*]BOINC credit calibration - set at 32 per validated WU, to be
checked against real WU duration, whose spread is still unknown.
[*]Machines with a stalled engine - three machines restart in a loop
without ever activating their kernel, about 700 unproductive threads.
[*]Linux engine PGO - x1.12 validated and wired up, never deployed.
[*]Effort telemetry - the local aggregator has not run since
9 September, which blocks any per-node yield measurement.

Open questions

The 467 is estimated at three to four months at the current rate. The only
identified way to speed that up remains allocation: serving more fresh roots
in parallel, since a root's yield halves every 10,000 tickets. That is also
the real argument for BOINC - not computing faster, but covering more roots
at once.

Thanks to everyone running a client. The 466 was found on a volunteer
machine, not on mine.

Hello Benjamin,

Is this your website too? https://eternity2.dev/

Interesting mathematical jigzaw puzzle. Maybe use AI to solve it ;)

Are you planning to build a gpu app in the future?

Edit: a few of the boinc volunteers in our community have used AI such as Claude Code to optimize or perhaps assist to port cpu app to gpu app. GPU app will certainly run a lot faster than cpu.

Thx.

Check the banner on the home page. It's the same puzzle.

Hi, and thanks for the interest.

eternity2.dev is not mine. It belongs to another French enthusiast working on
the same puzzle - we exchange regularly and he does excellent work.

On AI: I use it daily on the code, and I am happy to say so openly. But it
does not solve this puzzle. Eternity II is exhaustive combinatorial search,
not pattern recognition - there is nothing to infer, only branches to
eliminate.

On GPU, the honest answer is that we already tried, twice, and it is not the
porting that failed. We have working GPU code, verified sound. It is about
7000x slower than the CPU version.

The reason is the shape of the computation. It is a depth-first search with
backtracking, so every thread in a warp branches differently within a few
nodes and the parallelism collapses into divergence. Memory access is
irregular, with no coalescing to be had. Each placement depends on the
previous one, so there is nothing to vectorise. And the work is integer and
bitwise logic, not dense floating point - exactly where a GPU has no
advantage. It is the same wall SAT solvers and general backtracking hit on
GPU.

So AI assistance would not change the outcome here: the port is not the
obstacle, the architecture is.

That said, if anyone has an idea for reformulating the search into something
massively parallel and regular, rather than porting the existing one, I am
genuinely interested. That is the only way a GPU would help.

Wow thanks to this very big explaination of all this!

Its fresh to see that way of communication :)

---

---------- 24/7 Crunching since 2011 -----------
DSKAG Austria: http://www.dskag.at

The main problem I have is that is a full solution to this problem actually mathematically possible?

Here is what is actually known.

The puzzle was not generated at random and then offered up in the hope that it
happened to be solvable. Monckton recruited Alex Selby and Oliver Riordan - the
two people who had solved the original Eternity - to design Eternity II,
starting in 2005. A commercial puzzle carrying a two-million-dollar prize is
built the other way round: you start from a valid board and derive the pieces
from it. The creators know a solution. They have simply never published it,
and the contest closed on 31 December 2010 with the prize unclaimed.

That has a direct consequence for what we are doing here. The five official
clue pieces were supplied by the publisher, so they come from the creators' own
solution. The five-clue board we are searching therefore has at least one
solution - theirs. We are not chasing something that might be empty.

What does not exist is a public mathematical proof. Nobody outside the design
team has ever seen a complete board, and no one has published an existence
argument. Counting arguments suggest a solution space far larger than one, but
they assume independence between edges, which is false here, so they are
intuition rather than proof.

Also worth knowing: edge-matching puzzles of this kind are NP-complete. There
is no clever shortcut waiting to be found. The only known approach is search
with good pruning, which is exactly what your CPU is doing.

And if it turned out no solution existed? Proving that would require exhausting
the search space, which is far beyond any computing effort available today -
ours or anyone's. So that question cannot be settled by brute force either way.

In practice: the people who built it know it can be done, we are working on the
variant their own clues came from, and every board we push higher is a real
result regardless. Our current best is 466 of 480 edges.

In reply to benjamin's message of 29 Sep 2026:

Our current best is 466 of 480 edges.

Would be good to keep track of the number of edge-matching edges found by our boinc volunteers here and publish it somewhere in your project site for posterity. It seems that there are also folks outside of boinc community doing the search as in the link that I posted earlier by the French guy (also by the name of Benjamin) that you mentioned.
Something like 466 out of 480 found on 1/1/2020 by ....
467 out of 480 found on xx/xx/xxxx by ....
Until we reach 480 out of 480, mission accomplished!

From what I read in the earlier link that I posted, 470 out of 480 is the current record. https://eternity2.dev/viewer/?puzzle_size=16&puzzle=Joshua_Blackwood_470&board_edges=ajraaftjabvfafpbajefarcjablrajubafpjanefajmnabpjafebabifafsbaabfruratiouvvsiptuvewstcugwlwouuicwpdlieiidmocipctoelecigoesccgbabcrifaootisddoudmdsggdlddgopddcluplmwlimemicswttpcehutotvhcwetbajvftratuttdchumstcgvvsdwvvdwvwuhewwluhedvlsmsdptemupwtvvdcepemjarprijatdoihltdtmolvwomvcwwvcieesscuhssvtihshltetehwdltdhcdeighrarcjhjaoelhtileoliiosclwcssitpcscptscicilmclshlehhslgvhcwvgppvwrafpjmbalhmmlluhimulcmimsggmpppgpmhpiovmmwpohsewhwqsvwiwvovwvqdofafqbgbamhtguqghucmqitecglstpeclhmsevlompgtlehvgqtohievtvpmedutpfafubhfatplhgiipmqgiemdqsdpmclidsgglodegtohdvohoocsovcucmgoctikgfafiflnalqpliluqghvlddwhpdqdikgdgepkewiehodwhccosugcuuouoegukwlefarwnqnapdhqutkdvkqtwedkqswegpgspuopihpudqchcueqgqkuousqgpmulswprarsncnahqvckwoqqwuwdmewwvdmgttvovmtpkivcslkepkskuupsqgumsgqwsdsrajsnhfavqwhogkqukvgeowkdesothqemklhimwklklmkqtkuikqgsuigtvsdvktjanvfdnawlqdkgqlvlqgwqklsuhqqvqulimvwkpiloektkuokdckuqkdvpuqkompnajongbaqhqgqmkhqkkmkwgkhoqwqviomokvpmkoeqtmumiqcdhmkqedukwqmpkkjajpbraaqnarkjankbajgnabqbaninabkbankjabtnajiranhnarenanwrankrarjaar&motifs_order=jblackwood

I have a feeling that this will take a very very long time unless we can speed up the search process including the use of gpu, at least not 100% but majority of the time. Was thinking about cpu-gpu hybrid solution i.e. splitting the tree search between cpu and gpu. If gpu can do a fast tree search without backtracking (going deeper only) to the end point and then cpu can do something else. Just random thoughts here without any much knowledge in programming and combinatorial search with back tracking or perhaps that random thought of mine is very inefficient. Haha, found this that explains the gpu part of it: https://eternity2.dev/research/build/hardware/gpu-solving/

BTW, is there any collaboration with other teams to prevent search work duplication or this puzzle is inherently difficult to split the work among other teams due to the need to do back tracking?

That is a good suggestion. We already record every validated discovery with its score, date, contributor, and board, and we can publish a permanent milestone history.
One important distinction: the 470/480 record was achieved with one fixed clue, while our project searches the strict five-clue variant, so the scores are not directly comparable.
And the French Benjamin mentioned on eternity2.dev is actually me — it is the same project. 🙂