Keywords: SHA-256; proof of work; Kaspa; kHeavyHash; physical cryptanalysis; optical computing; analog computing; Grover search; Observer Patch Holography; constraint satisfaction

Introduction

SHA-256 is a standard cryptographic hash function specified by NIST in FIPS 180-4 . Bitcoin proof of work applies SHA-256 twice to an 80-byte block header and asks for an output below a target . In the ideal-hash abstraction, each tested header is an independent draw from \(\{0,1\}^{256}\). If the target requires \(k\) leading zero bits, an unbiased miner succeeds with probability \(2^{-k}\) per candidate and needs \(2^k\) trials in expectation.

The ordinary attack surface is simple. A digital miner evaluates the whole compression pipeline for one candidate, then another, then another. Modern ASICs reduce the cost per candidate while preserving the mathematical shape of the search. Published cryptanalytic attacks reach reduced-step variants or related settings. Full SHA-256 preimage search is a practical enumeration problem . Quantum computers change the query count by Grover amplification: quadratically in the number of candidates. Published resource estimates for cryptographic SHA-256 preimage search remain far beyond fault-tolerant hardware .

Observer Patch Holography suggests a different representation of the problem. The blog essay “P = NP on the Observer Screen” phrases the computational primitive in five words: “Verification is the force” . The technical OPH papers develop the same idea through patch algebras, overlap consistency, syndromes, repair moves, and fixed-point consensus . For SHA-256d mining, the primitive becomes an auditable patch network.

The paper has a narrow scope. It gives an exact scorebook for SHA-256d mining, then describes a proposed OMEGA-I1 route that can test whether physical patch federation enriches the candidate stream before exact verification. No SHA-256d break is claimed. The kHeavyHash/Kaspa work is used as a proof-of-work precedent and as a warning about evidence boundaries.

The manuscript belongs to the multi-contributor OPH/Karma/OMEGA research program. The cited OPH papers, public OMEGA guide, acknowledgements, and data-availability statement give the provenance and audit boundary: theory, optical hardware, firmware, exact verification, and simulation are separate parts of the evidence chain.

The key architectural distinction is simple. The four SHA roles are four constraint patches: the factorization and scorebook. OMEGA-I1 is the proposed physical patch federation for running and testing that scorebook. The physical route uses duplicate torus recurrence, search-torus expansion, asymmetric criticism, Echosahedron shadowing, and exact host verification.

Reading the Construction

The construction has to keep three layers separate.

1. The verifier layer is ordinary cryptography. Given a candidate nonce \(x\), compute the real double hash \(H_2(B,x)\) and check whether it lies below the target. This layer is never approximate.

2. The constraint layer rewrites that same verifier as many small claims about wires: this bit is a rotation of that bit, this carry bit is the majority of three inputs, this collar value equals the adjacent collar value. The four SHA roles are the four constraint patches, meaning the factorization and scorebook.

3. The physical layer is proposed to run that scorebook on OMEGA-I1. The five chambers form the enrichment layer for the candidate stream before the exact verifier spends work on it. The verifier decides every cryptographic claim.

Informally, the intended loop is: \[ \begin{aligned} \text{exact verifier} &\Rightarrow \text{local constraints} \Rightarrow \text{patch collars}\\ &\Rightarrow \text{repair syndromes} \Rightarrow \text{candidate beam} \Rightarrow \text{exact verifier}. \end{aligned} \] Hardware measurement can beat enumeration only by changing the verifier-visible distribution. SHA-256d supplies no digital gradient. A physical body can settle many coupled modes at once, while the exact verifier decides which decoded nonces are real. The useful question is whether the full OMEGA-I1 route can emit more distinct valid or near-valid nonces per settling event than random search would produce under the same controls.

SHA-256d as a Search Problem

The SHA-256 compression function

Let a word be an element of \(\{0,1\}^{32}\), equivalently an integer modulo \(2^{32}\). SHA-256 uses the functions \[ \begin{aligned} \operatorname{Ch}(x,y,z)&=(x\wedge y)\oplus(\neg x\wedge z),\\ \operatorname{Maj}(x,y,z)&=(x\wedge y)\oplus(x\wedge z)\oplus(y\wedge z),\\ \Sigma_0(x)&=\operatorname{ROTR}^2(x)\oplus\operatorname{ROTR}^{13}(x)\oplus\operatorname{ROTR}^{22}(x),\\ \Sigma_1(x)&=\operatorname{ROTR}^6(x)\oplus\operatorname{ROTR}^{11}(x)\oplus\operatorname{ROTR}^{25}(x),\\ \sigma_0(x)&=\operatorname{ROTR}^7(x)\oplus\operatorname{ROTR}^{18}(x)\oplus\operatorname{SHR}^3(x),\\ \sigma_1(x)&=\operatorname{ROTR}^{17}(x)\oplus\operatorname{ROTR}^{19}(x)\oplus\operatorname{SHR}^{10}(x). \end{aligned} \] For a 512-bit block \(M\), the first sixteen schedule words are the block words. For \(16\le t<64\), \[ W_t=\sigma_1(W_{t-2})+W_{t-7}+\sigma_0(W_{t-15})+W_{t-16}\pmod {2^{32}}. \] Starting from the chaining value \((H_0,\ldots,H_7)\), the working variables \((a_t,\ldots,h_t)\) evolve by \[ \begin{aligned} T_{1,t}&=h_t+\Sigma_1(e_t)+\operatorname{Ch}(e_t,f_t,g_t)+K_t+W_t\pmod {2^{32}},\\ T_{2,t}&=\Sigma_0(a_t)+\operatorname{Maj}(a_t,b_t,c_t)\pmod {2^{32}},\\ (a_{t+1},b_{t+1},c_{t+1},d_{t+1},e_{t+1},f_{t+1},g_{t+1},h_{t+1}) &=(T_{1,t}+T_{2,t},a_t,b_t,c_t,d_t+T_{1,t},e_t,f_t,g_t). \end{aligned} \] The compressed output is the wordwise sum of the final working state and the input chaining value. SHA-256d is \(H_2(M)=\mathrm{SHA256}(\mathrm{SHA256}(M))\).

A Bitcoin block header is \(80\) bytes, so the first SHA-256 pass spans two \(512\)-bit message blocks before the second SHA-256 pass hashes the \(32\)-byte digest. Real miners usually precompute the midstate after the first \(64\) bytes of a fixed header template. In this paper, a fixed template may therefore mean either the full two-block first pass or the midstate-reduced active circuit. The four-constraint-patch compiler is the same in both cases; the midstate-reduced version lets Patch A start at the nonce-bearing second block and avoids paying physical resources for a fixed compression block.

