Jane Street reveals its chip puzzle was an 11x11 Star Battle checker

In August, Jane Street published a puzzle that gave entrants only the final GDS layout of a small chip. There was no netlist and no internal signal names; solvers had to reverse-engineer what the chip did. The firm has now posted the results, the solution, and a tour of the approaches it liked best.

The firm received about 400 submissions from more than 30 countries, most of them from the US, India, the UK and Australia. Entrants ranged from high school students and researchers to working engineers and retirees. Most used KLayout, Yosys and Z3 alongside custom tools, many of them AI-written, in Python, Rust, C++, OCaml, Haskell and even Odin.

The chip turned out to be a hardware checker for an 11x11 Star Battle puzzle, also known as Two Not Touch. The goal is to place exactly two stars in each row, column and colored region, with no two stars touching, even diagonally. The chip accepts 121 cycles of inputs, one per square, each saying whether to place a star there. It then runs parallel checks: a 2-bit counter for every row and column requiring exactly 2 stars; a 121-bit ROM mapping squares to regions, with a 2-bit counter per region; a delay line that tracks nearby squares so no two stars touch; and a counter for the total number of stars, used for some Easter egg outputs. The checks are ANDed into a success signal. The output generator keeps its strings in ROM, obfuscated with a small LFSR driven by the game board, so the solution does not appear as plaintext. On success it deobfuscates and emits the solution string. Most wrong answers print "TRY AGAIN". The chip was designed with the SKY130 open-source standard cell library and the LibreLane toolchain.

The first step for solvers was extracting a gate-level netlist. Jane Street left cell names such as sky130_fd_sc_hd__nand2_2 in the GDS files so that LVS passes in tools like Magic and KLayout could produce a raw netlist. Some took the harder road: Vladislav Shapovalov wrote his own extraction pipeline in C++ to parse the GDS, extract each cell's shapes and combine them with the cell names, debugging it first on the warm-up design.

Next came simulation. Some solvers generated Verilog and used the SKY130 cell models with an existing simulator; others, such as Stephen Ebert, built their own evaluators. The supplied waveform let them replay inputs and compare outputs, but matching it did not prove the simulator was right. Alejandro Soto Franco described a Python model that reproduced the supplied trace while getting every tie-high cell wrong: these cells should supply a constant one, but the model left their outputs at zero. That effectively disabled the adjacency check, so a solver using it could find apparently valid boards with touching stars. He caught the problem by comparing the model against a separate Icarus Verilog simulation on additional inputs.

Four broad strategies are described. Working backwards from the success output through the netlist was the approach Jane Street most expected. It left floorplan hints: each island in the layout matched one module in the original RTL. Sanjay Ravishankar drew bounding boxes over each region, split the schematic along them, checked module boundaries by connectivity, and simulated each module. Dynamic exploration meant simulating with varied inputs and watching intermediate signals. Aaron Shi "treated the netlist like a system and hit it with impulses at various positions", diffing every flop against an all-zeros baseline. He saw that the changing flops matched rows, columns and regions, each needing to reach exactly 2, and built a solution grid from that. SAT solving can take a circuit unrolled over a fixed number of clock cycles and find inputs that make success true, but it reveals little about the chip. Lokesh Aravapalli used the SAT result as a start and then analyzed the circuit with those inputs, producing visualizations. Gabriel Taboada attacked the output generator directly, reverse-engineering the output circuitry to learn how the solution was encoded and which seed produced the right outputs.

The post also highlights visualizations. Joshua Stapleton built a viewer showing schematic and layout side by side. José Vargas made a walkthrough of how a chip is built from PMOS and NMOS transistors and how he extracted them to find each cell's logic. Amruth Gulawani made an online playable version of the encoded puzzle, including some Easter-egg outputs. Kjartan van Driel's interactive animated walkthrough of how a chip is constructed is called possibly the authors' favorite. Other projects: Alexander Smallwood synthesized the extracted netlist onto an FPGA with switches and LEDs as I/O; Nikhil Kaniyeri compiled it into Minecraft command blocks; David Garner converted the whole chip into an analog SPICE simulation to check his answer; Marcin Wójcik built a Groth16 zero-knowledge proof that he had the solution without revealing it.

