TZ
← All projectsTrezor

Trezor firmware

Firmware monorepo for Trezor One, Model T, and Safe devices.

BitcoinHardware walletsNormal
Repository coverage

2650 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.

915security candidates307second-pass queue1045AI analyses
338commits · 30 days
577commits · 60 days
1352commits · 180 days
2649commits · 365 days
Backfill bands
Aug 5 → Feb 61298 seen115 candidatesComplete
Feb 6 → Jun 6775 seen58 candidatesComplete
Jun 6 → Jul 6217 seen13 candidatesComplete
Jul 6 → Aug 5360 seen54 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.

66/100 average clarity
470Strong · 80–100
1316Adequate · 60–79
859Thin · 40–59
5Opaque · 0–39
Read the scoring rubric →
Developer activity

Who is changing the project?

Public Git author strings; identities are not independently verified.

DeveloperCommitsCandidatesAnalyzedHigh riskMessage avg.
Andrew Kozlik702427266
Roman Zeyde566176208171
tychovrahe292104109161
PrisionMike945975173
Jakub Janků19915184
Martin Pastyřík2389173
cepetr1968282059
Ioan Bizău23076116059
obrusvit2137683064
M1nd3r2067177071
Lukas Bielesch846767067
Martin Milata1744646063
Analysis record

Published AI watches

Last scanned 1 hour, 1 minute ago

Informational 18 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): remove sha1 from regular FW

This commit removes the SHA-1 hashing function from the regular Trezor firmware. SHA-1 is an old, weak hash algorithm that is no longer considered secure for sensitive uses. The change deletes the code that exposes SHA-1 to apps running on…

Removal of a deprecated cryptographic primitive (SHA-1) from the firmware API surfaceReduction of attack surface and prevention of future misuse of a collision-vulnerable hashNo direct vulnerability patch or memory-safety bug is present in the diff
16d15774by M1nd3r+0−2006 files
No security note in commit
Low 27 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(crypto): pass static public key to `noise_xxpsk3_*_init()`

This commit changes how a cryptographic library sets up secure connections. Previously, the code automatically calculated the public key from the private key. Now, the caller must provide the public key directly. This is a code-quality ref…

Cryptographic key handling changed: public key is now supplied rather than derivedPotential reduction of key-mismatch risk if caller provides correct public keyNew null-pointer check added for static_public_key
1b3128a4by Ondřej Vejpustek+20−92 files
No security note in commit
Informational 15 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(crypto): change order of parameters

This commit simply reorders the arguments of an internal function called dh() and updates every place that calls it. The actual math and security behavior are unchanged; it is a code cleanup with no security effect.

33a119eeby Ondřej Vejpustek+15−151 file
No security note in commit
Informational 15 AI analysisMessage 47 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(crypto): prefix enums

This commit simply renames two groups of internal status labels (called enums) in the Trezor firmware's cryptographic code. The old names like WAITING_FOR_REQUEST1 were shared between two different parts of the code, so the developer gave …

f1c74046by Ondřej Vejpustek+26−222 files
No security note in commit
Low 37 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(crypto): prevent calling `memzero(NULL, ...)`

This commit fixes three places in the Trezor firmware's cryptographic code where a memory-clearing function could be called with a NULL pointer. In practice, passing NULL to memzero is harmless on Trezor's platform (it does nothing), but i…

NULL pointer passed to memory-zeroing helper in cryptographic codeUndefined behavior in C standard library contractDefensive hardening in Noise protocol implementation
0394e934by Ondřej Vejpustek+11−51 file
No security note in commit
Informational 18 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(crypto): return remote static key from `noise_xxpsk3_*_handle_*()`

This commit is a code cleanup (refactor) for the cryptographic handshake code used in Trezor devices. It changes how the other party's long-term public key is returned to the caller: instead of storing it inside an internal state structure…

Removal of long-term public key storage from internal handshake stateCaller-supplied output buffer for remote static public key reduces internal secret retentionError-path memzero of returned key material on failure
3ead1aa6by Ondřej Vejpustek+79−423 files
No security note in commit
Informational 17 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(xtask): introduce project-toml build-options

