igneum/docs/analysis/attack-pass-2026-10.md

Internal attack pass before the freeze (F1 to F10)

The internal cryptanalysis pass of docs/plans/cryptanalysis.md section 4.2, run before the freeze tag cryptanalysis-target-1, so the paid engagement confirms rather than discovers. the project lead's word, 7 October 2026: "make sure they find ZERO flaws". Every finding is ours, fixed and re-gated, before any firm starts.

Target: the hash class the chain runs after 0.3.15's flip, igneum-pow generator v4 V4_CLASS = mx8+sh256x27 (LoadClass::MX8, ShadowClass { instrs: 256, reps: 27 }), the acceptance rule, the verifier, the era draw, the latency-shadow dataset and ladder, the chip and FPGA cost model. Scope and gates are section 1.1 and 1.4 of the plan, the same tests the firm is held to.

Lane: attack-pass, worktree igneum-wt-attack, branch attack-pass from origin/master ab99e5e3. Binary built on igneum-build-1 (ELF x86-64, igneum-pow 0.2.0, sha256 6d2867...1a9ebe5) and run there under the box's slots; model and era work from sim/horizon/algorithm/model.py and infra/fast-time/. Each row below carries the method, the known-failed shape where one exists, the result with numbers, and PASS, RUNNING, BLOCKED or FINDING. The freeze tag waits on every row reading PASS or FIXED-AND-PASSED. Main checks every number against the log before quoting it to the project lead.

Status board

#	Attack	Gate (same as 1.4)	Result so far	Status
F1	Shadow block compressibility and shortcut search	best compressed block within 5% of N on every program; no program over 10% compressible	pending evidence map + box run	RUNNING
F2	Mixer round margin (SAT/MILP, 1 to 4 keyed applications)	no distinguisher or shortcut beyond 2 of the 8 applications	pending evidence map (ca2-mixer) + box run	RUNNING
F3	Chained cache j+1 bound and storage-vs-recompute curve	no derivation under j+1 blocks; curve monotone; f=1 point unchanged	0 of 64 and 0 of 1,024 lines under j+1 (exhaustive closure search, cross-checked by exhaustive pebbling at 10 lines, 10,240 pairs, 0 mismatches); both planted broken chains fire; curve monotone at both op counts; f=1 point 9,360 ops per item unchanged. Record docs/analysis/attack-pass/f3-cache.md	PASS
F4	Weak-day census over 2^24 day keys	fraction of days with gain over 1.1x under 2^-20	pending box census	RUNNING
F5	Chip-model sweep + AWS F2 FPGA hour	evidence row 17 holds across the sweep; FPGA row under 27 M reads/s/W	sweep: 2.1x at k=1 GDDR7 reproduces, 3.2x at k=0.5, 4.1x at k=0.3 (matches ledger M32); FPGA row 2.3 to 2.9 G/s, 10 to 20 M reads/s/W (literature). FINDING: the k=0.33 figure is framed as the X9's measured core (M32) and a "measured class" (ladder branch §5a); the X9 was withdrawn before launch and never benchmarked. F2 hour SKIPPED: no AWS account	FIXED-AND-PASSED (sweep PASS; AP-F5-1 fixed and re-gated 7 Oct 2026: chip section re-run 2.1x at k=1 unchanged, identity grep 0 hits, site lane concurred); F2 hour SKIPPED-BY-DECISION (the project lead, 7 Oct 2026, 09:5x UK; plan 4.2 row F5 is the sweep only at 3714c2a0; the FPGA row stays the JEDEC-ceiling model row labelled unmeasured)
F6	Verifier worst case over 10^5 programs + O-1.14 laptop run	worst program under 10 ms cold on the half-core proxy and the laptop	v4 average 4.90 to 5.06 ms one-core cold, 8.23 ms half-core proxy (under 10 ms). Worst-case search over 10^5 and laptop run owed	RUNNING
F7	Era-draw bias harness + 2^20 era-seed census	no re-roll inside the publish window; no era class with gain over 1.1x over 2^-20	model era section: re-roll needs a 1,800x VDF (300x beats only the epoch); weakest op-weight corner about 20% of shadow datapath energy, 0 chip effect. Harness + 2^20 census owed	RUNNING
F8	Uniformity censuses (line-index 2^28, distinct lines, cross-hash histogram)	largest bucket within 6 sigma of uniform; no hot set under 1% of items	interim, phase D at 2^26 nonces: top 0.1% of items take 0.520% of reads vs 0.115% uniform (4.05x), top 1% 2.49% (1.37x), one item 153x the mean, read site 15 feeds 6.37% of its reads into the hot 0.1% in all 8 iterations; shortcut under 1% of rate today. FINDING AP-F8-1 routed to the Counter ASIC lane; phase E (64 seeds) pending	FINDING (open)
F9	Acceptance edges (39) + header grinding on an RTX 5090	zero passing programs with a hot set under 1%; grinding gain under 1% of rate	edges reproducible via accept; grinding measurement needs PC 2's 5090 or a rented pod	BLOCKED (PC 2 go / pod)
F10	Ladder signal monotonicity harness	no step without 90% over 7 windows in either direction	pending fast-time harness	RUNNING

