CommitWatch RSS
KS
← All projectsKeystone

Keystone 3 firmware

Open-source device firmware for Keystone 3 hardware wallets.

BitcoinHardware walletsNormal
Source repository ↗
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 queue45AI 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.
ww35126871755121026
soralit1143315048
Adam Tucker93115063
aaron3041048
willwang1521025
John Boyd621088
Qkin-Keystone2610036
qkin1211050
Greg Pfeil410071
Daira-Emma Hopwood210085
bianminyan4500032
stone wang300038
Analysis record

Published AI watches

Last scanned 43 minutes ago

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
Open full analysis →Source 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
Open full analysis →Source commit ↗
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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 62 · Adequate
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

feat: update dice roll entropy ui

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 …

Enforces minimum entropy input length based on target mnemonic strengthAdds server-side/model-layer validation in addition to UI gatingPrevents generation of 256-bit seeds from insufficient dice-roll entropy
7bc4d7d8by soralit+158−168 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 0 · Opaque
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

leap sunset

This commit removes support for the 'Leap' wallet from the Keystone 3 firmware. It deletes the Leap wallet icon and asset, removes Leap-related text strings from Chinese, Japanese, and Korean font files, and updates the Rust dependency ver…

920e9830by ww3512687+609−88123 files
No security note in commit
Open full analysis →Source commit ↗
Low 29 AI analysisMessage 100 · Strong
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

feat(zcash): enable Zcash for SLIP 39 wallets with 33-word shares

This commit changes how the Keystone hardware wallet enables Zcash for SLIP 39 wallets. Previously, Zcash was completely disabled for all SLIP 39 wallets. Now it is allowed when the SLIP 39 shares are 33 words long (256-bit entropy), but s…

Relaxation of a security-motivated disablement based on entropy lengthNew entropy-length gate for Zcash supportPotential risk if entropy length check is bypassed or miscalculated
2729141bby John Boyd+46−269 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 35 AI analysisMessage 57 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

feat(nufi-tron): update nufi-tron support

This commit adds a new way for the Keystone hardware wallet to handle Tron (TRX) transactions sent as plain JSON sign requests, alongside the older Keystone-specific format. It introduces code that parses JSON, derives the sender address f…

New transaction parsing path from untrusted JSON input (serde_json::Value then protoc::TronTx)Address-ownership check added before signing (derived address vs. JSON 'from' field)Use of keccak256 with slicing `digest[12..]` to form 20-byte TRON address
c9cc587eby qkin+571−1713 files
No security note in commit
Open full analysis →Source commit ↗
Low 26 AI analysisMessage 28 · Opaque
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

support core wallet

This commit adds support for the Core Wallet in the Keystone 3 firmware. It mainly expands the number of Avalanche X/P-chain derivation paths from one to ten, updates the Rust SDK dependency, and changes how signing requests extract deriva…

Change to cryptographic signing API (multiple paths / multiple signatures)Change to HD derivation path validation and selection logicChange to master-fingerprint / source-fingerprint verification
fa8a0579by ww3512687+165−13711 files
No security note in commit
Open full analysis →Source commit ↗
Low 27 AI analysisMessage 28 · Opaque
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

support core wallet

This commit adds support for the Core Wallet in the Keystone 3 firmware. It mainly expands the number of Avalanche (AVAX) X/P-chain account paths from one to ten, updates the Rust signing code to accept multiple derivation paths from the w…

Change from hardcoded derivation-path derivation to paths supplied by the signing requestAddition of multiple AVAX X/P-chain account indexes (0-9)Signature generation now iterates over multiple provided paths
cbcd90c1by ww3512687+165−13711 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 50 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

Remove the redundant code and comments related to TON

This commit removes the special 'TON-only wallet' feature from the Keystone 3 firmware. It deletes code that let users create or import a TON-native 24-word seed phrase separate from the normal BIP39 wallet. After this change, TON is handl…

No security-relevant signals present in the diff or commit metadataFeature removal, not a vulnerability patchNo mention of CVE, security advisory, researcher credit, or exploit in commit message
abe8f0b7by ww3512687+91−169342 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 61 AI analysisMessage 67 · Adequate
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

feat: improve update security, support X Layer, and refresh Zodl wallet integration

