SHA-only hardware verifier

The active hardware verifier implements HASHSIGS_SHA256_GENERIC_V1. It does not accept a legacy Keccak signature. Legacy verification remains a software reference operation.

Input and result

One canonical verifier frame is 2,240 bytes, exactly 35 512-bit beats:

signature (2,144) || public seed (32) || public-key hash (32) || message (32)

The message is already a 32-byte digest. Every beat has a full keep mask, and last is accepted only on beat 34. Ownership is released by the fixed accepted beat count, never by trusting an early unvalidated last.

The result reports the original job identity, a verified decision, and an error class. A cryptographically invalid but well-formed signature is different from a framing, transport, or audit failure.

Message-dependent work

Verification starts each chain at the signature’s message digit and performs only the remaining real transitions to endpoint 15. It emits:

• 16 mask jobs;
• 45 through 990 chain jobs, depending on the digest digits; and
• 34 endpoint-hash compression jobs.

The complete task count is therefore 95 through 1,040 SHA-256 compression operations. A skipped chain transition is a bypass, not a fake lane request.

Expected-tag transport

One cluster contains four verifier contexts and one exact-64-cycle compression lane. A speculative launch register accepts a context request only when the unchanged payload is actually launched. The transport writes its full tag into a 64-entry expected-return memory and advances across both tokens and bubbles.

On return, the transport checks timing, exact tag equality, task format, and physical ownership before routing the digest. This catches loss, extras, mistiming, malformed tags, wrong-context returns, and even a perfect swap of two otherwise valid in-flight tags.

Fail-closed top

Three four-context clusters sit behind a global top. A local integrity failure latches global poison. The top stops clean admission, broadcasts a registered peer abort, waits for contained in-flight effects, and drains identified error results. Result selection depends on registered validity rather than payload data, avoiding a fault-to-abort-to-fault combinational loop.

Current evidence

The full three-lane verifier has Rust/RHDL source simulation and modular descriptor evidence. It does not yet have linked generated-RTL simulation, Vivado synthesis, routed timing, resource, throughput, or card evidence. The evidence matrix preserves that lower boundary even though the signer has been promoted further.