LNURL-Auth Privacy: Why Login Keys Differ Between Domains

LNURL-auth uses a domain-specific key to identify you to a service, rather than presenting one common wallet identity to every site. The same service can still recognize repeat logins, and ordinary account linking or browser sessions can connect additional information. Domain separation is a specific privacy property, not a promise that your activity cannot be associated.

Follow one login, without confusing it with a payment

The LUD-04 authentication specification describes a service issuing a challenge and a compatible wallet signing it with a linking key. The service verifies the response and can use the public linking key as the account identifier. The login response does not need to disclose the wallet's seed or private linking key.

Reading a QR code is not itself enough to classify its request. A wallet can encounter payment, withdrawal or authentication flows. For LNURL-auth, inspect the login action and domain shown before approving it. Do not treat an unexpected payment amount or a request to import a seed into the website as an ordinary part of the authentication protocol.

Breez's SDK authentication guide demonstrates the relevant boundary: parse the request, display its domain and action for confirmation, then derive a key and respond. It documents an implementation following LUD-04 and LUD-05; it does not establish that every Lightning wallet has identical menus or supports this login.

The domain boundary is more precise than a brand name

Under the BIP32 derivation specification, LUD-05, the full service domain participates in generating the linking key. A change of authentication subdomain can therefore produce a different identifier. The important value is the authentication endpoint's domain, which might differ from the familiar brand name or the page where a login button appears.

These are illustrative hostnames, not claims about a real service. They show why 'one account per website' is too vague. The specification explicitly warns a service to keep its chosen authentication subdomain stable. For a user, a changed profile after a domain migration may be an identity-mapping problem rather than a lost Lightning payment.

Separate cryptographic identity from the service's profile

A stable linking key lets one service recognize the same login over time. The service may attach an order history, settings or other account records to that identifier. If you later add an email login or link another wallet through the service's own account controls, you are deliberately adding relationships beyond the original domain-specific key.

This is not merely theoretical account design. LN Markets' account documentation describes linking one or more Lightning wallets to a credentials account. That is a product-specific example of an intentional connection between login methods, not an endorsement of the platform or a claim about all LNURL-auth services.

Browser state is another layer. MDN's cookie guide explains how session cookies allow a site to recognize later requests from a signed-in browser. Replacing an email/password login with LNURL-auth does not, by itself, disable a site's session management or tracking choices. Read the service's privacy and retention information separately.

Why the same seed is not a universal migration guarantee

LNURL-auth identity depends on wallet derivation as well as the service domain. LUD-04 acknowledges that seed formats and wallet designs differ, so universal portability is not achieved simply by calling every application a Lightning wallet. A balance successfully restored in a different app is not proof that the app reproduced the former service's linking key.

There is also a separate signMessage-based derivation specification, LUD-13, for wallets without access to the same master-key derivation interface. Its sensitive internal derivation material must not be shared as a login credential. Users should use the wallet's supported authentication flow rather than sign and disclose an arbitrary message offered as an identity-repair shortcut.

The Bitcoin Company's LNURL-auth help article warns that losing the wallet's key can mean losing access when there is no fallback login. Its exact account menus and fallback availability are product-specific. For any service, verify the current recovery policy before removing the only working wallet or deleting an old installation.

A privacy and recovery check before depending on wallet login

1. Confirm that the wallet and service actually support LNURL-auth. A Lightning payment address is not proof of login support.
2. Read the authentication domain and requested action in the trusted wallet. Approve only a login or account-linking action you intended.
3. Check whether the service stores additional profile information and whether you have linked email, another wallet or other identifiers.
4. Record the original wallet application and its supported backup requirements without copying private credentials into support messages.
5. Before a migration, verify login continuity through the service's supported method while you still have working access.
6. If a different profile appears, compare domain, wallet derivation and account links before assuming either a balance loss or an account deletion.

For an authentication problem, useful support information includes the public service domain, wallet version, approximate time and the action you attempted. A login challenge, private derivation key or seed is not a substitute for a supported recovery process. Keep authentication evidence separate from transaction receipts: a successful login does not prove a payment, and a paid invoice does not prove control of an unrelated website account.

If your original question was about a payment rather than login, use the separate explanation of Lightning Address and LNURL. KOT.CASH's no-account swap is a different service flow, described in how it works. This discussion does not claim that KOT.CASH offers LNURL-auth or accepts an authentication QR as an exchange payout instruction.