A proposal to maintain a comprehensive list of all available tokens for index assignment in new nodes faces practical obstacles. The primary issue lies in the sheer volume of existing tokens combined with the rapid pace at which new tokens are created across various blockchains, rendering any such list quickly obsolete. Furthermore, the suggestion to utilize token addresses or their hashes as additional inputs in HMAC (Hash-based Message Authentication Code) processes negates the necessity of adding an extra node altogether. This approach also ensures backward compatibility with BIP 44 (Bitcoin Improvement Proposal 44), which outlines a specific structure for deterministic wallets.

The handling of extended public keys within hardware wallets presents another layer of complexity. Unlike regular public keys, extended public keys, when exported to frontend software by hardware wallets, enable the generation of new addresses for deposits or the scanning of change addresses without compromising private keys. This maintains the security integrity of the hardware wallets, preventing the recreation of private keys for account or change nodes. Nonetheless, the theft of an extended public key poses a privacy risk, as it allows an attacker to monitor all transactions associated with a specified coin type in a specified account, similar to the risks outlined in BIP 44.

The discourse further explores the feasibility of employing distinct application codes for each token to enhance transaction privacy and user identity protection on the blockchain. This method, however, is constrained by the fact that addresses can only be generated for the specified coin type, not the tokens themselves. Such a limitation risks the possibility of tokens being sent to incorrect addresses, thereby locking the tokens inappropriately due to application constraints. To mitigate this, the proposed solution advocates for the generation of independent addresses for each token or the main chain, encouraging users to utilize only those addresses recommended by the application for specific tokens. Additionally, applications would use token-specific addresses for internal transactions, including changes, and by default, scan for token transactions on both the main coin and token-specific addresses. Introducing a manual option for scanning other token addresses could address the issue of coins sent to incorrect addresses, ultimately aiming to preserve user anonymity by decoupling transactional addresses for different tokens, including ETH and USDT, thus enhancing privacy on the blockchain.