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

refactor(core/ethereum): handle staking/yielding in `confirm_tx_data()`

Public commit record

What the developer wrote

Authored by Roman Zeyde

85/100 · Strong
refactor(core/ethereum): handle staking/yielding in `confirm_tx_data()`

This way, we don't need to call `get_progress_indicator()`,
since all the data has been already loaded and hashed.

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This is an internal code cleanup in Trezor's Ethereum transaction signing. It changes how staking and yield-farming transactions hand off their user-confirmation step so the confirmation happens inside the same routine instead of being returned as a separate progress indicator. The commit message says the goal is to avoid needing a progress indicator because all transaction data is already loaded and hashed. There is no direct evidence in the commit of a security bug being fixed, but the change touches the code that decides what users see before they approve high-value operations like staking and vault deposits/withdrawals. The large set of updated UI test hashes shows the on-screen flow changed, which is expected for a refactor of this kind.

Recommended action

Treat as a routine refactor with no immediate security action required. Reviewers should verify that the new await-in-caller pattern does not change the order of data hashing versus user confirmation, and that the removed progress indicator did not provide a security-relevant check (e.g., ensuring additional data chunks are consumed before confirmation). Run the updated UI tests to confirm the new hashes match expected screens.

Security signals we found

01

Refactor of transaction confirmation orchestration for Ethereum staking/yielding

02

Removal of `get_progress_indicator()` usage in staking and yielding paths

03

Return type narrowed from tuple to coroutine, centralizing await in `confirm_tx_data()`

04

Large UI fixture hash churn for staking and vault tests, consistent with visible flow change

05

No explicit security claim, CVE, or advisory in commit message or diff

Risk score

Why this scored 27/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 6/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.