wallet-cli-4.13.1

Notice

Non-mandatory upgrade

If you created HD accounts at index 1 or above on 4.13.0 or earlier, read
Troubleshooting before upgrading — those TRON addresses need one export step
that must happen while the old wallet is still intact.

Troubleshooting

legacy_derivation — recovering TRON addresses derived before this release.

If a TRON account was derived at index 1 or above by 4.13.0 or earlier, it lives at
m/44'/195'/<index>'/0/0, a path this version no longer produces. Signing it, or deriving another
account into the same wallet, now fails with legacy_derivation (exit 1). The key is not lost —
the recovery phrase still derives it at that path — but this version's default import and derive
flow will not recreate the address, so it must be preserved before the wallet is rebuilt:

error [legacy_derivation]: account "main-1" was derived at m/44'/195'/1'/0/0, a TRON path this
version no longer produces, so it cannot be signed here. Follow the complete recovery procedure
before deleting anything:
  https://github.com/tronprotocol/wallet-cli/blob/wallet-cli-4.13.1/ts/docs/troubleshooting/legacy-derivation-recovery.md

The full procedure — save the account list and recovery phrase, export each affected TRON account
with backup --keystore and re-import it as a standalone account, then delete and re-import the
mnemonic wallet and re-derive every index — is documented in
Recover addresses after legacy_derivation.
Ethereum derivation did not change, so every EVM address is restored unchanged by the re-import;
only TRON at index 1 and above needs the export step. Do not delete the mnemonic wallet until
every TRON address you need appears as a standalone private-key account. The whole procedure
reorganizes local keys only — it moves no funds on chain.

derivation_mismatch is a different failure and has no such rescue: it means the stored address
matches no derivation path of its seed, which an edited wallets.json or a wallet pointing at the
wrong vault would cause.

New Features

Change

1. derive no longer demands a seed id. It now selects the HD wallet the way every other account command does: --account <accountId | label | address> names any account of the wallet, and with neither flag the active account decides. --seed-id wlt_… still works and takes precedence, so an existing script is unaffected, while wallet-cli derive on its own is now the common case. Selecting an account that belongs to a private-key, watch-only or Ledger wallet fails with seed_not_found at exit 2 and says which flag to reach for; --index names the address index in m/44'/<coin>'/0'/0/<index>, and re-running it on an index that already exists remains a no-op that re-activates the slot. (#1003)

2. backup asks which format you want. In an interactive terminal, omitting --keystore now opens a two-line choice — Native wallet backup (the recovery phrase for the whole HD wallet) or Web3 keystore (the single private key for the selected network's family) — instead of silently taking the native path. The prompt appears only for a fully interactive invocation: passing --keystore, or piping the password in with --password-stdin, keeps the long-standing non-interactive default, so pipes and CI stay deterministic. A native backup of a seed wallet now also warns about any account this version's default mnemonic recovery would not recreate, naming each one with the exact backup --keystore command that preserves it. (#1003)

3. derivationPath is now only ever reported by a command that actually opened the seed. list, current, use and rename need no master password, and without the seed they cannot tell an account derived under the old TRON template from one derived under the corrected one — so rather than print the current template as though it were an observed fact, they now return derivationPath: null for every account. A consumer that read derivationPath from those four commands must switch to a command that unlocks the seed: derive and backup resolve each cached address against its actual current or historical template before reporting, so their value is verified rather than assumed. ledger, watch and privateKey accounts return null as before. (#1003)

Bug Fixes

Change

1. HD accounts on TRON were derived at a path no other TRON wallet scans. derive --index 1 produced its TRON key at m/44'/195'/1'/0/0, hanging the number at BIP44's account level, while TronLink, the Java wallet-cli and the wider TRON ecosystem all increment address_index. The address was real and the funds are safe, but restoring the same recovery phrase in any other wallet would not show it. TRON now derives at m/44'/195'/0'/0/<index>, the same shape EVM already used, so a derived account follows the default restore flow everywhere. Index 0 is identical under both templates and is unaffected; only index 1 and above were reachable at the old path. Accounts already sitting there are detected rather than overwritten: the stored address is resolved against both templates before any key is used, so signing such an account fails with the new legacy_derivation code (exit 1) pointing at the recovery guide instead of signing with a different key; deriving a further account into that wallet is refused for the same reason, because one wallet must never mix templates; the 4.13.0 → 4.13.1 wallet-file migration keeps a cached TRON address that the old template explains, rather than re-deriving over it; and backup --keystore deliberately still exports the old path's key, since that is the one command whose whole purpose is to let the key leave. A stored address that no template explains is a different failure with a different fix — wallets.json and the encrypted vault disagree — and now raises derivation_mismatch instead of being papered over. Both codes are published in --json-schema, and the complete ordered recovery procedure ships with the release. (#1003)

2. import ledger --index did not mean what the device shows. The index was fed through the software derivation template, so on EVM it registered m/44'/60'/0'/0/<index> — an account Ledger Live does not display, leaving a user who picked "account 1" on their device with a different address than the one in front of them. Hardware paths are now built from Ledger Live's own template, m/44'/<coin>'/<index>'/0/0, for both families; TRON's path is unchanged, since that already was the template it used. --path remains the way to register any other scheme explicitly, --address scans Ledger Live accounts to find one, and the interactive account picker now prints each candidate's full path next to its address and says which template it is listing — so an account that lives on another scheme can no longer be silently mistaken for absent. (#1003)

Integrity Check

All jar files available in this release are signed via this GPG key:

• PUB: 1254 F859 D2B1 BD9F 66E7 107D F859 BCB4 4A28 290B
• UID: build@tron.network

From the download listings below you should see links to the downloadable jar files as well as sig signature files. To verify the authenticity of any jar file, grab the jar and sig files with the same prefix name and then execute the verification process: GPG signature verification