The specialist edge review

12 October 2026. A team seat, independent of the relation's owner, an in-house adversarial review of the Strata and window rounds, the floor lanes and a team seat that produced the band on the record. Written against main at 98b5a317 (the inputs listed in section 10 were read from that revision; nothing was asked of the team seats that produced the claims). Earliest draft; the computation named in section 9 has not run on a box.

Grades used on every number: MEASURED (a number read back from a card, a box or a shipped machine, its source named), DERIVED (arithmetic on measured numbers), ESTIMATED (an engineering estimate from published class figures, with its band), ASSUMED (a choice this review makes and states). No number in this document is served; it is a review for the board and the record.

0. The verdict in six lines

1. The frozen relation (version 8 revision 2c at the window gate point, features 4128, keyed twin 5152 at K 2) forces per hash: 64 dependent random 128-byte reads from a 2 GiB dataset and about 81,000 primitive 32-bit operations (DERIVED, section 2). Nothing in it forces an instruction stream: every data-dependent choice in the programme is a 3-bit lane select or a 2-bit phase, which a fixed datapath realises as a multiplexer.
2. A placed fixed-function engine (one round pipeline, contexts parked in a waiting station while their read is in flight, the dataset on a hybrid-bonded DRAM stack of the measured X16-Q class) spends 0.09 to 0.68 uJ per hash on the programme and 0.32 to 0.34 uJ on the memory (ESTIMATED on the engine, MEASURED class on the memory): 0.41 to 1.02 uJ per hash all in, central 0.57 (section 4).
3. Against the GPU row of record (RTX 5090 at a 500 W cap, 12.206 uJ per hash, MEASURED telemetry) the edge is 12x to 30x, central 22x, on the stacked class; 6x to 22x, central 12x, on an external GDDR board; against the most efficient card on the record (RTX 4090 at its 380 W knee, 7.05 uJ at the wall) 7x to 17x stacked, central 12x, and 3.7x to 12x on a board (section 5). Every band edge is above the 5x line; the one edge under 5x (3.7x) needs the weakest engine, the least costly memory class and the strongest card at once.
4. The record's band (2.53x central, 3.25x jointly feasible upper, 5.54x at the stacked extreme) rests on one modelling choice: the adversary is a SIMT-lane die that EXECUTES THE GPU'S INSTRUCTION STREAM, 610,352 thread-instructions per nonce (MEASURED on the card), at 5.5 to 7 pJ each. The relation's own arithmetic is 80 FP32 operations per lane-round out of 1,192 instructions the card issues (MEASURED, section 3); the other 93 percent is SIMT overhead (gathering programme words, bit-field decode, shuffles, selects, the tree computed in every lane, loop and control) that a wired engine does not pay. That is the structural shortcut the band missed (section 7).
5. The programme lever, as the measured kernel realises it, moves the edge the wrong way: it raises the card's energy 4.3x over the walk (12.206 against 2.844 uJ, MEASURED) and raises the engine's by about 0.1 to 0.7 uJ, so the edge on the stacked class goes from about 9x on the walk alone to about 22x on the blended relation (DERIVED).
6. What survives: the memory-class containment the record inherited from Ethash (a stacked specialist at 6 to 9x on the walk; shipped boards at 3 to 6x), the relation's exactness and admission rows, and the finding that the specialist's die is cheap and small (review 2 prices it). What does not survive is the sentence that the specialist's central edge is under 3x or that its upper edge is under 5x.

1. Scope and the rule I read by

