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 queue429AI 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.
Jakub Janků1997184
Martin Pastyřík2385173
Roman Zeyde56617677071
tychovrahe29210449061
cepetr1968224059
Ioan Bizău2307644059
obrusvit2137627064
M1nd3r2067131071
Lukas Bielesch846739067
PrisionMike945948073
Martin Milata1744620063
Ondřej Vejpustek95345060
Analysis record

Published AI watches

Last scanned 46 minutes ago

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 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 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 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): get rid of the STATIC macro

This commit is a large but purely mechanical code cleanup: it replaces the custom STATIC macro with the standard C keyword static across many MicroPython module files. There is no change to program logic, security boundaries, or behavior. …

053def4cby Martin Milata+789−79757 files
No security note in commit
Informational 15 AI analysisMessage 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): fix renamed micropython modules

This commit is a routine code cleanup that updates Trezor firmware to match a newer MicroPython version where built-in module names dropped the 'u' prefix (for example, 'uos' became 'os' and 'ustruct' became 'struct'). It renames imports, …

e1edbee0by Martin Milata+86−11727 files
No security note in commit
Informational 15 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): bump version to 2.12.5

This commit only updates the firmware version number from 2.12.4 to 2.12.5 in the source code and translation files. It does not change any security-related logic, fix any bug, or alter any cryptographic behavior. It is a routine release b…

82c04645by Martin Milata+10−108 files
No security note in commit
Informational 15 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): build trezor_lib with xbuild

This is a routine build-system cleanup for the Trezor firmware. It switches the internal 'trezor_lib' Rust crate to be built with the project's own 'xbuild' tool, removes transitional feature flags, and reorganizes Cargo.toml files. There …

9ba7ee1bby cepetr+597−86816 files
No security note in commit
Informational 15 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(nordic): add nrf/ble functionality to T3T2

This commit adds Bluetooth Low Energy (BLE) support for the Trezor T3T2 hardware model. It introduces new board configuration files, pin mappings, build scripts, and firmware binaries for the Nordic nRF54LS05A BLE radio used in T3T2. There…

d8b4daa6by tychovrahe+526−922 files
No security note in commit
Informational 15 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(core/rust): separate trezor-crypto to its own Rust crate

This commit is a large but straightforward internal refactoring: the cryptographic code is moved from one Rust crate (`rtl`) into a new dedicated crate (`crypto`), and all project dependencies are updated to point to the new crate. The act…

No security-relevant code changes detectedRefactoring only: moving existing crypto wrappers and build logic into a new crateFeature flags and C source lists preserved from the original `rtl` crate
836142c7by matejcik+2213−195139 files
No security note in commit
Informational 17 AI analysisMessage 90 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core/embed): reorganize error handling

This commit is a code cleanup that moves how Trezor firmware handles fatal errors and shutdowns between its internal software layers. It does not add new user-facing features or change security protections. The main risk is that reorganizi…

Refactor of fatal-error and shutdown code pathsNew noreturn annotations on systask_exit, systask_exit_error, systask_exit_fatal, systask_killRemoval of duplicated test-only system_exit_error/system_exit_fatal implementations
a9dbab53by matejcik+408−32227 files
No security note in commit
Informational 15 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(core/bootloader): correct "Change FW vendor" title

This commit changes a single on-screen label in the Trezor bootloader from lowercase 'Change fw vendor' to uppercase 'Change FW vendor'. It is purely a cosmetic wording fix with no security relevance.

5f756282by Roman Zeyde+1−11 file
No security note in commit
Low 30 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(clear_signing): calldata array support

This commit adds support in Trezor's Ethereum clear-signing feature for transactions that contain multiple embedded subcalls (like a multicall). Previously, only a single embedded call could be clearly displayed. The change lets the device…

New input validation added: callee array length must match subcall array lengthType validation enforced: each subcall blob must be bytes, each callee must be a 20-byte addressGraceful degradation preserved: unparseable subcalls fall back to raw hex display rather than failing the whole transaction
0feb0b96by PrisionMike+186−162 files
No security note in commit
Informational 15 AI analysisMessage 67 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

test(clear signing): multiple calldata

