NostrPX
NostrPX should not be treated like an active checkout product today. The public trail points to a registered domain and a NWC-shaped payment context, but not to a reachable service, codebase, documentation set or public operator identity you can rely on.
NostrPX is a name to verify, not a product to assume
NostrPX sits in the most sensitive part of the Nostr ecosystem: the payment edge where a name can lead a reader toward a wallet connection, Lightning invoice, Nostr Wallet Connect permission or checkout flow. That is why it deserves a page even when the public trail is thin. A dead payment link is not harmless background noise. It is a place where a future typo, clone, domain sale or revived service can ask for money-moving trust.
The important current fact is that NostrPX is not verifiable as an active service from the normal public trail. The domain `nostrpx.com` exists in RDAP records, but the hostname does not resolve to a working website during this review. Exact-name searches do not surface a public GitHub repository, official documentation set, package, app store listing, maintained Nostr profile or clear operator announcement. That makes it different from tools such as NakaPay, BTCPay Server, BitcoinLink or Flash, where the product trail is visible.
Read this profile as a practical caution page. If you encounter the NostrPX name in an old NWC diagram, a saved screenshot, a directory entry or a wallet app suggestion, do not jump from the name to the trust decision. Start from the evidence that exists today. If the project is revived later, the first question is not whether the label sounds familiar. The first question is whether the revived trail proves continuity with the original operator and explains exactly what permissions it asks from your wallet.
What can be verified today
The strongest verifiable artifact is the domain record. Verisign RDAP reports `NOSTRPX.COM` as a registered dot-com domain with Cloudflare, Inc. as registrar. The record shows registration on March 22, 2023, an expiration date of March 22, 2033, Cloudflare nameservers `leia.ns.cloudflare.com` and `sergi.ns.cloudflare.com`, and DNSSEC delegation data. Cloudflare RDAP repeats the same domain name and shows redacted registrant data, including a country code of Japan and a Kanagawa region value in the public registrant object.
That does not prove a product is operating. It proves that the name was registered and remains delegated. A registered domain can be a parked asset, a disabled product, a private experiment, a service waiting for deployment, a project that moved elsewhere, or a domain that still exists after the site stopped serving users. Payment readers should not treat registration length or DNSSEC as endorsement. They are infrastructure facts, not product facts.
The second verifiable fact is absence from the obvious active surfaces. The current getAlby `awesome-nwc` repository does not show a NostrPX entry. GitHub repository search for the exact name does not reveal an obvious official project. The public site is not reachable from the normal hostname. That combination is enough to classify NostrPX as unresolved today, even if it once existed as a payment idea, prototype or private NWC experiment.
What cannot be verified
A reader cannot currently verify a working checkout flow, supported wallet list, fee schedule, refund process, invoice state machine, NWC permission set, webhook behavior, account model, source code license, security policy or operator support channel. Those are not optional details for a commerce tool. They are the evidence that turns a payment name into something a merchant can test safely.
The most important missing piece is operator continuity. If a future NostrPX page appears, you need to know whether it is controlled by the same person or team who registered and originally promoted the name, or whether it is a new user of a familiar domain. The Nostr world makes identity portable, but payment services still need a public trail: signed Nostr posts, linked keys, repository history, release notes, domain proofs and support contacts that agree with one another.
You also cannot verify custody. A payment tool could be non-custodial, custodial, invoice-only, NWC-connected, LNURL-based, zaps-focused or simply a redirector. Without docs, there is no way to know. That is why this page does not call NostrPX a wallet, exchange, social client or active payment processor. The safer classification is a dormant NWC payment reference until the service provides enough public evidence to narrow the description.
Why dormant payment entries are risky
Dormant names are unusually risky in Bitcoin and Nostr because users can recognize a label before they understand the current trust path. A name that once appeared near NWC tooling can later be copied into a fake website, used by a different project, revived with new custody assumptions, or paired with a QR code that asks for a wallet connection. Familiarity is not authentication.
The risk is sharper with Nostr Wallet Connect. NWC is designed to let an app talk to a wallet over Nostr relays. That is powerful when the app is real and the permissions are scoped. It is dangerous when the app identity is unclear, because a connection string may authorize invoice creation, payment requests, balance checks or other wallet actions depending on the wallet and permission set. A stale brand can become a live permission request very quickly.
A normal website link can waste your time. A payment link can move funds, expose account metadata, or train you to approve dangerous prompts. That is why the right answer for NostrPX today is not curiosity-driven clicking through random mirrors. It is controlled verification: official domain first, public identity second, code and docs third, wallet permissions last.
How NWC would likely matter if NostrPX returns
The name appears in a finance and payment context, so the natural technical question is whether it was meant to use Nostr Wallet Connect. NWC is defined around NIP-47. It uses Nostr relays as a message transport between an application and a wallet service. The app receives a connection string containing a wallet public key, relay information and a secret, then sends encrypted requests through that relay.
That design is useful because it separates a user-facing app from a wallet. A checkout product can ask the wallet to create invoices, check payment state or perform permitted actions without holding the wallet itself. It also means the security boundary is the connection. If a product's identity is unclear, the connection is not a convenience detail. It is the object you should refuse until the app proves who it is and what it needs.
If NostrPX is revived as an NWC tool, the minimum docs should list exact NWC methods, permissions, relay choices, budget controls, expiration behavior, revocation path, fee handling, logging, error states and supported wallets. A serious payment tool should also show testnet or small-sat test paths, not ask users to jump straight into a production wallet connection.
The domain record is not enough
RDAP is valuable because it gives you public domain facts. It can tell you the registrar, nameservers, dates, status flags and sometimes a redacted registrant region. For NostrPX, those records show a real domain, not a typo invented out of thin air. That matters. But RDAP does not tell you what code runs behind the name, who controls the application server, whether the site is safe, or whether the service has any continuity with older references.
DNSSEC is similar. The domain has DNSSEC delegation data in RDAP, which is a good infrastructure signal when a site is otherwise alive. But DNSSEC does not make a missing site trustworthy. It protects DNS answers from certain kinds of tampering when the zone is configured, not from a bad product, a new operator, a weak wallet permission model or a future phishing page.
A payment reader should treat domain data as the first layer only. The next layers are HTTP reachability, TLS certificate identity, visible product docs, signed releases, Nostr key proofs, wallet permission explanations, code repositories, and independent mentions that point to the same operator. NostrPX currently stops before most of those layers.
The missing website changes the decision
A missing website is not automatically suspicious. Small Nostr projects disappear, rebuild, move domains, lose hosting, pause development, or keep prototypes private. But a missing website does change the user decision. You cannot evaluate a payment service from a logo, a memory or a directory label. You need docs and a working test path.
For NostrPX, the current website state means there is no visible onboarding flow to inspect. You cannot see whether it asks for NIP-07 signing, NWC, LNURL, a Lightning address, an API key, a custodial balance, a merchant dashboard or a hosted invoice. You also cannot inspect whether it has privacy terms, fee explanations, support contacts or a shutdown notice. The silence is itself a finding.
The practical rule is simple: do not connect a wallet to a project whose current website and official identity you cannot verify. If someone shares a new NostrPX URL, check whether it is actually `nostrpx.com`, whether DNS and TLS are sane, whether the page links to a public Nostr key, and whether that key can be traced through signed posts or older records.
Exact-name searches are part of due diligence
Payment due diligence should include boring searches. Look for the exact project name, domain, GitHub owner, npm package, Nostr profile, release notes and support channel. For active NWC products, those searches usually reveal a public trail: documentation, code, wallet app entries, blog posts, changelog mentions or community support threads. Thin results do not prove fraud, but they lower the trust ceiling.
NostrPX currently has that low-trail profile. The exact name does not produce the kind of public evidence you would expect from an active payment product. That matters more than general search noise. Search engines can produce unrelated results for almost any short name, so you should focus on exact matches, domains, repository names and signed identity links rather than broad keyword pages.
If a future NostrPX launch appears, a fresh search should become richer. You should be able to find an official announcement, docs, a code or issue trail if the project is open source, a Nostr profile that posts the same domain, and wallet ecosystem mentions that link back to the same place. If the only proof is a single checkout page, keep your wallet closed.
How to evaluate a revived NostrPX
A revived NostrPX should prove domain control and project identity before it asks for wallet access. The site should publish a Nostr public key, link that key from the domain, and post a signed note from that key explaining the product status. If there was an earlier operator, the new announcement should explain continuity or ownership change. A silent relaunch is not enough for a payment tool.
The second test is documentation. You should be able to read what the product does in plain terms: merchant checkout, payment links, zap routing, invoice generation, API access, wallet connection, accounting, refunds, subscriptions or something else. The docs should also state whether the service is custodial, non-custodial, hybrid or merely a frontend to a user's own wallet.
The third test is a small controlled payment. Use a wallet with strict NWC limits, tiny balances and revocable permissions. Pay a minimal invoice. Watch the wallet, the app state and any webhook or dashboard record. Revoke the connection and test that the app cannot continue. If those tests are confusing, do not scale usage just because the name appears in a Nostr context.
Nostr identity proof should be explicit
Nostr gives projects a way to publish durable public keys, but readers still need to verify how a key belongs to a service. NIP-05 can map a name at a domain to a public key. Signed posts can announce a domain. A website can link to an `npub`. A repository can point to the same key. The stronger the cross-linking, the harder it is for a clone to borrow trust from a familiar name.
For NostrPX, no official Nostr identity is visible enough to rely on today. That is why any future `npub` claiming the name should be treated as unproven until it is tied to the domain and to public project artifacts. A random profile name is not ownership. A profile picture is not ownership. Even a long history of posts is not ownership unless it links to the payment domain and product context in a verifiable way.
If you are evaluating a Nostr payment project, look for consistency. Does the website link the profile? Does the profile link the website? Does the NIP-05 domain match? Do release notes, documentation and package names use the same identity? If not, slow down. Identity confusion is where wallet permissions become dangerous.
Wallet permissions are the real product boundary
A payment product may look like a web page, but its real boundary is the permissions it receives. In an NWC setting, the wallet decides what the app can ask for and under what limits. Some wallets support budgets, expiration, method scopes and revocation. Others may expose fewer controls. The product should make this visible before the user grants access.
For a revived NostrPX, the safe permission model would be narrow. A checkout app that only needs invoice creation should not ask for broad payment rights without a clear reason. A merchant tool that needs to collect fees should explain how fees are charged. A zap-related product should distinguish public zap receipts from private wallet state. A dashboard should not need spending authority unless it performs payments on behalf of the user.
You should create a dedicated wallet connection for any new payment app, not reuse a broad connection from another service. Name it clearly, set a low budget, set an expiration if available, and revoke it after testing. If NostrPX returns without explaining how to revoke access, that is a reason to wait.
Zaps, LNURL and NWC are easy to confuse
Nostr payments can involve several overlapping ideas. Zaps are Nostr-aware Lightning payments described by NIP-57. LNURL-pay gives a wallet a way to fetch invoice details from a server. NWC lets an app talk to a wallet over Nostr relays. A product can use one of these, combine several, or use none of them while still accepting Lightning invoices.
That distinction matters for NostrPX because the public name alone does not tell you which path applies. A zap tool handles social payment receipts and event references. A merchant checkout handles order state. An NWC app handles wallet permissions. An LNURL endpoint handles invoice negotiation. Each path creates different privacy, custody, failure and support questions.
If a future NostrPX page says it supports Nostr payments, ask for specifics. Does it create NIP-57 zap requests? Does it use NWC for wallet control? Does it accept LNURL-pay? Does it simply display a Lightning invoice? The answer decides what you need to verify and what can go wrong.
No repository means no code review path
Not every payment service is open source, and a hosted service can still be legitimate. But the absence of a public repository removes one useful review path. You cannot inspect dependencies, release cadence, issue history, license, build instructions or security discussions. For a dormant project, that absence makes it harder to distinguish a paused product from a placeholder.
A revived NostrPX does not have to publish every backend secret to be trustworthy. It should, however, make the client boundary understandable. If it provides an SDK, the SDK should be public. If it provides a web widget, the widget should explain what data leaves the browser. If it asks for NWC, the request and response behavior should be documented well enough for wallets and merchants to test.
Code is not the only evidence, but it is especially helpful in Nostr because the ecosystem values portable clients and inspectable protocols. A payment product that depends on a closed hosted backend should compensate with excellent docs, clear operator identity, security contacts, terms, privacy explanations and a test mode.
A dormant domain can come back under different assumptions
Domains can stay registered for years while products change. An owner can relaunch with a new backend, sell the domain, move the project, or point the DNS at a temporary site. The RDAP record for NostrPX currently shows a long future expiration date, which means the domain may remain available as a visible name even without a live service.
That is useful and risky at the same time. It means a legitimate operator could return. It also means a reader might later see a live page and assume it is the same thing they once saw in a Nostr payment context. Do not make that assumption. Continuity has to be proven by signed identity links, archived announcements, repository history or other public evidence that survives the outage.
If the site returns, compare dates. When did DNS change? When was the TLS certificate issued? When did the Nostr profile announce the relaunch? When was the code first pushed? When were docs published? A real revival can answer these questions. A confusing revival will ask you to trust quickly.
Merchant use would need extra evidence
A merchant payment tool has responsibilities beyond taking a Lightning invoice. It needs order records, status transitions, expiration behavior, duplicate-payment handling, webhook retries, fee records, refund policy, support paths and accounting exports. Without those details, a merchant cannot safely connect revenue to the product.
For NostrPX, none of those merchant features can be evaluated today. That means it should not be used as a production checkout candidate. If someone recommends it as a payment processor, ask for current docs, a live demo, customer references, public changelog, wallet compatibility list and clear custody model. The burden of proof belongs to the payment tool, not to the reader.
The standard should be higher for merchant revenue than for a weekend experiment. A small test with a disposable wallet is one thing. Real customer payments are another. If a NostrPX successor wants merchants, it should publish exactly how a payment becomes a paid order and how a merchant can reconcile that order later.
Privacy questions start before the first payment
Payment tools can see more than money. Depending on design, they may see IP addresses, browser data, invoices, Lightning addresses, Nostr public keys, order metadata, webhook URLs, wallet relay choices and timing patterns. A service does not need custody of funds to create a privacy footprint.
Because NostrPX has no current privacy policy or docs to inspect, you cannot know what data a revived service would collect. That is another reason not to use unofficial mirrors or clones. If the official site returns, privacy language should be part of the first review, not a document you read after connecting a wallet.
A good Nostr payment tool should let users minimize data. It should avoid unnecessary personal fields, explain metadata retention, keep NWC secrets out of logs, and make webhook data predictable. If NostrPX returns without a privacy explanation, treat that as an unfinished payment product.
How to test safely if a live page appears
Use a dedicated test wallet with a tiny balance. Do not connect your main Lightning wallet or your main NWC-enabled node first. Check the domain manually. Check the certificate. Search the exact name again. Look for a signed Nostr post from a linked key. Read the docs before scanning anything.
If the app asks for NWC, inspect the permissions in your wallet UI. Prefer a connection that can only create invoices or perform the narrow action you need. Set a budget and expiration. Save the connection name. Confirm you can revoke it. Then perform a tiny payment and watch every state: wallet, app, invoice, relay, receipt and any dashboard record.
After the test, revoke the connection and repeat the action that previously worked. The app should fail clearly. If it still has access, you learned something important. If the wallet UI cannot show or revoke the permission, use a different wallet for testing. The safest payment experiment is one you can end.
How to spot a clone
A clone often tries to compress trust into urgency. It may use a familiar name, a copied logo, a rushed wallet prompt, a slightly different domain, a social profile with few posts, or a screenshot of an old ecosystem diagram. Payment clones do not need to be sophisticated if users connect wallets too quickly.
For NostrPX, the clone risk is straightforward: the real public trail is thin, so a convincing fake would not have much to contradict. That makes verification more important, not less. A legitimate relaunch should welcome slow checking. It should publish enough identity evidence that a careful reader can follow the trail without private messages or guesswork.
Never treat search rank as proof. Never treat a Telegram link as proof. Never treat a wallet app recommendation as the whole proof if the external site and Nostr identity are unclear. Use multiple public signals that point to the same operator and same domain before any payment permission.
Where NostrPX belongs in your mental map
Think of NostrPX as a payment-tool name with unresolved status. It is not a social client. It is not currently a wallet you can evaluate. It is not an exchange. It is not a relay. The strongest available context is NWC and Lightning payment tooling, but the active product details are missing.
That category matters because different Nostr projects fail in different ways. A dormant social client may simply not load your feed. A dormant relay may drop events. A dormant media tool may lose uploads. A dormant payment tool can become a risky trust decision if a user mistakes a name for evidence and connects a wallet.
The right mental model is therefore conservative: bookmark the name as unresolved, keep the page for future verification, and do not use the name as evidence by itself. If NostrPX becomes active again, evaluate it like a new payment product with an old domain, not like a known app that merely had a short outage.
What would make this profile change
This assessment should change if the project publishes a reachable official website, a signed Nostr identity, documentation, a clear custody model, a wallet permission list, a code or SDK trail, a support channel and a testable payment flow. The article is not trying to freeze NostrPX as dead forever. It is describing the evidence available now.
A strong revival would also explain history. Was NostrPX a prototype? Was it paused? Did the operator change? Was the domain always owned by the same person? Why is the current launch trustworthy? Payment users do not need a long apology, but they do need enough context to avoid confusing a relaunch with a copy.
Until that happens, the safest public guidance is direct: do not connect funds, do not paste NWC strings, do not scan unknown payment codes, and do not build merchant checkout around NostrPX. Watch for a verifiable return, then test with tiny limits.
The practical verdict
NostrPX is worth tracking because the name sits close to Nostr payments, and payment names can become operational risks even when the product is dormant. The domain record is real. The active product trail is not. That split is the whole story today.
For a reader, the decision is simple. Treat NostrPX as unavailable unless a future official trail proves otherwise. If you are a merchant, use active, documented tools with visible operators and testable payment flows. If you are a wallet user, keep NWC permissions away from anything that cannot prove its identity and scope.
The most useful thing a NostrPX page can do right now is prevent false confidence. A familiar name is not a wallet permission. A registered domain is not a checkout. A remembered app entry is not operator proof. With Nostr and Lightning, patience is a security feature.
Sources worth opening
Open the domain and RDAP records first, then compare the NWC, NIP-47, zaps, LNURL and wallet-permission references so you can judge any future NostrPX revival by evidence rather than by a familiar name.
- NostrPX domain
- Verisign RDAP record for NOSTRPX.COM
- Cloudflare RDAP record for nostrpx.com
- Cloudflare explanation of SOA records
- Cloudflare explanation of DNSSEC
- crt.sh certificate search for nostrpx.com
- getAlby awesome-nwc project list
- Nostr Wallet Connect official site
- Nostr Wallet Connect documentation
- NIP-47 Nostr Wallet Connect specification
- NIP-57 Lightning zaps specification
- NIP-05 identifier verification specification
- NIP-19 bech32 entity encoding specification
- NIP-46 remote signing specification
- NIP-65 relay list metadata specification
- Nostr protocol NIPs repository
- Nostr official website
- Nostr.how protocol overview
- Nostr.how guide to zaps
- Alby blog introducing Nostr Wallet Connect
- Alby Hub Nostr app connection guide
- Bitcoin Magazine article on Nostr Wallet Connect
- The Bitcoin Manual NWC risk analysis
- Breez SDK Liquid NWC guide
- LNURL LUD-06 pay request base specification
- LNURL LUD-09 successAction specification
- GitHub repository search for NostrPX
- DuckDuckGo exact search for NostrPX