The rows

F1. Shadow block compressibility and shortcut search (hash lane)

Method: over 10^4 class v4 programs, constant folding, dead-register elimination, common subexpressions across the 27 repetitions, linear sub-block detection, SAT equivalence on reduced blocks; the minimum op count per program against N. Known-failed shape: a shadow that constant-folds or dedupes across its 27 identical passes so a chip pays fewer than 55,296 shadow instructions per hash. Entry point: igneum-pow show --program-class v4 prints the 256-instruction shadow (op mix add=47 rotl=30 xor=30 shfl=29 mad=27 mul=22 sub=21 rotr=20 mulhi=18 or=12 on the genesis seed). Gate: best compressed block within 5% of N on every program; no program over 10% compressible. Result: RUNNING. What a failure moves: an acceptance-rule line for the shadow block (rule (c) runs the block), packs re-cut.

F2. Mixer round margin (hash lane, on the box)

Method: SAT or MILP differential and linear search on 1 to 4 keyed applications with drawn rotations; rotational-XOR on the ARX layer; the fold of the multiply layer across applications checked algebraically. Known-failed shape: a differential or linear trail or an algebraic fold that distinguishes or shortcuts more than 2 of the 8 applications between dependent reads. Gate: no distinguisher or shortcut beyond 2 of the 8 applications. Result: RUNNING (prior ca2-mixer evidence to be re-gated). What a failure moves: mixer_mult 16 or a shape change; verifier re-measured.

F3. Chained cache j+1 bound and storage-vs-recompute curve (hash lane, on the box)

Method: exhaustive search on a 2^10-line model segment for a line derivable without an earlier line; the curve from f = 1/64 to 1 in ops per item. Known-failed shape: a line (s, j) computable in fewer than j+1 block evaluations without an earlier line (the MTP address-steering break shape). Gate: no derivation under j+1 blocks; curve monotone; f=1 point unchanged. Result, 7 October 2026, 09:10 to 09:12 UK on the box (docs/analysis/attack-pass/f3-cache.md; logs /srv/builds/igneum-wt-attack/attack-f3/r1-*.log): PASS on all three clauses. The chain extracted from Cache::fill_segment (verified equal to the code on 16 of 16 key and segment pairs; block == chacha_block on 100,000 random inputs) has line j fed by line j - 1 only; the exhaustive closure search finds 0 of 64 and 0 of 1,024 lines under j + 1 (every line costs exactly j + 1), cross-checked by an exhaustive pebbling search at 10 lines (10,240 configuration and target pairs, 0 mismatches). The two planted chains fire: skip2 (63 of 64 under j + 1) and nofeed (every line in 1 block). The curve over stored cache lines is monotone non-increasing from f = 1/64 to 1 at 608 (counted) and 700 (MEMHARD.md) ops per block; the f = 1 point is 9,360 ops per item, 41.7 MH/s at the 50 T op/s budget, unchanged. ca2-cache was the hot-table experiment, not a chain analysis, so there was nothing to re-gate. Observation (coordinator and the F3 record, not a finding): funding.md B2 rank 2 prices the trade-off at the naive placement; the optimal placement of every 8th line costs 3.17 blocks per read, not 3.5, and 16.0 at f = 1/64, not 31.5 (brute force over 4,426,165,368 sets at n = 8); the chip stays worse than the full mirror at every f under 1, so the verdict stands, and a chacha_block shortcut in chaining mode stays the paid question (Lot A and B). What a failure would have moved: the chain construction (a second feed-forward or a cross-segment tie).

