Interoperability
Diverse applications with different philosophies, feature sets, and approaches are fantastic for bitcoin. It allows many different users around the world to choose the applications that best fit their needs. For this to be practical, interoperability should be worked towards for smoother interactions with fewer mistakes.
Below are areas within your bitcoin application where interoperability should be a focus.
Payments
You should ensure your application is interoperable with the various techniques for sending and requesting bitcoin.
Supporting, generating, and reading as many payment request formats as possible in your application will make it more interoperable with others.
It also matters how these formats are generated. Your applications should be able to read, and generate, BIP 21 encoded payment requests.
An evolving standard that improves payment usability between on-chain and lightning is being able to read and generate unified bitcoin payment requests that contain an on-chain address and lightning invoice inside a BIP 21 URI.
When dealing with lightning invoice amounts, your application should be able to read and generate zero amount invoices.
Payment links, often using BIP 21, should be readable by your application. Forms should be automatically opened and filled when a user clicks a payment link or button.
Near-field communication (NFC) should be supported for paying and sharing payment requests.
Wallet backups
Wallet backups generated in one wallet application should be able to be easily restored in another.
Over the years, bitcoin wallets have implemented various features in different ways, partly because standards take time to evolve. Standards such as BIP39 recovery phrases and wallet descriptors should be used to create wallet backups within your applications.
Backing up payment channels that are part of the lightning network can be more difficult. Currently, no standards exist for this, nor is it possible to have a static backup method like you can with on-chain bitcoin. Payment channels states regularly change and thus need to be regularly updated. Some applications make use of static-channel-backup (SCB) files, though this is still an evolving standard.
It should be convenient for users to back up the relevant information they need for recovery with other applications. An example solution is to provide a printable template or downloadable PDF with the wallet name, software name and version, address type, wallet descriptors, and other non-standard information. If your application makes use of the lightning network this could be done in conjunction with regular, encrypted SCB cloud backups.
User data
Data that users create, such as contacts, payment descriptions, notes, etc., should be interoperable between different bitcoin applications.
Transaction data is stored on the bitcoin blockchain and available in any wallet a user has set up. However, transaction data does not contain any information about: the reasons why a transaction was made, who owns each address, which node a lightning payment was made to, etc.
To better understand and organize their finances, users typically enrich transaction data by assigning contacts, notes, labels, and other useful information. This data should be stored in standardized, open formats and easily synced between applications. This is especially useful for users who rely on multiple devices.
QR codes
Your application should be able to scan and read bitcoin related QR codes.
QR codes are visual representations of data. Since most devices today feature cameras with built-in support for reading QR codes, this technique has become a convenient method to transfer data from one device to another, even if those devices are offline.
Some bitcoin use cases for QR codes include sending and requesting payments, backing up and recovering wallets, sharing PSBTs (partially signed bitcoin transactions), or constructing a multisig-wallet.
Although QR codes are a well-established and standardized format, there are details to consider. For example, it is more efficient to encode uppercase characters. So it is recommended to uppercase data that is not case sensitive, such as bitcoin addresses.
Static QR codes can only contain small amounts of information. If you need to include more information, you can use an animated QR code. This splits up the data over multiple static QR codes. Animated QR codes are often used for transferring PSBTs which can be quite large. You should ensure your application can read animated QRs if relevant.
Integrations
Most bitcoin applications rely on external data sources (like currency conversion data) and may also have integrations with third parties (like an external block or lightning explorer).
Whenever possible, it should be easy for users to learn about these dependencies and choose alternatives.
Interface elements
Although every application will have its own unique interface, there are certain elements that are beneficial to keep consistent across applications, in order to improve the overall user experience. This includes things like naming conventions, icons, unit formatting, etc. We have many suggestions throughout this design guide to help you.
Networking
Connecting to the bitcoin or lightning network should be as trust-minimized and privacy preserving as possible. While it is convenient when applications provide their own node connection, it is beneficial to allow users to connect to a trusted node or their own self-hosted bitcoin or lightning node.
Having the option to choose how that data is queried, say using Neutrino over SPV, should also be an option. This results in better network decentralization, and has privacy and security benefits for users.
If your application uses the lightning network, users should be running their own lightning node. However, there are certain aspects of a lightning node that can be outsourced, such as creating inbound liquidity from an LSP or constructing payment paths.
Your application should give users options as to which services (if any) they want to trust a third party to conduct. Your application should try to avoid having users locked into your application and give them various options for outsourcing lightning services.
Hardware wallets
Your application should support interfacing with the various hardware wallets (HWW) that exist on the market. This can be different from one hardware wallet to the next and can mean supporting things like NFC, PSBTs, animated QR codes, and the hardware wallet interface (HWI).
Transaction files
Your application should support constructing, sharing, and managing transaction files, also known as Partially Signed Bitcoin Transactions (PSBTs).
PSBTS allow for storage and transfer of transactions that are not yet finalized. They allow signing wallets to be offline, as the transaction data can be transferred via USB, NFC, or animated QR codes.
This is particularly useful if users want to open a payment channel directly from their cold storage.
Multi-key wallets
Multi-signature wallets require interaction between all cosigners and therefore interoperability between users of different software, or hardware setups is crucial. Especially when there are multiple cosigners (rather than one owner using multiple signing devices), there should be strong design considerations to how the cosigners exchange keystores and transaction data.
Our next page deals with accessibility.