The brief: take the frozen relation as the only input a specialist implementer has, derive the strongest specialist implementation that can be argued for at the level of a credible engineering estimate, compare it with the GPU row of record at the same work, state the edge as a ratio with its band and every assumption, and try to find a structural shortcut the band model missed. I read the relation earliest (SPEC-R0A-v0.md revision 0.19, sections 0.4, 0.8, 0.9, 4, 5), then the measured rows (cohort.json, the pod bundle's counters), then the record's model files as the thing under review (specialist-band-primary.json, the captured-mix files, version8-c-terms.json, simt-die.json, blend-machine.json, the ablation register's jointly-feasible-upper entries). I did not ask any seat for its verdict.

The frozen relation, as this review reads it: the launch document v8-d2048-s0-r64-k32-p256-w128-b2-x16-f5152-k2 (RELATION-STATE.md section 1, admitted; features bits 5, 10 and 12; KEYED_ROUNDS 2) and its unkeyed twin at features 4128, under which the shares and the open-seat blocks hash and under which every cohort row of record is measured (cohort.json: "the gate point (2, 16) f4128"). The keyed rounds are the sealer's alone (two keyed BLAKE3 compressions per attempt on the seal lane, RELATION-STATE.md 0.9.1: "the network's hashing carries no keyed overhead"), so the specialist's work per hash is the twin's; section 2.4 prices the keyed form for completeness.

2. The relation as a specialist implementer reads it

2.1 What one hash forces (the twin, features 4128; DERIVED from the text)

Primitive 32-bit operations per hash, counting a lane-descriptor as three (two selects and one FP pair), a tree node as five, a cell quad as eight, the exchange as six per lane: about 81,000 (DERIVED). State per nonce: 512 bytes of registers, the 512-byte block snapshot T (double-buffered inside the pipeline), the 128-byte item: about 1.2 KB.

2.2 What the relation binds, as the text itself states it

The text's own list of what cannot be shortened holds under this review: every item word enters the state (the absorb is a bijection in the item for a fixed state), the tree and the address (S1, S2); the item's bytes are keyed XOF output with no redundancy (S4, measured entropy 7.9999 bits per byte); nothing across rounds is precomputable because the next index depends on the whole round (S7); recomputing an item costs 256 cache reads and 8,192 FNV steps (S6); the programme's output depends on (item, state) and cannot be cached per item (0.8); the opcode class counts per block are fixed so no programme is cheaper than another (2b). I tried each of the shortcuts the brief names and section 7.2 says why each fails. None of this binds an engine to an INSTRUCTION STREAM, which is the point of this review: the relation fixes what is computed; it does not fix that a programmable lane computes it.

2.3 What the text expected the specialist to pay, in its own words

SPEC 0.8 (form (b)): "the GPU's cost per descriptor is two shuffles and one operation with no select; the specialist's is a crossbar per read"; and "the specialist's indexed-register shortcut is replaced by a crossbar it must build, which is the register-file term an in-house adversarial review found sets its edge". The crossbar of form (b) is eight-way within one nonce's octet (the overlap ruling, 0.8: "the crossbar form (b) forces is eight-way per read (the octet), not 32-way"). An eight-way 32-bit select is a three-level multiplexer tree, about 100 transistors per bit; its energy at a 7 nm class node is of the order of 0.05 to 0.15 pJ per select (ESTIMATED from the record's own mux term in blocks_engine.py, 0.004 to 0.015 pJ per bit per stage, times 32 bits times 3 stages). The record's engine charges 0.6 to 1.2 pJ for the two crossbar reads of a descriptor plus 1.25 to 1.95 pJ for a 128-entry register file plus 0.3 to 1.5 pJ of issue and decode PER INSTRUCTION, and then counts the GPU's instructions. Section 6 takes this apart term by term.

2.4 The keyed form (features 5152, K 2), for completeness

Two keyed BLAKE3 compressions per sealing attempt, the shares bound by the once-per-block proof pi (0.9.1). On a fixed-function BLAKE3 unit a compression is about 80 pJ (the record's own figure, REDTEAM-R0A.md 2.2, ESTIMATED), so the keyed form adds about 0.2 nJ per hash to the seal lane and nothing to the share lane. It does not move the edge. The split-execution and appliance questions of 0.9.2 are custody questions, outside this review.

3. The GPU row of record, and how the card spends its energy

3.1 The rows (cohort.json at main 98b5a317; MEASURED)

The brief names the GPU row of record; this review reads the edge against it and, beside it, against the 4090 knee, because the record itself names that row the candidate comparator and a reader of the public text will do the same division.

3.2 Where the 12.2 uJ goes

Thread-instructions executed per nonce: 610,352 (640 x 10^9 predicated-on thread-instructions over the launch), that is 1,192 per lane per round. By class:

So the relation's arithmetic (the FP32 operations the programme exists to force, plus the cell and the tree) is about 15 percent of what the card issues; the rest is the SIMT cost of expressing a data-chosen lane as a shuffle, a bit field as an extract, a phase as control, and the tree as eight redundant copies. The card's issue slots are 57 percent active (smsp__issue_active), warps active 39 percent, the chief stall reasons short scoreboard (29 percent, the shuffle and shared-memory latency) and fixed-latency wait (27 percent): the kernel is bound by its own dependent chains and shuffle latency, at a power cap it reaches whatever it does. A leaner kernel could cut the count; the card's energy per thread-instruction on this kernel is 20 pJ for the whole relation and 15 pJ attributed to the programme (DERIVED). The record's "13.7 pJ at the sheet rate" is the right order; the count is the problem, not the energy per instruction.

Per lane-descriptor the card spends 571 pJ (9,362 nJ of programme over 16,384 lane-descriptors, DERIVED). An FP32 multiply and add at a 7 nm class node cost about 1 to 2 pJ placed (section 4.2). The gap on the programme term is two orders of magnitude, and it is the whole story of this review.

4. The specialist design: a placed estimate

4.1 The machine

One compute die per 2 GiB dataset, the dataset on a hybrid-bonded DRAM stack (the X16-Q class, the record's stacked machine: a DRAM die bonded to a logic die, the row of record for Ethash's identical 64 x 128-byte random pattern), or, for the chip anyone can build, the same die beside commodity GDDR6 on a board (the Antminer E9 class). The compute die holds:

• R round pipelines, each fully pipelined over contexts: one round of one nonce enters per cycle and leaves about 45 to 60 stages later. Stages, in order: absorb (1 stage); block 0 (16 slots x 8 lanes in parallel, each slot a multiplexer pair, the mask wiring, one FP unit: about 6 to 8 stages of FP latency); block 1 the same, reading block 0's output (the snapshot T of the text is the pipeline register between the two block stages); the tree (5 levels of a multiply node, about 15 stages; or one SRAM or DRAM-beside-the-item read of the precomputed digest, S9, if the builder prefers the memory to the 31 multipliers); the cell (4 quads per lane in parallel, 8 sequential operations with two multiplies, about 12 to 16 stages); the exchange and the next address (2 stages). The pipeline's registers carry the context's 512 bytes of lane state plus the item and the snapshot; no register file exists.
• A waiting station: when a round leaves the pipeline its context (512 bytes of state and the next index) is written to a slot and its read is issued; when the item returns, the slot is read back into the pipeline's entry. Slots needed: the rate times the per-round latency. At the X16-Q class's random latency (the record's stacked-machine band 150 to 300 ns, ESTIMATED) plus about 40 ns of pipeline, a nonce takes 64 x (190 to 340) ns = 12 to 22 us; at 670 MH/s per stack (the record's central machine, MEASURED class) that is 8,000 to 15,000 contexts in flight, 5 to 10 MB. On a GDDR6 board the latency is 300 to 600 ns and the station 2 to 3x larger per MH/s. A station is an SRAM (the conventional form) or, for the strong band, banks of latches read through a multiplexer; either is a few mm2 at a 7 nm class node (N7 HD SRAM 24.8 Mbit per mm2, the record's sram_machine.json, DERIVED class).
• The memory controller and PHY (the stacked class's bond interface, or a GDDR6 PHY on the board class), the BLAKE3 units for the seed, the lane fill and the finalisation (3 to 4 compressions per hash, one unit per several pipelines), the nonce scheduler, the result filter and the host interface.

Throughput: one pipeline at 1.0 GHz completes 10^9 rounds per second, 15.6 MH/s; a stack serving 670 MH/s needs 43 pipelines, a 2,000 MH/s board about 130. Area at N7 (ESTIMATED from synthesis-class cell figures: an FP32 add-subtract about 600 um2, an FP32 multiply about 1,500 um2, a 32-bit integer multiply about 1,000 um2, simple ALU cells 100 to 200 um2): a pipeline holds 2 x 128 FP multipliers (one per slot per block, a quarter active), 2 x 256 FP adder-subtractors, 31 + 64 integer multipliers, about 1,500 simple cells and its multiplexers: about 1.5 to 2.5 mm2; 43 pipelines 65 to 110 mm2, plus the station, the controller and the PHY: a compute die of 100 to 180 mm2 at N7, or 250 to 450 mm2 at 28 nm (the Ethash boards' node class). Feasible on every count; review 2 prices it.

4.2 Energy per round on the engine (ESTIMATED; bands [strong, central, weak]; nJ)

Datapath energies at a 7 nm class node, placed: from the published 45 nm energy-per-operation table (ISSCC 2014 keynote: FP32 add 0.9 pJ, FP32 multiply 3.7 pJ, 32-bit integer multiply 3.1 pJ, 32-bit add 0.1 pJ; REPORTED) scaled by 5 to 8x for the node and multiplied by 2 to 2.5 for pipeline registers, clock and local wiring (ASSUMED, the usual placed-over-datapath factor; the record's own datapath term, 1.5 to 4.0 pJ per instruction in version8-c-terms.json, is the same class of figure and is not disputed here).

Beside it, the record's engine for the same work: 9,362 nJ divided by c, c 4.99 / 2.16 / 0.9: 1,876 / 4,334 / 10,402 nJ per hash (DERIVED from captured-mix). The two estimates differ by 5x at the record's stacked extreme and by 18x at the centrals. Section 6 says why.

4.3 The memory term per hash (the walk; the classes the record itself keeps apart)

The memory term does not change between the walk and the blended relation: the fetch pattern of version 8 is version 4's (0.8: "the fetch stream is version 4's walk"), and the AMD walk-only rows confirm the version 8 round without the block costs nothing over Strata W128 (TUNING-R0A.md, MEASURED on the 9060 XT).

4.4 The specialist's energy per hash, all in (DERIVED from 4.2 and 4.3)

Throughput per watt at the central stacked point: 566 nJ per hash is 1.77 MH/s per watt, against the 5090 row's 0.082 and the 4090 knee's 0.142 (DERIVED). Per die: a stack at 670 MH/s draws about 380 W central (the X16-Q's measured share 219 W plus the engine's 160 W at 0.24 uJ), a figure the X16-Q's own 620 W machine at 1,850 MH/s brackets.

5. The edge

x = (the GPU row's uJ per hash) / (the specialist's uJ per hash), the specialist strong against the GPU row gives the attacker-favourable edge (the record's convention: upper = the strongest credible specialist).

Beside these, the record's own reading on the same GPU row: 2.53x central, 3.25x jointly feasible upper, 5.54x at the stacked extreme (captured-mix, DERIVED by the record); and the walk-alone edge on the stacked class, 2,844 over 326: 8.7x (DERIVED).

The ratio with its band, in one line each:

• Condition 1's headline, this review: against the GPU row of record the specialist's energy edge is 22x central with a band of 12x to 30x on the stacked class (ESTIMATED on the engine, MEASURED class on the memory and the card), and 12x central, 6x to 22x, for the board any mining-ASIC vendor can build; against the most efficient card on the record the same machines read 12x (7x to 17x) and 7x (3.7x to 12x).
• The record's sentence ("central 2.53x, upper 3.25x, under 3x and under 5x") does not survive this review. The sentence the record's own class ruling allowed for Strata ("substantially limits conventional external-memory ASIC advantage, but does not presently limit hybrid-bonded stacked-memory specialists below 5x") survives for the walk and, on this review, no longer holds its earliest clause for the blended relation: the board class reads 6x to 22x against the row of record.

6. Why the record's band reads 2.5x and this review reads 20x: the reconciliation

The record's engine (version8-c-terms.json, captured-mix, the ablation register's jointly-feasible-upper rows, cycle_util.py, upper_published_file.py) is defined as follows, in its own words: "c = (the GPU's energy per programme instruction at 70 percent of its native rate) / (the placed engine's energy per instruction)"; the placed engine's energy per instruction is the sum of a datapath term (1.5 to 4.0 pJ), a register-file term (0.8 to 2.5 pJ at 16 entries, 1.25 to 1.95 at the 128-entry depth eight interleaved contexts need), an issue-and-decode term (0.3 to 1.5 pJ: "a fixed per-nonce schedule read from an on-die programme store") and a clock-and-leakage share (0.5 to 2.0 pJ), over a utilisation (0.75 to 1.0) and a package factor; the engine's energy per hash is then the GPU's programme energy over c, which is the GPU's INSTRUCTION COUNT times the engine's energy per instruction (upper_published_file.py: e = engine(mix, ...), the GPU's Nsight mix). The combined edge is 1 / (m / A + (1 - m) / c) with m the memory share of the card's energy (0.202) and A the memory class's edge.

Three things in that construction are, on this review, wrong for the frozen relation, and one is right:

1. THE COUNT. The engine is charged the GPU's 610,352 thread-instructions per nonce. The relation needs about 81,000 primitive operations per hash, and the heavy ones (the FP pairs) are 32,768 roundings. The card issues 7.6 instructions per primitive operation and 15 per FP operation (section 3.2) because a data-chosen lane is a shuffle, a bit field is an extract, a phase is a branch or a select, the programme words must be gathered across lanes, and the tree is computed in every lane. A wired engine pays none of these: the fields are wires, the lane choice is a multiplexer, the phase steers a 4-way FP unit, the tree is computed once, there is no loop. Correcting the count alone, at the record's own per-instruction engine energy (5.5 to 7 pJ), takes the engine's programme term from 3,400 to 4,300 nJ down to about 81,000 x 5.5 to 7 pJ = 450 to 570 nJ, and the combined edge on the stacked class to about 14x. This is the dominant correction and it does not depend on any energy figure of mine.
2. THE REGISTER FILE. The text (0.8) and the record price the specialist's lane as a programmable lane with a 2R1W register file, deepened to 128 entries so that eight contexts can interleave to hide the fetch (the ablation register's jointly-feasible-upper entry, cycle_util.py's output: "the utilisation the schedule allows needs eight contexts interleaved per lane"). A fixed round pipeline has no register file: the lane state travels in pipeline registers, the block snapshot is the register between the two block stages, and contexts waiting on memory sit in a station that is written once and read once per round (0.2 to 2.5 nJ per round, section 4.2, the engine's largest term). The register-file term the text names as "the term an in-house adversarial review found sets its edge" is a property of the SIMT-lane die the record chose as adversary, not of the relation.
3. THE CALIBRATION. c's band (1.3 to 4.0, "a GPU-shaped random program") was anchored on the Antminer X5 against a CPU on RandomX (REDTEAM-RANDOMX.md: "the specialist for a RandomX-class program is itself a CPU"). That anchor is right for RandomX, whose program space (about 30 instructions over 20 registers, a 2 MiB scratchpad, branches, double precision with program-set rounding modes, superscalar dependency shapes) defeats a fixed pipeline, and the same file says RXE1 "lacks the scratchpad, branches, FP and the superscalar shapes" and "as written buys the class nothing". Version 8 revision 2c has: fixed destination slots, fixed source slots, fixed opcode class counts per block, no scratchpad, no branch, no rotate under bit 5, no data-indexed register; its per-descriptor "programme" is 256 possibilities (8 x 8 x 4), all multiplexable. The late binding per nonce and per round (the item draws the fields) prevents COMPILING a programme; it does not prevent WIRING the datapath, because the datapath is the same for every programme and only its select lines change. The RandomX calibration was imported into a relation that is not in the RandomX class, and the record's own RandomX file says what the class needs.
4. WHAT IS RIGHT: the memory side. The stacked class's A band (5.98 to 9.74 on the walk) and the external board's (2.36 to 5.77) rest on measured shipped machines, and this review uses them unchanged. The record's finding that the 40 nm Ethash incumbent die cannot run the programme (SUPPLY-CORNERS.md section 11, superseded by 12) is also right; the error is in what replaces it (a GPU-class SIMT die) rather than the fixed pipeline of section 4.

The independent reviewer's gate conditions as the record read them ("combined central at most 4x, c upper at most 5x") were met by construction of c, not by the relation. The condition the independent reviewer wrote for closure, "an independent placed-design review", was the right instrument: a placed design is where the count assumption breaks.

7. The structural shortcut found, and the ones that fail

7.1 Found: the wired descriptor (the headline)

Stated once, plainly: under form (b) with bit 5 the programme is not code. Each descriptor's effect on lane l is R[l][d] = bits(f) ^ T[l][d] where f is one of four fixed two-rounding binary32 expressions of mask(T[l][d]), mask(T[(l + s1) & 7][d + 1]) and mask(T[(l + s2) & 7][d + 2]), with s1, s2 (3 bits each) and the block's phase (2 bits) the only data. An engine realises descriptor (b, d) for all eight lanes as sixteen 8:1 multiplexers, the mask wiring, eight 4-way FP units and eight XORs, all in one pipeline stage group; the 32 descriptors of a round are two such stage groups in series; the whole round is one pipeline. The cost per lane-descriptor is one FP pair and two multiplexers, 2 to 8 pJ placed, against the card's 571 pJ (MEASURED on the card, ESTIMATED on the engine). The relation's whole-item rule, the address path and the trace identity are untouched: the engine computes exactly the text, exactly as the reference does, and its proofs verify. Nothing in the text, the window ruling ("no shortcut that removes programme execution from the address path"), the verify ruling (2b) or the overlap ruling excludes it, because it removes nothing from the address path; it executes the programme on wires.

Four lesser shortcuts sit beside it, each granted or cheap:

• The tree once, not eight times: the engine computes h once per round (31 nodes) where the SIMT kernel computes it in every lane or shuffles it across them; or stores the 32-bit digest beside each item (S9, granted by the record for version 4 and still true of version 8, whose tree is version 4's over unkeyed leaves).
• The programme words are the item words: at B K = 32 = n there is no lap constant and no second read; the engine's select lines are tapped from the item register.
• The block snapshot is a pipeline register, not a double-buffered file: the text's T semantics ("a snapshot of every lane's register file at the block's entry") is the natural form of a pipelined datapath and costs nothing.
• The station replaces the register file: contexts in flight are a capacity question (5 to 10 MB), not a port question; the engine runs at full utilisation with one context per stage, which the record's cycle_util.py found a programmable lane could reach only with eight contexts and a 128-entry file.

7.2 Tried and failed against the relation as frozen (each with why)

8. Assumptions, ranked by how far each moves the edge

The single most dangerous assumption in the RECORD's band is the count: that the engine executes the GPU's instructions. The single most dangerous assumption in THIS review is the station term (rank 3), because it is the one engine term that is not a datapath and the one a placed design could show heavier than estimated; even at three times the weak estimate the edge stays above 5x on the row of record.

9. What would turn the edge from estimated to measured

1. A placed round pipeline on an open or licensed PDK: RTL of one pipeline (the absorb, two block stages, the tree, the cell, the exchange, the address) and a station of 256 contexts, synthesised and placed at a 7 nm predictive or a 28 nm open process, power-analysed on the reference's descriptor stream (the trace sets' block and regs records give the exact switching activity), read against the reference's vectors for exactness. This is one engineer-week of RTL and a box with the tools; the output is a MEASURED-class energy per round and an area, which replaces section 4.2's bands. This is the computation the earliest draft has not run; it needs a box allocated with a synthesis flow.
2. The memory side needs nothing new: the X16-Q wall row and the shipped-board rows are measured; a wall reading of a bonded stack running the version 4 walk would add nothing the Ethash pattern has not shown.
3. The GPU side: the card's energy per hash is measured; the one row that would move it is a leaner kernel, which is the project's own lever and is read on the card when it exists.
4. For the sentence on the public text, the artefact that would let the project say "measured" is an FPGA implementation of one pipeline against an HBM card (review 2 section 3.4): it measures the pipeline's exactness and energy at an FPGA's efficiency, a lower bound on the ASIC's.

10. Record: inputs, by path at main 98b5a317

Grade summary: the card's rows and counters MEASURED; the memory classes MEASURED class (shipped machines, the record's admitted rows); the operation counts DERIVED from the text; the engine's energies ESTIMATED with bands; the whole-machine factors ASSUMED and stated. No em dash; no personal name; no box name; times UK.