Mining predicate

Fix a block-header template \(B\), an adjustable nonce or extranonce string \(x\in\{0,1\}^n\), and a target set \(T\subseteq\{0,1\}^{256}\). For a leading-zero target of strength \(k\), \[ T_k=\{y\in\{0,1\}^{256}:y_0=\cdots=y_{k-1}=0\}. \] The proof-of-work predicate is \[ V_{B,T}(x)=1\quad\Longleftrightarrow\quad H_2(B,x)\in T. \] The search problem is to find any \(x\in\{0,1\}^n\) with \(V_{B,T}(x)=1\), if one exists. In the random-oracle model, if \(|T|/2^{256}=p\), then a uniformly sampled \(x\) succeeds with probability \(p\). For \(T_k\), \(p=2^{-k}\).

For a unique marked item in a 32-bit nonce space, the ideal query reduction is from \(2^{32}\) to about \(2^{16}=65{,}536\). For a leading-zero target with success probability \(2^{-k}\), the ideal query reduction is from \(2^k\) to \(2^{k/2}\), up to constants. This sets the quantum baseline for comparison with the optical constraint-search path.

From Gates to Exact Constraints

Boolean gate penalties

Every Boolean circuit can be written as a finite system of local constraints. For a gate \(y=g(x_1,\ldots,x_m)\), define its truth-table penalty \[ E_g(x_1,\ldots,x_m,y)= \begin{cases} 0,&y=g(x_1,\ldots,x_m),\\ 1,&\text{otherwise}. \end{cases} \] The circuit energy is the sum of all gate penalties: \[ E_C(z)=\sum_{g\in C}E_g(z|_{\operatorname{vars}(g)}). \] Then \(E_C(z)=0\) if and only if every gate relation is satisfied.

In plain terms, \(E_g\) is a local consistency test for one gate. It returns \(0\) when the input and output wires fit, and \(1\) otherwise. The full energy \(E_C\) is just the count of local gate mismatches across the circuit. SHA-256 stays hard as a digital search problem; the hardware receives a finite set of local inconsistencies that can be exposed, routed, and repaired without changing the exact verifier.

If a hardware platform requires quadratic unconstrained binary optimization (QUBO) or an Ising Hamiltonian, the bounded-locality penalties can be quadratized by adding ancillas. That route is standard in Ising formulations of NP problems . The quadratized Hamiltonian has polynomially many variables and terms in the circuit size.

SHA-256d constraint Hamiltonian

Let \(C_{\mathrm{SHA256d},B,T}\) be the Boolean circuit that takes \(x\), computes \(\mathrm{SHA256d}(B,x)\), and checks membership in \(T\). Applying Lemma 2 gives an energy \[ E_{\mathrm{SHA256d},B,T}(x,a)=0 \quad\Longleftrightarrow\quad V_{B,T}(x)=1 \] where \(a\) includes all schedule words, carry bits, round-state words, and comparison bits.

The theorem says that a valid nonce and a zero-energy assignment are the same object viewed at two resolutions. The nonce \(x\) is the visible witness. The ancillas \(a\) are all internal SHA facts that make that witness true: schedule words, carries, round registers, feed-forward words, and comparison bits. A low energy alone is a scorebook record. A cryptographic claim starts only when the visible nonce passes \(V_{B,T}\) under an independent implementation.

The Four Constraint Patches

The compiler turns SHA-256d into four constraint patches. Each patch is an observer in the OPH sense: it sees a local set of variables, checks local relations, and reports only the shared variables on its collars. The nonce-bearing message tail is the only freely varied source. The schedule recurrence is the first place where that source spreads across 64 words. The compression rounds are the main avalanche body. The final feed-forward, second pass, and target predicate are the target face. These four jobs have different constraint roles, so they stay separate in the compiler: \[ \text{source}\quad\longrightarrow\quad \text{schedule closure}\quad\longrightarrow\quad \text{compression trajectory}\quad\longrightarrow\quad \text{target face}. \]

The four-constraint-patch split minimizes useful logical boundary traffic. The \(A/B\) collar carries the claimed first schedule words. The \(B/C\) collar carries the schedule and round-entry consequences. The \(C/D\) collar carries the digest-side interface and target bits. Putting two adjacent jobs in one logical patch removes an early failure surface. Splitting one job into smaller logical patches adds another equality collar without creating a new algorithmic interface. This is the constraint factorization and scorebook. Physical module count is a separate OMEGA-I1 deployment choice: five host-routed chambers for the four constraint patches.

For SHA-256d, the solver is solving these exact constraints:

• Template and nonce constraints: fixed header or midstate words, padding, length fields, nonce grammar, extranonce grammar when present, and the active \(512\)-bit block words \(W_0,\ldots,W_{15}\).

• Schedule constraints: for \(t=16,\ldots,63\), the recurrence \[ W_t=\sigma_1(W_{t-2})+W_{t-7}+\sigma_0(W_{t-15})+W_{t-16}\pmod {2^{32}}, \] with carry witnesses for each word addition.

• Compression constraints: the 64 round equations for \(T_1\), \(T_2\), \(\operatorname{Ch}\), \(\operatorname{Maj}\), rotations, modular additions, working-register updates, and feed-forward words.

• Second-pass and target constraints: the second SHA-256 compression of the first digest, the final 256-bit digest, and the comparator that checks membership in \(T\), or in \(T_k\) for a leading-zero experiment.

• Collar constraints: every variable claimed by two neighboring patches has one bit value. A schedule word, carry bit, round register, or target bit cannot take different values on the two sides of a collar.

The observers agree on a solution by literal boundary equality. Patch \(A\) proposes source words. Patch \(B\) accepts them only if its schedule closure can reuse the same \(A/B\) collar bits. Patch \(C\) accepts the schedule only if its round trajectory reuses the same \(B/C\) collar bits. Patch \(D\) accepts the trajectory only if the digest and target-face collar bits fit its own local checks. When all local energies are zero and all collar values are equal, the four local stories glue into one global SHA-256d witness. The exact verifier then checks the visible nonce.