This commit is a build-system refactoring for Trezor firmware. It moves the mapping of command-line build options to Rust/cargo features out of hard-coded Rust logic and into per-project TOML files. It also adds a small change so debug bui…

Build-option mapping now lives in project.toml files, increasing the attack surface for supply-chain/build-configuration tamperingMakefile change automatically enables debug-link for PYOPT=0 debug buildsValidation added to reject storage_insecure_testing_mode in production builds
d44de007by cepetr+681−40817 files
No security note in commit
Informational 15 AI analysisMessage 67 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

test(ethereum): fix incorrect address checksum

This commit only updates test data. It corrects the capitalization (checksum) of Ethereum addresses used in automated tests and refreshes the expected screen-shot hashes those tests compare against. There are no changes to the actual Trezo…

2b1938ccby Tomas Martykan+52−523 files
No security note in commit
Low 33 AI analysisMessage 67 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(python/trezorlib): enable entropy check on T1 by default

This commit changes the Trezor Python library so that, when setting up a Trezor Model One (the original Trezor 1 device), it now performs an entropy check by default if the device runs firmware 1.13.1 or newer. Previously, the library only…

Enables a previously disabled security/validation feature (entropy check) for a specific device modelAdds version-gated behavior to avoid errors on older firmwareDefensive hardening of wallet setup randomness verification
a4af9107by Andrew Kozlik+10−42 files
No security note in commit
Informational 15 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): remove scons related files

This commit is a routine cleanup that removes the old SCons build system files from the Trezor Core firmware repository. It deletes Makefiles, SConscripts, and related Python helper scripts, but does not change any firmware source code, cr…

a4b25c31by cepetr+5−927554 files
No security note in commit
Informational 22 AI analysisMessage 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): assorted micropython-1.28.0 fixes

This commit updates Trezor's embedded MicroPython interpreter from an older version to 1.28.0. It pulls in several upstream MicroPython bug fixes, including stricter buffer-size checks for converting integers to bytes, a new stack-safety A…

Synchronizes upstream MicroPython fixes that include buffer-size and stack-safety hardeningPrevents Ctrl+C interruption of frozen boot code, reducing denial-of-service/control-flow risk during bootFixes sys.stdout.buffer.write() return value, which could affect code relying on correct I/O semantics
7ba7879dby Martin Milata+36−4012 files
No security note in commit
Informational 15 AI analysisMessage 70 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): use mp_obj_new_str_from_cstr

This commit is a simple code cleanup that replaces a common MicroPython string-creation pattern with a new helper function. It does not change what the code does, only how it is written. There is no security issue visible in the change.

6a889e6aby Martin Milata+3−33 files
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): replace hexlify with bytes.hex()

This is a large but straightforward internal cleanup: the project switched from using the MicroPython `ubinascii` module's `hexlify`/`unhexlify` functions to the standard Python `bytes.hex()` and `bytes.fromhex()` methods. The change remov…

44aa469eby Martin Milata+1334−1383120 files
No security note in commit
Informational 18 AI analysisMessage 70 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): replace m_new_obj_with_finaliser

This commit is a routine code cleanup in the Trezor firmware's embedded MicroPython modules. It replaces an older, two-step object allocation pattern with a newer helper that allocates memory and sets the object type in one step. The chang…

No security-relevant logic changes observedNo input validation changesNo memory safety bug fixes (e.g., no overflow, use-after-free, or uninitialized memory fixes)
142794eaby Martin Milata+40−5619 files
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): bundle the utimeq module

This commit is a routine maintenance refactor. MicroPython removed its built-in 'utimeq' module, so Trezor copied the same code into its own firmware tree and renamed it to 'timeq'. There is no security bug being fixed and no new vulnerabi…

617bc806by Martin Milata+284−2211 files
No security note in commit
Informational 17 AI analysisMessage 70 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): use mp_obj_new_str_from_vstr

This is a code cleanup change in Trezor's firmware that swaps one MicroPython internal helper for another. It replaces calls that create byte or string objects from a vstr buffer with newer, purpose-built helpers. The commit message says t…

