CraysCashu Redeem
Cashu Redeem turns a Cashu token into a Lightning payment path. The useful question is not whether it looks simple, but where the token, mint trust, melt quote, invoice and leftover change actually live.
A redeemer, not a full wallet
Cashu Redeem does one job: it helps a user turn a Cashu ecash token into a Lightning payment. The live app gives the user a field for the Cashu token and either a Lightning destination or a connected wallet. The README describes the product as a simple web application for redeeming Cashu ecash tokens directly to a Lightning wallet via Lightning Address or Bitcoin Connect. That is the correct frame. Cashu Redeem is not trying to be Cashu.me, Minibits, Nutstash or a complete ecash wallet. It is a bridge from a bearer token to a Lightning invoice.
That makes the page useful for a very specific moment. Someone receives a token string, an encoded token or an emoji version of a token and does not want to keep it as ecash. They want the value delivered to a Lightning wallet, Lightning Address or LNURL-pay compatible endpoint. Cashu Redeem gives them a browser surface to paste the token, choose the destination path, request a melt quote and complete the redemption.
The narrowness is good, but it should not be mistaken for safety by itself. Ecash redemption is a money movement. The app touches a token, a mint, a Lightning invoice, local change proofs and possibly a wallet provider. If any of those pieces are misunderstood, a simple looking redeem button can still lose money.
Cashu tokens are bearer instruments
Cashu's own documentation describes ecash as a digital bearer token stored on the user's device, similar to physical cash. That sentence is the starting point for Cashu Redeem. A token string is not just a receipt. It can contain spendable proofs. Anyone who has a valid unspent token can try to redeem it. The privacy and portability benefits come from that bearer model, and so do the handling risks.
Cashu Redeem decodes the token with `getDecodedToken` from `@cashu/cashu-ts` and checks that the token contains proofs and a unit. It then reads the mint URL from the token and loads that mint. The mint matters because the proofs are only useful if the issuing mint recognizes and redeems them. A Cashu token is not a universal Lightning invoice. It is a claim against a particular mint's ecash system.
For a reader, the habit is simple: keep the token private until redemption is complete. Do not paste tokens into random pages. Do not leave token strings in public notes, shared chat history or screenshots. If the token has already been redeemed or stolen, Cashu Redeem cannot make it good. It can only ask the mint and Lightning destination to perform the redemption that the token still permits.
What happens when you paste a token
The validation flow starts by making sure the token input is not empty. Cashu Redeem then decodes the token and verifies that proofs and unit information exist. If the user has the include-change setting enabled, the app merges locally stored change proofs from the same mint and unit into the token proofs before estimating value. That choice can be convenient because it sweeps old leftovers into the next redemption, but it also means local browser state can affect the amount that is melted.
After decoding, the app creates a Cashu wallet object for the mint and calls `loadMint`. It calculates keyset fees with `getFeesForProofs` and estimates the token's satoshi value through helper functions that create a small mint quote and parse the returned invoice. The amount used for the first redemption preview is the estimated value minus keyset fees. This is not a random UI guess. It is derived from the mint's own current quote behavior and the token proofs.
The result is a state where the app knows enough to ask for a Lightning invoice. If a connected wallet provider is present, it asks that provider to make an invoice. If not, it looks for a Lightning Address or LNURL input. Only after it has an invoice does it ask the Cashu mint for a melt quote. That sequence protects the user from pushing a token toward a destination before the destination can actually produce an invoice.
Lightning Address, LNURL or Bitcoin Connect
Cashu Redeem offers two broad destination paths. One path is a connected wallet provider through Bitcoin Connect. The other is a text input for Lightning Address or LNURL. Both are ways to request a Lightning invoice for the amount being redeemed, but they feel different to the user. A connected wallet keeps the destination inside the wallet connection. A Lightning Address or LNURL asks an external pay endpoint to create an invoice.
The Lightning utility code makes that split visible. If the source is a Lightning Address, the app fetches address metadata and calls `requestInvoice` with the satoshi amount. If the source looks like a WebLN provider with `enable` and `makeInvoice`, it enables the provider and calls `makeInvoice`. If the source has LNURL pay fields such as callback, minSendable, maxSendable and metadata, it checks the amount range and calls the callback with the amount in millisatoshis.
This gives users flexibility, but it also gives them more ways to make a mistake. A typo in a Lightning Address can send value to the wrong endpoint or fail. An LNURL endpoint can reject the amount. A connected wallet provider can be unavailable or mis-scoped. Cashu Redeem is a bridge, so both sides of the bridge must be correct: the Cashu token must be valid, and the Lightning destination must create the invoice the user actually wants paid.
The melt quote is the moment to slow down
A Cashu melt quote tells the wallet what the mint will do to pay a Lightning invoice from ecash proofs. Cashu Redeem has a preview setting for this step. When preview melt quotes are enabled, the user sees a modal with the amount to be melted, the fee reserve and the amount available to redeem. The user can accept or reject the quote before the app continues.
The default settings in the code are include change enabled and preview melt quotes disabled. That means the app can move quickly for ordinary use, but a careful user should understand the setting. If you are redeeming a tiny test token, automatic redemption may be fine. If you are redeeming a larger token, a multi-unit token or a token from a mint you do not know well, previewing the quote is the more careful path.
Fees and reserves matter because the number on a token is not always the exact number that reaches the Lightning invoice. The app subtracts keyset fees during estimation and later uses `meltQuote.amount - meltQuote.fee_reserve` when calculating the amount to melt. A reader should expect small differences and should use the quote preview when the exact satoshi result matters.
Why the app asks for a second invoice
The redemption code first creates an invoice to obtain an initial melt quote. When the user accepts, the app calculates the amount that can actually be redeemed after fee reserve, asks for a second invoice for that final amount, creates a new melt quote for the second invoice and then selects the proofs to send. This two-step shape is easy to miss if you only look at the interface.
The second invoice helps line up the final Lightning amount with the amount available after the quote. The app then calls `cashuWallet.send` with the new quote amount plus fee reserve and the token proofs. That produces proofs to keep and proofs to send. The app melts the send proofs with `meltProofsBolt11`, receives any change and then combines keep plus change as final proofs.
This is why Cashu Redeem is more than a paste-and-pay form. It is doing real wallet work: selecting proofs, accounting for fees, paying a Lightning invoice through the mint and keeping leftovers. That work is exactly where bugs can matter. The README's warning that the project could contain bugs that lose money should be read as an honest product boundary, not as a legal decoration.
Change lives in your browser
Cashu redemptions can produce change. Cashu Redeem stores change proofs and mint URLs in localStorage. The change utilities read a `mints` array and a `proofs` array, remove proofs that were used, add new proofs and calculate stored change by mint and unit. The app also has a View Stored Change screen that groups visible change by mint and unit and totals it by currency.
This is convenient because the app can sweep old change into a later redemption when include change is enabled. It is also a sensitive browser-state decision. Proofs are bearer value. If the browser profile is shared, backed up insecurely, synced unexpectedly, compromised by malware or left on a public device, stored change can become exposed. LocalStorage is not a hardware wallet.
After using Cashu Redeem, check stored change. If the app says there is change, either redeem it, move it into a wallet you control or treat that browser profile as holding spendable value. Clearing browser storage can remove access to that change. Leaving it behind can leak value. Both mistakes come from forgetting that a small web app can hold real bearer proofs after the main redemption appears finished.
URL parameters make automation possible
Cashu Redeem can read a token and a Lightning destination from URL parameters. It looks for `token`, and for destination values under `lightning`, `ln` or `to`. It also reads an `autopay` parameter. The code validates input from those parameters and can melt automatically when the conditions match. This is useful for integrations, but it increases the need to inspect links before using them.
A prefilled redemption link can be helpful in a controlled workflow. A service might generate a link that sends a specific token to a specific Lightning Address. A wallet might hand off a token to a redeemer page. A user might bookmark a routine destination. But a link can also hide the destination from a hurried user. If the token and destination are both in the URL, the URL itself contains the money path.
Before opening automated redemption links with meaningful value, read the visible destination and consider disabling automatic behavior by using the normal form flow instead. Autopay is a convenience for small, well-understood amounts. It is not a substitute for knowing which mint issued the token, which Lightning endpoint will receive the invoice and whether quote preview is enabled.
Emoji support is playful but still money
Cashu Redeem includes an emoji decoder. The interface labels it with a joke about the e in ecash standing for emoji, and the component links to an emoji encoder project. The feature is playful, but the decoded result can still be a real Cashu token. Once decoded into the token field, it follows the same redemption path as a normal token string.
That makes emoji tokens a good reminder of Cashu's portability. Ecash can be passed around as text, QR codes, links, images or silly-looking encoded strings. The presentation layer does not change the bearer nature of the value. If the decoded token is valid and unspent, the app can try to redeem it. If someone else has already decoded and redeemed it, the app cannot recover it.
The right habit is to separate fun encoding from value handling. It is fine to enjoy the culture of ecash tokens moving through chats and memes. When you are redeeming, slow down enough to confirm that the decoded token, mint and Lightning destination make sense.
The Cashu trust model does not disappear
Cashu improves privacy by using Chaumian ecash and blind signatures, but every Cashu token still depends on a mint. The mint issued the proofs, knows its own keysets and must be available and willing to melt those proofs into a Lightning payment. Cashu Redeem can load the mint and request quotes, but it cannot make an insolvent, offline or dishonest mint redeem.
That distinction is essential for readers coming from ordinary Lightning wallets. A Lightning invoice is a payment request. A Cashu token is ecash issued by a mint. Redeeming the token into Lightning means asking that mint to pay an invoice. If the mint fails, the redemption fails. If the mint's fees or unit behavior differ from expectation, the amount can differ. If the token was double-spent, the proofs may be rejected.
Use Cashu Redeem with the same caution Cashu's own documentation suggests for new ecash systems. Small amounts are the right default. Trusted mints matter. Tokens from strangers deserve extra caution. A successful melt is satisfying because it turns portable ecash into a Lightning payment, but the trust assumptions do not vanish just because the interface is clean.
Where Nostr enters the story
Cashu Redeem is in the NWC ecosystem map because Bitcoin Connect can provide a wallet connection path that includes Nostr Wallet Connect. The app itself does not publish notes, manage a Nostr profile or run a social client. Its Nostr relevance sits at the payment-connection layer: a user can connect a wallet provider that gives the app a WebLN-style interface for invoice creation.
The important thing is not to overstate that connection. Cashu Redeem's core work is Cashu token redemption. NWC or Bitcoin Connect can be the invoice source, but Lightning Address and LNURL are also first-class paths. A user can redeem without caring about Nostr if they paste a Lightning Address. A Nostr-aware wallet user can redeem through a connected provider. Both flows are legitimate.
That makes Cashu Redeem a useful example of how Nostr can be infrastructure rather than the public product surface. The reader sees a token field and a redemption button. Under the hood, the payment destination may be a wallet connection, a Lightning Address or an LNURL callback. Nostr is valuable when it helps the wallet connection stay permissioned and portable.
What to test before using real value
Start with a tiny token from a mint you already trust. Redeem to your own Lightning Address first. Confirm that the invoice is created, the melt quote appears when preview is enabled, the payment arrives and any change is visible in the stored-change panel. Then clear or move the change so you understand where it lives.
Next, test the connected wallet path. Use Bitcoin Connect with a wallet connection that can make invoices but cannot spend funds. Redeem another tiny token and verify that the destination wallet receives the payment. Then disconnect and confirm the app no longer has that provider available. If your wallet uses NWC behind the provider, know where to revoke that connection.
Finally, test a prefilled link only with dust amounts. Use the `token` and destination parameters, observe what the form does, and decide whether autopay is appropriate for your workflow. Cashu Redeem is useful because it makes redemption fast. The safest way to use it is to learn the slow path first, then decide which shortcuts deserve trust.
Sources worth opening
Open the live app, the repository, the token and Lightning utility files, the change storage code, the tests and the Cashu protocol sources together. Cashu Redeem is easiest to understand when the simple form is read beside the exact melt and change handling.
- Cashu Redeem live app
- Cashu Redeem GitHub repository
- Cashu Redeem README
- Cashu Redeem package dependencies
- Cashu Redeem main page flow
- Cashu Redeem Cashu utility functions
- Cashu Redeem Lightning utility functions
- Cashu Redeem change storage utilities
- Cashu Redeem settings hook
- Cashu Redeem melt quote modal
- Cashu Redeem settings component
- Cashu Redeem stored change display
- Cashu Redeem emoji decoder
- Cashu Redeem tests
- Cashu Redeem site manifest
- Cashu official website
- Cashu documentation
- Cashu protocol documentation
- Cashu NUT specifications
- Cashu TypeScript library repository
- cashu-ts npm package
- Alby Bitcoin Connect repository
- Alby Lightning Tools repository
- Lightning Address LUD-16
- LNURL pay request LUD-06
- Lightning BOLT 11 invoice specification
- NWC introduction
- NIP-47 Nostr Wallet Connect
- WebLN specification
- Emoji encoder reference project
