Publish one payment address. Keep using it forever. Every payer still lands on a fresh, unlinkable output — and when it is time to spend, the keys never leave the airgapped signer. That combination is rare: reusable for UX, private by default, and cold at the moment that matters.
Mainnet silent-payment receive & spend
Someone paid our sp1… address on mainnet; we found the coin, reviewed the spend on SeedSigner-class hardware, signed, and broadcast. Signing ran in the browser simulator with Doomsigner — same screens and seed logic a Pi would run.
Proved · block 965059
Mainnet BIP-375 send to sp1…
Pay someone else’s silent-payment address from a BIP84 wallet on the device: PSBTv2 with PSBT_OUT_SP_V0_INFO, ECDH output derivation at signing time, Schnorr on the input, coordinator finalizes. Same overlay as receive — not in official SeedSigner firmware yet.
Proved · block 965081
As far as we know, no prior mainnet silent-payment workflow had both directions signed on SeedSigner-class hardware. Sparrow already scans and builds PSBTs; official SeedSigner work in pull request #769 covers receive only and is still open — nothing you can flash from SeedSigner today signs a coin you received as a silent payment, let alone sends to someone else’s sp1….
One address, three wins
UX. No more “send me a fresh address.” No invoice per payer. You publish an sp1… string — or a name like rob@silentpayments.net that resolves to one — and leave it on your site, profile, or business card. I wrote the name half in I replaced my bitcoin address with a name.
Privacy. Reusing the same string does not reuse the same on-chain output. Each payment derives a new taproot coin. Two payers cannot link their payments to each other through your address alone.
Security. Finding payments needs a watch key (typically in Sparrow or a scanner). Spending needs the device. Receive is warm; the spend key stays cold until you approve a PSBT — the same airgap you already trust for ordinary bitcoin sends.
What this is and is not
Two mainnet proofs on SeedSigner-class hardware: receive-and-spend (pay our
sp1…, spend on device) and send-to-silent-payment (BIP-375 from a BIP84 wallet on device). Both ran in the simulator overlay — not a firmware release you can flash today.
What it feels like
- You show payers one silent-payment address (or name).
- A coordinator with your watch key — Sparrow, Frigate, or similar — notices the incoming coin.
- It builds a spend PSBT. You present it to SeedSigner.
- The device shows a Silent payment notice, then the normal review: amounts, destination, approve.
- You sign. Broadcast. Done.
No custom invoice protocol. No “paste a new address for every order.” Cold storage at the signing step, reusable address at the human step.
Sending to a silent payment
The sections above are the receive story: you publish sp1…, someone pays you, you spend on the device. The second world-first is the mirror — paying someone else’s silent-payment address from a normal wallet on the same device.
Sparrow and other coordinators already build BIP-375 sends: a PSBTv2 whose silent-payment output carries only scan and spend pubkeys (PSBT_OUT_SP_V0_INFO). The hard part on airgapped hardware is letting SeedSigner derive the taproot output script at signing time (ECDH between the sender’s input keys and the recipient’s pubkeys), sign eligible inputs, and return the BIP-375 hand-off PSBT — ECDH shares, DLEQ proofs, unfinalized output script — for the coordinator to finalize.
That send path is not in SeedSigner #769 (receive only). It tracks embit pull request #145 and the signing hooks from SeedSigner #949. We vendored that embit overlay into the same Doomsigner runtime as the receive menu — still stock 0.8.7 zip, still not a flashable release.
On mainnet, a demo BIP84 sender paid our published sp1… address: 10 000 sats out, 39 700 sats change, 300 sats fee. The overlay signed the PSBTv2 send; the coordinator finalized and broadcast. The silent-payment output is a normal P2TR vout — indistinguishable on chain from any other taproot payment.
Proved on mainnet
September 2026. All three transactions below are on Bitcoin mainnet. On mempool they look like ordinary taproot and segwit v0 — silent payments do not label themselves on chain. The proof is the workflow and PSBT fields, not a badge in the transaction.
| Txid | Block | Mempool | |
|---|---|---|---|
| Payment in (100 000 sats) | 98bf3f100c5903dbe76a4b7bc45f34cda0b6a77592271f26d0384f991b1ca5c2 | 965059 | view |
| Spend out (99 800 sats) | c0eaa7be5fe5ee447ebfdd644013de7d005246539df3bf6dab61caa8d4907775 | 965059 | view |
Send to sp1… (10 000 sats) | 172705760a51fa109b4aeef6f8bfbfde177a46c50d035abdd508b3d430b7c1ed | 965081 | view |
World first #1 is the payment-in → spend-out pair (receive path). World first #2 is the send row — BIP-375 from device to a silent-payment address, block 965081.
On the device — receive & spend
Mainnet receive path: someone paid our sp1…, we spent on the device. Screenshots from the Doomsigner simulator.
On the device — send to sp1…
Mainnet send path: BIP84 wallet on the device pays someone else’s silent-payment address. The SP output has no fixed address until signing — the device shows a Silent payment notice, reviews the transaction, ECDH-derives the taproot script, signs, and returns the BIP-375 export QR.
Why nothing on-chain says “silent payment”
BIP-352 is deliberate stealth. The incoming coin is a normal P2TR output; the spend is a normal key-path signature. Observers see taproot, not “SP.”
You prove it off-chain: the published sp1… address, a scanner that finds the coin with your watch key, PSBT fields coordinators use for silent-payment spends, and the device’s silent-payment notice in the screenshots above.
Signet dry run (development only)
We developed the path on Bitsaga Signet with published test seeds before moving proofs to mainnet. Signet blocks 80062–80063 (receive/spend) and 84584 (BIP-375 send) were regression checks — not the claims in this article.
Overlay and signing mechanics
Stock SeedSigner TapTweaks taproot keys. A silent-payment output is already the tweaked key (B_spend + t·G). Our simulator overlay signs with the spend key plus the payment tweak, even Y, Schnorr — not BIP-341 TapTweak.
The PSBT carries the tweak; the device shows a silent-payment warning, then the stock review. Sparrow-shaped PSBTv2 on mainnet; companion panel can present the QR frames.
Spend (coin you received): PSBTv0 or v2 with the BIP-352 tweak on the input (0x20); device signs (b_spend + tweak).
Send (pay someone’s sp1…): PSBTv2 with PSBT_OUT_SP_V0_INFO on the output; device ECDH-derives the output script, signs inputs, returns the BIP-375 export for the coordinator to finalize.
Upstream receive work lives in SeedSigner #769; spend-from-received-coin and send-to-silent-payment are what we added in the overlay. Not merged into official firmware yet.
Pull request #769 checklist
We did not merge pull request #769. We implemented a smaller menu on stock 0.8.7 and proved spend. Address vectors match earthdiver’s four published test seeds. Connect-to-Sparrow exports spscan; spend notice matches Keith’s wording; labels omitted by default.
Full thread-by-thread table lives in the repo under research/seedsigner-sp/ and in git history of this article. If #769 upstreams, port its flow tests and run a Pi hardware pass.