Silent payments
Silent payments is a protocol that uses static addresses to simplify payment experience, while preserving privacy. Once the receiver shares a static address, senders derive a new unique on-chain addresses while making payments. This prevents address reuse without repeated user interaction.
For example: Alice can simply post a static address on her website, and receive bitcoin donations at unique on-chain addresses. The static address itself never shows up on-chain.
Silent payments also allow users to customize their static address with labels that are detected when payments are received. This is a powerful tool that provides actionable information for coin selection, with minimal manual effort.
Static addresses & labels enable robust contacts features. The result is a better interaction model centred around users.
Rationale
Since the bitcoin blockchain is public, reusing an on-chain address informs the network that these payments are made to the same user. However, specifying a new address for each transaction usually requires user interaction. This is error-prone, takes time and requires manual effort.
Silent payments circumvent both these issues by using static addresses (starting with sp1).
How silent payments work
Silent payments are made in 4 broad steps:
- The receiver shares/publishes a static payment address (manual, one-time)
- The sender obtains & uses it to derive a unique on-chain address (partly automated)
- The sender broadcasts a transaction that pays this derived address (manual)
- The receiver scans the blockchain & identifies their payments (automated)
Alice posts a static address on the website of her non-profit, Chasing Rabbits. Bob uses it to send bitcoin from his wallet. This transaction pays a derived on-chain address that Alice can recognise while scanning the blockchain.
A new conceptual model
Silent payments introduce a new technical model that separates payment information based on its purpose.
Here are the main components of this new model with their purpose:
| Component | Used by | Purpose |
|---|---|---|
| Static address | Senders | Making payments |
| Scan key | Nodes & light clients | Detecting payments |
| Spend key | Wallet owner | Spending bitcoin |
As shown above, the model introduces a scan key that is used for payment scanning and a static address which is used for deriving on-chain addresses. This is in contrast with the BIP-32 model where extended public key are used for both purposes. Below is a summary of the differences between the two models:
| BIP-32 | Silent payments | Benefit |
|---|---|---|
| On-chain address | Static address | Reusable; untraceable on-chain |
| Extended private key (xprv) | Spend key | |
| Extended public key (xpub) | Scan key | Nodes & light clients can scan for payments but cannot derive addresses |
| Address-based model | Contact-based model | More intuitive and familiar |
Labels & contacts
Labels
Adding labels to a static address before posting or sharing with others.
Labels (such as business or no-kyc) are brief identifiers often associated with information such as payments, transactions and addresses. They’re used to organise, categorise or quickly spot information from a large set.
Silent payments allow users to add labels to their static addresses on a case-by-case basis before sharing or posting them. When a payment is received, these labels can be detected by the receiver (but no one else) and used to identify the static address that was used to make the payment.
For example, Alice can customise her static address with different labels before sharing them:
- with a certain client
- on Nostr and
- on her website
When she receives payments from any of these sources, the respective label(s) will be detected in the on-chain address and used to infer the source of the payment.
Alice customizes her static address with labels before she shares them. Whenever she receives a payment from one of them, the label is auto-applied and detected by the wallet.
This scheme improves labelling in general, since labels get auto-applied to all derived on-chain addresses. This eliminates the friction of manually adding labels to addresses or transactions. Labels can contain crucial information that is useful for automatic or manual coin selection for future outgoing payments.
Tracking payments
Without labels, receivers have no way of knowing who may have paid them. This is because the sender independently generates the on-chain addresses without any involvement of the receiver.
Recommendation
Labels in silent payments are critical when receivers, such as businesses, need to match payments with customers.
Here’s how businesses, such as exchanges, merchants and vendors can use labels:
- Invoices: merchant software like BTCPay must use labels to match incoming payments with invoices and/or provide unique static addresses to repeat customers.
- Bitcoin exchange deposits: Customers looking to sell/deposit bitcoin at exchanges encounter friction when their deposit addresses change constantly. Labelled static addresses for users fix this without address reuse while retaining the ability to match deposits to customers.
- Bitcoin exchange withdrawals: Customers can withdraw bitcoin from exchanges by providing a (labelled) static address just once, without having to provide an on-chain address every time. This facilitates best practices like DCA and self-custody, while labels identify bitcoin from exchanges.
Contacts
Since senders can safely use the same static address for multiple payments, it is natural for them to want to store these for future use. Contacts are a great way to do this in a way that users can intuit: names and faces. The contacts page provides guidance about the topic.
Silent payments (along with BOLT-12) allow applications to center their payments experience around people instead of addresses. This was not advisable before, due to issues with on-chain address reuse.
A modal encourages the user to save a static address when it is detected on the clipboard.
The wallet owner’s contact page allows them to view and quickly share their payment information.
A Contacts page lets the user search and quickly access saved payment information, including their own.
A home screen with a pinned contacts section allows quick access to frequently used payment information.
Tip
Contacts are not just for sending. The receiver can create contacts for parties they only receive bitcoin from. When they share a labelled static addresses with others, such as employers or customers, creating a contact can help with invoicing, tracking payments and coin selection.
Setup
Applications can take a variety of approaches to set up and communicate silent payment wallets. Benefits of silent payments, such as contacts and auto-labelling, should be explained during setup. Some wallets may use unique or significant locations (mobile widget, custom app logos, watch faces) to place this static address for easy retrieval, and may highlight the same during setup.
An onboarding page introducing the static address its ability to be safely reused.
An onboarding page introducing labels, explaining they are automatically applied to payments received.
An onboarding page introducing the Contacts feature.
Sending
With the improvements to contacts, on-chain send flows may start from a number of entry points. When users start with obtaining a static address, every on-chain address derived from it will be visibly different from the static address the sender started with. This is likely to be confusing for users. Applications should take measures such as short explainers to avoid confusion on the user’s part. Test transactions are another good way to help users deal with this.
A note below the on-chain address explains that it is derived from the static address.
A note below the static address mentions that the on-chain address is different from it.
Using contacts allows send pages to avoid mentioning addresses altogether.
An error message under the address field informs the user about a static address not being supported.
Recommendation
Applications that do not support static addresses should provide helpful, actionable, human readable errors.
Coin selection
As mentioned in the introduction, coin selection can be significantly improved due to auto-applied label information. Applications should encourage and assist users during coin selection by surfacing relevant or related labels. Automatic coin selection should be improved with all the label information available.
Tip
The coin(s) selected for a transaction determine the derived on-chain address, due to the nature of the silent payments protocol. The interface should avoid showing the on-chain address before the coin selection is done.
Receiving & scanning
The user contact page allows the user to add labels to their receive static address before sharing it.
Receiving flows are likely to be used less often, since static addresses can be safely reused. If the receiver has publicly posted their static address, they will receive payments without any interaction with the sender. Therefore, applications should encourage users to add labels or a contact whenever they actively share a static address with a sender.
Applications should also allow receivers to generate and share conventional on-chain addresses in case the sender’s wallet cannot send to static addresses.
Some practical examples for where users might want to share (labelled) static addresses include:
- Social media pages
- Fundraising websites
- Exchanges
- Email signatures
The tradeoff with silent payments, for all their benefits, is a higher blockchain scanning requirement. This scanning process is more computation-intensive and time-consuming than for popular BIP-32 wallets and addresses. Mobile wallet users are likely to face a noticeable delay in detecting payments once they come online. While scanning takes place, applications should show progress and the estimated completion time.
Backup & Recovery
Backup
Display wallet birthday as a part of the backup flow and explain the benefit of storing it.
Like lightning wallets, on-chain wallets with robust silent payments functionality require file backups (cloud or offline). This is because such wallets have valuable user metadata such as:
- scan and/or spend keys
- tweak data
- labels
- contacts
Applications should allow users to manually note backup information in case they misplace the backup file or the recovery application does not support backup files at all. Like regular wallets, silent payment wallets can also be backed up and restored using a recovery phrase. However, this method may result in longer recovery times as well as loss of valuable metadata.
Recommendation
Applications should display backup information such as recovery phrase or wallet birthday in the UI even if file backups are being performed. This could reuse existing functionality and serve as a partial manual backup.
Recovery
In addition to recovery methods mentioned here, applications may enable manual recovery with data unique to silent payments wallets, such as scan/spend key material.
Allowing users to enter the wallet creation date (wallet birthday) during recovery can help reduce recovery time substantially.
Applications should allow both backup & recovery through multiple methods. This is especially important when backup & recovery features are not standardised – during early stages of adoption and if wallets do not support silent payments.
Applications should allow users to enter wallet birthday and while explaining its benefits.
A date picker allows the user to enter the wallet birthday before beginning recovery process.
Pros and cons
Pros
- Prevents address reuse without repeated user interactions
- Enables a better user interaction model centred around users instead of unwieldy addresses
- Reduces the possibility of mistakes while handling on-chain addresses
- Allows users to optionally infer payment sources through labels
- Auto-applied labels improve coin-labelling and coin selection
- Scanning process is more private since sharing on-chain addresses (or xpubs) is not required
Cons
- Static addresses do not match on-chain addresses in transactions, breaking the conceptual model for seasoned users
- Scanning for payments doesn’t work well with electrum servers (widely used by wallets)
Resources
Wallets implementing silent payments
- Cake wallet
- Blue wallet (sending only)