There were Easter eggs. Two entrants found all six intended ones, and six people found six of the seven when counting the floating-wire bug. The eggs: decoding the two failed attempts in example_inputs.vcd as 7-bit ASCII gives "THE NIGHT SKY AWAITS"; the VCD header is dated Sat Dec 31 23:59:60 2016, a real leap second, and its $version string nudges you to open the file in a waveform viewer; marks on an unused layer below the die spell PER ARENAM AD ASTRA in Morse code, "through the sand, to the stars"; failure messages include EMPTY SKY for all zeros, BIG BANG for all ones, and a TWO NOT TOUCH hint for boards that pass the counts but have adjacent stars; about 1,400 isolated squares on met2 form a 57×57 pixel Jane Street logo; and the eleven regions spell out "JSC". The seventh item is an unconnected wire in the TWO NOT TOUCH output path, which made some solvers see TWO"NOT TOUCH in simulation. It began as a bug in Jane Street's layout, was caught in an LVS pass, and was left in on purpose. Many solvers traced it to the floating a31oi input, and a few reported it as a bug.

In its takeaways, Jane Street says AI is going to be part of challenges like this and is a game changer for building analysis, netlist viewing and debugging tools. Some entrants used it for small scripts; others gave agents the whole puzzle. When the authors first devised the puzzle, they saw that the latest models could, given a single prompt, come up with the final solution in 30 minutes or less, which takes away much of the fun and learning. They also note that several solvers kept digging after finding the answer to understand what the chip was counting, and that models which reproduced the sample waveform perfectly still contained mistakes that only comparing separate implementations and constructing inputs that should fail exposed.

Key facts

Jane Street's August puzzle gave only a chip's GDS layout; the chip is a hardware checker for an 11x11 Star Battle puzzle (Two Not Touch), built with the SKY130 library and LibreLane toolchain.
About 400 submissions arrived from more than 30 countries; most solvers used KLayout, Yosys and Z3 plus custom tools, many AI-written.
Approaches included backward tracing from the success output, impulse-style dynamic exploration, SAT solving, and attacking the LFSR-obfuscated output generator.
One Python model matched the supplied waveform yet got every tie-high cell wrong, silently disabling the adjacency check.
Two entrants found all six intended Easter eggs; Jane Street says the latest models could solve the puzzle from a single prompt in 30 minutes or less when it was devised.

Why it matters

The post is a detailed case study in hardware reverse engineering from a physical layout alone, and it shows how many different routes lead to the same answer: layout-aware tracing, simulation, SAT solving and attacks on the obfuscation. It also gives a concrete data point on AI in this kind of work. Jane Street says AI is a game changer for analysis, netlist viewing and debugging tools, and that when the puzzle was first devised the latest models could, from a single prompt, reach the final solution in 30 minutes or less.

Who it affects

Mainly people who enjoy puzzles, hardware engineers, and anyone interested in chip layout analysis or verification tooling. The entrants themselves were a mixed group: high school students, researchers, working engineers and retirees. Puzzle designers also take away a lesson, since the authors note that AI assistance takes away a lot of the fun and learning from working through a challenge like this.

How to use it

The post is a reading list of writeups. Anyone wanting to learn the workflow can follow the steps it describes: extract a gate-level netlist from the GDS (Magic or KLayout LVS passes work because cell names were left in), build or reuse a simulator, then reason about the logic or hand the circuit to a SAT solver. Most solvers used KLayout, Yosys and Z3. The visualizations by Kjartan van Driel, José Vargas and Joshua Stapleton, and the playable version by Amruth Gulawani, are pointed to as good ways to see how the chip works.

How solid is it

This is a first-party account from the puzzle's authors, who know the design, so the description of the chip and its Easter eggs is authoritative. The statements about AI are the authors' own observations. The visible text names no winner, prize or ranking of submissions, and does not say how many solvers used AI or how.

Risks and caveats

Matching a supplied waveform is not proof that a simulator is correct: Alejandro Soto Franco's model reproduced the trace while leaving tie-high cells at zero, which disabled the adjacency check and allowed apparently valid boards with touching stars. The authors say comparing separate implementations and building inputs that should fail exposed errors that replaying examples missed. The claim that models could solve the puzzle in 30 minutes or less is the authors' own, given without detail on which models or prompts.

“treated the netlist like a system and hit it with impulses at various positions”

— Aaron Shi, quoted from his writeup in Jane Street's post