Creating wallets for cryptocurrencies which fully inherit the benefits of the underlying protocol and provide the user with a reasonable experience is a real challenge when it comes to legitimate cryptocurrencies like Monero and Zcash. Most users of these cryptocurrencies expect interfaces which allow them to control their own private keys, conduct their financial affairs in complete privacy, and expect something that looks nice and is easy to use.
There are two overarching themes for wallet developers to be concerned with: the first is that you must ensure the app is a tomb for the user's data. There should not be any data leaks, including metadata, and there cannot be any methods of data exfiltration available which could be exploited. Exchange integrations, which allow users to trade cryptocurrencies within the wallet, are an egregious example of such an exploit. It should come as no surprise that this is the method by which many wallet developers generate revenue. Users should be aware that such wallets offer no privacy at all, and many may very well be quietly capturing the user's data using this method for their own reasons.
In reality, it's very difficult for an honest developer to protect users against metadata leaks, especially if the user is connecting their wallet to a default remote node offered by the developer, who again must be trusted, or to one offered by random, altruistic users (most are probably honeypot operators). But this is a relatively minor concern that should not have any tangible impact on the privacy of the vast majority of users. In time, products which allow users to easily operate a full node in their home should solve this issue.
The second important theme is delivering a reasonable user experience, from initial setup to creating transfers and updating the balance. Cryptocurrency wallet setup is a particularly difficult process for the unwashed masses, since it typically requires that users leave the context of the app to take some action. In some cases the user might be asked to write down a long list of random words, in others the user might be asked to come up with their own passphrase. For software which interfaces with Monero, updating the user's balance and enabling multiple consecutive are difficult tasks due to the way the protocol works to provide protection against blockchain surveillance. These are all incentives for unscrupulous wallet developers to cheat, and this cheating can be very hard or nearly impossible to detect.
How does a well-intentioned smartphone cryptocurrency wallet developer reconcile these two themes? The devil is in the details when it comes to cryptocurrency, and for smartphone cryptocurrency wallets the devil is also in the architecture. For cryptocurrencies with large storage requirements like Bitcoin, Zcash and Monero, we want to keep the blockchain isolated somewhere. It would be impractical and poor manners to ask the average user to dedicate more than 80% of their smartphone's storage to a single app. Maybe at some point in the future smartphone storage space will increase dramatically, and it will be no problem to keep a 300GB blockchain on your phone. But at this point in 2018, we need to think and work pragmatically so that we can make these tools usable right now. This means that we need to separate out the blockchain from the wallet (see Fig. 1).
Some wallet developers choose to write their own custom code for some wallet operations, rather than using the default API calls that are built into the reference wallet. This requires a good amount of ambition, but the results can be really interesting. This makes features like offline signing possible. However, this also creates technical debt that must be serviced. Bitcoin development may appear to move slowly and carefully, but have a look at all the different address types that are now available, and their potential compatibility issues! Projects like Monero, which fork twice per year, become more and more costly to keep up with as you write custom code. Creating your own tools comes with the obligation to keep updating them.
Instead of writing custom wallet code, it will be more efficient to simply build the reference wallet (e.g. monero-cli) into an archive file that can then be included in your binary. This way when the reference wallet is updated, maybe in the event of a hardfork or due to an emergency update, it's a relatively fast and easy procedure to rebuild the archive file and re-deploy your own app, and you don't have to worry about the details behind the transactions your users are creating. This should also lead to improved reliability of your wallet.
There are of course a lot more details to consider when building a cryptocurrency wallet, and the features, benefits, costs and constraints will always be unique to the underlying protocol. Return to main