This firmware update for the Keystone 3 hardware wallet is billed as a security improvement. The most important change is a complete rewrite of the bootloader/firmware update path: it now uses SHA-256 and a signed/length-prefixed 'bootupda…

Bootloader/firmware update verification upgraded from MD5 to SHA-256 with length-prefixed magic headerAUTO_REBOOT_AFTER_COPY_FILE path removed from USB MSC SCSI handler, eliminating host-triggered reboot on file copyUSB endpoint address validation added across DCD, USBD core, and class drivers to prevent out-of-bounds EP array access
c42b3eebby ww3512687+3821−98482 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
Moderate 57 AI analysisMessage 0 · Opaque
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

boot update

This commit is a large firmware update for the Keystone 3 hardware wallet, primarily adding a bootloader update mechanism and hardening the USB stack. It introduces a way to overwrite the device's bootloader from a specially formatted regi…

New bootloader self-update path from application flash with magic-number header, SHA-256 hash, and CRC32 verificationFlash encryption enabled for production builds using OTP-derived AES-CBC key/IVUSB control endpoint hardening: request length validation, descriptor bounds checks, endpoint address validation, stall-on-invalid requests
4df8c325by ww3512687+3369−73160 files
No security note in commit
Open full analysis →Source commit ↗
Informational 20 AI analysisMessage 57 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix: zcash transparent is not signing

This is a one-line build-configuration fix for the Keystone hardware wallet's Zcash signing code. Previously, transparent Zcash transaction signing was only enabled when the 'multi_coins' feature was active. The change also enables it when…

No memory-safety issues visible in the diffNo cryptographic algorithm changesNo input validation changes
18300002by soralit+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Low 41 AI analysisMessage 57 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix: zcash transparent is not signing

This is a one-line build-configuration fix for the Keystone hardware wallet's Zcash transparent transaction signing. Previously, the code that signs the transparent (non-shielded) part of a Zcash PCZT transaction was only compiled when the…

Functional bug in cryptographic signing pathBuild-feature conditional compilation errorCould produce invalid/incomplete transaction signatures
635fc76eby soralit+1−11 file
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 28 · Opaque
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

support gero wallet

This commit adds support for a new wallet partner called Gero Wallet in the Keystone 3 firmware. It is a routine feature addition: a new icon, a new entry in wallet lists, a tutorial link, and recognition of the wallet's origin name when h…

254e8157by ww3512687+112−712 files
No security note in commit
Open full analysis →Source commit ↗
Informational 17 AI analysisMessage 57 · Thin
KS KeystoneKeystone 3 firmware BitcoinHardware wallets

fix: keystone slip39 not support zcash

This commit fixes a product limitation: Keystone 3 hardware wallets using a SLIP39-style recovery phrase could not connect to the Keystone mobile app for Zcash. The patch removes Zcash from the list of coins shared when a SLIP39 wallet is …

Functional/compatibility fix for SLIP39 Zcash supportInput validation added for zcash seed fingerprint length (must be 0 or 32)No evidence of buffer overflow, use-after-free, or cryptographic weakness in the patch
2ff0478eby soralit+70−127 files
No security note in commit
Open full analysis →Source commit ↗
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(simulator): return password error on PIN mismatch in SimulatorLoadAccountSecretby soralit · 6bec6930 · Aug 4, 2026 · 1 fileMessage 85 · StrongTriage 18Details
Commit message · soralit

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

SimulatorLoadAccountSecret returned SUCCESS even when the stored password
did not match. This made the duplicate-PIN check (CheckPasswordExisted ->
VerifyAccountPassword) always treat any new PIN as a duplicate of an
existing account, so setting a PIN for the second account and onwards
failed with 'Duplicate PIN code detected'.

Return ERR_KEYSTORE_PASSWORD_ERR on mismatch, matching the real-device
behavior (LoadAccountSecretFromSE returns ERR_KEYSTORE_AUTH on HMAC
failure, which VerifyAccountPassword maps to ERR_KEYSTORE_PASSWORD_ERR).

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
access control
Security candidatechore: remove implementation planby ww3512687 · 4620fe94 · Aug 4, 2026 · 1 fileMessage 47 · ThinTriage 0Details
Commit message · ww3512687

chore: remove implementation plan