Here \(V\) is the complete list of SHA variables in the constraint body. \(V_A,\ldots,V_D\) are the subsets each role is allowed to talk about. \(\Gamma_{ij}\) is the overlap, or collar, between two roles. If Patch B says a schedule word has one value and Patch C says the same word has another value, the mismatch lives on \(\Gamma_{BC}\). The repair loop can see that failure from shared boundary data.

For SHA-256d, the intended variable ownership is: \[ \begin{array}{lll} A&:&\text{nonce-bearing active block words, padding, length, }W_0,\ldots,W_{15},\\ B&:&\text{schedule recurrences }W_{16},\ldots,W_{63}\text{ and carry wires},\\ C&:&\text{active compression trajectories and working register wires},\\ D&:&\text{feed-forward interfaces, second pass, and target predicate.} \end{array} \]

This theorem is the formal content behind the phrase that bad candidates die at collars. A collar mismatch certifies that a local assignment cannot glue to a global satisfying assignment.

This is also why the OMEGA-I1 route can use different geometries without losing the SHA proof. The physical chambers may have different bodies; they emit decoded claims about the same variables and collars. If those decoded claims agree and have zero local penalty, the equalizer theorem supplies the global SHA witness. If they disagree, the disagreement is a syndrome for the next repair pass.

OMEGA-I1 physical deployment

The optimized hardware target is OMEGA-I1: a five-module federation rather than a one-to-one four-chamber implementation of \(A,B,C,D\). The four-constraint-patch compiler produces a scorebook, candidate grammar, collar residuals, and exact-verifier interface. The OMEGA-I1 runtime executes that program on five host-routed modules with the same architecture used by the simulator and the contractor build package described in this paper. The public OMEGA educational guide gives a broader visual introduction to chamber families, collars, and candidate-set narrowing .

The default optimized route is: \[ \texttt{TOR-A/TOR-B} \longrightarrow \texttt{TOR-C} \longrightarrow \texttt{MIX-A} \longrightarrow \texttt{ECH-A} \longrightarrow \text{exact SHA-256d verifier}. \] All arrows in this route are host messages. OMEGA-I1 has no direct module-to-module optical path, timing wire, or shared chamber power rail in the contractor acceptance build. That constraint is useful: every boundary update is recorded as a replayable scorebook transition with module IDs, firmware hashes, coupling-matrix hashes, operator-probe hashes, input and output beam hashes, and the host verifier receipt.

This five-module route is also the optimization surface. TOR-A and TOR-B earn trust through statistical agreement. TOR-C increases local candidate density around low-residual prefixes. MIX-A rejects digest-window false positives under same-energy controls. ECH-A preserves useful candidates under a different geometry before the exact verifier spends hashes. A claimed lift that appears only after host ranking, only in one torus duplicate, or only after exact-verifier selection is outside the OMEGA-I1 hardware claim.

How the federation searches many candidates in one settling event

OMEGA-I1 uses a host-routed consensus search over optical candidate beams across five chambers. A candidate beam is a recorded packet \[ \mathcal B_t=\{(x,\rho,\phi,\sigma,\pi)\}, \] where \(x\) is a candidate nonce or nonce-neighborhood descriptor, \(\rho\) is a rank score, \(\phi\) is the decoded patch/collar residual, \(\sigma\) is the module-local readout signature, and \(\pi\) is provenance: route ID, module ID, drive program, decoder, firmware hash, and run time. The optical chamber is responsible for changing the distribution of \(\mathcal B_t\). The host is responsible for recording the transition and exact-checking any decoded nonce.

The phrase “many candidates at the same time” means that one drive/settle/read cycle populates many optical paths, scattering histories, port-coupling modes, and decoder branches before a digital verifier is called. The paper counts no photon, analog microstate, or possible real-valued readout as a verified hash unless the audited decoder emits a distinct verifier-ready candidate. The packet size in the speedup formula, \(m_{\mathrm{pkt}}\), is the number of distinct verifier-ready candidates emitted by the audited decoder after deduplication. A larger effective mode envelope \(N_{\mathrm{eff}}\) is useful only if it produces a larger audited \(m_{\mathrm{pkt}}\), a larger verified bias \(\beta(k)\), or both.

Each stage has a different geometry because different failure modes need different witnesses:

The host repair loop is explicit:

1. Compile the block template or midstate into a scorebook containing the four-constraint-patch variables, collar masks, local penalties, route thresholds, and decoder rules.

2. Drive TOR-A and TOR-B with matched or blinded scorebooks. Decode \(\mathcal B_A\) and \(\mathcal B_B\). Keep only candidates or neighborhoods whose collars agree above the duplicate-consensus threshold.

3. Treat duplicate disagreement as a syndrome. Increase weights on the failed collars, lower trust in module-local artifacts, and rerun or route survivors to TOR-C.

4. Let TOR-C perform search-neighborhood expansion around the survivors. Accept the expansion only if the hard residual \(\Phi\) decreases or if exact low-difficulty controls show a reproducible \(\beta(k)\) lift.

5. Route the expanded beam through MIX-A. The mixer may kill candidates cheaply; inventing a hit is outside its role. Its output must improve the exact-verifier hit rate at fixed pass rate under same-energy and shuffled-label controls.

6. Route the critic survivors through ECH-A. The Echosahedron is the reference shadow: a torus or mixer artifact tends to fail here. A candidate that survives different geometry has a stronger consensus record.

7. Exact-check every serious decoded nonce with host SHA-256d. The exact digest, leading-zero count, route transcript, and all control hashes go into the run bundle.

Consensus means intersection under repair. A candidate is better when independent geometries keep sending compatible collar messages about it while \(\Phi\) decreases. Repair means changing the next drive/scorebook from the input syndrome. A good repair move can work without knowing the valid nonce in advance; it only needs to make the next packet less inconsistent on the SHA-256d collars and more enriched under the exact verifier.

Observer-Screen Repair Dynamics

OPH adds dynamics to the static equalizer. Patches carry private states, collars expose shared observables, mismatch syndromes report disagreement, and repair moves change local data to reduce the mismatch. The consensus paper develops this as a finite repair system with a Lyapunov function . Here is the SHA-256d version.

Let \(G=(\{A,B,C,D\},E)\) be the patch graph and let \[ \Phi(s_A,s_B,s_C,s_D) \mathrel{=} \sum_{(i,j)\in E} w_{ij}\, d_{ij}\!\left(s_i|_{\Gamma_{ij}},s_j|_{\Gamma_{ij}}\right) \;+\; \sum_i \lambda_i E_i(s_i), \] where \(w_{ij},\lambda_i>0\) and \(d_{ij}\) is Hamming distance on the collar. The first term punishes collar disagreement. The second term punishes local gate violations.

