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

test(core): move debug asserts into unit tests

Public commit record

What the developer wrote

Authored by obrusvit

95/100 · Strong
test(core): move debug asserts into unit tests

Move `if __debug__` address/signature asserts out of production modules
(`ethereum/yielding_vaults.py`, `ethereum/yielding.py`,
`ethereum/clear_signing_definitions.py`, `tron/consts.py`) into unit
tests under `core/tests`, so they no longer inflate debug build
firmwares.

- `test_apps.ethereum.yielding_vaults.py`: asserts hardcoded ETH vault
and token address bytes match their published Etherscan hex values
- `test_apps.ethereum.yielding.py`: asserts ERC-4626 / claim function
selectors match keccak256 of their signatures, and Merkl distributor
address matches its hex literal
- `test_apps.ethereum.clear_signing_definitions.py`: asserts
approve/transfer function selectors match keccak256 of their
signatures
- `test_apps.tron.consts.py`: asserts hardcoded TRC-20 token address
bytes match their published base58check addresses

Also fix a typo in USDT link comment.

[no changelog]
✓ 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
The short version

What changed, and why it matters

This commit is a code cleanup and test reorganization. It moves sanity-check assertions (which verify that hardcoded cryptocurrency addresses and function signatures are correct) out of the main firmware code and into dedicated unit tests. The actual checks still run during development testing, but they no longer get baked into debug firmware builds. There is no security vulnerability being fixed here.

Recommended action

No security action required. Treat as a normal refactoring/test-maintenance commit. Continue running the relocated unit tests in CI to catch future typos in hardcoded constants.

Security signals we found

01

No vulnerability patched

02

No change to runtime behavior or trust assumptions

03

Debug-only assertions relocated to unit tests

04

Hardcoded address/signature constants remain identical

Risk score

Why this scored 14/100

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