Refactor only: helper function renames with equivalent semanticsNew str helper adds UTF-8 validation; bytes helper does not validateNo input validation, length, or error-handling changes observed
7ea11191by Martin Milata+72−7433 files
No security note in commit
Informational 15 AI analysisMessage 85 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): switch to slots-based mp_obj_type_t

This commit is a routine internal cleanup that switches how Trezor's firmware defines built-in MicroPython object types. It replaces older, manually-written type structures with a newer macro provided by the upstream MicroPython project. T…

ab51798fby Martin Milata+163−16624 files
No security note in commit
Informational 15 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core/rust): bindgen wrapper for calling static micropython functions

This commit is a straightforward internal code refactor. It adds a small C wrapper file so that Rust code can call two specific internal MicroPython functions that are declared as static/inline in headers. There is no user-facing change, n…

d5121d92by Martin Milata+20−06 files
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

build(core): adjust mpy-cross paths

This commit is a routine build-system update for the Trezor firmware. It changes where the build process looks for the MicroPython cross-compiler binary (mpy-cross) and synchronizes a configuration header with newer MicroPython code. There…

2ef70e16by Martin Milata+18−264 files
No security note in commit
Low 30 AI analysisMessage 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

build(core): collect micropython GC root pointers

This commit updates the Trezor firmware build system to use a newer MicroPython mechanism for tracking special memory pointers called 'root pointers.' It removes hard-coded lists of these pointers from configuration files and instead colle…

GC root pointer handling changedBuild system now auto-collects root pointers instead of hard-coding themRemoves manual MICROPY_PORT_ROOT_POINTERS lists
fc128f3dby Martin Milata+75−107 files
No security note in commit
Repository ledger

Explore captured commits

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

AI review queuedfix(solana): show `source_account` when approving a delegateby Jakub Janků · 13abf4de · Jul 23, 2026 · 3 filesMessage 97 · StrongLow 49Details
Commit message · Jakub Janků

fix(solana): show `source_account` when approving a delegate

The Solana Token programs provide two instructions for approving a
delegate for an account: `Approve` and `ApproveChecked`. The former
is shown on trezor as deprecated because it doesn't contain any
information about the token mint and decimals. However, it is still
important to show the source account for which we are approving the
delegate --- otherwise, if the user has multiple token accounts,
they may unknowingly approve the delegate for a different account
than they intended. Note that the `source_account` IS shown when
confirming the latter, checked, instructions.

[no changelog]

(cherry picked from commit c881bfedc5c556cce5884fd975b1b3993a34dbfe)

97/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
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Low 49/100

This update fixes a display issue in Trezor's Solana token support. When a user approves a delegate (someone who can spend tokens on their behalf) using the older 'Approve' instruction, the device screen previously did not show which token account was being delegated. If a user owns several token accounts, they could accidentally approve the wrong one. The fix adds the source account to the on-screen confirmation, matching what the newer 'ApproveChecked' instruction already shows.

Security candidatefix(solana): show threshold on multisig initby Jakub Janků · f5305c2f · Jul 23, 2026 · 3 filesMessage 85 · StrongLow 49Details
Commit message · Jakub Janků

fix(solana): show threshold on multisig init

The current flow makes it appear as if the signature scheme is an
N-out-of-N multisig (i.e., all signers are required), when in fact
the scheme is an M-out-of-N threshold scheme. This can give the user
a false sense of security, in particular when M=1 and anyone from
the list of signers can approve token-related operations. This commit
displays the value M to the user.

[no changelog]

(cherry picked from commit 1e5c4edbd7e9073f271f0cdf1bf744cbe0f82c9b)

85/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 49/100

This commit fixes a misleading display on Trezor hardware wallets when a user initializes a Solana multisig account. Previously, the device only showed the list of possible signers without showing how many signatures were actually required to approve transactions. This made a 1-out-of-N multisig look like an N-out-of-N multisig, which could trick a user into thinking funds or token operations were safer than they really were. The patch now displays the threshold number (M) so the user sees, for example, '1 of 3 signers required' rather than just '3 signers'.

