[Feature PR] ETH and TRC20 address derivation and display

[probeerka]

Summary

I've implemented support for deriving and displaying Ethereum (EVM)
and TRON (TRC20) addresses from the seed phrase, and would like to
propose a PR for review.

This is view-only — no transaction signing. The goal is to allow
users to verify their deposit addresses for ETH and TRC20 tokens
directly on the air-gapped device, without exposing the seed to
an online machine.

Motivation

A common real-world scenario: a user holds ETH or TRON-based assets
(USDT, USDC) in cold storage and needs to share a deposit address —
for example, to receive funds or to set up watch-only monitoring in
a portfolio tracker.

Today, the typical workflow forces the user to either:

• enter the seed phrase into a mobile wallet app (Trust Wallet,
  MetaMask mobile, etc.), or
• use a third-party browser extension or library

Both approaches expose the seed phrase to an online environment,
closed-source code, or external libraries that may have been
compromised.

The threat model here is broader than just trusting the app itself.
Any device that has ever been connected to the internet must be
considered potentially compromised — regardless of whether it was
factory reset beforehand. A reset removes user data, but does not
guarantee the absence of firmware-level vulnerabilities, supply chain
implants, or OS components that may have been silently affected prior
to the reset. Installing a wallet app on such a device and entering
a seed phrase means trusting not just the app, but the entire software
stack beneath it.

With this feature, the full workflow stays air-gapped:

1. Load seed into SeedSigner as usual
2. Navigate to ETH or TRC20 address derivation
3. View and scan the address QR on the offline device
4. The seed phrase never touches any networked device or
   third-party software

This is the same trust model users already apply to their Bitcoin
addresses with SeedSigner — extended to the two most widely used
non-Bitcoin networks for stablecoin storage.

What's implemented

• ETH address derivation via BIP44 path m/44'/60'/0'/0/x
  — secp256k1 key derivation + Keccak-256 + EIP-55 checksum encoding
• TRC20 address derivation via BIP44 path m/44'/195'/0'/0/x
  — same secp256k1 curve, Base58Check encoding with 0x41 prefix
• Address displayed on screen + QR code for easy verification
• No new dependencies for ETH (uses existing embit);
  TRC20 requires base58 (lightweight, pure Python)

Why this fits the project

This fork already extends the original SeedSigner beyond pure Bitcoin
(Satochip, SeedKeeper, encrypted QR). ETH and TRON are the two most
common networks users need to verify cold storage addresses for —
particularly for USDT and USDC holdings. View-only derivation adds
meaningful utility with minimal attack surface since no signing logic
is involved.

Questions for the maintainer

1. Is this direction acceptable for the fork's scope?
2. Should ETH/TRC20 be opt-in via Settings to keep the UI clean
   for Bitcoin-only users?
3. Any preference on where in the menu tree to place address
   derivation for non-Bitcoin coins?
   Currently implemented under the loaded seed properties menu,
   below the existing Address Explorer entry — open to moving it
   if there's a more logical place.

Happy to adjust the implementation based on feedback before
opening the PR formally.

[3rdIteration]

Thanks for opening the issue.

I suspect that this would probably cause issues upstream, and would probably need to live in a separate release/edition (As despite the fact that there are no extra requirements, some folk would still take issue with it increasing surface area). (So a Trezor type approach, a block of code or module that is easy to import on its own to enable/disable at build time)

That said, it would probably make the most sense to be a feature that can be turned on/off in the settings and for the address explorer to just prompt the coin/chain when it opens. Multi-account derivation for Eth is still a mess across Ledger/Trezor but is at least consistent for the first account now. (For the most part)

It would really need to stay view only as the logic required to parse and display smart contract stuff a bit of a disaster on either chain. (And on the Bitcoin side is just provided by Embit)

I should also add that the expectation would be that you maintain this feature.

[3rdIteration]

Also, thinking about this some more, my main concern would be that folk end up sending funds to a wallet that isn't easy to spend from.

For example, the next release will support Aezeed seed import. As far as I am aware, no wallet supports Aezeed other than LND, it would really need to be gated to only support things like BIP39 and SLIP39 seeds. (Unless it also had a loose private key export function, which creates a variety of issues on its own)