CraysRizful
Rizful gives Nostr users a browser-based Lightning wallet with NWC codes, Lightning Addresses, NIP-05 identity and a deliberately conservative account model.
A Lightning vault for Nostr users
Rizful is a browser-based Lightning wallet built for the moment when a Nostr user wants to receive zaps, connect a wallet to apps, and make small payments without running their own node. The home page calls it a free, easy-to-use homebase for Bitcoin on Lightning. That description is plain enough: Rizful is meant to be an account a normal person can open, use from any browser, and connect to Nostr clients through Lightning Address and Nostr Wallet Connect.
That makes Rizful different from a pure mobile wallet and different from a self-hosted node stack. A mobile wallet usually lives on one device. A self-hosted node stack asks the user to manage infrastructure. Rizful lives on the web. It offers a hosted account, a personal Lightning Address, NWC codes, browser notifications, QR receiving, on-chain swaps, gift cards and docs for connecting popular Nostr clients.
The product is therefore best read as a practical Nostr payments vault. It is not trying to be a social client. It is not trying to be cold storage. It is not asking the reader to understand channel management on day one. It gives people a Lightning endpoint that can receive zaps, fund small payments and sit behind apps that already speak NWC.
The operator is the Megalith Node team
Rizful is presented as a project from the people behind The Megalith Node. The Rizful home page says that team runs Megalith LSP, Megalith Lightning Docs and the Lightning Power List, and says the team has been working with web applications since 2010 and Bitcoin since 2013. The GitHub profile for MegalithicBTC lists Megalithic.me and Rizful.com together and describes Rizful as a way to run a Lightning node instantly in the cloud.
That operator context matters because Rizful is a hosted wallet service. A hosted wallet is not only code. It is liquidity, routing, uptime, account security, withdrawal behavior, fee policy, customer support and server operation. The home page leans into that point by emphasizing fast Lightning payments, high uptime and the central routing position of the Megalith Node.
A reader should still keep the category straight. Operator experience can make a hosted wallet more useful. It does not turn a hosted wallet into a hardware wallet. The trust surface is the point: Rizful can be convenient because it handles operational work for the user, and the same convenience means the user should keep meaningful long-term savings somewhere else.
What a Rizful account gives you
A basic Rizful account gives the user a Lightning wallet surface in the browser. The home page lists free receiving, Lightning payments, a personal rizful.com Lightning Address, on-chain receiving and sending through swaps, NIP-05 identity, browser access across devices, NWC, optional 2FA, USDT sending and Bitcoin gift cards. The breadth is the product pitch: one web account can cover many small-payment cases.
The Lightning Address is the most visible receiving feature. A Rizful user can claim an address that looks like an email address and can receive payments from wallets, apps and Nostr clients that support Lightning Address or LNURL-Pay. Rizful says each account can have up to fifteen Lightning Addresses, each with its own balance and ledger. That is useful for separating projects, identities or test flows.
The Nostr identity feature sits beside the payment address. Rizful says existing Nostr users can import a public key and that it will not ask for a private key. Public NIP-05 checks confirm the normal Nostr pattern: a name query against rizful.com returns a public key. The important detail is that Rizful connects to the public key, not the private key. The user's Nostr signing key does not need to become the wallet login.
Rizful's conservative key model
Rizful's integration demo is blunt about its philosophy. It argues that many normal users will paste private keys into unsafe apps, misplace them, or forget where their sats are stored. Rizful therefore separates wallet access from the user's nsec and uses an email/password account with optional two-factor authentication instead of asking for a Nostr private key.
That choice will not satisfy everyone. Some users prefer pure key-based systems and dislike any account recovery model based on email. Rizful is making the opposite tradeoff: it wants a user who loses a Nostr key to avoid losing wallet access at the same time. It also allows privacy-preserving email choices, so the account model does not have to mean a normal personal inbox.
This is a real design decision, not a footnote. In a Nostr wallet, the most tempting shortcut is to let a social key become the money key. Rizful rejects that shortcut. The result is less cyberpunk and more recoverable. Readers should decide whether that fits their risk model. If they want maximum sovereignty, they may prefer a self-custodial wallet. If they want simple NWC onboarding and recoverability, Rizful's model may fit.
Nostr Wallet Connect is the main app bridge
Nostr Wallet Connect is the bridge between Rizful and the rest of the app ecosystem. NIP-47 lets an app talk to a wallet over Nostr relays. The app can request payment-related actions without becoming the user's wallet. For Rizful, that means a Nostr client such as Primal, Damus, Amethyst or Jumble can use Rizful as the wallet behind its zaps.
Rizful's docs show a repeatable pattern. The user opens NWC in Rizful, creates a connection code, copies it, and pastes it into the app's wallet settings. For Primal, the guide tells users to turn off Primal Wallet and paste the Rizful NWC string. For Damus, it tells users to paste a NWC address in wallet setup. For Amethyst, it uses the zap settings. For Alby Go and Alby Extension, Rizful becomes the backend wallet through NWC.
This broad integration story is why Rizful belongs in the NWC ecosystem map. It is not merely a Lightning Address provider. It is designed to be the payment backend for many apps. The reader's task is to know what kind of NWC code is being created, which app receives it, and whether that code can spend funds or only receive payments.
Read-only NWC and send-and-receive NWC are different
Rizful's docs separate read-only NWC codes from send-and-receive NWC codes. That distinction is one of the most useful things a wallet can teach. A read-only connection is for receiving payments and checking information; it should not be able to spend the vault balance. A send-and-receive connection can spend from the vault and must be treated like a sensitive credential.
The send-and-receive docs are direct about the danger. A code that can spend from the vault should only go into apps the user trusts. Rizful recommends unique names, deleting old codes, setting spending limits and expiration dates, and never sharing the code publicly. That is exactly the kind of behavior NWC needs if it is going to move beyond hobbyist setups.
Readers should use that distinction aggressively. If an app only needs to display a receiving address or receive zaps, start with read-only. If an app needs to send zaps or pay invoices, use the smallest useful spending limit. Give each code a name that identifies the app. Delete codes after experiments. A forgotten NWC string is not harmless just because it came from a familiar wallet.
The OAuth-like onboarding flow
Rizful's integration demo shows a second path for app developers: an OAuth-like flow that gives a Nostr client a NWC URI and a Lightning Address. The user can sign up or sign in to Rizful, open a Rizful token page, receive a one-time code, paste that code into the client, and let the client exchange it together with the user's public key.
The demo's response includes a NWC URI, a Lightning Address and the public key used for the integration. The README tells developers to keep the NWC code on the user's device whenever possible, apply the Lightning Address to the user's profile metadata, and optionally use the Lightning Address as a NIP-05 identifier. That is a complete onboarding loop for a Nostr client that wants zaps without making every new user shop for a wallet first.
The security lesson is just as important as the convenience. The demo warns that a NWC URI is sensitive and should not be written to a server unless the developer is truly sure it can be handled securely. That advice should be treated as product law. A wallet onboarding shortcut is only good if it avoids creating a hidden custody or spending risk for the user.
Lightning Address and zaps
Rizful's Lightning Address support is not only a nice-looking address. It connects to LNURL-Pay, the convention that lets a wallet or app resolve a human-readable address into payment instructions. Public LNURL checks for Rizful addresses show a pay request response with minimum and maximum sendable values, a callback endpoint, identifier metadata, optional comments, and Nostr zap support fields.
The `allowsNostr` field in those LNURL responses matters for zaps. NIP-57 uses LNURL-Pay and Nostr metadata to attach Lightning payments to Nostr identities and events. If a Nostr profile advertises a Rizful Lightning Address, a zap-capable client can resolve that address and prepare a zap request. The user does not need to expose a private key to Rizful for that receiving path.
A Lightning Address is still a public payment endpoint. If a person uses the same Rizful address across many apps, people may connect those activities. If a person wants separate identities, the ability to create multiple addresses and ledgers becomes useful. The practical question is not only whether the address works. It is whether it belongs to the identity the user wants to expose.
NIP-05 identity is useful but narrow
Rizful's NIP-05 feature lets a user associate a rizful.com identifier with a Nostr public key. A NIP-05 record is a DNS-based identity proof. It tells clients that a domain is willing to vouch that a given name maps to a given public key. It is not a login system, not custody, and not proof that the person is trustworthy.
The practical benefit is profile clarity. A user can have a readable identifier and a Lightning Address on the same domain. That can simplify app setup and make profiles look less raw. Rizful's guides often tell the user to copy their public key from the Nostr client back into Rizful and then set the profile's Lightning Address. The result is an identity and payment surface that line up.
Readers should still treat NIP-05 as a pointer, not as a passport. The domain operator can change records. The user can change keys. A verified-looking name can still behave badly. For Rizful, the value is convenience and discoverability around zaps. The private key remains outside Rizful, and the NIP-05 check should not be confused with money custody.
On-chain swaps, USDT and gift cards
Rizful is not limited to Lightning invoices. The home page and docs describe on-chain receiving and sending from a Lightning balance, including inbound on-chain payments that are credited to the Lightning balance. There are also pages for sending Lightning funds to on-chain Bitcoin, sending on-chain Bitcoin into Lightning, sending small USDT payments from the Bitcoin balance, and creating Bitcoin gift cards.
These features matter because many users do not live entirely inside Nostr zaps. Someone might receive sats from a Nostr post, move some value to a Bitcoin address, share a gift card with a friend, or use a small USDT transfer where local conditions make that useful. Rizful is trying to be a spending and receiving account for near-term value, not a single-purpose zap button.
The risk language should stay honest. Swaps add fees, counterparties and timing assumptions. USDT adds a different asset with different legal, custody and issuer risks. Gift cards depend on who holds the claim code and whether it has already been redeemed. Those tools can be useful, but they make the vault less simple. Use them for small amounts first and keep records.
Browser-first is a feature and a compromise
Rizful has no native App Store or Google Play app, and its FAQ explains that the product works through the browser instead. The docs show how to use Rizful from any mobile web browser and how to add it to a phone home screen. Browser notifications are also documented, with special instructions for iPhone and iPad users who need to add the site to the home screen first.
That browser-first approach has advantages. It works on desktop, phone and tablet without waiting for app-store approval. It makes setup links and docs easier to share. It also fits the Nostr habit of switching between web clients and mobile clients. A person can manage the wallet in one browser and use it as an NWC backend somewhere else.
The compromise is that browser wallets have their own security chores. Users must protect the account password, browser session, email inbox, 2FA app and recovery codes. They should also be careful with shared computers, browser extensions and phishing links. A web wallet can be convenient, but it is not magically safer than a native wallet. It simply moves the security boundary.
Security starts with 2FA and recovery codes
Rizful's safety page says two-factor authentication is mandatory for accounts that hold more than 100,000 sats. It also tells users never to share 2FA codes with anyone, including support staff. That is a concrete threshold and a concrete habit. A user who keeps any meaningful balance in Rizful should enable 2FA before the balance grows.
Recovery codes deserve the same attention. Rizful says recovery codes are the only way to access the account if the 2FA device is lost. That means they should be stored like wallet recovery material: offline, private and durable. Losing access to the email account, password and 2FA recovery path can turn a convenient wallet into a problem at exactly the wrong moment.
The safety page also fits the broader wallet advice from the home page. Rizful is not a cold-storage replacement. Use it for funds expected to move on Lightning soon. Keep long-term bitcoin on an offline or hardware-controlled setup. That is not an insult to Rizful. It is the right separation between spending money and savings.
Privacy is practical, not absolute
Rizful's privacy policy recommends using a VPN and privacy-preserving email. That is unusual enough to mention. It also says Rizful collects email address information to manage the account and stores data needed to operate hosted Lightning node services. For public Lightning channels on the node side, it explains that public channel data becomes visible in the network graph.
For the main Rizful vault user, the practical privacy issue is linkability. A rizful.com Lightning Address can be public. A NIP-05 identifier can be public. NWC connections can tie a wallet to apps. Zaps can reveal support relationships. If a person uses one address everywhere, the convenience comes with a visible pattern.
The remedy is not to avoid the tool; it is to use the right compartments. Use a privacy-preserving email if that matters. Avoid reusing one address for every identity. Keep test vaults separate from main vaults. Use read-only codes where possible. Do not put a spend-capable NWC string into random web experiments. Privacy in a wallet like Rizful is mostly discipline.
Test vaults are a serious best practice
Rizful's docs include a page on setting up test vaults for NWC. That advice is worth highlighting because NWC experimentation can go wrong quietly. A person may paste a send-capable code into an app that stores it badly, or a developer may test against a real wallet because it is faster than setting up a sandbox.
A test vault changes the blast radius. It lets the user try a new client, BTCPay plugin, website integration or app demo with a small amount of money. If the code leaks, the app misbehaves or the user misunderstands the permissions, the main vault remains separate. This is especially important when testing send-and-receive NWC codes.
The same practice helps developers. The Rizful demo makes it easy to build an onboarding flow, but developers still need to treat returned NWC strings as secrets. Use a test vault. Keep secrets client-side unless there is a carefully reviewed reason not to. Log less than feels convenient. Delete test credentials after use. Wallet onboarding should be boring by design.
Where Rizful fits against other wallets
Rizful sits between several wallet categories. It is easier than running LNbits or a node. It is more Nostr-specific than a generic exchange account. It is more recoverable for normal users than a pure private-key wallet that has no account path. It is less sovereign than a self-custodial mobile wallet or a hardware-backed setup.
That middle position is useful. A new Nostr user can receive zaps with a Lightning Address, connect to Primal or Damus through NWC, and keep the account recoverable through email and 2FA. A merchant or developer can test BTCPay Server or a website integration without running Lightning infrastructure on day one. A power user can create separate vaults and codes for different experiments.
The wrong use case is long-term storage. Rizful says this itself. A hosted browser vault is spending money, receiving money and app money. It is not the place for savings that should survive service outages, account compromise, legal pressure or a lost 2FA path. The right comparison is a useful Lightning account, not a bank vault or hardware wallet.
What to check before using it
Start with the account. Use an email address you can keep secure, preferably privacy-preserving if that matters. Set a strong password. Enable 2FA early, not after a balance grows. Store recovery codes offline. Confirm that you can log in from the devices you actually use, and add the browser app to your phone home screen if that is your workflow.
Then set the payment identity. Choose a Lightning Address you are comfortable sharing. If you want NIP-05, set the correct Nostr public key and verify it from another client. If you use multiple Nostr identities, consider multiple addresses or vaults. Send a tiny payment in and out before publishing the address widely.
Finally manage NWC like a password drawer. Create read-only codes where possible. Create send-and-receive codes only for trusted apps. Name every code. Set spending limits and expiration dates. Delete stale codes. Test new integrations with a small vault. Keep long-term bitcoin elsewhere. Rizful is useful when it stays small, clear and deliberately connected.
The durable lesson
Rizful shows a practical side of Nostr payments. It does not ask every reader to run Lightning infrastructure. It does not ask them to put an nsec into a wallet. It gives them a web vault, a Lightning Address, NIP-05, NWC codes and a set of guides for real apps. That is why it appears in the NWC ecosystem beside more technical wallets.
The tradeoff is visible and should remain visible. Rizful is hosted, account-based and browser-first. It can be excellent for zaps, small balances, onboarding, app testing and everyday Lightning use. It should not be treated as cold storage. The user must protect email, password, 2FA, recovery codes and NWC strings.
For a reader choosing a Nostr wallet, Rizful is worth considering when convenience and broad app compatibility matter more than maximum sovereignty. Use it as a working wallet, not a savings vault. Keep permissions tight. Verify the Lightning Address and NIP-05 records. Let small, successful payments prove the setup before trusting it with anything meaningful.
Sources worth opening
Open the Rizful home page first, then the First Steps docs, NWC code docs, app integration guides, safety page, privacy policy, demo integration repository, NIP-47, NIP-57, NIP-05 and the LNURL documents behind Lightning Addresses and zap receiving.
- Rizful official site
- Rizful manifest
- Rizful official 512 icon
- Rizful First Steps
- Use Primal with Rizful
- Use Jumble.social with Rizful
- Use Amethyst with Rizful
- Use Damus with Rizful
- Use Alby Extension with Rizful
- Use Alby Go with Rizful
- Use BTCPay Server with Rizful
- Get a read-only NWC code from Rizful
- Get a send-and-receive NWC code from Rizful
- Easy onboarding flow for Nostr clients
- Set up test Rizful vaults with NWC
- Rizful FAQ
- Use Rizful on phone or tablet
- Rizful browser notifications
- Rizful QR payments
- Swap Lightning to on-chain Bitcoin
- Swap on-chain Bitcoin to Lightning
- Send USDT from a Lightning balance
- Rizful gift cards
- Rizful safety guidelines
- Rizful privacy policy
- Rizful terms
- MegalithicBTC GitHub profile
- Rizful integration demo repository
- Rizful integration demo README
- Rizful integration demo app source
- Rizful NIP-05 example lookup
- Rizful LNURL-Pay example lookup
- NIP-47 Nostr Wallet Connect
- NIP-57 zaps
- NIP-05 DNS identifiers
- LNURL LUD-06 payRequest base spec
- LNURL LUD-16 Lightning Address
