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

feat(common,core,python,tests): support signing Stellar Soroban authorization entries.

Public commit record

What the developer wrote

Authored by Jun Luo

100/100 · Strong
feat(common,core,python,tests): support signing Stellar Soroban authorization entries.

Fixes: https://github.com/trezor/trezor-firmware/issues/7312
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a new Trezor feature that lets users sign Stellar Soroban smart-contract authorization entries. The device now supports a new message type where it derives the user's Stellar address, shows confirmation screens, and produces an Ed25519 signature over a protocol-defined authorization payload. The change is a feature addition rather than a bug fix, and the signing flow includes user confirmation steps.

Recommended action

Review the new signing handler and confirmation screens for correctness against Stellar Protocol 27 / CAP-71 XDR serialization, ensure the preimage serialization exactly matches the network specification, and run targeted tests for edge cases such as deeply nested invocations, malformed addresses, and mismatched signing/on-behalf-of addresses.

Security signals we found

01

New signing surface added for Stellar Soroban authorization entries

02

User confirmation flow implemented before signing

03

Authorization payload binds signature to network, nonce, expiration ledger, address, and invocation tree

04

Only ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS is accepted; other envelope types are rejected

05

On-behalf-of signing path requires explicit user confirmation when authorizing address differs from device account

06

Legacy firmware explicitly excludes the new message types

Risk score

Why this scored 36/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 4/15
Affected reach 7/15
Confidence 7/10
Evidence quality 4/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.