F4. Weak-day census over 2^24 day keys (hash lane, on the box)

Method: 2^24 day keys through MixParams::with_shape; the ROT classes (all equal, complementary pairs, small amounts), MUL low weight, RC structure, each per-day gain measured on the box verifier. Known-failed shape: a day key whose drawn ROT/MUL/RC gives a fixed datapath a gain over 1.1x (the "weaker authorized parameters" class, Kudelski 2019). Gate: the fraction of days with any gain over 1.1x under 2^-20. Result: RUNNING. What a failure moves: a rejection-and-redraw rule on the draws.

F5. Chip-model sweep and the FPGA hour (algorithm lane)

Method: sim/horizon/algorithm/model.py over k 0.2 to 1.5, tFAW 12 and 28 ns, HBM4 2.3 and 21.4 G reads per stack, amortisation 1 to 3 years, electricity USD 0.05 to 0.15 per kWh; and the AWS F2 hour replacing the FPGA ceiling row with a measurement. Known-failed shape: an input of the published model that, when corrected, lifts the f=1 chip's per-joule edge over the 5090 above the published 2.1x at k=1.

Gate: the published sentence (evidence row 17) holds across the sweep; the FPGA row under 27 M reads/s/W.

Result (sweep): PASS on the numbers. The model's measured-anchor column (GDDR7, the 5090 reads 82% of its ceiling) gives the f=1 chip's v4 per-joule edge over the RTX 5090 bench row as 4.1x / 3.2x / 2.1x / 1.5x at k = 0.3 / 0.5 / 1 / 1.5. At k = 1 the figure is 2.1x, and 3.9x at k about 0.33, which matches fud-ledger.md M32. The higher HBM3 and HBM4 columns rest on an 8-activate per 12 ns window that JEDEC HBM2 timings (4 per 28 ns) do not support; the model already states GDDR7 is the column to quote. One wording gap: evidence.md row 17 says "brings it to about 2x", which is a floor that holds at k about 0.9 and above but understates the edge at lower k (3.2x at k = 0.5). The accurate statement is M32's, 2.1x at k = 1 with the k range beside it. The sweep's numbers stand; the finding is the X9 framing below.

FPGA row: the HBM2 FPGA ceiling is 2.3 to 2.9 G reads/s (measured Shuhai U280, FCCM 2020, equal to the JEDEC tFAW-bound 2.3 G/s), 10 to 21 M reads/s/W at 115 to 150 W, 0.30 to 0.47x of the 5090 per watt. Under the 27 M reads/s/W gate. The AWS F2 hour is SKIPPED-BY-DECISION (the project lead, 7 October 2026, 09:5x UK: not needed for now, not blocked; plan 4.2 row F5 at commit 3714c2a0 on branch cryptanalysis is the chip-model sweep only, 4 h, the algorithm lane). There is also no AWS account or aws CLI on this Mac. The FPGA row stays the JEDEC-ceiling model row labelled unmeasured; Lot C prices it from the reads-in-flight model; the firm is told the F2 measurement was not run.

FINDING (X9 framing), owning lane algorithm and hash (the ladder lane is closed, so ours): the published numbers already carry 2.1x at k = 1 beside 3.9x at k about 0.33 (fud-ledger.md M32, recalibrated under X35). The error is the framing. M32 calls the k = 0.33 figure "the X9's core" and the ladder branch's latency-ladder.md section 5a calls k about 0.33 a "measured class". Bitmain's Antminer X9 (RandomX ASIC, 1 MH/s, 2,472 W, about USD 5,600) was announced and, per pcpraha.cz ("Antminer X9 canceled: Bitmain withdraws model from market before launch") and r/MoneroMining, withdrawn before launch. Its implied core efficiency (k about 0.33) is a CLAIMED datasheet figure from a design that never shipped and was never benchmarked, not a measured calibration point. It is carried as the pessimistic bound, not a calibration. This collides with the merged ledger X34 ("RandomX has a shipping chip; correct every sentence that said otherwise"): if the X9 was withdrawn, X34's correction is itself wrong and must be reversed. Confirmed from primary sources (coordinator, 7 October 2026): pre-orders opened 26 December 2025 (shipments scheduled for July 2026), withdrawn in mid-May 2026 with buyers refunded before any unit shipped, no independent benchmark, Bitmain never published a cancellation (its shop lists it as sold out), and the box was commodity Sophgo SG2044 server SoCs with an AES accelerator and 60-plus DRAM sticks, no tapeout; its claimed edge about 2x per joule over a tuned Zen 4 part, about 3x over a stock desktop CPU. Re-cut applied the same day: evidence.md row 17 (claim and measured cells) and fud-ledger.md M32's answer paragraph on attack-pass, and the ladder design doc section 5a on branch attack-ladder-5a from the ladder tip 7003f9f5 (the ladder branch is checked out by another lane, so the fix rides its own branch for the ladder owner to take). The served-text rows (X34 reversal, X36) belong to the site lane, which confirmed the wording agrees. What a finding moves (plan 4.2 F5): the sentence re-cut before the freeze so the firms attack the corrected model. The re-cut, once the fact is confirmed: k about 0.33 labelled a claimed pessimistic bound from a withdrawn design everywhere it appears; 2.1x at k = 1 on the GDDR7 measured anchor kept as the headline with the k range beside it; k itself unmeasured until Lot C produces it. This row reads FIXED-AND-PASSED only after the re-cut and its re-gate.