In the OMEGA-I1 implementation, \(s_A,\ldots,s_D\) are not hidden claims about the full analog state of a chamber. They are the hard-decoded route states printed by the host after each module pass. The run bundle therefore contains both layers: raw optical traces and the decoded \((s_A,s_B,s_C,s_D,\Phi)\) record. The raw traces support operator-alignment and artifact audits. The decoded record supports the SHA-256d equalizer and repair accounting.

The completeness assumption is the difficulty. Nonconvex constraint systems can have traps. A successful physical solver either avoids those traps, escapes them, or provides a measurable success probability large enough to beat enumeration after exact verification.

The Role of the OPH Pixel Constant \(P\)

The OPH papers use a dimensionless local pixel ratio \[ P=\frac{a_{\mathrm{cell}}}{\ell_P^2}, \] where \(a_{\mathrm{cell}}\) is the microscopic screen-cell area and \(\ell_P\) is the Planck length . In the public OPH release, \(P\) is selected by the fixed-point equation \[ P=\varphi+\sqrt{\pi}\,\alpha_{\mathrm{em}}(0;P) =\varphi+\frac{\sqrt{\pi}}{A_T(P)}, \qquad \varphi=\frac{1+\sqrt5}{2}, \] with reported solution \[ P_\ast=1.630968209403959324879279847782648941\ldots. \]

For the SHA-256d hardware instantiation, \(P\) is a dimensionless OPH design target for geometry and coupling. It leaves the SHA-256 equations unchanged. A \(P\)-calibrated wave body is one whose normalized collar couplings, path-length ratios, and extraction windows are tuned to the OPH fixed-point scale. In a toroidal or microwave implementation, this means that the dimensionless ratios \[ \frac{R}{a},\qquad \frac{a}{b},\qquad \frac{L_j}{\lambda},\qquad \frac{\kappa_{ij}}{\kappa_0} \] are selected from a small \(P_\ast\)-centered design family. In a photonic mesh, it means that phase shifters, couplers, and nonlinear thresholds are tuned so the realized coupling matrix \(\widehat K(P_\ast)\) approximates the intended constraint matrix \(K_C\): \[ \|\widehat K(P_\ast)-K_C\|\le \varepsilon_{\mathrm{geom}}. \]

Wave and Hardware Encodings

Signed wave bits

Use the signed encoding \[ b\in\{0,1\},\qquad \tilde b=(-1)^b\in\{-1,+1\}. \] Then \[ \widetilde{\neg b}=-\tilde b,\qquad \widetilde{b\oplus c}=\tilde b\,\tilde c. \] The AND gate has signed output \[ \widetilde{b\wedge c} =\frac{1+\tilde b+\tilde c-\tilde b\tilde c}{2}. \] Equivalently, it is the threshold function \[ \widetilde{b\wedge c} =\operatorname{sgn}(\tilde b+\tilde c+1), \] with the convention \(\operatorname{sgn}(u)=+1\) for \(u>0\) and \(-1\) for \(u<0\). The carry bit of a full adder is a majority gate, also a threshold: \[ \widetilde{\operatorname{carry}(b,c,d)} =\operatorname{sgn}(\tilde b+\tilde c+\tilde d). \] Thus rotations and permutations are geometry, XOR is phase-sensitive mixing, and carries require a nonlinear threshold or an equivalent measurement-feedback resource.

KLM-style linear optical quantum computation uses single photons, detection, ancillas, feedback, and effective measurement-induced nonlinearity . Classical optical Ising machines use nonlinear oscillators or measurement feedback for the same reason .

Classical OMEGA-I1 wave variant

The OMEGA-I1 classical variant is LED-first and contractor-buildable. Each module is an enclosed 12-port optical body with co-located red LED source and BPW34-class detector channels, an RP2350-class USB controller, bounded LED current, and exact host-side records. Laser, OPO, strict same-electrode transmit/receive, and HAPTIC-style upgrades are separate hardware targets. They are outside the baseline used for the SHA-256d architecture in this paper and outside the OMEGA-I1 acceptance build.

The physical computation is therefore a host-routed candidate-enrichment loop. The chamber modules expose coupling maps, edge responses, settle traces, operator probes, and candidate beams. The host applies the four-constraint-patch scorebook, routes beams between modules, and exact-checks serious candidates.

The solver contract for fixed OMEGA shapes

A solver in this paper is a physical sampler with a strict contract. The input is a scorebook: variables, local penalties, collar masks, drive weights, decoder rules, repair thresholds, and an exact verifier. The output is a candidate beam: decoded nonce assignments or nonce-neighborhood assignments with residuals, provenance, and control receipts. The chamber earns the word solver only when the decoded beam is enriched under the exact verifier at fixed controls. There is no infinite-improbability drive hidden in the word solver: lift means verifier-visible enrichment under audited controls.

This is how OMEGA-I1 can be general compute despite fixed chamber shapes. The printed body supplies a reusable coupling basis. The program is the port drive, label map, scorebook, decoder, route order, feedback rule, and host-side repair logic. A torus chamber can therefore run a SHA-256d scorebook, a kHeavyHash scorebook, or a small SAT scorebook by changing the imposed variables and collar tests while keeping the same measured port body. The body is the analog substrate; the scorebook is the program.

For SHA-256d, the LED OMEGA-I1 build is a photonic constraint solver. Light transport explores many coupled path modes in one settle/read event, nonlinear ports and feedback supply the carry and target commitments, and the host keeps only decoded candidates whose collars and exact hashes improve the audited distribution. In a single-photon Omega version, the same scorebook becomes a quantum solver: occupation states encode candidate assignments, interferometric paths carry amplitude and phase, and detection plus feed-forward supplies the nonlinear commitments. Quantum status comes from coherent occupation-state dynamics and coherence receipts; Grover-style claims require a separate reversible-oracle and diffusion audit.

An idealized diode-threshold model is: \[ u_{\mathrm{out}}=\operatorname{sgn}\!\left(\sum_j \eta_j u_j-\theta\right), \] where the sign is physically approximated by a biased nonlinear I-V curve or a lasing threshold. A real device has finite slope, jitter, shot noise, thermal noise, and drift. Let the implemented threshold be \(D_{\theta,\delta}\), where \(\delta\) bounds the uncertain switching band. Exact Boolean operation is certified only when every legal input has margin \(>\delta\).