This commit only adds new automated tests for Trezor's Ethereum 'clear signing' feature. It includes a test case for an Aave multi-call transaction, a matching test data blob, and expected screen snapshots for different device models and l…

0de94b8aby PrisionMike+46−64 files
No security note in commit
Informational 19 AI analysisMessage 82 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(clear_signing): double display of amount.

This commit fixes a user-interface bug in Trezor's Ethereum 'clear signing' flow where the transaction's native ETH amount could be shown twice on the device screen. The old code tried to avoid duplication by checking whether an 'AmountFor…

No cryptographic, authorization, memory-safety, or input-validation changesChange is limited to on-screen display deduplication logicNo changelog entry requested by the vendor ('[no changelog]')
ce2282bdby PrisionMike+14−172 files
No security note in commit
Informational 21 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(clear_signing): Add enum formatter - core

This commit adds a new display formatter for Ethereum clear signing. It lets a transaction descriptor map numeric enum values (like 1 or 2) to human-readable labels (like 'stable' or 'variable') on the Trezor screen. The change is purely a…

New formatter raises InvalidFormatDefinition on unexpected/missing enum values, causing fallback to blind signing rather than displaying an untrusted labelDuplicate enum keys are rejected at descriptor decode timeNon-integer enum values are rejected at format time
4b25321cby PrisionMike+131−42 files
No security note in commit
Informational 15 AI analysisMessage 72 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

test(clear_signing): add device test for calldata formatter.

This commit only adds a new automated test case for an existing Ethereum transaction display feature. It does not change any production firmware code, so it cannot introduce a security vulnerability or fix one. It is purely a test-data add…

701624d3by PrisionMike+21−02 files
No security note in commit
Low 39 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(clear_signing): support for calldata formatter. - core changes

This commit adds a new Trezor firmware feature called 'clear signing' for nested Ethereum calls. It lets the device understand when a transaction wraps another contract call (like a router or multicall) and tries to show the user readable …

New nested calldata parsing path with explicit depth cap of 1@.to override to callee to prevent token resolution from pointing at the wrapper contract@.from and @.value rejected in nested parse to avoid displaying confidently wrong sender/value
570eb868by PrisionMike+627−503 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.

Security candidaterefactor(core/stellar): move generic Soroban layout helpers to layout.py.by Jun Luo · 9ce451bd · Jul 28, 2026 · 4 filesMessage 90 · StrongInformational 15Details
Commit message · Jun Luo

refactor(core/stellar): move generic Soroban layout helpers to layout.py.

SCVal formatting and invocation confirmation helpers are used by both
the transaction flow and the standalone authorization signing flow, so
they are no longer operation-specific.

[no changelog]

90/100 · StrongMessage clarity
✓ Specific, 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 boundaryaccess controlsigning or wallet pathauthentication path
AI analysis · Informational 15/100

This commit is a straightforward code cleanup: it moves helper functions for formatting Stellar Soroban smart-contract values and showing confirmation screens from one file to another shared file. No security behavior changes are visible in the diff. The only functional tweak is narrowing an exception handler from a broad 'except Exception' to 'except OverflowError' when formatting timestamps, which is a minor hardening improvement, not a vulnerability.

Security candidatefeat(common,core,python,tests): migrate Soroban authorization to SOROBAN_CREDENTIALS_ADDRESS_V2.by Jun Luo · 0d2cc2ac · Jul 28, 2026 · 13 filesMessage 77 · AdequateLow 29Details
Commit message · Jun Luo

feat(common,core,python,tests): migrate Soroban authorization to SOROBAN_CREDENTIALS_ADDRESS_V2.

[no changelog]

77/100 · AdequateMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Mentions testing or verification✓ Names security-relevant behavior explicitly! No meaningful explanatory body
Why it was queued
access controlcredential or privilege statesigning or wallet path
AI analysis · Low 29/100

This commit updates Trezor's Stellar/Soroban smart-contract support to match a newer Stellar protocol version (Protocol 27). It renames the credential type from the older SOROBAN_CREDENTIALS_ADDRESS to SOROBAN_CREDENTIALS_ADDRESS_V2 and updates the related field name from address to address_v2 across the firmware, Python library, Rust client, and tests. The older credential type is intentionally no longer supported. There is no direct evidence in the commit of a security vulnerability being fixed; it reads as a routine protocol compatibility update.