Economic row the withdrawal implies: a recompute chip at a 3x fixed-function factor against a CPU and GPU fleet must recover its NRE (low to mid seven figures at a modern node, chip-model-v3.md) and carry a fork threat (a class change at 95% miner signal can redraw the datapath the chip bakes in). The X9 at 2.47 J per KH against a RandomX CPU fleet did not clear that bar at Monero's hash and price; the same arithmetic against Igneum's class v4, with the shadow block and the automatic era draw as extra firmware risk, is why the chip model's verdict is a deliverable and not a courtesy (plan 2.3). The confirmed reading: a box with a 2x to 3x per-joule edge and no NRE (commodity SoCs) was withdrawn rather than face a 1.5x re-tune of RandomX, so the tapeout economics of a 3x chip against Igneum are worse than the X9's. This row is the pessimistic case, not a measured gain.

F6. Verifier worst case (algorithm lane)

Method: 10^5 class v4 programs timed on the box one-core and half-core proxies for the slowest warp (base program and shadow block), plus the O-1.14 laptop run (the Windows igneum-pow build on the box, the relay, bench --warps 50). Known-failed shape: a drawn program whose verifier warp exceeds 10 ms cold (the acceptance rule bounds the miner's side, not the verifier's; dr736 already FAILs at 10.51 ms cold one-core, but it is not the shipping class). Gate: the worst program under 10 ms cold on the half-core proxy and on the laptop.

O-1.14 route (coordinator, 7 October 2026, 10:1x UK): no US laptop is due, so the laptop run is replaced by a rented 2019-class CPU host through the fleet agent, capped at two hours of rent; the Linux igneum-pow from the box (the same binary as the proxies) runs bench --warps 50 for v2, mx8, mx8+sh256x27, dr368 and dr736 (the known-fail) on it; INCOMPLETE with the numbers so far if the cap lands first. The Windows exe was also built on the box for the day a laptop appears (1,009,675 bytes, sha256 fbed7538...e6c9). Outcome, 09:40 UK: no 2019-class CPU host stood up. Vast accepted and dropped five CPU-class rents within 30 s each (i7-9700K, i5-8500, Xeon W-2133 and W-2123) under the account's automatic new-account spend limit (support ticket open since 6 October), and RunPod has no 2019-class CPU pod; so O-1.14 reads INCOMPLETE on the box proxies today and stays a precondition of the freeze. Next try: the US laptop when it registers on the relay (the exe is ready), or Vast once the spend limit lifts; the bench script is staged and runs in minutes. Correction, 10:4x UK (fleet agent): the provider dropped nothing; every rent stood up and ran, hidden by Vast's instance listing cap of 25 rows on an account holding 38, so the hosts sat idle and were destroyed. The fallback is re-rented under the same word (i7-9700K class, two-hour cap from its start, read by id); the result replaces this line when it lands.

Result (average, verified on the box): class v4 mx8+sh256x27 runs 4.90 to 5.06 ms per warp cold on one EPYC 9454P core (nice 19, taskset), 8.23 ms on the half-core proxy (both SMT siblings busy). Under 10 ms. Status RUNNING: the 10^5-program worst-case search and the O-1.14 laptop relay run are owed before the row reads PASS. What a failure moves: an acceptance-rule bound on verifier cost; the ladder's ceiling set from the measured core.

