Jump to Use Case | Jump to Infographic | Validate Payment Example Script | Sweep Silent Payment Example Script
The BIP-352 Silent Payments proposal creates an opportunity to define a distinct Nostr Silent Payments (NSP) derivation model for a Nostr identity.
This work arose from related efforts to derive a Taproot (p2tr) address from a Nostr public key and to understand how Nostr identity material could map deterministically into Bitcoin wallet semantics. That earlier exploration made it clear that the same identity-linked approach could be extended beyond a single visible Taproot address into a richer Silent Payments receive model.
One of its most important properties is that Silent Payments can provide a static payment address: a stable Silent Payments receive identity that can be reused by senders without creating a reusable on-chain receive address.
Under the Nostr Silent Payments derivation rule, a Silent Payment address can be deterministically derived from a known npub. This means every Nostr identity can be treated as having a corresponding Nostr Silent Payments address model, even if the identity owner has never explicitly published or acknowledged it.
This creates several important properties:
- Independent verifiability: anyone who knows the
npuband the Nostr Silent Payments derivation rule can derive the expected Silent Payment address and verify it independently. - Anti-spoofing assurance: a sender does not need to trust a pasted or manually shared address. The correct Silent Payment address is fixed by the recipient identity and can be derived locally.
- Plausible deniability: because anyone can derive the Silent Payment address from the
npub, the existence of that address does not prove thensecholder intentionally created, published, or even knew about it. - Private receipt detection: while the Silent Payment address is publicly derivable, only the holder of the matching private scan key can detect which on-chain outputs belong to the identity-derived Nostr Silent Payments model.
- Private fund control: only the holder of the matching private spend path can sweep or spend the detected outputs.
NSP has a strong sender-verification and receiver-privacy story, but it also has an important scanning constraint that must be understood clearly.
In the NSP derivation model:
scan_priv = d + t_scan mod nt_scanis publicly computable from thenpub- anyone who learns
scan_privcan recoverd - once
dis known, the observer can also derivespend_priv
This means:
- the NSP scan private key is root-equivalent
- disclosing
scan_privdiscloses the underlyingnsec - disclosing
scan_privalso discloses the NSP spend private key - NSP is a strong local-scanning model
- NSP is not a safe untrusted remote-scanning model
Operationally, that means:
- local scanning is the preferred NSP model
- self-hosted or fully trusted scanner infrastructure can be acceptable
- untrusted third-party remote scanners should not be treated as safe for NSP
- the sender-side benefits of public derivability remain intact even though the receiver-side scan key must be handled as a root secret
This protects both the sender and the recipient.
- The sender is protected because they can derive the correct receive address themselves and avoid spoofed payment instructions.
- The recipient is protected because incoming payments do not expose a reusable on-chain receive address, and detected outputs can be swept to unrelated addresses.
As a result, the funding relationship between donor and recipient is difficult to establish from public chain data alone.
The key architectural insight is that Nostr Silent Payments differs from a wallet-style Silent Payments implementation in how the receiver's base Silent Payments keys are derived.
- The Nostr Silent Payments model is derived from Nostr identity using deterministic additive tweaks.
- In a wallet-style implementation, the Silent Payments keys are usually derived from private seed material through a BIP-32 tree.
The resulting sp1... address is still the same kind of Silent Payments object in both cases, so a sender paying to it may see no practical difference. The difference shows up on the receiver side: scanning, recovery, and wallet interoperability depend on whether the wallet can reconstruct the matching private scan and spend keys from the same derivation contract.
For practical purposes, Nostr Silent Payments should be treated as its own distinct derivation and recovery model:
- it is identity-linked
- it is privately discoverable
- it is publicly verifiable
- it is difficult to attribute to intentional publication
- and it preserves the core on-chain privacy benefits of Silent Payments
There is also a direct traceability tradeoff to understand.
- NSP gives stronger independent verification than a published
sp1...address string alone, because a sender can derive the correct address from a knownnpubor human-readableNIP-05 - this is especially useful when the recipient has no better public communication channel than a profile, website, or
NIP-05identifier - but that same public derivability means the static Silent Payment address is more attributable to the public Nostr identity than in a seed-derived BIP-352 wallet
- the tradeoff is therefore stronger sender assurance and anti-spoofing on one side, and weaker off-chain identity unlinkability on the other
What does not materially change is the on-chain privacy model:
- the static
sp1...address still does not appear on-chain - each payment still lands as a fresh Taproot-looking output
- outsiders still cannot trivially identify which outputs belong to that static address without the relevant scan key material
BIP352 contains important ideas, but on its own it creates a serious risk by normalizing exposure of receiver-side private key material for receipt detection. The proposal itself states: "Since Bob needs his private key b to check for incoming payments, this requires b to be exposed to an online device."
That is not a minor implementation detail. It is a dangerous trust assumption. Even if the spend key remains safe and the receiver's funds are not immediately spendable, exposing the scan private key still creates a meaningful privacy failure mode.
The core problem is not only receiver risk. It is sender and donor risk. If the receiver-side scan key is exposed, leaked, logged, intercepted, or later doxxed, an observer may be able to identify the full set of payments made to that silent payment address. In that case:
- the receiver's incoming payment graph is exposed
- the privacy of donors and counterparties is exposed
- the receiver may rotate to a new silent payment address, but prior donors remain exposed
That means the privacy harm is durable and asymmetric. The receiver can move forward with a new address, but the senders who already paid cannot undo their exposure.
For that reason, any design that treats disclosure of private scan material as operationally acceptable should be described with much more caution. Telling users to share any form of private key material, even a hardened derived key, is a bad security pattern because it trains users and implementers to normalize private-key exposure as long as it appears scoped.
On this view, BIP352 by itself asks too little about the privacy of senders and too much from the receiver's operational security. It protects spend authority, but it does not adequately protect the privacy of everyone who paid that address if the scan key becomes exposed.
This is why BIP352, on its own, should be treated as dangerous unless the scanning trust model is made explicit and tightly controlled.
Using a public scanning server adds another serious risk layer on top of the key-exposure problem. Even if the connection uses JSON-RPC over TLS, that protection exists only hop by hop. It does not mean the payload is protected from the infrastructure that terminates, forwards, inspects, or relays the request.
If a reverse proxy is used in front of the scanning service, the private scan material may be exposed at that proxy layer. The proxy can terminate TLS, observe the full RPC payload, and then forward it onward to the underlying scanner. If the downstream connection is re-encrypted, that only protects the next hop. It does not protect the data from the proxy itself.
That means a user cannot safely assume that a public endpoint is only the scanner they think they are talking to. With a domain name, there is no reliable way for the user to know whether there is a reverse proxy, logging layer, WAF, traffic inspector, or other middleware in the middle. With a raw IP address, the problem does not go away. The user still has no way to know whether the server is running additional software that siphons off the scan key material before forwarding the request to a Frigate instance.
So the trust question is not just whether Frigate itself is honest. The trust question is whether every server, proxy, process, log pipeline, and middleware component that touches the request is fully trusted not to retain, inspect, or exfiltrate the scan key.
This is why public remote scanning should be treated as especially dangerous. The RPC call may be encrypted in transit between hops, but the payload is still fully available to each hop that handles it. That is not a safe model for root-equivalent scan key material.
There is also a major omission in the ordinary BIP352 threat model: receiver culpability. The model often treats scan-key exposure as an unfortunate operational failure, but it should also account for the possibility that the receiver themselves may deliberately expose the scan key after receiving and spending funds.
A malicious or reckless receiver can follow a simple pattern:
- Generate a Silent Payment address.
- Solicit funds from donors.
- Spend the funds.
- Dox the scan private key.
- Dox all donors who paid that address.
- Deny that it was ever really their Silent Payment address, or deny responsibility for the exposure.
- Generate a new address and repeat.
This is not just a technical edge case. It is a structural asymmetry in the trust model. The receiver controls the address lifecycle, benefits from the incoming funds, and can later reveal the scan key in a way that permanently harms donors and counterparties. The donors have no way to revoke the payments they already made, and no way to repair the privacy loss once the scan key is public.
That makes sender and donor privacy dependent not only on technical competence, but also on receiver integrity. A receiver who is careless, compromised, malicious, pressured, or strategically opportunistic can externalize the privacy cost onto everyone who paid them.
This is one place where the Nostr Silent Payments approach changes the incentive structure in an important way. When the Silent Payment address is derived from the npub, the receiver has much stronger reason to protect the corresponding nsec. Revealing the scan key in the NSP model is not merely exposing a disposable scanning secret. It is exposing root-equivalent identity material. That creates a much stronger deterrent against careless disclosure because the receiver would also be harming their own key security and identity continuity.
By contrast, in a plain BIP352 operating model, the receiver can more plausibly treat the scan key as something operationally separable from their broader public identity. That weaker binding makes post hoc donor betrayal easier to imagine, and therefore makes receiver culpability an essential part of the threat model rather than an afterthought.
NSP is also a strong fit for machine or agentic identity.
In many automated systems there is no human-maintained social profile at all. A component, service, agent, or device may simply have:
- a generated
npub - a corresponding
nsec - and no published profile, website, or human-facing payment page
In that environment, NSP provides a clean private payment primitive:
- a machine can expose only its
npub - another component can derive the correct Silent Payment address independently
- the sender does not need a separate address-distribution channel
- and the resulting payment still lands on-chain as a fresh Taproot-looking output
This is useful for:
- agent-to-agent settlement
- component-to-component billing
- service payments between autonomous systems
- private treasury flows between software-controlled identities
This also changes how the traceability tradeoff should be evaluated.
- the
npub-derived NSP model does create a stronger public correlation between the staticsp1...address and the public identity than a hardened seed-derived BIP-352 wallet - but for bare, ephemeral, or non-human
npubidentities, that correlation may be a very acceptable tradeoff - if the
npubis not carrying a rich human-facing social graph, profile history, or public persona, then the off-chain linkage cost can be much lower - in those settings, the benefits of independent verification and private machine-to-machine payment coordination may outweigh the weaker identity unlinkability
In short, NSP makes it possible for components that hold Nostr key material to pay each other privately using only identity-derived address discovery, even when there is no human-readable profile or social presence at all.
This model has especially important implications in high-risk or adversarial environments where counterparties may be required to:
- send payment to a known identity
- later confirm receipt
- produce signed confirmations or acknowledgements
In those environments, ordinary payment coordination often creates trust gaps that must be managed by:
- intermediaries
- compliance staff
- auditors
- counterparties maintaining off-chain address books and attribution records
The Nostr Silent Payments (NSP) approach reduces those gaps significantly.
The sender can derive the correct Silent Payment address directly from the recipient identity, so there is no need to trust:
- a copied payment address
- an address provided by a third party
- an address embedded in a message that could have been altered or spoofed
That means the sender has strong assurance they paid the correct identity without relying on a separate trusted address-distribution channel.
At the same time, the recipient can later confirm receipt using private scan knowledge and, if needed, produce signed statements about receipt or sweeping without the blockchain itself exposing a reusable public funding relationship.
In practice, for NSP, that receipt detection should be treated as a local or fully trusted-operator function. A third-party scanner can technically discover NSP receipts, but using one requires disclosing a root-equivalent scan key and therefore giving up the wallet's key isolation.
This changes the operational trust model in an important way:
- address authenticity can be derived independently
- receipt detection can be performed privately by the intended recipient
- receipt confirmation can be made explicitly and deliberately, rather than inferred from public chain data
As a result, many of the trust gaps that would otherwise need to be:
- maintained by third parties
- documented through shared address registries
- or risk-managed through manual verification procedures
are reduced or eliminated by the cryptographic structure itself.
In short, this approach lets counterparties:
- derive the correct payment destination independently
- avoid spoofed payment instructions
- confirm receipt deliberately and privately
- and do so without exposing a durable public linkage between sender and recipient on-chain
This model is also important for protecting vulnerable donors who might otherwise reveal themselves unintentionally through ordinary Bitcoin payment coordination.
A useful real-world example is the 2022 Canadian trucker protest funding environment. During that period:
- donor information associated with crowdfunding support for the convoy was leaked and reported on publicly, exposing names, email addresses, locations, and other identifying details in many cases; see ABC News and The Guardian
- crypto-related accounts and addresses associated with convoy funding were identified and targeted by authorities and intermediaries; see Reuters via Investing.com and reporting on address blacklisting such as CryptoAdventure
That episode shows how vulnerable both donors and recipients can become when:
- payment destinations are publicly reused
- recipient infrastructure is easy to map
- donor activity can be linked to known recipient endpoints
- third parties can identify, freeze, or pressure visible funding paths
The Nostr Silent Payments model helps prevent or sharply reduce that exposure.
With the Nostr Silent Payments model:
- the sender can derive the correct destination from identity without relying on a publicly circulated payment address
- that independent derivation is stronger than merely trusting an
sp1...address published on a website, profile page, or message thread, because those published address strings can be spoofed, replaced, or tampered with - in many real cases the recipient may have no safer public communication channel than a human-readable
NIP-05address, and NSP lets the sender resolve that identity and derive the correct Silent Payment address locally - the reusable
sp1...receive identity does not appear on-chain - the actual received outputs are not publicly obvious without the private scan key
- the recipient can later sweep funds to unrelated addresses, reducing durable public linkage
This makes it much harder to:
- track down vulnerable donors from a known public Bitcoin address reuse pattern
- map incoming payments to a publicly attributed recipient address
- establish a clear public funding relationship between a specific donor and recipient from chain data alone
In that sense, the Nostr Silent Payments model protects both sides:
- the donor is less likely to reveal themselves by paying a publicly watchable recipient address
- the donor is less likely to be tricked by a spoofed or substituted Silent Payment address, because the correct destination can be derived independently from the intended Nostr identity
- the recipient is less likely to have their funding flows mapped and attributed through visible receive infrastructure
Everything here comes with tradeoffs, and that should be stated plainly.
- NSP gives stronger sender-side address assurance than a published
sp1...string alone - NSP is especially useful when the only practical public identifier is an
npubor a human-readableNIP-05 - NSP improves recipient privacy on-chain and in payment coordination
- but NSP also requires that receipt scanning be kept local or limited to fully trusted scanner infrastructure because the NSP scan key is root-equivalent
So the correct conclusion is not that NSP removes every risk. It is that NSP removes one of the largest and most common privacy failures in Bitcoin payments, while introducing a clear operational requirement around how the receiver performs scanning.
The Nostr Silent Payments (NSP) model shows that Bitcoin payments do not have to force a tradeoff between identity assurance and financial privacy. By making the correct receive identity independently derivable from Nostr while keeping on-chain receipt discovery and fund control private, this approach creates a stronger, safer, and more trustworthy payment model for both senders and recipients. It reduces spoofing risk, narrows operational trust gaps, protects vulnerable counterparties, and opens the door to a form of Bitcoin coordination that is more resilient in ordinary use and far more defensible in adversarial environments.
This also offers an important practical privacy advantage relative to layered Bitcoin privacy solutions such as Lightning and Cashu. Those systems can provide strong privacy properties, but they introduce additional infrastructure and additional trust or operational dependencies, including node operators, routing assumptions, channel management, or mint operators. The Nostr Silent Payments (NSP) model achieves a comparable improvement in payment privacy at the address-coordination layer without requiring the user to rely on a Lightning node, a federated or custodial mint, or other specialized intermediary infrastructure. The result is a simpler privacy model built directly on Bitcoin and Nostr identity semantics, with fewer moving parts and fewer third-party trust assumptions at the address-coordination layer, provided NSP receipt scanning remains local or confined to fully trusted scanner infrastructure.
The NSP approach leverages the BIP-352 payment model, but changes the base derivation layer.
BIP-352:
- starts from already-existing Silent Payments private keys (usually generated by a wallet hardware or app)
- does not prescribe where these keys came from
NSP:
- derives Silent Payments keys deterministically from the publicly known Nostr identity key (
npub)
So the BIP-352 base derivation is essentially:
- “pick or derive private keys, then compute pubkeys”
NSP is simply adding another base-derivation option:
- “start from the publicly known Nostr key d/P, derive additive tweaks, and turn that into scan/spend keys”
So in a nutshell, the core difference is this: instead of starting from an already-existing Silent Payments wallet keyset, NSP derives the receiver’s base Silent Payments keys from the publicly known Nostr identity (npub).
Everything else is the same at the sender and address-format layer. There is no difference in how the Silent Payments addresses are used on the sending side, but the receiver (the nsec holder) needs to know the NSP recovery rule.
Math details on the NSP base derivation:
Let:
d = Nostr private key
P = dG = Nostr public key
where d is the scalar value of the nsec
Derive deterministic tweaks:
t_scan = H_tag("nostr-sp/scan", P)
t_spend = H_tag("nostr-sp/spend", P)
Then:
ScanPub = P + t_scan G
SpendPub = P + t_spend G
the two public keys are encoded into the address:
sp1... = bech32m(v0 || ScanPub || SpendPub)
and privately:
scan_priv = d + t_scan mod n
spend_priv = d + t_spend mod n
This additive derivation also creates the most important security caveat in the NSP model:
d = scan_priv - t_scan mod n
Because t_scan is publicly computable from the npub, anyone who learns scan_priv can recover d and then derive spend_priv. So NSP scanning should be treated as local-only or trusted-scanner-only. It should not be described as a safe untrusted remote-scanning model.
As far as any sending wallet is concerned, the sp1... address is nothing special; it is just another Silent Payments address. However for the receiver, they need to know how to recover against those address using d (their nsec)
The opsec recommendation is to never spend from this wallet to an address outside of your control. Always sweep to a fresh address under your control.
Some might philosophically object to using the nsec this way, but NSP gives every Nostr identity an attributable Silent Payments derivation by default while still preserving plausible deniability about intentional publication or awareness.


I think this is incredibly important, both for cryptographic and UX reasons.