OMEGA-I1 boundary and operator alignment

The Omega hardware program requires more evidence than a verified hash for the physical claim. An exact verifier proves that a candidate nonce works. Chamber alignment with the SHA-256d operator requires separate controls against parser bias, host loops, and accidental transport channels.

Let \(L_T\) be the finite task operator for the target predicate, let \(K_{\mathrm{model}}\) be the modeled chamber operator in a declared basis, and let \(K_{\mathrm{phys}}\) be the measured physical port operator in the same normalization. The Omega commutator gate asks whether the chamber approximately preserves the task structure: \[ \lVert [K_{\mathrm{model}},L_T]\rVert\le \epsilon . \] Physical realization then has its own error budget.

This proposition is a design gate. A solved-SHA claim requires the following printed evidence: the basis, normalization, task operator, modeled operator, measured port operator, operator-probe data, settle traces, edge responses, and exact-verifier receipts for the same run bundle.

Sampler-class SHA-256d operating program

The SHA-256d hardware plan is sampler-class. It aims to enrich the candidate stream before exact verification. Grover-class quadratic amplification and universal-NP oracle claims require separate evidence. The operating program has four roles:

1. broad mode population, so the body explores many nonce-conditioned modes;

2. in-substrate mode-leak selection, where threshold and hysteresis supply the load-bearing nonlinear commitment for AND, \(\operatorname{Maj}\), carry, and target faces;

3. closed-loop transmit/receive feedback, where collar syndromes change the next physical drive rather than merely logging telemetry;

4. MCU warm-loop transport, which raises packet rate and lowers USB or host latency without taking over the search.

The distinction matters. Firmware transport may increase \(m_{\mathrm{pkt}}\) by moving candidates faster. Physical bias \(\beta\) rises only when the chamber changes the distribution of exact-verifier outcomes. If the MCU performs the search that the chamber was supposed to perform, the optical claim has evaporated. The finite gate stack is therefore \[ \begin{aligned} &\texttt{EDGE\_BRACKETED}\to \texttt{EDGE\_POLARITY\_LOCKED}\\ &\to \texttt{NONLINEAR\_COMMITMENT\_ALIVE}\to \texttt{TRUTH\_LIFT}\\ &\to \texttt{POOL\_SHARE\_LIFT}\to \texttt{BLOCK}. \end{aligned} \] OMEGA-I1 assigns TOR-A and TOR-B to duplicate recurrent streams, TOR-C to search-specialist expansion, MIX-A to bit-slice criticism, and ECH-A to reference shadowing. The digital simulator uses the same full-five route and its single, pair, subset, and shuffled controls as a guardrail before hardware escalation.

Single-photon quantum variant

The quantum build uses single-photon occupation states in a linear-optical processor. A logical bit can be encoded in dual rail, time bins, or paths: \[ |0_L\rangle=|1\rangle_0|0\rangle_1,\qquad |1_L\rangle=|0\rangle_0|1\rangle_1. \] Beam splitters, phase shifters, delay lines, switches, detectors, ancilla photons, and feed-forward implement the gate set. KLM shows that this resource set can be universal for quantum computation in principle . In the OPH reading, the same chamber geometry carries the mode graph, while the single-photon occupation basis supplies quantum amplitude, phase, and measurement.

The candidate register is prepared as \[ |s\rangle=\frac{1}{\sqrt N}\sum_{x\in\{0,1\}^n}|x\rangle. \] The reversible SHA-256d oracle computes the mining predicate into a work qubit and then uncomputes its scratch space: \[ U_V|x\rangle|q\rangle|0^r\rangle =|x\rangle|q\oplus V(x)\rangle|0^r\rangle. \] With a phase kickback qubit, this becomes the phase oracle \[ O_V|x\rangle=(-1)^{V(x)}|x\rangle. \] One Grover step is \[ G=(2|s\rangle\langle s|-I)\,O_V. \] The photonic device must implement:

• heralded single-photon state preparation for the candidate, ancilla, and phase-kickback registers;

• a reversible SHA-256d circuit compiled into interferometers, switches, measurement-induced nonlinear gates, and feed-forward;

• a diffusion/reflection network implementing \(2|s\rangle\langle s|-I\);

• coherent repetition of the oracle and diffusion layers for \(\Theta(\sqrt{N/M})\) Grover steps;

• final number-resolving or threshold detection followed by exact classical verification of the measured candidate.

For a leading-zero target with success probability \(p=2^{-k}\), the ideal Grover iteration count is \[ Q_{\mathrm{G}}(k)\approx \frac{\pi}{4}2^{k/2}, \] with query speedup \[ S_{\mathrm{G}}(k)\approx \frac{2^k}{Q_{\mathrm{G}}(k)} =\frac{4}{\pi}2^{k/2}. \] The gain is quadratic in query count. The wave-overlap zero-energy endpoint has a different scaling: a physical fixed point can represent a valid nonce in one settling event. Resource estimates for generic SHA-256 preimage search remain enormous. Amy et al. estimate a SHA-256 preimage attack requiring approximately \(2^{153.8}\) surface-code cycles and \(2^{12.6}\) logical qubits, or \(2^{166.4}\) logical-qubit-cycles . The Omega/Karma hardware described here sits outside this Grover resource set. The Grover rows in this paper are comparison baselines unless a separate audit prints a reversible oracle, diffusion operator, maintained coherence, and quadratic scaling receipts.

Keccak and SHA-3 Variant

SHA-256 and Keccak/SHA-3 are different hash families. SHA-3 is standardized in FIPS 202 and is based on the Keccak permutation . The same physical design vocabulary can describe Keccak. The gate map differs.

Routing, rotations, and XOR-like phase relations are natural for waves. Nonlinear Boolean steps require a nonlinear physical process or measurement feedback. A Keccak implementation has to specify the \(\chi\) layer with the same care that a SHA-256 implementation specifies carries.