F7. Era-draw bias harness and census (node lane harness, hash lane census)

Method: the fast-time 3-node network (infra/fast-time/) with an adversary withholding or publishing the last blue block before C_era(n) to re-roll the draw; a census of 2^20 era seeds for stride, ROT and weight-perturbation classes with gain over 1.1x; the 64-bit seeding of the day-key stream against the spec's intent. Known-failed shape: a re-roll of the era draw inside the 2 s publish window, or an era class (stride bijection, all-equal ROT, low-weight M) with a chip gain. Gate: no re-roll inside the publish window; no era class with gain over 1.1x at a fraction over 2^-20; the draw's input set as the spec states it.

Result (model, from the era section): re-rolling by withholding needs the 3,600 s VDF evaluated inside the 2 s publish window, a 1,800x faster evaluator; the spec's margin table gives 300x, which beats only the epoch, not the era. Forging the checkpoint needs 20 days of 100% hash. The weakest op-weight corner (fewest multiplies, 16 of 75) is about 20% of the shadow's datapath energy and 0 on the memory side, and the GPU moves the same way. The fast-time re-roll harness and the 2^20 census are owed. Status RUNNING. What a failure moves: the draw procedure or the C_era cut rule; a redraw rule for the era stream.

F8. Uniformity censuses (hash lane, on the box)

Method: the line-index distribution over 2^28 derivations; distinct lines per hash and per warp on 10^6 nonces of three programs; the cross-hash item histogram of one epoch. Gate: the largest bucket within 6 sigma of uniform; no hot set under 1% of items. Result: RUNNING. What a failure moves: the mask or the fold; packs re-cut.

F9. Acceptance edges and header grinding (hash lane; one PC 2 job)

Method: the 39 edge disagreements reproduced and bounded; a search over 10^6 seeds for programs that pass rule (c) with a hot set under 1%; the header-grinding search cost against its DRAM-locality gain measured on PC 2's RTX 5090 (one job through tools/build-job.mjs). Known-failed shape: a seed grind that steers a program to a hot cache set for DRAM locality, or an edge where the closed-form stand-in disagrees with the live verifier in the attacker's favour. Gate: zero passing programs with a hot set under 1%; the grinding gain under 1% of rate at any search cost.

Result: the accept path reproduces per-seed verdicts (genesis seed: 1 candidate ACCEPTED, bias max 54, 0 saturated). The header-grinding cost-versus-gain measurement needs a 5090. Status BLOCKED on the go decision: use PC 2's 5090 through a relay run job only if PC 2 is online and mining is unaffected, else a rented pod under the standing fleet budget. What a failure moves: the closed-form stand-in replaced by the live verdict at the edges; a locality term in rule (c).

F10. Ladder signal monotonicity (node lane)

Method: the fast-time harness with a weight that steps the ladder down and never up, and an 89% signal; the step rule's monotonicity and its memoisation per seed block. Known-failed shape: a chip owner stepping the ladder down (cheaper N) without the 90% threshold, or a step registered under 90%. Gate: no step without 90% over 7 windows in either direction; a step down needs the same. Result: RUNNING. What a failure moves: the step rule's text in spec 01 before the ladder is frozen.

Operating hazards found by the pass

