Algorithm decision: ZFX-FP8C v0.1

Decision date: 2026-11-09. Spec: docs/SPEC_v0.1.md section 2A plus docs/SPEC_AMENDMENT_A.md.

Selected: candidate E, ZFX-FP8C. Each attempt pushes one row through a chain of restricted-domain FP8 GEMM layers, with per-epoch random weights and S-box requantization between layers.

Security readiness: MAINNET_READY = false. PRIVATE_TESTNET_READY = true.

Every number below comes from bench/results/*.json, produced by zfx-research all and bench/run_benchmarks.sh on an Apple M5 Pro (18 CPU threads, integrated GPU). NVIDIA H100 and AMD MI355X numbers were measured on ephemeral cloud GPU sandboxes (bench/results/gpu_summary.json). Other GPUs are UNSUPPORTED, and no number here is extrapolated from one device to another.

1. What was tried

Spec 2A required candidates A to D. I added E after the D measurements showed a structural problem that none of A to D can fix.

2. Gate 1: correctness (bit-exact across implementations)

I ran each candidate's real inputs through seven accumulation models of what hardware and libraries do: sequential, reversed, pairwise tree, split-K 4, FP16 accumulate, and a truncating-alignment model of an FP8 MMA accumulator that keeps 14 bits (the behavior DeepSeek-V3 reports for H800). The test is whether the output still matches the canonical bits. N=256, so 65,536 outputs per candidate (divergence.json).

Readings:

• A and B fail Gate 1 on every native GEMM path. A miner cannot use cuBLAS, hipBLASLt or any tensor-core FP32 accumulator and get consensus bits. A canonical result is reachable only by emulation. The Ozaki-style split into three signed 7-bit slices gives 9 int8 GEMMs with exact int32 accumulation, and that output is bit-exact against the canonical reference (ozaki_int8_emulation_of_A). So A costs 9x the int8 GEMM work of D/E for the same MAC count. B needs the same treatment.
• D and E are reduction-order independent by construction (|sum| < 2^24), and the models confirm it. The one hazard is a reduced-precision accumulator, which diverges on the rare rows where |partial| > 2^14. At K=4096 that was 0.6% of rows. A random self-test would miss it, so the published vectors and zpu_miner.py stress force |sum| = 2^20 rows, and miners must refuse any backend that fails them.
• Measured cross-implementation agreement for E: Rust (zpu-cli), C++ (zpu-miner), Python NumPy, PyTorch CPU, PyTorch MPS (Apple GPU) and MLX/Metal (Apple GPU) all pass the 278 published checks plus the 512x4096x4096 max-magnitude stress test with 0 mismatches (miners.jsonl). On real datacenter silicon: NVIDIA H100 (cuBLAS int8, cuBLASLt FP8 E4M3, portable kernel) and AMD MI355X (hipBLAS int8, hipBLASLt FP8 E4M3, portable kernel) pass all 278 checks and the 2^20 stress test, as do PyTorch fp32/int8/fp8 on both. Hopper's FP8 tensor-core path through cuBLASLt (default precise accumulation) did not show the reduced-precision divergence our truncation model warns about. B200, B300, RTX and MI300X remain UNSUPPORTED. Device code compiles for sm_100, sm_120 and gfx942.

3. Gate 2: security (forgeries and shortcuts)

C1 and C1' are disqualified: a cheap proof-forging path disqualifies a candidate "regardless of throughput" (spec 2A). The flaw is structural for any sampled-opening scheme whose lottery input depends on miner-chosen unopened data, or whose lottery runs before the work. C2 avoids it, because every tile is its own ticket and the verifier recomputes the ticket's whole tile, but C2 then inherits D's input-generation problem (section 5).

4. Gate 3: verification cost

E's verifier does exactly one attempt's work, which is the hashcash asymmetry Bitcoin has: mining costs 1/p attempts and verifying costs one. A dedicated GPU runs millions of attempts per second against a 1 ms CPU check. Validation of 1,000,000 headers costs about 1,000 CPU-seconds, parallel across cores. The open questions are DoS economics (an invalid block costs a peer 1 ms before the ban) and initial sync, both listed as blockers below. No recursive or succinct proof was adopted. Recomputing 1 ms of integer arithmetic is cheaper to verify, and easier to audit, than any SNARK verifier would be.

5. Gate 4: GPU efficiency, and why E exists

The key measurement for D: input generation per MAC. Fresh A, B per nonce cost 2N² SHAKE bytes for N³ MACs, which is 512 MACs per generated byte at N=1024. On the M5 CPU, generation was already 39% of D's attempt time (3.7 ms of 9.6 ms). A GPU tensor core running 10^15 MAC/s would need about 2 TB/s of SHAKE256 output to keep up. No GPU produces Keccak at that rate, so D on a GPU would be a SHAKE256 PoW with a matmul attached. A and B have the same ratio. C2 has it per ticket. Pearl's fix is low-rank noise on a fixed base matrix. That cuts generation, but it replaces "dense random matmul" with an algebraic hardness assumption ("batch low-rank random linear equations", per Pearl's own write-up), which ZeroFlux does not need because it makes no usefulness claim.

E removes the problem by amortization plus nonlinearity:

• Weights (51.6 M values) are generated once per 32-block epoch and shared by every attempt.
• Per attempt, only 64 input bytes are generated, so 806,912 MACs per generated byte, about 1,576x D's ratio.
• The S-box requantization between layers blocks the shortcut that makes fixed weights dangerous. Without it, X·W1·W2·W3 collapses to one precomputed matrix. With it, there is no algebraic composition, and the parity experiment shows the naive modular alternative is not enough.
• Batching nonces makes each layer a plain [batch x 4096] x [4096 x 4096] GEMM. That is the shape of a transformer MLP forward pass at inference, and every vendor BLAS runs it near peak.

Measured attempts/s on the v0.1 profile (miners.jsonl):

A datacenter GPU does 2,400x (H100) to 4,000x (MI355X) the attempts of an 18-thread M5 CPU, and the Apple integrated GPU 25x. Measured energy: H100 85.9 µJ/attempt (int8), MI355X 91.4 µJ/attempt (FP8), within 10% of each other, so neither vendor gets a structural advantage per joule. Apple joules are BLOCKED (no root for powermetrics).

6. Gate 5: implementation complexity

7. Scores and selection

Gates are applied in spec order. A gate failure ends the evaluation for production use.

E is the only candidate that passes Gates 1 to 3 and is compute-bound on tensor-core hardware. The runner-up, C2, is the fallback if review finds a structural flaw in the S-box chain. Its generation cost would then need Pearl-style noise, together with that noise's hardness assumption.

8. Frozen parameters (private testnet)

Profile 1 (zfx-fp8c-v0.1): d_in 64, H 4096, 3 hidden layers, d_out 256, shifts 0 and 2, epoch length 32 blocks, LWMA N = 30, testnet target spacing 30 s, MAINNET_READY = false. The full byte-level rules are in CONSENSUS.md.

9. Blockers to MAINNET_READY

See RELEASE_READINESS.md for owners. In short: B200, B300, RTX and MI300X not yet measured, no external cryptanalysis of the S-box-chain hardness assumption, no DoS/initial-sync economics study, no P2P transport encryption (it must use ML-KEM when added), an unaudited SLH-DSA integration, and no economic or legal review.

Sign-off

Selected and implemented by the ZeroFlux build agent, 2026-11-09, for the private testnet only. A production decision needs the Gate 3 to 6 reviews in RELEASE_READINESS.md.

Track B experiments (2026-11-09)

Raw results are in bench/results/. Each experiment names its winner and what lost.

Difficulty rule under timestamp manipulation (fork_resilience.json)

4,000-block simulations, 60 s target, mean block time over the second half:

Winner: RunningMax (t_i - max(t_0..t_{i-1})). Classic LWMA-1 lost: a 30% miner could more than double block production. This was found by the experiment, not assumed.

Monetary schedule (tokenomics.json)

Four consensus-parameterized families were modeled over 20 years: A constant 50 ZFX (uncapped), B halving every 2 years with a 0.5 ZFX tail, C Bitcoin-like 4-year halving with a hard cap, D smooth daily decay (half-life about 4 years) with a 0.5 ZFX tail. Recommendation: D, because miner revenue has no step changes for the LWMA to absorb and the tail keeps a security budget once fees are small. C is the main alternative if a hard cap is a product requirement. This is an owner decision; the node refuses network: "mainnet" until one is chosen.

Miner workload sizing (workload_cpu.json)

GPU batch 32,768 (measured +14% on H100 and +40% on MI355X over 8,192); one CPU thread per core; minimum supported GPU memory about 0.7 GB. On real v0.1 mining, zpu-cli jobs sized to 0.5 s of backend work reach 94% (H100) and 94% (MI355X) of the raw benchmark rate; fixed 2,000-attempt jobs reached 0.4%.

Trust-minimized bridge feasibility (onchain_pow_gas.json, stark_prototype.json)

Winner for v1: the committee. A proof-verified bridge needs a full PoW circuit, a NEAR verifier gas measurement, and external review first.