47/100 · ThinMessage clarity
✓ Descriptive subject✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
seed or entropy pathdocumentation-only discount
Security candidatefix: remove insecure PRNG fallbackby ww3512687 · 17c78e30 · Aug 4, 2026 · 3 filesMessage 80 · StrongModerate 64Details
Commit message · ww3512687

fix: remove insecure PRNG fallback

Remove trezor-crypto's unused LCG and weak fallback so device builds must link the platform random_buffer implementation. Keep a simulator-only standard library stub.

Co-authored-by: Nikolaus Heger <nheger@gmail.com>

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
entropy or randomnesscryptography-sensitive pathseed or entropy path
AI analysis · Moderate 64/100

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 could silently fall back to the weak generator, which would make wallet backup seeds predictable. Now the weak generator is gone for hardware builds, so a missing proper random source causes the build to fail instead of silently producing insecure seeds. The simulator still keeps a simple software-only stub for testing.

Security candidatechore: update ciby soralit · 39cfff13 · Jul 31, 2026 · 1 fileMessage 40 · ThinTriage 12Details
Commit message · soralit

chore: update ci

40/100 · ThinMessage clarity
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
boot or update path
Security candidatechore: upgrade rust versionby soralit · 82a48133 · Jul 28, 2026 · 21 filesMessage 47 · ThinTriage 19Details
Commit message · soralit

chore: upgrade rust version

47/100 · ThinMessage clarity
✓ Descriptive subject✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
boot or update pathparser or protocol path
Security candidatechore: update ciby soralit · 7f2c4423 · Jul 21, 2026 · 1 fileMessage 40 · ThinTriage 12Details
Commit message · soralit

chore: update ci

40/100 · ThinMessage clarity
✓ Subject identifies a change✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
boot or update path
Security candidatefix(zcash): defer checked batch cleanup after signingby Adam Tucker · 3b8995fa · Jul 20, 2026 · 1 fileMessage 62 · AdequateTriage 18Details
Commit message · Adam Tucker

fix(zcash): defer checked batch cleanup after signing

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
signing boundary
Security candidateRelease Zcash batch review widgets before signingby Adam Tucker · 2982da56 · Jul 18, 2026 · 1 fileMessage 45 · ThinTriage 18Details
Commit message · Adam Tucker

Release Zcash batch review widgets before signing

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundary
Security candidatefix the issue of uvfk not changed if changed passwordby aaron · 6d8e2d9d · Jul 16, 2026 · 4 filesMessage 50 · ThinTriage 15Details
Commit message · aaron

fix the issue of uvfk not changed if changed password

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
cryptography-sensitive path
Security candidateReject existing Zcash batch signaturesby Adam Tucker · a50410ac · Jul 14, 2026 · 3 filesMessage 45 · ThinTriage 18Details
Commit message · Adam Tucker

Reject existing Zcash batch signatures

45/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
signing boundary
Security candidateScope Zcash shielded signing to selected accountby Adam Tucker · 3d14c7dd · Jul 13, 2026 · 6 filesMessage 45 · ThinModerate 64Details
Commit message · Adam Tucker

Scope Zcash shielded signing to selected account

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

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 account controlled by the same seed. The patch now checks that every shielded spend belongs to the account the user actually selected, and rejects the transaction if any spend comes from another account. This prevents an attacker or buggy wallet software from tricking the user into signing a spend from an account they did not review.

Security candidatefix(zcash): skip finalized dummy spends during signingby Adam Tucker · 9792998a · Jul 13, 2026 · 3 filesMessage 62 · AdequateLow 43Details
Commit message · Adam Tucker

fix(zcash): skip finalized dummy spends during signing

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 43/100

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 fail because it tried to re-sign a dummy spend whose signature had already been finalized and then stripped for transport. The fix tells the signer to skip these finalized zero-value dummy spends, allowing the real spend to be signed normally. The changelog frames it as a fix for batch signing with finalized zero-value dummy spends.

Security candidaterefactor(zcash): rename redacted PCZT signing helperby Adam Tucker · 01bd8e2b · Jul 9, 2026 · 2 filesMessage 62 · AdequateInformational 15Details
Commit message · Adam Tucker

refactor(zcash): rename redacted PCZT signing helper

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

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 is no security issue here.

Security candidateenhance the data content checking on the boot update logicby aaron · b10a29b0 · Jul 7, 2026 · 1 fileMessage 50 · ThinTriage 12Details
Commit message · aaron

enhance the data content checking on the boot update logic