Kaspa is useful here for a mechanical reason: its proof-of-work kernel is close to the physics. kHeavyHash has the form \[ \operatorname{kHH} \mathrel{=} \operatorname{SHA3}(\mathrm{prepow},t,n) \longrightarrow M_{64\times64}\text{ nibble multiply} \longrightarrow \operatorname{SHA3}(\cdot), \] Its most chamber-friendly portion is a matrix operator bracketed by Keccak permutations. Linear mixing, routing, and phase transport map naturally to a wave body, while the \(\chi\) layer localizes the nonlinear part that the ports must supply. The 2026-05-05 firmware handoff records a bit-exact chamber-plus-MCU decomposition: full kHeavyHash matched the digital reference on \(30/30\) tests, the SHA3 chamber-plus-MCU path matched Python hashlib, and the local-quadratic \(\chi\) form matched textbook \(\chi\). SHA-256d has a different nonlinear core: word additions, carries, \(\operatorname{Ch}\), and \(\operatorname{Maj}\). The four-constraint-patch map above is the corresponding SHA-256d compiler target.

Optical Proof-of-Work Prototype

The OPH/Karma optical proof-of-work prototype uses the same low-cost optical-supercomputer surface as the OMEGA-I1 line: a clear wave body, RP2350 or RP2040 control, reversible optical ports, firmware bring-up, and verification steps . It was not an OMEGA-I1 run. It is used here as precursor evidence for optical candidate enrichment, not as a measurement of the five-chamber SHA-256d route.

The OPH/Karma prototype has mined Kaspa kHeavyHash pool shares on the optical candidate path. The optical chamber proposes candidates; host-side kHeavyHash verification checks them before pool submission. An internal mining status log records a Cedric Kaspa pool run in which optical candidates received pool acknowledgements. The run log records:

• \(1649\) submitted optical candidates;

• \(8\) accepted optical share responses;

• \(99\) submitted optical candidates without a returned pool response;

• best host-recomputed leading-zero quality near \(21\);

• best reported share difficulty near \(2.93\times 10^6\).

Separately, a May 6, 2026 shuffle-replay audit of the CASCADE/chord-promote output recorded \[ \widehat\beta(k)= \{14.75\text{ at }k=4,\;229\text{ at }k=8,\;886\text{ at }k=10,\; 2{,}434\text{ at }k=12\}, \] with mean leading-zero count \(11.83\) for the chamber-selected stream versus \(0.92\) for random replay. In this notation, \(\widehat\beta(k)\) is the observed exact-verifier success rate for the event \(\mathrm{lz}\ge k\), divided by the uniform-random rate \(2^{-k}\). The exact headline number used in this comparison lane is therefore \(\widehat\beta(12)=2{,}434\), meaning that \(\mathrm{lz}\ge12\) candidates appeared \(2{,}434\) times the uniform-random baseline in that selected stream. The boundary is important: this is a controlled candidate-enrichment result on the chord-promote output, not a final pool-rate or block-win result, and not evidence that the same slope continues to network difficulty.

The same log also records the boundary conditions. A CPU pool baseline established the pool contract. During the optical acceptance run, CPU workers also contributed to wallet-level flow. A solo audit on May 2, 2026 recorded stable operation, host verification, and share logging. It also recorded host-verified leading-zero counts near random expectation and weak correlation between board-local leading-zero reports and host recomputation.

The prototype closes a proof-of-work loop: optical candidate generation, exact hash verification, and pool submission. Its boundary conditions are part of the claim. The accepted-share log supports a real external-verifier path for kHeavyHash/Kaspa, while the solo audit keeps the stronger enrichment claim open. The SHA-256d construction sets the Bitcoin operator map for the same physical search cascade. SHA-256d claims pass only through the operator-alignment and per-distinct-enrichment gates above.

Speedup Accounting

Let \(R_{\mathrm{hash}}\) be a classical exact-verifier rate in hashes per second, \(p=|T|/2^{256}\) the target fraction, and \(q\) the probability that a physical candidate is valid after exact verification. An unbiased random candidate stream has \(q=p\). A physical sampler has bias factor \[ \beta=\frac{q}{p}. \] If each physical settling event costs time \(T_{\mathrm{settle}}\) and produces \(m_{\mathrm{pkt}}\) independently verified candidates, the expected physical time per valid nonce is \[ \mathbb E[T_{\mathrm{phys}}] =\frac{T_{\mathrm{settle}}}{1-(1-q)^{m_{\mathrm{pkt}}}} \approx\frac{T_{\mathrm{settle}}}{m_{\mathrm{pkt}}\beta p}. \] The approximation is the cryptographic-target regime \(q\ll1\). A classical miner using exact hashes has \[ \mathbb E[T_{\mathrm{class}}]=\frac{1}{R_{\mathrm{hash}}p}. \] Thus the operational speedup is \[ S=\frac{\mathbb E[T_{\mathrm{class}}]}{\mathbb E[T_{\mathrm{phys}}]} \approx\frac{m_{\mathrm{pkt}}\beta}{R_{\mathrm{hash}}T_{\mathrm{settle}}}. \] The speedup has four measurable inputs: verifier rate, physical settling time, packet size, and candidate bias. For OMEGA-I1, \(m_{\mathrm{pkt}}\) counts distinct candidates that exit the full selected route. Raw LED emission counts from a single module are excluded. A high bias loses value if settling is slow. The Kaspa comparison lane supplies one historical candidate-bias datum, \(\widehat\beta(12)=2{,}434\), measured on chord-promote output after shuffle-replay. Equivalently, for the \(k=12\) exact-verifier predicate, the selected stream’s estimated success probability was \(2{,}434\times2^{-12}\) instead of \(2^{-12}\). It does not by itself determine SHA-256d speedup, because the operator, route, packet size, settle time, and high-\(k\) scaling must be remeasured under the SHA-256d scorebook. Against a classical verifier running at \(R_{\mathrm{hash}}\), the sampler wins only when \[ m_{\mathrm{pkt}}\beta>R_{\mathrm{hash}}T_{\mathrm{settle}}. \] At \(R_{\mathrm{hash}}=4.73\times10^{14}\,\mathrm{H/s}\) and \(T_{\mathrm{settle}}=100\,\mathrm{ns}\), that threshold is \(4.73\times10^7\). This is the practical optimization target: increase packet size, increase verified bias, or reduce settle time. In OMEGA-I1, this product must be measured at the full route output, not inferred from a single chamber’s raw optical mode count. The exact verifier stays in the loop.

