Silent Payments — one address you can publish, that is never reused

You publish a single code — a string starting sp1. It is not an address and nothing is ever paid to it directly, which is the part worth holding on to.

When someone pays you, their wallet does a calculation between the coins they are spending and your published code, and that calculation produces a brand-new address. It is the same trick that lets two people who have never met agree on a shared secret in the open: your code and their coins each contain half of what is needed, and only the two of them together produce the answer. The sender can work out the address to pay. Only you can recognise it afterwards, and only you can spend from it.

Two people paying the same published code produce two entirely unrelated addresses. So does the same person paying you twice. On the chain there is nothing tying them together and nothing tying any of them to the code you published.

The cost lands on your side, and it is the honest catch. Because no address was ever handed out, your wallet has to check every block to find out whether anything in it was meant for you — one cheap test per transaction, done for every transaction there is. A wallet doing this itself needs to be running and connected to a node. A wallet that hands the job to a server does not.

What ends up on the chain is an ordinary payment of the most common modern type. There is no badge on it saying a silent payment happened.

Publish one plain address and reuse it. This is what most people do, and it is the single worst on-chain privacy habit there is. Every payment anyone has ever made you lands in one visible pile, with your running balance attached, permanently, for anyone who has ever seen that address. The course gives the habit that prevents it a rule of its own, in the privacy lesson.

Hand out a fresh address each time. Correct, free, and what the course teaches — and it works perfectly whenever you are in a conversation with the person paying you. What it cannot do is cover a tip jar, a subscription, a donation page, or being paid back at some unspecified point in the future. Those are the cases this page is about.

Payment codes, the earlier attempt at this. They worked, but starting a payment relationship required an extra transaction announcing that it was starting — so while the payments themselves were private, the fact that you and I were about to transact was written on the chain in plain sight. Its main wallet was seized in 2024 and it lost its user base with it. We would not begin here today.

Take tips over Lightning instead. Genuinely a good answer for small amounts, and the one we use on our own tip page. It is a different set of trade-offs rather than a substitute — Lightning is for lots of small payments, not for receiving savings.

Let a service do the block-scanning for you. This is a real trade rather than an error, and it is what most wallets do by default. The server doing the scanning learns which payments are yours — not your keys, not your coins, but exactly the fact you came here to protect. Reasonable for a tip jar. Not what you want standing behind your savings.

If you do not need a public address, you do not need this. The habit the course already teaches — a fresh address each time — covers you completely. Nothing here is an upgrade on that; it is a fix for the case where that habit cannot be applied.

If you do need one, use this, and 2026 is the year that got straightforward. Sparrow can send to a silent payment address and can receive to one, including with an airgapped hardware wallet holding the keys. That last part is the change that matters for readers of this guide: money sent to a code you published in public can land directly in cold storage, without a hot wallet standing in the middle of it. Cake Wallet has had both halves since 2024.

Scan with your own node if the amounts matter to you. The convenient default hands a server the one fact you are trying to keep, and swapping it for your own node is a settings change, not a project. If you are already running one — the lesson on running your own node walks through it — you have what you need.

Know the two limits, because they are easy to miss. It protects you going forward and does nothing about addresses you have already published. And it protects you, the receiver: the coins the sender used are grouped exactly as they were before, so this does nothing for their privacy, and nothing for yours when you are the one paying.