50/100 · ThinMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
Why it was queued
boot or update path
Security candidatefeat(se): Move 2 W1 — SE generation detection, gen-isolated backend, gen-1 page-8 gateby aaron · 57a92dcd · Jul 3, 2026 · 36 filesMessage 100 · StrongModerate 59Details
Commit message · aaron

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

- SeGen_t + GetSeGen(): classify the SE generation from the IMMUTABLE locked config manifest only (countMatch/chipOptions/slotConfig[8,13]/keyConfig[4,7,8,11,13]); fail-closed on UNPROVISIONED/INVALID. match_count is NOT used for classification (mutable; a transient slot-8 read must not flip a healthy device to INVALID).

- SeAccountBackend vtable + SeBackend() dispatcher: gen-1 wrappers map to the existing legacy derivation (derive_608/provision_608/on_unlock_success no-op); gen-2 stubs (filled in W2-W9); SeBackend() returns NULL for UNPROVISIONED/INVALID (fail closed).

- Gate the legacy page-8 wipe to SE_GEN_1 at the caller (AccountManagerInit) so it can never erase a gen-2 R_wrapped.

Scaffolding only: vtables in se_manager.c for now (physical split to src/managers/se/ during the gen-1 extraction); no callers wired -> zero runtime change.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

add the function seCounter, matchCounter, rearm etc for se gen2

tmp

refactor the gen2 functions and add some functions in the driver

add the function for the gen2 R and K608 related usage

Gen2Provision608

change Gen2Provision608 and clear the secret K608

refactor the 608b logic and set add gen1 and gen2 backend logic

fix the building issues

fix the paras issues

update the solt/key config

show the se gen version in the device info

get the exsiting pwd to get R when adding the 2/3 wallet

check the device bricked in init on gen2

destroy the account and wipe device setting

add the se account status checking logic and change pwd logic

unset the pwd after change pwd and for gen2 use new way to get the existing account number

disable lock on add wallet and change password/pin

adjust current wallet limit and clear the r passs value as required

add the feature for forget password

fix the wrong pin limit issue and remove the logs

feat: add the weak pin modal

fix simulator and disable boot checking for dev build

fix: the weak-passcode modal free issue

clear the pw for R when lock the device

add data checking function when provision608 before R generation

init the view with g_proveOwnershipDone to false

roll kdf_i in the data check failed

set the state after all passed zero

fix the possible save account issues

prevent the pin dup try when reached back to lock view

add log for desstory account

fix the initail value issue on KeyboardWidget

fix: remove bump on the counter to enlarge the lifetime

refactor the code to move gen decision into the se backend

default to gen2 config in the blank chip

check the operation result to avoid mutation issue

fix the simulator

reorder the wipe function steps

add 10 limit on the password check try

drop the current working flow(add-wallet, change-pin etc) to home view if the password try reached limit and fix the memory leak issue

fix the R Recovery issue for nav back and forth on adding wallet view

fix the issue of drop forget pw flow

protect test R_wrapped value to prevent zero value caculation

remove the ForceLockScreen and fix create-wallet missing R issue

R protect: when forget pass, retype the same wallet pw and seed return not pass

clean the comment and salt value

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
Why it was queued
access controlcryptography-sensitive pathsigning or wallet path
AI analysis · Moderate 59/100

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 current fielded design, and gen-2, a new production design) in one binary. The patch moves legacy gen-1 key derivation into its own file, adds a gen-2 backend with a different key-derivation scheme, adds lifecycle status pages so interrupted wallet create/change-PIN/delete operations can be safely resumed or erased at boot, and adds UI flows for weak-passcode warnings and a 'forget password' ownership-proof step. It also gates the legacy page-8 wipe to gen-1 only so it cannot accidentally erase gen-2 data. The commit is described by its authors as scaffolding with no runtime change for current gen-1 devices, but it does add substantial new crypto and state-machine code.

Security candidatefix buildby ww3512687 · 5e26e323 · Jun 29, 2026 · 1 fileMessage 0 · OpaqueTriage 12Details
Commit message · ww3512687

fix build

0/100 · OpaqueMessage clarity
! Very short subject! Too few words to establish purpose! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
boot or update path
Security candidatefix(zcash): sign shielded PCZTs without RoleSigner to fit the device stackby Adam Tucker · 11592ebc · Jun 26, 2026 · 3 filesMessage 100 · StrongModerate 54Details
Commit message · Adam Tucker

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

