CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 37 Bitcoin

feat(ethereum): Add erc-4626 claim flow.

TZad421a7c View source ↗
Public commit record

What the developer wrote

Authored by PrisionMike

72/100 · Adequate
feat(ethereum): Add erc-4626 claim flow.

- Changelog previously added.

[no changelog]
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
The short version

What changed, and why it matters

This commit adds support for ERC-4626 vault reward claims and changes how Trezor handles Ethereum transactions with extra trailing bytes (calldata suffix). Previously, vault transactions with any trailing bytes were rejected as errors. Now, the device accepts them but shows the extra bytes to the user as a 'Calldata suffix' screen. The change also introduces a new 'claim' function path, but the actual claim UI is stubbed out and returns None (disabled) for now. The commit is a feature addition, not a documented security fix, but it touches transaction parsing and user confirmation flows.

Recommended action

Review whether displaying raw trailing calldata as a suffix provides sufficient user understanding and protection; trailing bytes can encode hidden actions or bypasses. Ensure the claim handler stub is not reachable in production, and complete or remove the TODO before release. Consider adding tests for maliciously crafted suffixes and verifying that the suffix screen cannot be skipped or confused with other data. No immediate patch is indicated by the diff alone, but the behavioral change from reject to accept-with-warning warrants security review.

Security signals we found

01

Calldata parsing relaxed: trailing bytes no longer hard-fail for ERC-4626 vault methods; instead they are surfaced in UI as 'Calldata suffix'.

02

New claim function signature recognized (0x71ee95c0) but handler is stubbed and returns None, so no active claim flow is exposed.

03

Vault lookup refactored; unknown vaults fall back to UNKNOWN_VAULT sentinel rather than boolean flag.

04

Error message changed from 'Invalid data for ERC-4626 vault transaction' to 'Invalid data for ERC-4626 vault transaction.' (punctuation only).

05

Test expectations changed: trailing-bytes cases now produce valid signatures instead of zero signatures, confirming behavior change from reject to accept-with-warning.

06

No vendor-authored security disclosure, CVE, or researcher attribution present in commit or supplied references.

Risk score

Why this scored 37/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 6/15
Affected reach 7/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.

More from Trezor firmware

Related watches

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
Open full analysis →Source 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
Open full analysis →Source 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
Open full analysis →Source commit ↗