AP-H1 (box scratch cleaned by builds; found by F3, 7 October 2026, 10:0x UK). infra/build-server/remote-run.sh line 71 runs git clean -qfd -e target -e 'target-*' ... on /srv/builds/<worktree> before every remote build, so an untracked box scratch directory of one row (a venv, a log dir, a crate's tools/attack/*/target) is deleted by the next build from any row. F3 protected its own directory through the box mirror's .git/info/exclude; the lane then added attack-*/, target-attack-*/, tools/attack/ and .build-remote.log to that file at 10:1x UK, after which git clean -fdn on the mirror lists nothing (the clean has no -x, so the exclude file applies). The class check is owed to the build-server lane: the clean line should spare a lane's declared scratch prefix (-e 'attack-*' style, or read a per-worktree exclude list), and a CI check should fail a remote-run.sh whose clean line lacks it. OPEN until that check lands (CLAUDE.md: a rule row closes only with its check).

Ledger rows

AP-F5-1 (algorithm and hash lane, ours; the ladder lane is closed). The k about 0.33 chip-efficiency figure is framed as a measured calibration ("the X9's core", fud-ledger.md M32 L172; "measured class", ladder branch docs/design/latency-ladder.md section 5a). The Antminer X9 was withdrawn before launch and never benchmarked, so k about 0.33 is a claimed datasheet bound, not a measurement. This also puts the merged ledger X34 ("RandomX has a shipping chip") in question. Fix owed, held until the coordinator's research agent confirms the withdrawal and the no-benchmark fact: relabel k about 0.33 as a claimed pessimistic bound from a withdrawn design in evidence.md row 17, fud-ledger.md M32 and the ladder branch; reverse X34 if the withdrawal is confirmed; keep 2.1x at k = 1 on the GDDR7 measured anchor as the headline with the k range beside it. Re-gate after the re-cut. Status: FIXED on the docs rows (evidence 17, M32, ladder 5a on branch attack-ladder-5a d3cb17b6; attack-pass rebased on master a3678789 after X36); FIXED-AND-PASSED once the site lane's X34/X36 served rows are confirmed in one voice (no objection received) and the sweep is re-run against the re-cut sentence (the numbers are unchanged, so the re-gate is the identity check and one model.py --section chip run against the new wording). Re-gate done 7 October 2026, 09:5x UK: the 5090 bench row still reads 5.7x / 4.1x / 3.2x / 2.1x / 1.5x (v3; v4 at k = 0.3 / 0.5 / 1 / 1.5), identity grep 0 hits over 290 export files, the site lane confirmed the served text agrees. AP-F5-1: FIXED-AND-PASSED.

AP-F8-1 (hash lane; the generator fix is the Counter ASIC lane's on the v4 seam, routed 7 October 2026, 10:3x UK). The class v4 item read map is not uniform. F8 phase D, one program, 2^26 nonces: the top 0.1 percent of items take 0.520 percent of reads against 0.115 percent for the uniform control (4.05x); the top 1 percent take 2.49 percent (1.37x); one item (0xca5b92) takes 78,479 reads, 153x the mean; read site 15 feeds 6.37 percent of its reads into that 0.1 percent in all 8 iterations; the excess grows with N as a real skew does. Sized: a chip caching the hot 0.1 percent in SRAM serves about 0.5 percent of reads from cache, so the shortcut is under one percent of rate today; an auditor flags a non-uniform read map in a design that claims uniform random reads, and site 15's index derivation is the cause to name. Fix asked: per-site index whitening or a rejected class above a bound. Re-gate: the top 0.1 percent within 1.2x of the control over 2^26 nonces on every one of 64 seeds, with F8's harness against the Counter ASIC lane's branch. Phase E (the 64-program census) decides whether it is one program or the class. Framing from the Counter ASIC lane (the generator's owner, 7 October 2026, 10:5x UK): class v4's item map is not designed to be uniform per program. Layer 8 (spec 01 section 1.13.1) gives each load site k_off = below(3), so a site reads the whole dataset, a half or a quarter under the era's stride and interleave; a quarter-window site concentrates 4x on its quarter by design, which is the 4.05x at the top 0.1 percent, and the windows exist so a chip's SRAM mirror must hold the whole dataset every hour (the Counter ASIC 2.0 windows-union census). The right control is therefore the window model from the program's own 16 draws, reported beside the uniform control (what an auditor sees first); the number that must be explained is the single item 0xca5b92 at 153x the mean (window coincidence under the era mapping with a stated tail, or a low-entropy index source at site 15, which would be a fault). The lane reproduces with F8's harness on branch ca3-v4-uniform, waits for phase E, re-prices the chip consequence (a 0.1 percent hot-set cache, about 1.7 MB of SRAM, serving 0.5 percent of reads: under one percent of rate) and changes the generator only on a fault beyond the model, since v4 is on the live devnet's vote. F8 was re-briefed to carry both controls and the per-site table. Raised to the coordinator: plan 1.4 gate (4) and row F8 say "within 6 sigma of uniform"; if the design is windowed, the gate text must say "uniform within the window model of spec 1.13.1" before the freeze tag, or every reviewer files the windows as a finding on day one. Status: FINDING-OPEN (fault or model tail to be decided by phase E).

Any further finding is logged here and in docs/fud-ledger.md with its owning lane (hash and algorithm: fixed in igneum-pow behind a test and re-gated; node: the node lane, relay agent) before the row is marked FIXED-AND-PASSED.