The cypherpunk shielded PCZT signing path used the upstream pczt RoleSigner,
which reconstructs a full TransactionData for every bundle just to compute the
32-byte ZIP-244 sighash. That setup alone needs ~61 KB of stack, well over the
26 KB UiDisplayTask budget, so signing an Orchard->Ironwood migration batch
overflowed the task stack and the device reset into firmware verification.

Replace RoleSigner with the lean signer used before Ironwood: low_level_signer
driven in place, with the sighash computed by the in-repo byte-level
pczt_ext::shielded_sig_commitment instead of a TransactionData rebuild. Extend
that hasher to the v6 (NU6.3) Orchard and Ironwood commitment domains so it
stays correct for migration transactions. This restores the pre-Ironwood
signing footprint (~45 KB on host, the same as the path that already signs
shielded Orchard on shipping Keystones) while supporting Ironwood.

pczt_ext (zcash_vendor):
- digest_orchard_v6 / digest_ironwood_v6 and a v6 branch in
shielded_sig_commitment: v6 bundle personalizations, anchor omitted from the
effects digest, the 5-node to_hash_v6 layout.
- sign_ironwood driver mirroring sign_orchard; a shared sign_orchard_action
that defers the sign/skip decision to the signer (wallet-controlled
zero-value spends are still signed; tx_modifiable is cleared only when a new
signature is added).

app_zcash:
- A lean SeedSigner (PcztSigner) deriving keys and signing actions in place,
preserving the strict per-action validation from the removed collect path
(ZIP 32 derivation shape, dummy_sk rules, already-signed skip, per-account
key cache, PcztNoMyInputs).
- validate_supported_pczt rejects v6 PCZTs carrying a Sapling spend: the lean
hasher implements the Orchard/Ironwood v6 domains but not the v6 Sapling-spend
domain (distinct noncompact personalization, anchor omitted). Keystone never
signs Sapling spends; Sapling outputs are version-independent and remain
supported.

Oracle tests assert the lean sighash is bit-exact against
RoleSigner::shielded_sighash for Orchard-only, dual-pool migration, and
Ironwood-spend shapes, so any upstream sighash change fails CI rather than
producing wrong on-device signatures.

100/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarymemory safetydefensive validationsigning or wallet path
AI analysis · Moderate 54/100

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-to-Ironwood migration. The patch replaces it with a leaner, in-house signer and adds the new v6/Ironwood hash logic needed to keep signatures valid. It also rejects v6 transactions containing Sapling spends because the lean signer does not yet support that specific hash domain.

Security candidatefix: remove duplicate SIG_BACKGROUND_UR_GENERATE_FAIL enumeratorby Adam Tucker · 1a8cfcb4 · Jun 24, 2026 · 1 fileMessage 85 · StrongTriage 18Details
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
Security candidatechore: point ur-registry at upstream SDK revby Adam Tucker · ef575e15 · Jun 24, 2026 · 2 filesMessage 80 · StrongTriage 18Details
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
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.

Security candidateBump Zcash deps to Ironwood revisions + mechanical API migrationsby Adam Tucker · 4487747f · Jun 23, 2026 · 10 filesMessage 83 · StrongTriage 18Details
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
Security candidatefix ar bugsby ww3512687 · 26fffdc3 · Jun 22, 2026 · 9 filesMessage 0 · OpaqueTriage 15Details
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
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 · ThinTriage 15Details
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
Security candidateleap sunsetby ww3512687 · 920e9830 · May 22, 2026 · 23 filesMessage 0 · OpaqueInformational 15Details
Commit message · ww3512687

leap sunset

0/100 · OpaqueMessage clarity
! Very short subject! Too few words to establish purpose! No meaningful explanatory body! Opaque security-relevant change
Why it was queued
cryptography-sensitive pathsigning or wallet pathparser or protocol path
AI analysis · Informational 15/100

This commit removes support for the 'Leap' wallet from the Keystone 3 firmware. It deletes the Leap wallet icon and asset, removes Leap-related text strings from Chinese, Japanese, and Korean font files, and updates the Rust dependency versions for the UR (Uniform Resources) parsing libraries used by the firmware. There is no indication of a security fix or vulnerability being patched.