Description:

Problem Statement:

The current database path configuration in MM2 is determined globally by the public key generated from the MM2 seed, affecting both Iguana and HD wallet modes. This configuration presents issues across several scenarios:

1. When swaps are restarted in HD wallet mode or when a coin is enabled using an external wallet (e.g., Keplr, MetaMask, or WalletConnect) with a different seed/public key than the one used by MM2. In these cases, inconsistency in swap data may occur due to the requirement for transactions to be signed with a different private key/seed.

2. Enabling a coin with a public key different from the MM2 seed-derived one leads to misplacement of swaps and orders files among other things, as the database is anchored to the seed with which MM2 was initialized.

Proposed Solution:

The solution proposed aims to decouple the database initialization and cryptographic context global initialization from MM2 initialization. This involves:

• Initializing a distinct database path for each coin, where the database path is derived from the coin's specific pubkeyhash RIPEMD160(SHA256(pubkey)). This allows for greater flexibility and modularity in managing coin-specific data and configurations.
• Incorporating coin-specific database information within each coin's structure, moving towards a more modular and scalable architecture.

Implementation Considerations:

• Backward Compatibility: It's critical to ensure that the new implementation maintains backward compatibility, preserving existing database paths for public keys across all environments.

• Integration with HD Wallet PRs: Prior to initiating this refactoring, it's necessary to merge the ongoing HD wallet PRs (#1962 and #1979), as they contain changes to the HD wallet code that may impact this implementation.

IndexedDB/Wasm Implementation: The initial implementation will focus on IndexedDB/Wasm due to its relative simplicity, utilizing the same IndexedDB instance but with different namespaces for each pubkeyhash. Considerations for native or SQLite implementations will follow, particularly regarding migrations and compatibility issues.

Future Implications:

While this issue primarily addresses the modularization and flexibility of database paths, it lays the groundwork for future enhancements such as enabling concurrent swaps for different addresses of the same coin and facilitating a more gradual adoption of HD wallet functionality in GUIs. This includes the potential for migrating funds from Iguana to HD wallets. However, the focus of this implementation does not extend to realizing these future capabilities within its scope.

Action Items:

• Implement per-coin database path initialization based on the coin's pubkeyhash.
• Ensure backward compatibility for existing database paths.
• Begin with the implementation in IndexedDB/Wasm environments, considering the simplicity and existing implementation.