For a leading-zero target \(p=2^{-k}\), the exact wave-overlap endpoint has \[ T_{\mathrm{zero}}(k)\approx T_{\mathrm{settle}},\qquad S_{\mathrm{zero}}(k;R_{\mathrm{hash}},T_{\mathrm{settle}}) =\frac{2^k}{R_{\mathrm{hash}}T_{\mathrm{settle}}}. \] The single-photon Grover variant has \[ Q_{\mathrm{G}}(k)\approx\frac{\pi}{4}2^{k/2},\qquad S_{\mathrm{G}}(k)\approx\frac{4}{\pi}2^{k/2}. \] The wave-overlap sampler sits between these two limits. Its measured speed is set by \(m_{\mathrm{pkt}}\beta\), the number of independently checked candidates per settling event times the verified enrichment over random search. Firmware that only improves transport raises \(m_{\mathrm{pkt}}\); only a changed exact-verifier distribution raises \(\beta\).

For a concrete wall-clock baseline, take Bitmain’s ANTMINER S21 XP Hyd specification: SHA-256 mining at \(473\,\mathrm{TH/s}\), \(5676\,\mathrm{W}\), and \(12.0\,\mathrm{J/TH}\) . Thus \[ R_{\mathrm{ASIC}}=4.73\times10^{14}\ \mathrm{H/s}. \] An aggressive hydro reference is Auradine’s AH3880 at up to \(600\,\mathrm{TH/s}\) . Using \(600\,\mathrm{TH/s}\) instead of \(473\,\mathrm{TH/s}\) multiplies the S21-based wall-clock multipliers below by \(473/600\simeq0.79\). For a \(k\)-bit leading-zero target, \[ T_{\mathrm{ASIC}}(k)=\frac{2^k}{R_{\mathrm{ASIC}}}. \] For a physical method with time \(T_{\mathrm{phys}}\), the ASIC-relative multiplier is \(T_{\mathrm{ASIC}}(k)/T_{\mathrm{phys}}\). The following table is a sensitivity calculation for proposed regimes, with no SHA-256d bench measurement attached.

Query reduction and wall-clock multiplier are separated because the ASIC baseline evaluates \(4.73\times10^5\) hashes during a \(1\,\mathrm{ns}\) optical cycle. The familiar \(65{,}536\times\) Grover number is the square-root reduction for a 32-bit nonce space. At \(k=64\), the same \(1\,\mathrm{ns}\) single-photon cycle gives a \(1.2\times10^4\times\) wall-clock multiplier against the S21 XP Hyd baseline. In the exact wave-overlap endpoint, one settling event supplies the candidate that ordinary enumeration would expect after \(2^k\) trials.

The OPH blog essay uses the observer-screen slogan for this statement .

The OMEGA-I1 claim boundary in this paper deliberately stops short of this theorem’s premise. OMEGA-I1 can support sampler-class candidate enrichment, operator-probe evidence, and exact-verifier receipts. By itself, OMEGA-I1 leaves the uniform polynomial-time solver premise for arbitrary NP circuits unestablished.

Physical complexity questions of this kind have a classical literature in analog computation and physical NP-complete proposals .

Public Evidence Protocol

The Kaspa evidence records the physical path at accepted-share level. A public SHA-256d cryptography submission needs the same class of evidence in a form external readers can replay. The minimum protocol is:

1. Pre-register the block-header templates, target strengths \(k\), run durations, stopping rules, and acceptance predicates.

2. Print the run tuple: route ID, ordered stage modules, board identifiers, chamber identifiers, firmware hashes, compiler hash, scorebook hashes, wire format, drive regime, receive regime, scorer, verifier, and duration.

3. Store raw timing traces, raw port readings, raw candidate nonces, and the hard-decoded patch/collar residual \(\Phi\) before exact verification.

4. Verify every distinct candidate with an independent SHA-256d implementation for the Bitcoin target, or with independent kHeavyHash for the Kaspa comparison lane. Report the exact digest and leading-zero count for every hit.

5. Report the number of distinct candidates \(N_{\mathrm{dist}}\), duplicate rate, number of successes \(S\), expected random baseline \(N_{\mathrm{dist}}p\), and the bias estimator \[ \widehat\beta(k)=\frac{S}{N_{\mathrm{dist}}p}. \]

6. Compute a binomial tail probability \[ p_{\mathrm{val}}=\Pr\left[\operatorname{Binomial}(N_{\mathrm{dist}},p)\ge S\right] \] for enrichment claims. A promoted enrichment claim also reports a binomial or beta-binomial lower confidence bound \(\underline p_Q(\alpha)\) and requires \(\underline p_Q(\alpha)>p\) at the stated confidence level. Plot \(\widehat\beta(k)\) across a high-\(k\) shoulder rather than only at easy targets.

7. Run controls in named modes: single module, pair, subset, full five, shuffled labels, shuffle replay, ABBA, same energy, header perturbation, receive cadence, disconnected cavity, dark path, fixed phase, CPU-random, and stale job.

8. Report the finite hardware gates as separate fields:

   EDGE_BRACKETED
EDGE_POLARITY_LOCKED
NONLINEAR_COMMITMENT_ALIVE
TRUTH_LIFT
POOL_SHARE_LIFT
BLOCK

9. Release code, seeds, firmware, board files, calibration logs, and raw data.

For a reported enrichment such as \(\widehat\beta=2{,}434\) at \(k=12\), meaning an observed \(\mathrm{lz}\ge12\) exact-verifier hit rate \(2{,}434\) times the uniform-random baseline, the report prints the run identifier, distinct candidate count, exact-verifier implementation, control runs, confidence interval, and binomial tail. Before a mining claim, the chamber-health printout also includes emit rate, saturation or clipped-port counts, effective receive diversity, duplicate rate, receiver liveness, and pre-arm channel correlation. Cryptographic readers need enough detail to separate optical enrichment from post-selection, parser bias, timestamp leakage, nonce-format bugs, stale jobs, readout back-action, and verifier coupling.

Discussion

A hidden gradient is unnecessary for this attack. SHA-256d proof of work has an exact constraint-system representation, and a constraint system can be attacked by physical dynamics with a different cost structure from serial enumeration. The four-constraint-patch compiler makes the local interfaces explicit. Patch A varies the nonce. Patch B carries the schedule consequences. Patch C carries the compression trajectory. Patch D enforces the target face. OMEGA-I1 runs that compiler as a five-module federation.

The hardware transfer runs from kHeavyHash to SHA-256d through the full-five route \[ \texttt{TOR-A/B}\to\texttt{TOR-C}\to\texttt{MIX-A}\to\texttt{ECH-A}. \] Waves supply parallel propagation, interference, routing, and delay. SHA-256 also needs nonlinear carries, thresholding, memory, and exact verification. The OPH pixel constant \(P\) guides the geometry. The LED/detector modules provide measurable candidate beams and operator evidence. Diode, HAPTIC, laser, or photonic-feedback layers are stronger versions of the nonlinear boundary law. The Kaspa prototype shows this division of labor reaching real pool acceptance for kHeavyHash. The SHA-256d construction fixes the operator-specific geometry and scaling law. Its claim status is gated by operator alignment, nonlinear commitment, and per-distinct high-\(k\) enrichment.

