CraysVortex
Vortex puts a NWC wallet inside Raycast: send to invoices or Lightning Addresses, create receive invoices, inspect recent transactions, and redeem Cashu or LNURL vouchers without opening a full wallet app.
A wallet in the command palette
Vortex is best understood as a Lightning wallet remote control for people who already live in Raycast. It is not trying to become a full mobile wallet, a node manager or a social Nostr client. Its product idea is narrower and more useful: press the Raycast shortcut on macOS, type a command, and move through a payment action without changing context.
That framing matters because Vortex uses Nostr Wallet Connect as a bridge to a wallet somewhere else. The extension stores a NWC connection string in Raycast preferences, creates a `NostrWebLNProvider` from Alby's SDK, and calls wallet methods through that provider. The money is not held by Raycast or by Vortex. The money remains in the connected wallet service or node that issued the pairing URI.
The result feels closer to an operator panel than a consumer wallet app. A user can pay an invoice, send to a Lightning Address, create a receive invoice, view recent transactions and redeem vouchers. Each command is small, fast and shaped around Raycast's keyboard-first interface.
Where the project lives
The public code lives at `getAlby/Vortex`. GitHub describes the repository as `The fastest way to use bitcoin on macOS`, and the README repeats that line before explaining that Vortex controls a Bitcoin Lightning wallet directly from Raycast. The repository was created on February 17, 2024 and was still public and not archived when checked.
The project is MIT licensed, written in TypeScript, and small enough to audit command by command. GitHub's repository metadata showed four stars, two forks and one open issue when checked. Those numbers describe a focused utility rather than a large wallet company, and they are the right mental model for the reader.
The author field in `package.json` is `saunter`, while the repository sits under the Alby GitHub organization. The README lists wallet connection examples such as Alby Accounts, Mutiny, Umbrel and Start9. That does not mean Vortex is limited to those providers. It means the remote wallet must be able to create a Nostr Wallet Connect app connection.
The Raycast surface is the product
Raycast extensions are packaged around commands, preferences and assets. Vortex's `package.json` declares the extension name `vortex`, the title `Vortex`, the category `Finance`, the icon `vortex.png`, and two preferences. The first preference is a required password field named `nwcurl`; its placeholder is `nostr+walletconnect://...`. The second preference lets the user pick USD, EUR or GBP for fiat display.
The command list is compact. `send` accepts an optional text argument and is described as sending to a Lightning Address or paying a Lightning invoice. `createinvoice` is labeled Receive and can take an amount argument. `listtransactions` shows recent transactions. `redeem` accepts an optional LNURL or Cashu token and is labeled Redeem Sats.
That design suits Raycast because the extension can use selected text, clipboard text, inline arguments and command actions. Vortex does not need a long dashboard. It needs precise inputs, validation, a few forms and clear confirmations. The product wins when the user can move from copied invoice to payment review in a few keystrokes.
NWC is the wallet boundary
The connection code is intentionally short. `src/utils/wallet.ts` reads Raycast preferences, takes the saved NWC URL, creates a new `webln.NostrWebLNProvider` with `nostrWalletConnectUrl`, calls `enable()`, and returns the provider. Every wallet command depends on that helper.
This makes the boundary easy to explain. Vortex does not parse seed phrases, run a Lightning node or custody a balance. It delegates to the remote wallet that issued the NWC connection. The provider turns Raycast actions into wallet requests, and the remote wallet answers through the Nostr relay path defined by the pairing string.
For readers, the most important operational question is not whether Vortex has a balance. It is what the connected wallet allows this particular NWC connection to do. Spending limits, permissions, expiry, relay choice, invoice creation and transaction visibility belong to the wallet service and the NWC app connection.
What Send actually accepts
The Send command accepts two broad input shapes: BOLT11 Lightning invoices and Lightning Addresses. If no argument is supplied, the command tries to read selected text first and then the clipboard. That is the classic Raycast advantage: a user can highlight an invoice on the screen, launch Vortex and let the command prefill it.
The code treats invoices as strings starting with `lnbc`, then uses `Invoice` from `@getalby/lightning-tools` to inspect the payment request. A blank or amountless invoice is not paid. The payment form displays the amount and any decoded description before the user submits the action. When submitted, Vortex connects to the NWC wallet and calls `sendPayment`.
Lightning Addresses follow a different path. Vortex validates the address against a regular expression, fetches LNURL-pay data through `LightningAddress`, checks that a callback is present, and then asks the user for an amount. If the user enters a fiat amount instead of sats, Vortex converts it with Alby's fiat helpers before requesting a Lightning invoice from the address.
Lightning Address payments are opinionated
The Lightning Address component shows why Vortex is more than a thin invoice paste box. It fetches metadata from the address, surfaces the address description, respects whether comments are allowed, and offers two actions: send payment directly or copy the requested invoice. That gives the user a chance to use Vortex as either a payment tool or an invoice resolver.
The component converts sats to millisats for checking the LNURL min and max bounds. If the requested amount is outside the range, it stops before payment. After a valid invoice is returned, Vortex checks that the invoice amount matches the requested satoshi value. That is a valuable guardrail because a Lightning Address server is part of the payment flow.
The tradeoff is speed. A command palette payment tool can become very quick, especially when it reads from selection or clipboard. That is good for routine small payments, but it raises the bar for careful review. The reader should verify the recipient, amount and description before submitting, especially when the input came from copied text.
Receive is a small invoice station
The Receive command asks for an amount and an optional description. It can switch between satoshi input and the configured fiat currency. If fiat mode is active, the extension calls Alby's fiat helper to estimate the satoshi amount before creating the invoice.
After connecting to the NWC wallet, Vortex calls `makeInvoice` and expects a payment request back. It renders a QR code as markdown with the `qrcode` package, prefixes the QR payload with `lightning:`, and shows metadata for amount, description and status. The invoice can be copied to the clipboard from the action panel.
The command also polls settlement. Every 1.5 seconds it calls `lookupInvoice` on the provider, stops after a fixed counter, and marks the invoice as paid if the wallet reports a paid invoice with a preimage. This is a useful desk workflow: create invoice, show QR, wait for the payer, copy if needed, and return to work.
Recent Transactions is also the balance view
Vortex previously had a separate balance function, but the changelog says the balance view was removed and folded into recent transactions. In the checked code, `ListTransactions.tsx` calls `listTransactions({})`, calls `getBalance()`, formats the balance in sats, and also fetches a fiat value for the selected currency.
Transactions are shown with incoming and outgoing icons, amounts in sats, optional fiat equivalents, descriptions and settlement times. Opening details exposes metadata such as amount, fiat amount, description, settled-at time, payment hash, preimage and fees paid. The action panel lets the user copy the preimage or payment hash.
This view is useful, but it also demonstrates a privacy consequence of NWC permissions. If a connection can call `listTransactions` and `getBalance`, the interface can display wallet history and balance data. That may be exactly what a trusted desktop tool needs, but it should not be granted casually to every app connection.
Redeem covers LNURL and Cashu
The Redeem command is where Vortex becomes more interesting than a basic NWC demo. It reads selected text or clipboard text and looks for `lnurl`, `cashu` or `web+cashu://` inputs. If the input is an LNURL withdraw code, Vortex decodes the bech32 payload, fetches the callback data, validates the withdraw format and then presents a withdraw form.
For LNURL withdraw, the component lets the user choose an amount between the server's minimum and maximum. It then creates a Lightning invoice through the connected NWC wallet and sends that invoice back to the LNURL callback with the `k1` challenge. If the server returns `OK`, the voucher has been redeemed into the connected wallet.
Cashu redeem is more complex. Vortex decodes the token with `@cashu/cashu-ts`, requests a melt quote from the mint, creates an invoice from the connected NWC wallet, sends enough proofs to cover the quote amount and fee reserve, and then melts the proofs. That means Vortex can turn ecash tokens into Lightning balance without being a full Cashu wallet.
Cashu support has real limits
The Cashu path is useful, but it is not a full ecash custody model. Vortex handles a token presented to it and attempts to melt it into the connected Lightning wallet. It does not present itself as a mint manager, token database, multi-mint portfolio or offline ecash wallet.
The checked code asks the mint for quotes and uses the token unit when constructing the Cashu wallet object. The January 2025 changelog says Vortex added support for Cashu tokens with all units, which matches the code's attention to unit price and fee conversion. That is important because not every Cashu token is necessarily denominated in plain satoshis.
A reader should still treat Cashu redeem as an interaction with a mint. Mint availability, token validity, fees, unit conversion and quote state all matter. If the mint is down, malicious, incompatible or slow, Vortex can surface an error but cannot make the mint behave.
The changelog tells the maintenance story
The changelog has four useful milestones. The initial version is dated December 22, 2023. On May 17, 2024 a bug was fixed around Lightning Addresses with no custom key/value records. On January 12, 2025 the balance function was removed, transaction details were improved, Cashu tokens and LNURL redeem were added, inline parameters were added and dependencies were updated.
The January 26, 2025 changelog added fiat invoice creation, fiat Lightning Address payments and Cashu token support across units. The latest commit returned by the GitHub API was a February 4, 2025 merge that updated the changelog and cleaned code after the fiat transaction work.
There were no GitHub releases returned by the releases API when checked. Raycast extensions are usually installed through the Raycast Store rather than GitHub release artifacts, so that is not automatically a problem. It does mean that repository commits, the Store page and the Raycast extension version are the useful public signals.
Dependency age is worth checking
The checked `package.json` asks for `@getalby/sdk` `^3.5.1`, `@getalby/lightning-tools` `^5.0.3`, `@cashu/cashu-ts` `^2.1.0`, `@raycast/api` `^1.74.1` and `@raycast/utils` `^1.18.1`. The checked lockfile resolved those to Alby SDK 3.8.2, lightning-tools 5.1.2, cashu-ts 2.1.0, Raycast API 1.88.4 and Raycast utils 1.18.1.
The npm registry currently shows much newer major versions for the Alby SDK, lightning-tools and cashu-ts. That does not prove Vortex is broken, because extensions can deliberately stay on stable older APIs. It does mean maintainers or advanced users should review dependency changes before assuming the current ecosystem behavior matches a 2025 lockfile.
This is especially relevant for NWC and Cashu because both areas have moved quickly. NIP-47 has continued to clarify request kinds, response kinds, notification kinds and encryption expectations. Cashu libraries and NUTs have also evolved. A command palette that can spend should be kept boring, current and easy to audit.
NIP-47 details behind the shortcut
Nostr Wallet Connect is the protocol that lets an app request wallet actions over Nostr. The current NIP-47 document defines request events, response events and wallet notifications, and the common connection URI starts with `nostr+walletconnect://`. Vortex asks the user for exactly that kind of string.
From the user's point of view, the connection string is a delegated capability. It is not the same thing as a normal website login. It can grant a desktop extension the ability to ask a wallet to pay invoices, create invoices, list transactions or return balance information depending on how the wallet connection was configured.
That is why pairing should be done with small limits first. A good NWC wallet lets the user create an app-specific connection, label it, cap it, revoke it and inspect what it can do. Vortex becomes safer when the wallet side has clear permissions and a spending ceiling that matches command-palette usage.
Raycast preference storage matters
Vortex marks the NWC connection field as a Raycast password preference. That is better than a plain visible field, and it fits the way Raycast extensions are configured. Still, the NWC URL is a powerful secret. Anyone who can read or reuse it can potentially act through the app connection until the wallet revokes or limits it.
The article reader does not need to know Raycast internals to use this wisely. The practical rule is simple: create a dedicated NWC connection for Vortex, do not reuse the same connection across many tools, keep the spend limit low, and revoke the connection if the Mac, Raycast profile or exported configuration becomes untrusted.
A keyboard launcher can make payment flows pleasant, but it also sits close to the clipboard and selected text. Vortex's discovery behavior is useful, and it is also a reason to keep review steps visible. Fast does not mean invisible; the user still needs to see what will be paid.
What Vortex is not
Vortex is not Zeus, Phoenix, Alby Hub, Mutiny or a node package. It does not run channels. It does not manage liquidity. It does not expose peer configuration. It does not claim to be a mobile wallet or a full account dashboard. Its job is to make a remote wallet usable from Raycast.
It is also not a Nostr social app. It uses Nostr because NWC uses Nostr relays and Nostr keys to connect a wallet service to an app. The visible product is still Lightning money movement, not posting, following, long-form writing or direct messaging.
That distinction helps the reader choose the right tool. If someone wants a general Lightning wallet, Vortex is incomplete by design. If someone wants a macOS command palette for a wallet that already supports NWC, Vortex is exactly in the right shape.
Who gets the most value
Vortex is strongest for Mac users who already trust Raycast, use Lightning frequently and have an NWC-capable wallet with sensible app permissions. It is especially attractive for people who receive invoices in chats, browsers, issue trackers or documents and want to pay without opening a separate wallet window.
It is also useful for people who receive Lightning Address requests or LNURL/Cashu vouchers as text. The selected-text and clipboard discovery flows can save time when a QR code is not involved. The receive command is handy for quick desk invoices, especially because it can show a QR and watch for settlement.
The least suitable user is someone who wants a beginner wallet with extensive onboarding, backup education and guardrails. Vortex assumes the reader understands what a NWC pairing string is, where the wallet balance lives and why app-specific limits matter.
What to check before using it
Before using Vortex with meaningful funds, check the Raycast Store page, the repository activity, the installed extension version and the current issue list. Then inspect the wallet-side NWC permission screen. The best connection is a fresh one labeled for Vortex, with a low spend limit and an easy revoke path.
Also test each command with tiny amounts. Pay one small invoice. Send to a Lightning Address you control. Create a small receive invoice. Load recent transactions and confirm the extension is showing what you expect. Redeem a low-value LNURL voucher or Cashu token before trusting larger values.
Finally, treat clipboard and selected text with care. Vortex's speed is real, and that speed is the reason to review inputs deliberately. The extension can be a very good desk tool when the wallet permissions are narrow and the user keeps final confirmation human.
Why it belongs in the NWC map
Vortex is a clean example of why Nostr Wallet Connect is broader than browser wallets. The app does not need to own a wallet backend to become useful. It can live in a macOS command palette, read a delegated wallet connection, and turn tiny daily payment tasks into native desktop actions.
It also shows how NWC can combine with older and adjacent Lightning conventions. BOLT11 invoices, Lightning Addresses, LNURL withdraw vouchers, fiat conversion helpers and Cashu tokens all appear in one compact extension. Nostr is the control path, but the user sees practical payment objects.
That makes Vortex a useful project to study even for readers who will never install it. It demonstrates a pattern: wallet services can expose permissioned capabilities, and small tools can build specialized interfaces around those capabilities without becoming banks, nodes or social clients.
The reader takeaway
Vortex is a sharp little macOS tool for people who already know what they are connecting. Its appeal is not a giant feature list. Its appeal is that a payment, an invoice, a transaction lookup or a voucher redeem can happen from the same keyboard surface used for the rest of a Mac workflow.
The caution is equally direct. A NWC connection is spending authority and wallet visibility, not just a harmless API key. Keep it scoped, keep it revocable, keep the balance exposure small and check that the extension is still maintained enough for the wallet software you use today.
Used that way, Vortex is one of the better examples of NWC as plumbing for everyday tools: small, fast, permissioned and useful because it disappears into a workflow the user already has.
Sources worth opening
Useful entry points are the Raycast Store page, the `getAlby/Vortex` repository, the README, `package.json`, the command files in `src/`, the changelog, Awesome NWC, NIP-47, the Alby SDK, Cashu's NUT specifications and the LNURL/LUD documents.
- Vortex Raycast Store page
- Vortex GitHub repository
- Vortex README
- Vortex package.json
- Vortex changelog
- Vortex wallet connection helper
- Vortex Send command
- Vortex Receive command
- Vortex Recent Transactions command
- Vortex Redeem command
- Vortex Lightning Address payment component
- Vortex invoice payment component
- Vortex Cashu redeem component
- Vortex LNURL redeem component
- Vortex Cashu redeem utilities
- Vortex constants and validation helpers
- Vortex type definitions
- Vortex GitHub API repository metadata
- Vortex GitHub commits
- Awesome NWC Wallet Interfaces listing
- nwc.dev
- NIP-47 Nostr Wallet Connect
- Alby JavaScript SDK
- Alby SDK npm package
- Alby Lightning Tools repository
- Alby Lightning Tools npm package
- Cashu TypeScript library
- cashu-ts npm package
- Cashu NUT specifications
- Cashu documentation
- LNURL LUD specifications
- Lightning Address
- Raycast extension documentation
- Raycast preferences documentation
- Raycast clipboard API
- Raycast forms API
- Raycast lists API
- BOLT11 payment request reference in lightning-tools usage
