KS
← All projectsKeystone

Keystone 3 firmware

Open-source device firmware for Keystone 3 hardware wallets.

BitcoinHardware walletsNormal
Repository coverage

532 commits in the local evidence base

Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.

107security candidates287second-pass queue108AI analyses
116commits · 30 days
155commits · 60 days
272commits · 180 days
532commits · 365 days
Backfill bands
Aug 5 → Feb 6260 seen14 candidatesComplete
Feb 6 → Jun 6117 seen7 candidatesComplete
Jun 6 → Jul 639 seen4 candidatesComplete
Jul 6 → Aug 5115 seen4 candidatesComplete
Commit communication

Does the history explain itself?

Message quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.

41/100 average clarity
35Strong · 80–100
64Adequate · 60–79
201Thin · 40–59
232Opaque · 0–39
37security candidates with opaque commit messaging
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Adam Tucker931112163
aaron3044148
ww35126871755151026
soralit1143333048
willwang1522025
John Boyd622088
Qkin-Keystone2611036
qkin1211050
Greg Pfeil411071
Daira-Emma Hopwood211085
bianminyan4500032
stone wang300038
Analysis record

Published AI watches

Last scanned 33 minutes ago

Informational 19 AI analysisMessage 85 · Strong
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix(simulator): return password error on PIN mismatch in SimulatorLoadAccountSecret

This commit fixes a bug in the firmware's simulator (a software stand-in used for testing, not the real hardware wallet). When checking a stored account password/PIN, the simulator was accidentally returning 'success' even when the passwor…

Incorrect success return on authentication failure in simulator-only codeMismatch between simulator and real-device authentication error semanticsFunctional regression in multi-account PIN creation in simulator builds
6bec6930by soralit+4−11 file
No security note in commit
Informational 12 AI analysisMessage 47 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

chore: remove implementation plan

This commit only deletes a planning document from the repository's docs folder. No firmware code, build scripts, or cryptographic logic were changed. The deleted file described a previously completed security-hardening task about removing …