Security candidatefeat(clear_signing): support sliced paths.by PrisionMike · 017cf136 · Jul 27, 2026 · 6 filesMessage 72 · AdequateLow 31Details
Commit message · PrisionMike

feat(clear_signing): support sliced paths.

- This should enable deleting 1inch builtin addresses. (QA)
[no changelog]

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

This commit adds a new feature to Trezor's Ethereum 'clear signing' system that lets wallet definitions extract a slice of bytes from a numeric parameter. For example, a 32-byte number that secretly packs an address into its last 20 bytes can now be sliced so the device shows only the real address. The change is described as a feature, not a bug fix, and there is no vendor statement that it fixes a security vulnerability. It does reduce one real risk: users could otherwise be tricked into approving transactions where hidden extra bits in a number change the meaning of what they see on screen.

Security candidatefeat(core): confirm ERC-8213 calldata digest if all data is shownby Roman Zeyde · 10c82edd · Jul 27, 2026 · 22 filesMessage 62 · AdequateLow 35Details
Commit message · Roman Zeyde

feat(core): confirm ERC-8213 calldata digest if all data is shown

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
cryptography-sensitive pathsigning or wallet pathboot or update path
AI analysis · Low 35/100

This commit adds a new user-facing safety feature for Trezor hardware wallets when signing Ethereum transactions. If the user chooses to view all the raw transaction data (calldata), the device will now also show a final cryptographic hash (digest) of that data, based on a community standard called ERC-8213. This helps users verify that what they saw on screen matches what is actually being signed, reducing the risk of hidden malicious changes in very long data fields. It is a defensive improvement, not a fix for an active bug or vulnerability.

Security candidatetest(core/ethereum): don't duplicate "skip_models" for EIP-7702 testsby Roman Zeyde · 1f20560e · Jul 27, 2026 · 1 fileMessage 87 · StrongInformational 15Details
Commit message · Roman Zeyde

test(core/ethereum): don't duplicate "skip_models" for EIP-7702 tests

It will be supported on T2T1.

[no changelog]

87/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification
Why it was queued
signing or wallet pathauthentication path
AI analysis · Informational 15/100

This commit only changes a test data file. It removes duplicate 'skip_models' entries from Ethereum EIP-7702 test fixtures so that the T2T1 model is no longer excluded from these tests. There is no change to firmware code, no security fix, and no user-facing behavior change.

Security candidatefeat(core): support EIP-7702 authorization/revocationby Roman Zeyde · 0cd72f03 · Jul 27, 2026 · 15 filesMessage 98 · StrongLow 36Details
Commit message · Roman Zeyde

feat(core): support EIP-7702 authorization/revocation

Figma: https://www.figma.com/design/3wF1eh3Ftj0XGX7wFmev8t/EIP-7702?node-id=6358-2421&t=vo7F599zB7Cp9K5D-0

Changelog entry has been updated in a previous commit.

[no changelog]

98/100 · StrongMessage clarity
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
access controlcryptography-sensitive pathsigning or wallet pathauthentication path
AI analysis · Low 36/100

This commit adds support for signing Ethereum EIP-7702 authorizations and revocations on Trezor hardware wallets. EIP-7702 lets an Ethereum account temporarily delegate control to a smart contract. The code adds a new signing workflow, user confirmation screens, and command-line support. It is a feature addition, not a fix for a known vulnerability. The main security consideration is that authorizing delegation is a powerful operation, so the code requires users to disable strict safety checks and confirm on the device, while revocation remains allowed under strict checks.

Security candidatedocs(core): update EIP-7702 changelog entryby Roman Zeyde · d12287b5 · Jul 27, 2026 · 2 filesMessage 93 · StrongInformational 15Details
Commit message · Roman Zeyde

docs(core): update EIP-7702 changelog entry

It allows creating an `authorization_list` tuple,
but doesn't include set-code transaction signature:
https://eips.ethereum.org/EIPS/eip-7702#set-code-transaction

93/100 · StrongMessage clarity
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundaryaccess control
AI analysis · Informational 15/100

