Allow Beam wallet to manage multiple wallets

I didn’t see any formal FR for it, but I understand it’s a common request.

Even if Beam transactions are confidential, and even if different addresses can be used each time, it would be useful if the Beam wallet app itself could manage multiple wallets (this request is mainly for the Desktop GUI wallet).

The switch between wallets would be done at the very start of launching the app. And that initial window would also have all the needed options to manage these wallets (create new wallet, delete, rename, etc.).

I guess this feature would imply handling multiple wallet.db files, etc. Thus, each wallet would need to have at least a name defined by the user. And optionally a description, if possible.

I don’t know if the information about the name could be stored within the wallet.db file itself (although, if so, it should be visible without needing the password). Maybe other methods would be needed (like using different filenames: wallet-[some hash or random number].db and then have a list of all these files, with their associated names and descriptions, in the beam-wallet.cfg).


After a few tests… Good news, good news! :grinning:
The desktop wallet can already be used with multiple wallets! :tada:

There is no specific GUI to manage all the wallets, but the setup is quite simple.

Because the only thing needed to run the program with a second (or third, or fourth) wallet is to tell it at launch to use a different folder for the wallet data (i.e. where the wallet.db file is, and the node.db file in case of using an integrated node, etc.).

And that can easily be done with the –appdata parameter.

Moreover, multiple instances of the wallet app can be running at the same time, each with its own wallet, as long as their respective nodes use different ports.

And that can also be defined with the –node_addr parameter.

In conclusion, making a new shortcut/link to the Beam wallet exe, and adding these two parameters to it, is the only thing needed to be able to open the desktop wallet with another wallet!


As an example, these are the three shortcuts I am now using on Windows (I simply added the two parameters to the target of each shortcut). The setup would be similar on Linux and Mac.

The first one corresponds to the default configuration (it would work the same without the parameters). The second one also uses its own integrated node, but on another port. And the last one uses a remote node.

“C:\Program Files\Beam Wallet\Beam Wallet.exe” --appdata “%LOCALAPPDATA%\Beam Wallet” --node_addr=“”

“C:\Program Files\Beam Wallet\Beam Wallet.exe” --appdata “%LOCALAPPDATA%\Beam Wallet 2” --node_addr=“”

“C:\Program Files\Beam Wallet\Beam Wallet.exe” --appdata “%LOCALAPPDATA%\Beam Wallet 3” --node_addr=“”


Last thing: The appdata folder given in the shortcut/link does not need to exist beforehand. It will be created by the program at first launch. That’s good. It make things even easier!

However, the program will first propose to migrate the wallet from the default location. The option to restore or create a wallet should be selected instead.

Also, the node parameter seems to be ignored at first launch, so it’s better (faster) to ask the program to start with a remote node. And then, after that, call the shortcut/link again for its parameter to be taken into account.


It may be good to bring this up in a beam space. The devs may become more active here soon due to what the CTO said in the latest beam space and they did increase the activity on discord. But as of late they haven’t been here much unfortunately.

Like this idea if it doesn’t involve too much rework (prioritization of dev resources matters with such little funding, and don’t want to introduce potential bugs)

One additional remark:
When installing a new version of the wallet app, each of the wallet.db files needs to be migrated. But for each instance of the app, that db file should be selected with the “Manual migration” button. Indeed, the “Auto migration” button will migrate the wallet.db file that is in the default appdata location (I reported this as being a bug).