Firmware
KeepKey firmware source is published under LGPLv3. Use the published release record for installable firmware and the candidate’s own evidence for development and testing.
What this section covers
- Supported Chains: chain and operation coverage, with version-specific limits.
- Device Display Reference: examples of confirmation screens.
- CI Test Atlas: how to read results, captured frames and candidate provenance.
- python-keepkey: the device client used in tests and integrations.
CI test suite
Firmware CI includes host-side and emulator tests. Selected tests contribute OLED captures to the curated PDF report. The exact jobs, variants and tests depend on the workflow and candidate. A green run or a captured screen is not a substitute for required physical-device testing.
The Test Atlas identifies an inspected report and explains passed, skipped, pending and withheld coverage. Historical reports remain useful for their own builds; their counts do not describe current coverage.
Building from source
Select the exact release tag or commit before initializing dependencies and building. Follow the build instructions at that ref, including its pinned toolchain and submodules. Do not mix source from one candidate with dependency pins or an emulator from another.
The firmware repository contains device and emulator build scripts. Available CI artifacts vary; a container image is not necessarily the libkkemu library used by Vault.
Verifying a release
Compare a downloaded file’s SHA-256 with the value recorded for that exact artifact. Reproducing a build is a separate check: compare the appropriate firmware payload with one built from the matching source and toolchain. A signed release header can differ from a local unsigned build.
A matching hash establishes file equivalence to a particular reference. It does not alone establish what is installed on a physical device or prove the source has no defects. Follow the update guide and keep the release record with your verification results.