5. Hardware requirements

5.1 Stated as capabilities

No requirement here names a board, SoC or panel. Where nullroute's current profile is described, it is the Raspberry Pi 4 (4GB) with the official 7 inch DSI touchscreen at 800x480, which is the only profile it builds for (docs/VERIFICATION.md, "Hardware"). First boot on that hardware is the next milestone. Until it happens, anything that depends on the panel, the camera or the running kernel is recorded below as unverified, and every such line names the build-time check that already exists.

SP-HW-1. The review (section 3) and the software identity (section 4) MUST be shown on a display that only the signer's software drives. A display belonging to a networked machine does not satisfy this. Check: manual inspection of the hardware.

SP-HW-2. The display MUST show a full address without elision (SP-REV-5). The longest address this profile expects is 62 characters, a mainnet P2WSH or P2TR address: 2 characters of human-readable part, 1 separator, 1 witness version, 52 for 32 bytes in 5-bit groups (256 / 5 = 51.2, rounded up), and the 6-character checksum BIP-173 defines (bip-0173.mediawiki line 127). Check: manual on hardware; headless layout check where the implementer has one.

SP-HW-3. The display MUST render the largest single QR frame the signer emits at a module size the intended cameras decode, with a quiet zone. The profile sets no pixel count, since that depends on panel density and camera. nullroute caps frames at QR version 12 (65 modules across) at error correction level M, a choice its spec derives from an 800x480 panel (packages/core/src/qr/bbqr.spec.yaml lines 102-106). Check: nullroute INV-QR-5 against an independent decoder in software; manual on hardware: scan every frame of a multi-frame export with at least one coordinator's camera.

SP-HW-4. The signer MUST have an input method sufficient to enter dice digits and a passphrase without a networked device. Check: manual on hardware.

SP-HW-5. The signer MUST have at least one inbound path that is not a network: a camera for QR, removable media, or both. A camera SHOULD be provided, since a card that has been in both machines is a channel in its own right (docs/USING.md, "The two transports"). Check: manual on hardware.

SP-HW-6. The signer MUST have no working network path. Radio hardware MUST be absent, or the drivers, firmware and userspace that operate it MUST be absent from the image; the implementer MUST say which. No listener MAY exist outside loopback. Check: nullroute INV-PROV-13 against the built image and a radio-module count in the boot test, INV-NET-1 to INV-NET-3 for listeners; manual on hardware: list network interfaces on the running device.

SP-HW-7. Where a seed is stored, it MUST be stored only in encrypted form and there MUST be no swap. Check: nullroute INV-STORE-1, INV-PROV-11.

SP-HW-8. The signer SHOULD detect modification of its system partition (tier 1). Check: nullroute provisioning/profiles/os-verity.yaml (INV-PROV-4, INV-PROV-9 and others), INV-BOOT-1; manual on hardware: modify one block of the system partition on a card and confirm the device fails to read it.

SP-HW-9. A hardware RNG MUST NOT be required for seed generation in dice mode or for signing: both consume no randomness (SP-ENT-2, SP-SIG-1). A signer that seals the seed at rest will still use an operating system random source for salts and nonces, and SHOULD document that dependency. nullroute uses node:crypto randomBytes for the Argon2id salt and AES-GCM nonce (packages/daemon/src/store/envelope.ts lines 174-176), and for Modes A', B and C. Check: vector dice-to-entropy.json and INV-SIG-2 for the first sentence; manual review for the second.

SP-HW-10. Cost parameters tuned to one board (key stretching, parse size limits) SHOULD be re-measured on each board a profile adds. nullroute's Argon2id at 64 MiB and three passes is stated as "roughly half a second per guess on a Pi 4" (packages/daemon/src/store/store.spec.yaml). Check: manual timing on the board.

5.2 Hardware assumptions already in nullroute

From research/00-current-state.md section 3: the hard dependencies are the Pi 4 device tree and boot files, the DSI panel overlay and its touch controller, and 800x480 as the only viewport. None of them is in packages/core. A second board needs its own profile entry, device tree and overlay, and a second panel needs a layout that passes SP-HW-2 at its size.

5.3 nullroute conformance