AI review queueddocs(core,prodtest): changelog update core v2.12.2 prodtest v0.3.8by PrisionMike · f7bd2917 · Jul 23, 2026 · 24 filesMessage 77 · AdequateTriage 0Details
Commit message · PrisionMike

docs(core,prodtest): changelog update core v2.12.2 prodtest v0.3.8

(cherry picked from commit 2549fb7f8ff7e758e63036a349284927bd55e4f2)

77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
second-pass: unusually broad change
Security candidatefix(solana): check owner in predefined flowby Jakub Janků · 5d781acc · Jul 23, 2026 · 2 filesMessage 80 · StrongLow 35Details
Commit message · Jakub Janků

fix(solana): check owner in predefined flow

Only the Stake11111111111111111111111111111111111111 program makes
sense as the owner in the predefined staking flow.

Note that this should not be exploitable as the transaction should
fail on chain --- the Solana runtime should enforce that the Stake
program is the owner of the account that it is about to manipulate.
However, it is better to not hide it from the user that the transaction
contains unexpected params.

[no changelog]

(cherry picked from commit ea194d6eedea43c35c1c98ecf521a11e8554b960)

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
explicit security languagesigning or wallet path
AI analysis · Low 35/100

This update tightens a Solana staking flow in Trezor firmware so that the device now verifies the staking account is owned by the legitimate Stake program before showing the user a friendly confirmation screen. Previously, a crafted transaction with a different owner could slip through the predefined staking prompt, though the Solana network itself would likely reject it. The change also fixes a missing display option in the claim flow.

Security candidatefix(clear_signing): parse arrays of static structs per the ABI spec.by PrisionMike · 6cf0c47d · Jul 23, 2026 · 5 filesMessage 100 · StrongModerate 62Details
Commit message · PrisionMike

fix(clear_signing): parse arrays of static structs per the ABI spec.

Unify head handling in ABIValue.parse(): a static value is encoded in
place (head_size bytes), a dynamic value's head is one word holding its
body offset, relative to the enclosing block. Subclasses now implement
only parse_body(). This replaces the four-branch isinstance dispatch in
Array and the two-mode Tuple.parse.

