Found via manual device testing against a real, pre-Tron production
wallet: TRX/USDT-TRC20 didn't appear anywhere in the Assets list, not
even as a zero balance - unlike every other configured chain (KSM, USDC,
ETH, BNB, AVAX, LINK all show up at 0). Root cause: MetaAccount.hasAccountIn()
gates Tron balance sync on tronAddress != null, but tronAddress is only
ever populated once, at fresh-mnemonic-creation time in
AccountSecretsFactory.metaAccountSecrets(). The migration that added the
tronPublicKey/tronAddress columns (73_74_AddTronSupport) is pure ALTER
TABLE like every other migration in this codebase - it never derived a
value for pre-existing rows. Net effect: BalancesUpdateSystem silently
skips Tron entirely for every wallet that existed before this feature
shipped, with zero error surfaced anywhere. No automated test catches
this because every automated test creates a fresh (post-Tron) account -
this is exactly the class of bug that only manual testing against a real,
aged wallet can find.
Adds TronAddressBackfillMigration: a one-time, flag-gated pass (mirroring
the existing AccountDataMigration idiom) over SECRETS-type accounts that
still hold their mnemonic entropy in SecretStoreV2 but have no TronKeypair
yet. Derives the Tron keypair via AccountSecretsFactory.chainAccountSecrets
(isEthereum=true, same BIP32/secp256k1 path Tron already uses everywhere
else) at TRON_DEFAULT_DERIVATION_PATH - the same call fresh-account
creation already makes - so a backfilled wallet ends up with byte-for-byte
the same Tron address it would have gotten had it been created today, not
a separately-reimplemented derivation. Watch-only/Ledger/Json/multisig/
proxied accounts (never had a Tron-capable mnemonic) and raw-seed imports
(no entropy) are correctly left untouched, same as they already are for
Ethereum.
Includes a dedicated unit test asserting the backfill derives the exact
same reference Tron address (TUEZSdKsoDHQMeZwihtdoBiN46zxhGWYdH) that
TronDerivationTest already cross-validated against live TronGrid data for
the standard BIP39 test mnemonic - this touches real wallets' key
material, so it's pinned to a known-good vector rather than just asserting
against its own output.
SELECT * FROM chains had no ORDER BY - SQLite gives no ordering guarantee
for that, so registration/connection order across ~98 chains was
effectively unpredictable per run. The merged chains.json lists Pezkuwi's
own chains first (wallet-utils' merge_chains()), and CollectionDiffer's
findDiff()/Room's batch insert both preserve that order on first sync, so
ordering by rowid (insertion order) makes Pezkuwi's own chains reliably
register and start connecting first/early, instead of being interleaved
unpredictably among ~90+ Nova-inherited chains where they could end up
processed dead last - observed directly: a fresh install took 45+ seconds
without a single Pezkuwi-related registration/connection attempt.
No user should wait minutes for their own wallet's native chain to even
start syncing after install, regardless of whether the eventual outcome
is correct.
* Add read-only Tron (TRC20) chain family support
Adds Tron as a third chain family alongside Substrate and EVM:
address derivation (BIP44 coin type 195, secp256k1 reused from the
existing Ethereum path, Base58Check encoding), TronGrid-backed TRX
and TRC20 USDT balance display, and a Room migration for the new
per-account Tron key/address columns. Read-only only — no send,
signing, or broadcast support yet.
* fix: exhaustive when branches for Trc20/TronNative asset types
ChainExt.kt's onChainAssetId and Common.kt's existentialDepositError
both switch exhaustively over Chain.Asset.Type and didn't have cases
for the new Trc20/TronNative variants, breaking compilation. Trc20
mirrors EvmErc20 (contract address as the on-chain id, dust burns
rather than transfers on removal); TronNative mirrors EvmNative.
pezkuwichain