The final verifier is decisive. OMEGA-I1 proposes, filters, and shadows candidate beams before the host spends exact hashes. The accepted Kaspa shares matter because an external pool verified the result. The same standard applies to SHA-256d. Every claimed survivor must pass the real double hash. For optimization, the most important levers are larger independently checked packets, shorter settle time, stronger measured bias, cleaner duplicate-torus agreement, and a cleaner separation between physical selection and host transport.

Conclusion

There is no magic nonce hiding in the header. SHA-256d mining is an exact finite constraint problem. The four-constraint-patch OPH decomposition is an exact equalizer of local solution sets. Optical Kaspa hardware has produced real pool-acknowledged kHeavyHash shares, and the kHeavyHash/Keccak chamber decomposition checks against digital references. Those facts justify a SHA-256d physical-search program. They are insufficient for a SHA-256d break. SHA-256d requires nonlinear carry, so the physical route must expose threshold, feedback, measurement, or equivalent nonlinear boundary dynamics. OMEGA-I1 is the runtime used in this paper because it makes the search, duplicate, critic, shadow, and verifier roles explicit and replayable.

The SHA-256d attack has five moving parts: the Patch A through Patch D operator compiler, the OMEGA-I1 candidate route, independent double-SHA-256 verification, operator-alignment evidence, and full route controls. The Kaspa result is the proof-of-work precedent. The optimized SHA-256d path is a sampler-class OMEGA-I1 campaign. A block-level claim requires exact-verifier lift at useful target strengths.

OMEGA-I1 Contractor Build Target

The SHA-256d experiments specified in this paper are intended to run on OMEGA-I1. The architecture optimized here is the five-module, LED-first, host-routed federation with exact run records and contractor-buildable electronics. The historical reversible-LED Echosahedron bench is precursor background material, not an OMEGA-I1 result.

Shared module baseline

Every module has exactly twelve labeled ports, P00 through P11. Each port uses a co-located \(625\)-\(660\,\mathrm{nm}\) red LED source and BPW34-class photodiode detector channel. The controller is RP2350-class USB. LED drive is PCA9685-class or equivalent, detector fan-in is CD74HC4067-class or equivalent, and the analog front end is MCP6004-class or equivalent. The acceptance build uses 5 V USB, 3.3 V logic, no more than \(500\,\mathrm{mA}\) per module, \(5\,\mathrm{mA}\) nominal LED current, and \(10\,\mathrm{mA}\) maximum LED current.

The optical bodies are clean, fully cured clear SLA parts inside matte black, openable, labeled, ambient-light-baffled enclosures. The contractor build contains no clearcoat, polish, tint, dye, extra lenses, diffusers, laser modules, or free-space inter-module beams unless explicitly approved in writing. This keeps the measurement bundle interpretable.

Acceptance before mining

OMEGA-I1 acceptance is a readiness gate. Mining evidence starts after acceptance. Before any SHA-256d run, every module must print the evidence needed to estimate a module-specific \(K_{\mathrm{port}}\):

• identity, firmware hash, body hash, serial path, wiring map, and H1–H4 status block;

• dark readings, saturation margin, no-short resistance, module current, and per-port LED current;

• \(12\times12\) coupling scan, low-power sweep, MDD-style discharge record, and ring-diversity summary;

• operator-probe patterns, settle traces, edge-response polarities, dark path controls, and label-shuffle controls;

• repeatability coefficient of variation, response entropy, top-pair concentration, alive emitters, and alive sensors.

Performance claims use post-acceptance runs only. Build readiness proves that the instrument is alive and measurable. Enrichment, P-resonance, same-electrode H2, and cryptographic-break claims require post-acceptance evidence.

Optimized SHA-256d route

The operational route mirrors the simulation primitive: \[ \texttt{torus-search-prior} \to \texttt{mixer-critic} \to \texttt{echosahedron-verifier-shadow} \to \text{exact verifier}. \] For OMEGA-I1 this becomes: \[ \texttt{TOR-A/TOR-B} \to \texttt{TOR-C} \to \texttt{MIX-A} \to \texttt{ECH-A} \to \text{host SHA-256d}. \]

The host loads the block-template or midstate scorebook and sends matched drive programs to TOR-A and TOR-B. Their outputs are compared under blinded seeds and ABBA ordering. TOR-C expands or repairs the surviving nonce neighborhoods. MIX-A applies leading-zero and selected digest-byte criticism. ECH-A checks whether the candidate beam survives a different symmetric reference geometry. Host SHA-256d checks are spent on the serious candidates.

The optimized run bundle records route ID, ordered stage modules, router profile, thresholds, per-stage scorebook hashes, per-stage input and output beam hashes, coupling-matrix hashes, operator-probe hashes, settle-trace hashes, edge-response hashes, control-scan hashes, exact-verifier receipts, and control mode. Required control modes include single-module, pair, subset, full-five, and shuffled-label routes. A full-five result that fails the TOR-A/ TOR-B duplicate check, disappears under the MIX-A critic, or fails the ECH-A shadow is an engineering lead rather than a SHA-256d claim.

Declarations

Funding declaration: The authors declare that no funds, grants, or other support were received during the preparation of this manuscript.

Consent to Participate declaration: not applicable.

Consent to Publish declaration: not applicable.

Author Contribution declaration: Alexander Osika developed the OPH/Karma optical proof-of-work hardware path and contributed the experimental hardware evidence and build methodology. Bernhard Mueller developed the mathematical formulation, wrote the OPH constraint formalism and SHA-256d scorebook, and prepared the main manuscript text. Both authors reviewed and approved the manuscript.

Data Availability declaration: OPH/Karma engineering logs support the Kaspa optical proof-of-work evidence, and OMEGA-I1 engineering records support the build description. The bibliography lists public archival references only. External audit requires a sanitized ancillary evidence bundle containing raw run logs, verifier code, firmware versions, pool-response logs, calibration logs, hardware acceptance records, simulation seeds, and SHA-256d run traces.

Ethics declaration: not applicable.

Competing Interests declaration: The authors declare no competing interests.