Previously the Array unconditionally dereferenced element heads,
assuming every struct element is a dynamic type, and from_proto
compensated by mislabeling array-nested tuples as is_dynamic=False
("don't dereference again"). That pair is correct for dynamic structs
(e.g. LiFi's, with bytes callData) but misparses arrays of fully static
structs, whose elements are canonically encoded in place at a stride of
the struct size, with no offsets at all.

is_dynamic is now the truthful, type-level ABI property everywhere:
the four LiFi array-nested tuples become is_dynamic=True, and
from_proto derives the flag for array-nested tuples from their fields
(the wire flag stays ignored in that position, as it always was).

The two hand-crafted vectors for the debug paths descriptor encoded the
old non-canonical layout (offset heads for a static struct array) and
are re-encoded canonically; the JSON fixture's signature is recomputed
accordingly. Note the signature assertions cannot catch encoding
regressions (blind-signing fallback signs the same bytes); the new
array-of-static-structs unit test and the token-request assertions in
test_definitions_request.py are the real guards.

[no changelog]

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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 boundarysigning or wallet path
AI analysis · Moderate 62/100

This commit fixes a bug in how Trezor firmware parses Ethereum transaction data for 'clear signing' of complex smart-contract calls. The parser previously misread arrays of simple structs (e.g., lists of token-swap details) because it assumed every struct element was stored via an offset pointer, which is only true for structs containing variable-length data. With the correct ABI behavior, static structs are now read directly in sequence. The bug could cause Trezor to display wrong values or fall back to blind signing, but it does not leak private keys or directly steal funds. The fix also hardens parsing against malformed empty structs and out-of-bounds reads.

Security candidatefix(clear_signing): fix bytes[] and strings[] parsing. [no changelog]by PrisionMike · 6eb57726 · Jul 23, 2026 · 1 fileMessage 77 · AdequateModerate 59Details
Commit message · PrisionMike

fix(clear_signing): fix bytes[] and strings[] parsing.
[no changelog]

77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Moderate 59/100

This commit fixes how Trezor firmware parses certain Ethereum transaction data types—specifically arrays of byte blobs (bytes[]) and arrays of strings (string[])—when showing clear signing details on the device screen. Before the fix, the code would follow an offset pointer twice, likely reading the wrong memory location and producing incorrect decoded values. That could cause the Trezor to display misleading transaction details to the user, potentially tricking them into approving a transaction that does what the screen does not show.

Security candidatedocs(ethereum): document clear-signing ABI calldata parsing.by PrisionMike · 5609a3ed · Jul 23, 2026 · 1 fileMessage 95 · StrongInformational 15Details
Commit message · PrisionMike

docs(ethereum): document clear-signing ABI calldata parsing.

Covers the static/dynamic head rule, per-node body layouts, static
tuple and static-struct-array encodings, a word-by-word decode of the
paths-descriptor test vector, failure behavior (blind-signing
fallback), and which test exercises which encoding shape.

[no changelog]

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

95/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
Why it was queued
signing boundaryfuzzing or regression evidencedocumentation-only discount
AI analysis · Informational 15/100

This commit only adds documentation. It explains how Trezor's Ethereum app decodes smart-contract call data for clear-signing and how the tests cover different data layouts. No code behavior changes.

Security candidaterefactor(clear_signing): remove dead parse_uint256_array and unreachable guards.by PrisionMike · 9d516f9f · Jul 23, 2026 · 1 fileMessage 85 · StrongInformational 13Details
Commit message · PrisionMike

refactor(clear_signing): remove dead parse_uint256_array and unreachable guards.

parse_uint256_array was never constructed by from_proto nor by any built-in
definition. It could not have worked if wired in: a dynamic tuple field goes
through _read_dynamic_data, which reads the 32-byte prefix as a byte length,
while an array's prefix is an element count.

With it gone, no Parser returns a container, so the
isinstance(v, (tuple, list)) -> NotImplementedError guards in Tuple.parse are
unreachable; the Parser type alias is tightened to Callable[[memoryview], Value]
to match.

[no changelog]

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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 boundarysigning or wallet path
AI analysis · Informational 13/100

This commit removes unused code and unreachable safety checks from the Ethereum clear-signing module. The removed function (parse_uint256_array) was never actually used, and the type-check guards it supported could never be triggered. There is no evidence this change fixes or introduces a security vulnerability; it is a code cleanup.

Security candidaterefactor(clear_signing): rename for readability, no behavior change.by PrisionMike · 87ac4b19 · Jul 23, 2026 · 2 filesMessage 85 · StrongInformational 15Details
Commit message · PrisionMike

refactor(clear_signing): rename for readability, no behavior change.

* _EVM_WORD_SIZE = const(32): ABI encoding is aligned to the 256-bit EVM
word - every atomic value, offset, length prefix and head slot occupies
one word. Replaces the magic 32s in the parsing code.
* Dynamic -> DynamicLeaf: "dynamic" is an ABI property that arrays and
bytes/string-bearing tuples also have; the class only represents the
dynamic leaf types (bytes, string).
* i_pointer -> element_head_offset, hoist elements_start in
Array._parse_body; ABI spec link on ABIValue.

[no changelog]

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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 boundarysigning or wallet path
AI analysis · Informational 15/100

This is a pure code cleanup: it replaces hard-coded '32' values with a named constant, renames a class from 'Dynamic' to 'DynamicLeaf' for clarity, and renames a variable for readability. The commit message explicitly says 'no behavior change' and there is no functional change visible in the diff.

Lower-prioritychore(deps): bump libusb1 to v3.4.0by M1nd3r · f0db6145 · Jul 23, 2026 · 2 filesMessage 80 · StrongTriage 0Details
Commit message · M1nd3r

chore(deps): bump libusb1 to v3.4.0

- Updated libusb1 v3.3.1 -> v3.4.0 to resolve Python 3.14 related deprecation warnings.
- Removed now unnecessary exclusion of `cryptography` from 30-day moratorium.

[no changelog]

80/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
AI review queuedchore(python): make merkle tree balancedby M1nd3r · 6c40c944 · Jul 23, 2026 · 4 filesMessage 57 · ThinInformational 19Details
Commit message · M1nd3r

chore(python): make merkle tree balanced

[no changelog]

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 analysis · Informational 19/100

This commit changes how Trezor's Python library builds Merkle trees so that the trees are balanced. Previously, leftover odd nodes were pushed upward, which could make some membership proofs much longer than others. The change is described as a routine improvement ('chore') with no security claim by the vendor. There is no direct evidence in the commit that this fixes an active vulnerability, but unbalanced Merkle trees can theoretically leak information about which item is being proved or create subtle correctness/performance issues in protocols that assume balanced trees.

Lower-priorityrefactor(core): make wireless charging driver optionalby tychovrahe · 340dbf7e · Jul 23, 2026 · 9 filesMessage 62 · AdequateTriage 0Details
Commit message · tychovrahe

refactor(core): make wireless charging driver optional

[no changelog]

62/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Security candidatefeat(common,core,python,tests): add support for StellarInvokeHostFunctionOp.by Jun Luo · 05344ecd · Jul 23, 2026 · 43 filesMessage 72 · AdequateLow 36Details
Commit message · Jun Luo

feat(common,core,python,tests): add support for StellarInvokeHostFunctionOp.

72/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathboot or update pathauthentication path
AI analysis · Low 36/100

This commit adds support for signing Stellar Soroban smart-contract transactions on Trezor hardware wallets. It introduces new message types, on-device confirmation screens, and serialization logic for complex contract arguments and authorization trees. The change is a feature addition rather than a bug fix; it does not by itself fix a known vulnerability, but it does expand the attack surface of the Stellar signing flow and includes several security-relevant design choices (e.g., showing externally signed authorizations only on request).

Security candidaterefactor(core): rename `MsgInSignTx` to `HandlerChainIdArg`by Roman Zeyde · fc8cc311 · Jul 23, 2026 · 1 fileMessage 85 · StrongInformational 15Details
Commit message · Roman Zeyde

refactor(core): rename `MsgInSignTx` to `HandlerChainIdArg`

`MsgInSignTx` was used for both `with_keychain_from_chain_id`
message handler and by clearsigning-related code.

`with_keychain_from_chain_id` message handler will be used also for
EthereumSignAuth7702, which is not compatible with clearsigning -
so it's better to separate the types.

[no changelog]

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 is a clean internal code rename in the Trezor firmware's Ethereum module. A shared type variable used by two different pieces of code is split into two separate type variables so that a future feature (EthereumSignAuth7702) can use the keychain helper without being incorrectly tied to transaction-signing code. No behavior changes, no bug fixes, and no security issue is present in the diff.

Lower-priorityfix(core): fix storage migrationby cepetr · d589df69 · Jul 23, 2026 · 2 filesMessage 57 · ThinTriage 0Details
Commit message · cepetr

fix(core): fix storage migration

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Security candidatechore(clear_signing): Remove hardcoded LI.FI definitions [no changelog]by PrisionMike · ba9fded8 · Jul 23, 2026 · 6 filesMessage 77 · AdequateInformational 19Details
Commit message · PrisionMike

chore(clear_signing): Remove hardcoded LI.FI definitions
[no changelog]

77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 19/100

This commit removes built-in, hard-coded display rules for the LI.FI swap/bridge protocol from Trezor's Ethereum 'clear signing' feature. It is a feature cleanup, not a fix for a code vulnerability. The change means Trezor will no longer automatically show friendly LI.FI transaction labels unless the user or wallet later loads an external definition file. The commit itself does not introduce a security bug, but it slightly changes how users verify LI.FI transactions on the device screen.

Security candidatetests(clear_signing): add external definition fixtures. [no changelog]by PrisionMike · 97eaee6c · Jul 23, 2026 · 26 filesMessage 75 · AdequateInformational 15Details
Commit message · PrisionMike

tests(clear_signing): add external definition fixtures.
[no changelog]

75/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This commit is purely a test-data update for Trezor's Ethereum 'clear signing' feature. It removes old built-in test fixtures and adds new externally-supplied token/chain definition files so the test suite can exercise how the device handles user-provided definitions. There is no change to firmware, wallet logic, or security-critical code.

Security candidatetests(prodtest): introduce prodtest device testsby M1nd3r · 9a271a98 · Jul 22, 2026 · 32 filesMessage 70 · AdequateInformational 15Details
Commit message · M1nd3r

tests(prodtest): introduce prodtest device tests

[no changelog]

Assisted-by: Claude, Opus 4.8

70/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
authentication path
AI analysis · Informational 15/100

This commit only adds automated tests and test-support tooling for Trezor's production-test firmware mode. It does not change the firmware itself, introduce new device commands, or alter how secrets are handled. There is no user-facing security change.

Lower-priorityci: add prodtest device tests jobby M1nd3r · 6a732963 · Jul 22, 2026 · 1 fileMessage 67 · AdequateTriage 0Details
Commit message · M1nd3r

ci: add prodtest device tests job

[no changelog]

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
documentation-only discount
Lower-priorityfeat(prodtest): add `prodtest-model` commandby M1nd3r · c2796b96 · Jul 22, 2026 · 1 fileMessage 57 · ThinTriage 0Details
Commit message · M1nd3r

feat(prodtest): add `prodtest-model` command

[no changelog]

57/100 · ThinMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
Lower-prioritytest(prodtest): mention prodtest-tests in docsby M1nd3r · d256f548 · Jul 22, 2026 · 1 fileMessage 67 · AdequateTriage 0Details
Commit message · M1nd3r

test(prodtest): mention prodtest-tests in docs

[no changelog]

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
documentation-only discount
Lower-prioritychore(ci): show slowest prodtest tests durationby M1nd3r · 67811b94 · Jul 22, 2026 · 1 fileMessage 67 · AdequateTriage 0Details
Commit message · M1nd3r

chore(ci): show slowest prodtest tests duration

[no changelog]

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
documentation-only discount
Lower-priorityfix(tools): exception for English is no longer necessary in crowdin.py [no changelog]by Michal Kazda · 6801273f · Jul 22, 2026 · 1 fileMessage 77 · AdequateTriage 0Details
Commit message · Michal Kazda

fix(tools): exception for English is no longer necessary in crowdin.py
[no changelog]

77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
Why it was queued
translation-only discount
AI review queuedtest(core): fix Stellar payment request tests.by Jun Luo · e9bd96f3 · Jul 22, 2026 · 2 filesMessage 67 · AdequateInformational 15Details
Commit message · Jun Luo

test(core): fix Stellar payment request tests.

[no changelog]

67/100 · AdequateMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification! No meaningful explanatory body
Why it was queued
signing or wallet pathsecond-pass: security-sensitive path
AI analysis · Informational 15/100

This commit only updates test data and a test assertion for Stellar payment request tests. It does not change any production firmware code, so it has no direct security impact on users.

Security candidatetest(stellar): verify signatures in fixturesby Jakub Janků · 8ea9cc20 · Jul 22, 2026 · 1 fileMessage 95 · StrongInformational 12Details
Commit message · Jakub Janků

test(stellar): verify signatures in fixtures

Instead of relying on the fixtures as the single source of truth,
let's verify the fixtures as well. This should prevent taking a
wrong device-produced signature and declaring it as the correct one
when adding a new fixture.

95/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✓ Names security-relevant behavior explicitly
Why it was queued
signing boundary
AI analysis · Informational 12/100

This commit only changes a test file for Stellar cryptocurrency transaction signing. It adds a check that the expected signatures stored in test fixtures are mathematically valid, so that future tests don't accidentally treat a bad signature as correct. It does not change the actual Trezor firmware code that users rely on, so it has no direct security impact on devices.