This commit only edits changelog text. It adds a more precise description of an already-released Ethereum feature (EIP-7702 support) and removes an older, less accurate changelog line. No code, transaction logic, or cryptographic behavior is changed, so there is no security issue in this commit itself.

Security candidatefeat(clear_signing): adding some more simple types.by PrisionMike · 1e146d45 · Jul 27, 2026 · 8 filesMessage 62 · AdequateLow 32Details
Commit message · PrisionMike

feat(clear_signing): adding some more simple types.

mostly bytesN type.
[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
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 32/100

This commit adds support for more Ethereum data types in Trezor's clear signing feature. It introduces parsing for signed 160-bit integers (int160) and fixed-size byte arrays of various lengths (bytes4, bytes8, bytes16, bytes20, bytes32). The code also refactors existing parsers to use shared factory functions. The changes are primarily feature additions with built-in validation checks, and there is no direct evidence in the commit of a security vulnerability or fix.

Security candidatefeat(clear_signing): update defs with providersby PrisionMike · 8698d011 · Jul 27, 2026 · 4 filesMessage 57 · ThinInformational 19Details
Commit message · PrisionMike

feat(clear_signing): update defs with providers

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

This commit updates the Trezor Ethereum 'clear signing' feature so that when a known DeFi contract (like 1inch or Uniswap) is recognized, the device screen shows the provider's human-readable name (e.g., '1inch Aggregation Router V6') instead of just a raw address or a generic vault label. It also updates some URL comments to point to the community ERC-7730 registry rather than Ledger's copy. There is no obvious security vulnerability in the change; it is a user-experience improvement for transaction clarity.

Security candidatefeat(clear_signing): externalise provider namesby PrisionMike · 0a882a4a · Jul 27, 2026 · 6 filesMessage 57 · ThinInformational 17Details
Commit message · PrisionMike

feat(clear_signing): externalise provider names

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

This commit adds a new optional 'provider_name' field to the data structure used for Ethereum 'clear signing' on Trezor devices. When a provider name is supplied, the device will show that name instead of the usual recipient address lookup during transaction confirmation. The change itself is a feature addition, but it creates a new channel where a connected computer could tell the Trezor screen to display an arbitrary label for the recipient. There is no evidence in the commit that the input is validated, length-limited, or checked against the actual blockchain address, which could allow a malicious or compromised host application to mislabel a transaction recipient.

Security candidatefeat(clear_signing): WETH wrap and depositby obrusvit · fdbfc031 · Jul 26, 2026 · 6 filesMessage 57 · ThinInformational 20Details
Commit message · obrusvit

feat(clear_signing): WETH wrap and deposit

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

This commit adds user-friendly on-screen labels for wrapping and unwrapping Ether using the popular WETH token contract on several Ethereum-like networks. It does not change transaction security rules; it only makes the device show clearer messages such as 'Wrap ETH to WETH' instead of raw contract data. There is no indication of a vulnerability being fixed.

Security candidatefeat(solana): migrate to off-chain message signing v1by Jakub Janků · d289db4b · Jul 24, 2026 · 24 filesMessage 100 · StrongLow 39Details
Commit message · Jakub Janků

feat(solana): migrate to off-chain message signing v1

This commit completely removes support for Solana Off-Chain Message
Signing (OCMS) v0. This change follows the decision by Solana Foundation
(SF) to drop support for v0 and focus on v1 [1]. The motivation was that
v0 is flawed and its adoption is close to zero. However, note that not
all parties followed this decision fully: while Wallet Standard supports
v1 only (see [2]), Anza Docs [0] still list v0 as supported for
backwards compatibility.

Support for OCMS v1 is added instead. The protobuf interface is changed:
instead of accepting a serialized message in OCMS format, the device now
expects a structured protobuf message which it then serializes itself.
This again follows a decision by SF to shift the serialization
responsibility from dApps to wallets, see [1].

Moreover, the CLI is simplified as well. The "raw mode" of solana
sign-message (verify-message) commands which allowed the user to pass
a serialized OCMS message (envelope) is removed. This reflets the
protobuf interface change and makes the commands easier to use.

Fixes: https://github.com/trezor/trezor-firmware/issues/7053

[0] https://docs.anza.xyz/proposals/off-chain-message-signing

[1] https://app.notion.com/p/solanafoundation/OCMS-Meeting-June-3-2026-Notes-374d36dad52d80e3a517e5d2a8b29a2c

[2] https://github.com/anza-xyz/wallet-standard/pull/92

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✓ Links an issue, advisory, or supporting reference
Why it was queued
signing boundarysigning or wallet path
AI analysis · Low 39/100

This commit updates Trezor's Solana off-chain message signing feature from an older version (v0) to a newer version (v1). It changes how messages are packaged and sent to the device: instead of the computer app formatting the message and sending raw bytes, the device now receives a structured message and formats it itself. This is a feature migration, not a fix for an active security bug, but it removes support for the older format and changes the command-line interface. The change is described as following Solana Foundation's direction because v0 was considered flawed.

Security candidatechore(core): bump version to 2.12.4by Martin Milata · 98259629 · Jul 23, 2026 · 8 filesMessage 57 · ThinInformational 15Details
Commit message · Martin Milata

chore(core): bump version to 2.12.4

[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 pathboot or update path
AI analysis · Informational 15/100

This commit is a routine version bump from 2.12.3 to 2.12.4 for the Trezor firmware. It only changes the version number in one header file and updates the same version number in translation files, plus refreshes the translation signature metadata. There are no code behavior changes, no bug fixes, and no security-related modifications visible in the diff.

Security candidatefix(solana): show account owner to userby Jakub Janků · f3d5724f · Jul 23, 2026 · 3 filesMessage 80 · StrongHigh 76Details
Commit message · Jakub Janků

fix(solana): show account owner to user

When assigning an `owner` to an account, using the `CreateAccount`,
`CreateAccountWithSeed`, or `AllocateWithSeed` instructions, it is
critical to display the value to the user. Usually, the owner is a
well-known Solana program, such as the System program
(11111111111111111111111111111111) or the Stake program
(Stake11111111111111111111111111111111111111). However, an attacker
could set the value to a Solana program that is controlled by them
and later drain money from the account. This is especially problematic
since the two `CreateAccount` instructions immediately send funds to
the new account.

[no changelog]

(cherry picked from commit d3f24b0f6739cdae93074c5a4f60658e15c456e0)

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

This update fixes a security gap in how Trezor displays Solana transactions. When creating or allocating a Solana account, the device now shows the 'owner' program that will control the new account. Before this change, a malicious owner could be hidden from the user, allowing an attacker to later seize funds sent to the freshly created account. The fix is purely a user-interface change on the hardware wallet screen, not a change to Solana itself.

Security candidatefeat(core): show maximal coordinator fee rateby Roman Zeyde · e369fb17 · Jul 23, 2026 · 18 filesMessage 72 · AdequateInformational 20Details
Commit message · Roman Zeyde

feat(core): show maximal coordinator fee rate

[no changelog]

(cherry picked from commit 85c405ef787a1e815a47f757e1be1b78afbdfbed)

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
cryptography-sensitive pathsigning or wallet pathboot or update pathauthentication path
AI analysis · Informational 20/100

This commit adds a new line on the Trezor screen when authorizing a CoinJoin: it now shows the 'Max coordinator fee rate' alongside the existing 'Max rounds' and 'Max mining fee'. This is a user-interface improvement that gives the device owner more information before they approve a CoinJoin session. It does not change any security logic, fee enforcement, or authorization checks; it only displays an extra value that was already part of the authorization message.

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

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

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 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 candidatetest(ethereum): check function signature at source.by PrisionMike · 54c20421 · Jul 22, 2026 · 2 filesMessage 100 · StrongInformational 15Details
Commit message · PrisionMike

test(ethereum): check function signature at source.

- Improves on #7308
- instead of copying func sig, we import it from source.
- We can also safely use raw bytes instead of unhexlify at source.

[no changelog]

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✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
Why it was queued
signing boundarysigning or wallet path
AI analysis · Informational 15/100

This is a test-only refactoring commit. It changes how Ethereum function signatures are represented in firmware source code (from hex strings converted at runtime to raw byte literals) and updates the corresponding unit test to verify those signatures against Solidity function definitions. There is no runtime behavior change and no security fix or vulnerability.