Deleted document references a prior security-hardening task (issue #2255 / PRNG fallback removal)No source-code or build-system changes in the diff
4620fe94by ww3512687+0−1041 file
No security note in commit
Moderate 64 AI analysisMessage 80 · Strong
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix: remove insecure PRNG fallback

This commit removes a weak, predictable random-number generator that was bundled as a backup inside the firmware's SLIP-39 code. Previously, if the device's proper hardware random source was accidentally left out of a build, the firmware c…

Removal of deterministic LCG PRNG (random32)Removal of weak-symbol random_buffer fallbackRemoval of unused random helper APIs
17c78e30by ww3512687+108−693 files
Vendor flagged security relevance
Informational 10 AI analysisMessage 40 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

chore: update ci

This commit is described as a routine CI (continuous integration) update with only one line changed in a release-related file. No code changes affecting wallet security, cryptography, or user funds are visible, and no security relevance is…

39cfff13by soralit+1−11 file
No security note in commit
Informational 15 AI analysisMessage 47 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

chore: upgrade rust version

This commit upgrades the Rust compiler toolchain from one nightly version to a newer one and adjusts code to keep the project building and tests passing. It does not fix a known security bug or change how user funds are protected. Most of …

82a48133by soralit+511−1321 files
No security note in commit
Informational 10 AI analysisMessage 40 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

chore: update ci

This commit is described as a routine CI (Continuous Integration) update with only one line changed in one file. No diff content is available, and there are no verified references suggesting any security relevance. It appears to be a munda…

7f2c4423by soralit+1−11 file
No security note in commit
Low 42 AI analysisMessage 62 · Adequate
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix(zcash): defer checked batch cleanup after signing

This patch changes when a Zcash batch signing screen frees a sensitive internal data structure. Instead of destroying the data immediately when the page is cleared, it now schedules the cleanup to run after the signing operation has finish…

Use-after-free / premature-free risk in cryptographic signing pathAsync deferred cleanup introduced to avoid race with FIFO signing taskInline comment explicitly describes security-relevant ordering constraint
3b8995faby Adam Tucker+32−11 file
No security note in commit
Low 35 AI analysisMessage 45 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Release Zcash batch review widgets before signing

This commit fixes a potential memory/resource issue in the Zcash batch signing flow on the Keystone 3 hardware wallet. Before opening the signature view, the code now explicitly frees (destroys) the on-screen review widgets. Without this c…

Resource cleanup before sensitive signing operationUI object destruction to prevent memory pressure during cryptographic signing flowPotential UI state inconsistency mitigated by explicit widget release
2982da56by Adam Tucker+4−01 file
No security note in commit
Moderate 64 AI analysisMessage 50 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix the issue of uvfk not changed if changed password

This commit fixes a bug in the Keystone 3 hardware wallet's Zcash support: when a user changed their login password, the encrypted Zcash 'unified full viewing key' (UFVK) was not re-encrypted with the new password. That meant the stored UF…

Credential/key material desynchronization after password changeZcash UFVK ciphertext keyed by login passwordAutomatic migration/recovery of stale encrypted key material
6d8e2d9dby aaron+137−464 files
No security note in commit
Moderate 56 AI analysisMessage 45 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Reject existing Zcash batch signatures

This firmware update changes how Keystone hardware wallets handle Zcash batch signing. Previously, the device might have accepted a transaction request that already contained spend authorization signatures. Now it rejects such requests. Th…

Defensive input validation added to reject pre-existing spend authorization signatures in Zcash batch PCZT flowPotential host-supplied signature smuggling vector in batch signing mitigatedNew unit tests cover both Orchard and Ironwood pools for the rejection behavior
a50410acby Adam Tucker+126−33 files
No security note in commit
Moderate 64 AI analysisMessage 45 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Scope Zcash shielded signing to selected account

This commit fixes a bug in the Keystone 3 hardware wallet's Zcash shielded transaction signing. Previously, when a user reviewed and approved a transaction for one account, the device could accidentally authorize a spend from a different a…

Account-scoping enforcement added to shielded spend authorizationPrevents cross-account signing under same seedNew validation in PCZT check path before signing
3d14c7ddby Adam Tucker+166−296 files
Vendor flagged security relevance
Low 43 AI analysisMessage 62 · Adequate
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix(zcash): skip finalized dummy spends during signing

This commit fixes a bug in the Keystone hardware wallet's Zcash signing code. When signing a batch of Zcash transactions that include 'dummy' placeholder spends (zero-value decoy actions used for privacy), the signer could get stuck or fai…

Zcash privacy-spend signing bypass for finalized dummy actionsBatch-transport redaction state reproduced in regression testPotential signing failure / denial-of-service for Zcash PCZT transactions with dummy spends
9792998aby Adam Tucker+81−13 files
No security note in commit
Informational 15 AI analysisMessage 62 · Adequate
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

refactor(zcash): rename redacted PCZT signing helper

This commit is a simple rename of an internal function from `sign_pczt_to_pczt` to `sign_and_redact_pczt` in the Zcash Rust code. No behavior, logic, or security properties changed; it only makes the function name more descriptive. There i…

01bd8e2bby Adam Tucker+4−42 files
No security note in commit
High 71 AI analysisMessage 50 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

enhance the data content checking on the boot update logic

This commit adds safety checks to the bootloader update code in a cryptocurrency hardware wallet. Before the change, the firmware could trust attacker-controlled length values read from a staged update image, potentially allowing a malicio…

Length value from untrusted staged image used as loop bound and copy size before validationFixed-size 4 KB buffer g_fileUnit copied into with a length derived from external inputAddition of bootLen bounds check against header size and partition size
b10a29b0by aaron+13−01 file
No security note in commit
Moderate 59 AI analysisMessage 100 · Strong
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

feat(se): Move 2 W1 — SE generation detection, gen-isolated backend, gen-1 page-8 gate

This is a large firmware commit for the Keystone 3 hardware wallet that restructures how the secure element (SE) chip is used. It introduces a generation-aware backend so the firmware can support two different SE configurations (gen-1, the…

Generation-aware SE backend with fail-closed NULL backend for UNPROVISIONED/INVALID chipsLegacy page-8 PIN-hash wipe gated to gen-1 only to avoid erasing gen-2 R_wrappedPer-account lifecycle status pages for atomic crash recovery of create/change-PIN/delete
57a92dcdby aaron+2163−16736 files
Vendor flagged security relevance
Informational 10 AI analysisMessage 0 · Opaque
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix build

This is a one-line build fix that changes a padding length constant from 1 to 2 in a file used only for Bitcoin-only firmware builds. There is no indication in the commit of any security issue, vulnerability, or functional bug. It appears …

5e26e323by ww3512687+1−11 file
No security note in commit
Moderate 54 AI analysisMessage 100 · Strong
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix(zcash): sign shielded PCZTs without RoleSigner to fit the device stack

This commit fixes a crash in the Keystone hardware wallet when signing certain advanced Zcash transactions. The previous code used a heavy upstream signing helper that needed too much memory, causing the device to reset during an Orchard-t…

Stack overflow / device reset in signing task due to excessive stack usage by upstream RoleSignerReplacement of heavy upstream signer with lean in-repo low_level_signer to fit device stack budgetAddition of consensus-critical NU6.3 v6 Orchard/Ironwood sighash domains in pczt_ext
11592ebcby Adam Tucker+603−2173 files
No security note in commit
Informational 15 AI analysisMessage 85 · Strong
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix: remove duplicate SIG_BACKGROUND_UR_GENERATE_FAIL enumerator

This commit removes a duplicate entry in a list of internal software signal names used by the device's user interface. The duplicate would have caused the firmware to fail compilation, so the change is a straightforward build fix with no s…

1a8cfcb4by Adam Tucker+0−11 file
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

chore: point ur-registry at upstream SDK rev

This commit simply switches a software dependency from a temporary community fork back to the project's own official upstream repository. The code being used is the same feature (Zcash batch registry support); it has just been merged into …

ef575e15by Adam Tucker+3−32 files
No security note in commit
Low 37 AI analysisMessage 45 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Add Zcash batch signing for shielded PCZTs

This commit adds a new Zcash batch-signing feature for shielded transactions and fixes a UI bug where Zcash signing could freeze if the response QR code could not be generated. The changes introduce new Rust code to validate, parse, and si…

New batch signing path for Zcash shielded PCZTs with 35-message limitAtomic batch semantics: any invalid message aborts the whole batchPreflight check `ensure_pczt_has_signable_shielded_action` prevents silent no-signature results
745330f6by Adam Tucker+2201−5232 files
Vendor flagged security relevance
Repository ledger

Explore captured commits

Expand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.

Security candidatefix: remove duplicate SIG_BACKGROUND_UR_GENERATE_FAIL enumeratorby Adam Tucker · 1a8cfcb4 · Jun 24, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Adam Tucker

fix: remove duplicate SIG_BACKGROUND_UR_GENERATE_FAIL enumerator

The batch-signing change added a second SIG_BACKGROUND_UR_GENERATE_FAIL to
the GUI signal enum, which already defines it a few lines above. A duplicate
enumerator is a C redefinition error, and gui_views.h is included across the
UI layer, so the firmware would fail to build. Drop the duplicate.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
signing boundary
AI analysis · Informational 15/100

This commit removes a duplicate entry in a list of internal software signal names used by the device's user interface. The duplicate would have caused the firmware to fail compilation, so the change is a straightforward build fix with no security relevance.

Security candidatechore: point ur-registry at upstream SDK revby Adam Tucker · ef575e15 · Jun 24, 2026 · 2 filesMessage 80 · StrongInformational 15Details
Commit message · Adam Tucker

chore: point ur-registry at upstream SDK rev

The Zcash batch registry types have merged into the upstream
keystone-sdk-rust repo, so the valargroup fork pin is no longer needed.
Repoint ur-registry to the upstream rev that carries them.

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
access control
AI analysis · Informational 15/100

This commit simply switches a software dependency from a temporary community fork back to the project's own official upstream repository. The code being used is the same feature (Zcash batch registry support); it has just been merged into the official repo. There is no indication of a security problem, fix, or vulnerability.

Security candidateAdd Zcash batch signing for shielded PCZTsby Adam Tucker · 745330f6 · Jun 24, 2026 · 32 filesMessage 45 · ThinLow 37Details
Commit message · Adam Tucker

Add Zcash batch signing for shielded PCZTs

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet pathparser or protocol path
AI analysis · Low 37/100

This commit adds a new Zcash batch-signing feature for shielded transactions and fixes a UI bug where Zcash signing could freeze if the response QR code could not be generated. The changes introduce new Rust code to validate, parse, and sign batches of Zcash PCZT messages, plus new C UI screens to review and approve those batches. It also tightens error handling so that QR/USB generation failures are reported instead of leaving the device stuck. There is no direct evidence in the commit of an exploitable vulnerability, but the size and complexity of the new signing path means it should be reviewed carefully.

Lower-prioritychore: bump beta versionby soralit · 4e28d917 · Jun 24, 2026 · 1 fileMessage 40 · ThinTriage 0Details
Commit message · soralit

chore: bump beta version

40/100 · ThinMessage clarity
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
AI review queuedfix: reject all shielded PCZTs in the legacy transparent-only pathby Adam Tucker · c0faa647 · Jun 23, 2026 · 4 filesMessage 85 · StrongHigh 72Details
Commit message · Adam Tucker

fix: reject all shielded PCZTs in the legacy transparent-only path

The legacy multi_coins check/parse/sign path only handles transparent
data, but pczt_requires_cypherpunk_support only rejected V6/Ironwood PCZTs.
A v5 PCZT carrying an Orchard or Sapling bundle slipped through: its
transparent part was validated and signed while the shielded bundle was
silently ignored. Extend the guard to also reject Orchard actions and
Sapling spends/outputs so the boundary is strictly transparent-only.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
defensive validationsigning or wallet pathsecond-pass: near security thresholdsecond-pass: security-sensitive path
AI analysis · High 72/100

This commit fixes a security gap in the Keystone hardware wallet's Zcash transaction handling. The older 'legacy' code path was only designed to inspect and sign transparent (non-private) Zcash transactions, but its safety check only blocked the newest V6 and Ironwood transaction types. A version 5 transaction containing hidden Sapling or Orchard transfers could slip past the check. The wallet would then validate and sign only the visible transparent portion, while silently ignoring the shielded part. That could let a malicious or buggy app trick a user into approving a transaction that also moves funds privately. The patch now rejects any transaction containing Sapling or Orchard shielded data in the legacy path, forcing it to use the newer 'cypherpunk' path that understands those formats.

Lower-prioritytest: add p2pkh transparent-output decode testby Adam Tucker · 612a4a94 · Jun 23, 2026 · 1 fileMessage 90 · StrongTriage 0Details
Commit message · Adam Tucker

test: add p2pkh transparent-output decode test

Replace the removed hex-blob transparent-output decode test with a
runtime-built equivalent: build a p2pkh output to an external recipient and
assert parse decodes its address, value, and not-change classification.
Mirrors the existing p2sh output test.

90/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
Lower-priorityrefactor: flatten check_transparent_input with let-else + map_orby Adam Tucker · e76f36e3 · Jun 23, 2026 · 1 fileMessage 85 · StrongTriage 0Details
Commit message · Adam Tucker

refactor: flatten check_transparent_input with let-else + map_or

Replace the nested match/match in check_transparent_input with a let-else for
the script->address refinement and .map_or for the derivation lookup, per the
reviewer's suggestion. The // 1/2/3 step comments are preserved. No behavior
change.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Lower-prioritystyle: import alloc::{format, vec} at the top of check.rsby Adam Tucker · 658f5b57 · Jun 23, 2026 · 1 fileMessage 73 · AdequateTriage 0Details
Commit message · Adam Tucker

style: import alloc::{format, vec} at the top of check.rs

Replace the inline `alloc::format!` / `alloc::vec!` prefixes with a single
`use alloc::{format, string::ToString, vec};`, matching the sibling pczt
modules and keeping the allocator import in one place. No behavior change.

73/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
Lower-priorityrefactor: drop dead seed-fingerprint check from transparent derivation helperby Adam Tucker · d6e8bbde · Jun 23, 2026 · 2 filesMessage 85 · StrongTriage 8Details
Commit message · Adam Tucker

refactor: drop dead seed-fingerprint check from transparent derivation helper

Every caller of the helper already filters by seed fingerprint before
invoking it, so its internal `if seed_fingerprint != ... { Ok(false) }`
branch was unreachable. Drop it and the now-unused seed_fingerprint
parameter, return Result<()> (the helper only validates the derived pubkey,
erroring on mismatch), and rename it to check_transparent_derivation.
check_transparent_input returns Ok(true) directly for a matched derivation.
No behavior change.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
defensive validation
AI review queuedrefactor: thread ShieldedPool enum instead of stringly pool labelsby Adam Tucker · 28380dac · Jun 23, 2026 · 4 filesMessage 85 · StrongTriage 12Details
Commit message · Adam Tucker

refactor: thread ShieldedPool enum instead of stringly pool labels

Replace the `pool_label: &str` threaded through the Orchard/Ironwood check,
parse, and sign helpers with the existing `ShieldedPool` enum, lifted into
`pczt/mod.rs` as its shared home. Rename `check_orchard` to the pool-agnostic
`check_shielded_bundle`. Each helper derives the label from the enum
internally, so all error messages are unchanged.

Addresses review feedback that the customizable string pool label was
confusing next to the always-Orchard bundle type, and that an Orchard-named
helper was being used for the Ironwood pool.

85/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedAdd Ironwood PCZT supportby Adam Tucker · c28575be · Jun 23, 2026 · 9 filesMessage 68 · AdequateTriage 12Details
Commit message · Adam Tucker

Add Ironwood PCZT support

Add cypherpunk Zcash PCZT parse/check/sign support for v6/Ironwood while
preserving existing Orchard and transparent behavior. Legacy multi_coins
paths reject v6/Ironwood PCZTs instead of mis-handling them. Signed
responses stamp the firmware version and redact optional PCZT fields
(including Ironwood bundle data) before returning QR-sized results.

Restores, against the new builder API, the runtime-constructed regression
tests dropped during the dependency bump:
- internal-OVK change-spoofing rejection (parse + check)
- empty Sapling bundle with non-zero value sum rejection
- Orchard spend/output value + ownership decode (parse + check)

68/100 · AdequateMessage clarity
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing or wallet pathsecond-pass: broader security terminologysecond-pass: security-sensitive path
Security candidateBump Zcash deps to Ironwood revisions + mechanical API migrationsby Adam Tucker · 4487747f · Jun 23, 2026 · 10 filesMessage 83 · StrongLow 27Details
Commit message · Adam Tucker

Bump Zcash deps to Ironwood revisions + mechanical API migrations

Pin the Zcash crates to the Ironwood fork revisions (orchard via
zcash/orchard, the zcash_*/pczt crates via the valargroup fork) using
[patch.crates-io], enable the zcash_unstable="nu6.3" cfg, and apply the
mechanical API migrations the bump forces:

- TransparentAddress::from_script_from_chain / from_script_pubkey
- Note::from_parts note-version argument, SignableInput::from_parts
- pczt_ext ZIP-244 sighash digest adjustments

Tests embedding the old PCZT wire format or the pre-bump builder API are
dropped here (they no longer parse/compile); equivalents against the new
API are restored with the Ironwood feature in the following commit.

NOTE: this commit does not build in isolation. The parse.rs/sign.rs API
migrations are interleaved with the Ironwood parsing/signing changes and
land together in the next commit; this is split out purely to isolate
the dependency bump for review.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
signing boundary
AI analysis · Low 27/100

This commit updates the Zcash-related Rust libraries inside the Keystone 3 firmware to newer versions. It also makes small code changes so the firmware keeps compiling with the new library APIs, removes some old tests that no longer work with the new wire format, and adjusts how transaction hashes are computed. The commit itself is described by its author as not building in isolation; the remaining matching changes are in the next commit. There is no direct evidence in the commit that this fixes or introduces a security vulnerability.

AI review queuedRefactor PCZT handling: extract shared helpers (no dependency changes)by Adam Tucker · bd1298f6 · Jun 23, 2026 · 4 filesMessage 83 · StrongTriage 8Details
Commit message · Adam Tucker

Refactor PCZT handling: extract shared helpers (no dependency changes)

Pure code reorganization ahead of Ironwood support, on the existing
Zcash dependencies:

- move validate_sapling_bundle_consistency into pczt/mod.rs behind a
shared validate_supported_pczt entry point
- extract transparent_derivation_matches_selected_account and
map_orchard_verifier_error helpers
- have check_pczt_transparent report whether a wallet input was found
- thread a pool_label through the Orchard check helpers
- generalize the shielded-pool renderer to GuiZcashOverviewShielded

The original test suite is retained and passes on the current
dependencies (cypherpunk: 73 tests, multi_coins: 38 tests), showing the
refactor introduces no behavior change. The dependency bump and the
Ironwood feature follow in later commits.

83/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
Why it was queued
defensive validationsecond-pass: broader security terminology
AI review queuedfeat: add vizor tutorialby soralit · 9a423f33 · Jun 23, 2026 · 2 filesMessage 40 · ThinTriage 12Details
Commit message · soralit

feat: add vizor tutorial

40/100 · ThinMessage clarity
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
Lower-priorityremove the noneeded cancel opby aaron · 4bc89798 · Jun 23, 2026 · 1 fileMessage 45 · ThinTriage 0Details
Commit message · aaron

remove the noneeded cancel op

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Lower-priorityfix: fix the issue on lock screen pw and fp race issueby aaron · 2051feef · Jun 23, 2026 · 4 filesMessage 62 · AdequateTriage 0Details
Commit message · aaron

fix: fix the issue on lock screen pw and fp race issue

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
AI review queuedfeat: add vizor wallet to cypherpunkby soralit · 7a5cef79 · Jun 23, 2026 · 7 filesMessage 57 · ThinTriage 12Details
Commit message · soralit

feat: add vizor wallet to cypherpunk

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedrun font scriptsby ww3512687 · d2ccb0ee · Jun 23, 2026 · 4 filesMessage 28 · OpaqueTriage 0Details
Commit message · ww3512687

run font scripts

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
Security candidatefix ar bugsby ww3512687 · 26fffdc3 · Jun 22, 2026 · 9 filesMessage 0 · OpaqueModerate 57Details
Commit message · ww3512687

fix ar bugs

0/100 · OpaqueMessage clarity
! Very short subject! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
cryptography-sensitive path
AI analysis · Moderate 57/100

This commit fixes several bugs in the firmware of the Keystone 3 hardware wallet, mainly around how Arweave (AR) cryptocurrency keys and RSA prime numbers are handled. It replaces direct array indexing with safer lookups, adds checks for missing or corrupted data, stores a hash of sensitive RSA primes in a secure chip, and erases that data when an account is deleted. The changes reduce the chance that a malformed or out-of-range value could cause the device to read the wrong key, crash, or leave sensitive key material behind after deletion.

AI review queuedchore: resume Zcash firmware version changesby soralit · 4ec3335f · Jun 22, 2026 · 9 filesMessage 72 · AdequateTriage 12Details
Commit message · soralit

chore: resume Zcash firmware version changes

This reverts commit 718548072bc0929b34d9af7eb57061cc10b3b7cc.

72/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedchore: revert Zcash firmware version changesby soralit · 71854807 · Jun 22, 2026 · 9 filesMessage 57 · ThinTriage 12Details
Commit message · soralit

chore: revert Zcash firmware version changes

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI review queuedfix the build issuesby aaron · 41a41374 · Jun 18, 2026 · 1 fileMessage 28 · OpaqueTriage 0Details
Commit message · aaron

fix the build issues

28/100 · OpaqueMessage clarity
✓ Subject identifies a change! No meaningful explanatory body
Why it was queued
second-pass: opaque commit message
Lower-priorityresolve the code review commentsby aaron · 0f1e0e21 · Jun 18, 2026 · 2 filesMessage 45 · ThinTriage 0Details
Commit message · aaron

resolve the code review comments

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Security candidatefeat: update dice roll entropy uiby soralit · 7bc4d7d8 · Jun 18, 2026 · 8 filesMessage 62 · AdequateLow 35Details
Commit message · soralit

feat: update dice roll entropy ui

62/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Names security-relevant behavior explicitly! No meaningful explanatory body
Why it was queued
entropy or randomnesscryptography-sensitive path
AI analysis · Low 35/100

This commit updates the user interface and internal checks for generating wallet seed phrases using dice rolls as a source of randomness. It enforces a minimum number of dice rolls depending on the desired seed strength: at least 50 rolls for 12-word (BIP39) or 20-word (SLIP39) seeds, and at least 100 rolls for 24-word (BIP39) or 33-word (SLIP39) seeds. Previously, the firmware only required 50 rolls regardless of seed length. The change is a security hardening measure to ensure that higher-strength seeds receive enough physical entropy, but it is a partial patch because the dice-roll input itself is not fully validated and the entropy extraction method is not visible in this diff.

Security candidatechange the se config and usageby aaron · 24f68a8e · Jun 17, 2026 · 14 filesMessage 45 · ThinModerate 57Details
Commit message · aaron

change the se config and usage

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
AI analysis · Moderate 57/100

This firmware update changes how the Keystone hardware wallet stores and checks device passwords. Previously, the device kept a separate password hash page in its secure element (SE) storage. After this update, password verification is done by trying to decrypt the actual account secret using the password, and the old password hash pages are wiped. The change also removes hard assertions on SE operations so that failures return error codes instead of crashing, and it maps a specific secure-element authentication failure to a wrong-password error. The version number is bumped from 12.4.6 to 12.5.0.