CraysBoardwalk Cash
Boardwalk Cash sits at the edge between Cashu ecash, Lightning payments and Nostr wallet connections: easy to open, useful for small payments, and important to understand before trusting it with funds.
An ecash wallet with a public Lightning face
Boardwalk Cash is not a normal Nostr social client. It is a wallet surface. The live site introduces it as a way to send and receive cash, its metadata names Bitcoin, Lightning, Cashu, ecash, Nostr and Nostr Wallet Connect, and the installable PWA starts at a wallet route rather than at a feed. That first impression matters because the product touches Nostr through payment connectivity, not through posting, following or reading notes.
The wallet layer is Cashu. Boardwalk asks you to add a mint before the wallet becomes useful, and the warning pages are direct about the relationship: Boardwalk itself does not provide mint custody. A Cashu mint issues and redeems ecash, while the wallet stores the tokens and presents the spending interface. That is a very different trust model from a bank-style account and also different from a self-custodial Lightning node.
The public face is Lightning. Boardwalk exposes Lightning Address receiving and can create invoices through its wallet infrastructure, so a person or app can send money to an address-like identifier instead of asking for a fresh invoice every time. Nostr enters when wallet authority, identity and payment automation need to be connected. That makes Boardwalk Cash a wallet article first, with Nostr as an important control and discovery layer.
The live Boardwalk surface is small on purpose
Open boardwalkcash.com and the browser sees a concise web app rather than a long exchange dashboard. The manifest names Boardwalk Cash, uses a standalone PWA display mode, and starts the installed app at /wallet. The visible copy and metadata are built around ease: a web wallet that can be opened quickly, installed and used for small ecash and Lightning flows.
The setup flow is more important than the landing copy. Boardwalk asks you to add a mint, checks the mint, prefers mints that support the right units, and points toward public mint discovery. The page does not hide that the mint is the monetary counterparty. If the mint is bad, offline, illiquid, censored or mismanaged, the wallet interface cannot make the ecash safe by itself.
This is the right level of friction for a Cashu wallet. If a web wallet lets you hold bearer tokens, it should force a mint decision into view. Boardwalk is easy to open, but it is not pretending that ease removes custody questions. The interface invites a fast first test, while the warning pages keep pointing back to the hard question: which mint are you trusting, and how much money should sit there?
The warnings are part of the product
Boardwalk's warning text is unusually useful because it says the quiet part plainly. Boardwalk Cash describes itself as a self-custodial wallet interface for payments on your own device, but it also says the Cashu mints are third-party custodians. That distinction is the whole product risk in one sentence: the wallet can hold your tokens locally while the issuer of those tokens still matters.
The older public warning flow says ecash tokens, private keys and NWC access tokens are stored on the device and that Boardwalk cannot recover them for you. It also calls the app early beta and experimental. Those are not generic legal decorations. They are operational instructions. If browser storage is deleted, if a private window is used, if the device is lost or if a token is copied into the wrong place, the recovery story can be unforgiving.
A good Boardwalk test therefore begins with tiny value. Create or open the wallet, add a mint you have researched, send a small amount, receive a small amount, close and reopen the browser, and confirm exactly what survives. That habit is not paranoia. It is how you learn whether the wallet, mint, browser storage and Lightning path are all behaving before the balance matters.
Boardwalk became part of Agicash
The old public GitHub URL for Boardwalk Cash redirects into MakePrisms/agicash. That matters because the current repository is not just a frozen Boardwalk demo. It is a larger wallet codebase with a different architectural center: Agicash. The repo was active in June 2026, with recent dependency and monorepo work, so the code should be read as a living project rather than an abandoned landing page.
The Agicash README describes a React Router wallet deployed through Vercel with a custom Express development server. The workspace includes a web-wallet app, end-to-end tests and a wallet SDK package. The package list shows Cashu, Breez Spark SDK, Open Secret, Supabase, TanStack Query, Zustand, React 19, zod, QR tooling and Lightning invoice decoding. That stack says a lot about the product direction: this is no longer only a local browser experiment.
The architecture document is even clearer. Agicash splits the system into server, client, Open Secret secure enclave and Postgres database. The server serves code and can handle offline-style requests such as Lightning Address service, but the client initializes wallets and handles sensitive data. Open Secret manages authentication, wallet seeds, mnemonics and encryption keys inside an enclave. Supabase stores wallet data protected by row-level security, with sensitive records encrypted and decrypted client-side.
The trust model changed, not disappeared
The Agicash architecture improves parts of the older local-storage story, but it does not make trust vanish. Moving from a small PWA to an account-backed wallet stack changes where the risk sits. Now the user must understand the browser client, the Open Secret enclave, the Supabase database, the Cashu mints, Spark infrastructure and the hosted web app itself.
That can be a reasonable trade. A wallet that only stores everything in local browser storage is brittle for everyday use. A wallet that can authenticate a user, recover encrypted state, keep account records and sync data can be much more usable. But every added service becomes part of the dependency graph. Convenience moves some risk away from the browser and into the architecture.
For a reader, the practical question is not whether Boardwalk or Agicash is pure. No wallet is pure once it connects web apps, mints, Lightning, databases and hosted services. The practical question is what each component can see, what each component can lose, what each component can censor, and whether the amounts involved match that risk.
Cashu is the cash layer
Cashu is the reason Boardwalk can feel like digital cash instead of a normal account ledger. Cashu wallets hold signed bearer tokens issued by mints. The mint signs blinded outputs, the wallet stores the resulting proofs, and spending means presenting valid proofs back to a mint or swapping them into fresh proofs. The privacy goal is unlinkability between issuance and redemption, not a promise that the mint can never fail.
The Agicash code builds directly on @cashu/cashu-ts and wraps it with application-specific behavior. It maps BTC to sat units, maps USD to Cashu's usd convention for cent amounts, validates supported token units, normalizes mint URLs, checks test mints and builds an ExtendedCashuWallet around mint info, keysets, mint quotes, melt quotes and fee estimation. That is practical wallet code, not only a protocol reference.
The current shared Cashu code also shows strict mint expectations. It builds a validator that requires a set of NUT capabilities and WebSocket commands before treating a mint as suitable. That is important for Boardwalk users because Cashu is not one global server. Each mint can support different features, fee policies and units. A wallet that touches real money has to ask what the specific mint can actually do.
Mints are the hard custody question
The mint warning is not optional background. In Cashu, the mint is the issuer and redeemer of the ecash. If a mint disappears, refuses redemption, changes terms, loses liquidity or is compromised, the wallet interface can do little. Boardwalk can help hold and spend tokens, but it cannot turn a bad mint into a safe one.
Agicash's own mint risk text says mints issue ecash tokens and are responsible for custody, validation, issuance, redemption, valuation and authentication. It also says the relationship with a mint is between you and that mint. The public terms and privacy text explain that ecash has bearer-style behavior and that third-party services such as Cashu, Bitcoin, Lightning, Spark and mints affect reliability.
That means the useful review question is concrete. Which mint is selected? Does it support the required NUTs? Does it have public operators, terms, fees, units and liquidity information? Is it a test mint? Does it handle the currency you expect? How much would be painful to lose if that mint failed today? Boardwalk's interface is approachable, but the mint decision remains the center of the wallet.
Lightning Address turns the wallet outward
Boardwalk and Agicash are not only about holding Cashu tokens. They also expose Lightning receiving through LNURL-P and Lightning Address. In the code, the route for /.well-known/lnurlp/:username delegates to a LightningAddressService, which returns LNURL pay parameters for a username. That is the server-side piece that lets a human-readable address resolve into payment instructions.
The callback flow is more interesting. When the request is for a Cashu account, Agicash creates a Lightning receive quote through the selected Cashu wallet, records the receive quote and returns a BOLT11 invoice plus a verify URL. When the account is Spark-based, it builds a Spark receive quote instead. The same public Lightning Address can therefore hide different backend account types behind the wallet's default-account logic.
The code also adds privacy-aware detail. LNURL verify data is encrypted before it is placed into the verify URL, so the client checking settlement does not receive plain quote data. External Lightning Address requests are limited to BTC in the normal path to avoid exchange-rate mismatch. Those are the kinds of implementation details that separate a real payment service from a slogan about easy receiving.
NWC appears as payment authority, not social identity
Nostr Wallet Connect matters for Boardwalk because it is a way to let another app ask a wallet to do wallet things. In NWC, an app and wallet service exchange encrypted requests and responses through Nostr relays. The important methods are wallet methods: get_info, get_balance, make_invoice, pay_invoice, lookup_invoice, list_transactions and related commands. This is about payment authority, not timeline identity.
The older Boardwalk bundle includes NWC client usage for mintless Lightning mode. It stores an NWC URI and a Lightning address, checks that getInfo returns support for pay_invoice, uses getBalance, pays invoices through the NWC client and shows errors such as unauthorized, budget exceeded, rate limited, restricted or insufficient balance. That code treats an NWC connection as a spend path that can sit beside Cashu accounts.
This is why Boardwalk Cash belongs in the wider NWC ecosystem, but it should not be flattened into only NIP-47. NWC is one of the connection surfaces. Cashu is the ecash layer. LNURL and Lightning Address are the receive layer. Agicash account state and encryption are part of the modern wallet architecture. A useful user mental model keeps those layers separate.
Nostr Wallet Auth is a permission handshake
The older Boardwalk /connect bundle also includes a nostr+walletauth flow. That matters because Nostr Wallet Auth is not the same as pasting a ready-made NWC connection string. It is a handshake where an app asks for wallet access and the wallet can authorize a scoped relationship. The bundle parses app pubkey, relay, secret and required commands from the wallet-auth URL.
After parsing, Boardwalk builds an encrypted Nostr event, uses a kind in the 33194 range, and stores a connection with permissions that include getInfo, payInvoice and getBalance. It also includes a lud16 value so the app can learn the Lightning Address connected to the wallet. The details may evolve with NWA tooling, but the shape is readable: a wallet is granting limited command authority to another app.
That is an important UX direction for Nostr wallets. Copy-paste NWC strings are powerful but clumsy and easy to leak. A permission flow can be friendlier if it shows which app is connecting, which commands are requested, which relay is involved, and how to revoke the connection later. The hard part is not the protocol slogan. The hard part is making permission boundaries obvious enough for normal use.
Mint Connect points at deeper Cashu infrastructure
Boardwalk's older bundle also contains nostr+mintconnect handling. That flow is more specialized than everyday wallet use. It parses a signer public key, relays, a secret and a mint URL, then sends an encrypted event to a mint-connect request endpoint. The methods named in the bundle include issue_tokens, cashu_verify, deposit, deposit_status and metrics.
This is a sign that the MakePrisms ecosystem was exploring more than a wallet UI. Wallets, mints and reserve-style services need ways to talk about issuance, verification, deposits and metrics. Nostr-style event transport can be used as part of that coordination, but it is a different problem from a social app requesting one zap payment.
For Boardwalk users, the takeaway is not that every Mint Connect detail must be memorized. The takeaway is that Boardwalk sits near the boundary between a consumer wallet and infrastructure for Cashu services. When a wallet is close to mint operations, reserve flows and Nostr-mediated permission events, the safest posture is to treat every connection as a capability that needs context.
Spark sits beside Cashu in the newer stack
Agicash is not Cashu-only in its current architecture. The docs list Spark as an external component, the package manifest includes an Agicash build of Breez SDK Spark, and the Lightning Address service can receive into either Cashu or Spark accounts. That dual-account design matters because it shows the wallet trying to route payments through more than one backend.
Spark changes the payment shape. A Spark account can generate Lightning receive requests through the Spark wallet path, while a Cashu account depends on mint quotes and token issuance. In both cases, the public Lightning Address route can return an invoice. From the outside, a sender may only see an address. Inside, the wallet decides which account type is the default and which backend should handle the receive.
That design is useful, but it also adds more moving pieces. A problem may come from a Cashu mint, a Spark service, an LNURL route, a quote record, a hosted server, a browser client or the user's account configuration. Boardwalk Cash began as an easy ecash web wallet. The Agicash direction is closer to a multi-backend payment wallet.
What to check before trusting it
Use Boardwalk Cash with the habits of a payment tester. First, confirm the domain and app icon. Then read the warning and mint-risk pages. Add a mint only after checking its operator, units, NUT support, fees and public reputation. Send a tiny amount in, send a tiny amount out, and test the Lightning Address from another wallet. If any of those steps are confusing, stop before the balance grows.
Next, test persistence and recovery. Close the app, reopen it, switch browsers if that is part of your real use, and understand what can be restored. If you are using an older local-storage style flow, avoid private windows and know what browser cleanup will destroy. If you are using the newer Agicash account model, understand what Open Secret, encrypted database state and account credentials are responsible for.
Finally, treat every wallet connection like a spend permission. An NWC or wallet-auth relationship can let another app read balance, create invoices or pay invoices depending on granted commands. Check which app requested access, which relay is used, which commands are allowed and how the connection can be revoked. Boardwalk's promise is convenience at the edge of ecash and Lightning. Convenience is useful only when the authority boundary stays visible.
Sources worth opening
Open the live Boardwalk site, the redirected MakePrisms repository, the Agicash architecture notes, the Cashu NUTs, NWC docs, NIP-47 and the LNURL LUD documents together. The useful picture comes from comparing the product surface with the payment and storage code.
- Boardwalk Cash live site
- Boardwalk Cash web app manifest
- Boardwalk Cash warning page
- Boardwalk Cash setup page
- Boardwalk Cash connect page
- Boardwalk Cash wallet route
- Boardwalk Cash mint risks page
- Boardwalk Cash reserve documentation route
- Boardwalk Cash NIP-05 style nostr.json
- MakePrisms boardwalkcash repository redirect
- MakePrisms Agicash repository
- Agicash README
- Agicash architecture notes
- Agicash web wallet package manifest
- Agicash web app manifest route
- Agicash Lightning Address route
- Agicash LNURL callback route
- Agicash LNURL verify route
- Agicash Lightning Address service
- Agicash LNURL helpers
- Agicash send destination resolver
- Agicash shared Cashu wallet code
- Agicash Cashu utilities
- Agicash user repository
- Agicash mint risks markdown
- Agicash terms of use markdown
- Agicash privacy policy markdown
- Agicash mint customer terms
- Agicash mint privacy policy
- NWC.dev
- NWC docs introduction
- NWC reference API overview
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning zaps
- Cashu main site
- Cashu NUT specification index
- Cashu NUT-00 notation, models and wallets
- Cashu NUT-01 mint public keys
- Cashu NUT-02 keysets
- Cashu NUT-03 swap tokens
- Cashu NUT-04 minting tokens
- Cashu NUT-05 melting tokens
- Cashu NUT-07 token state check
- Cashu NUT-08 Lightning fee return
- Cashu NUT-10 spending conditions
- Cashu NUT-16 animated QR codes
- Cashu NUT-20 proof state subscriptions
- Cashu NUT-23 BOLT11 mint and melt methods
- LNURL LUD-06 payRequest
- LNURL LUD-16 Lightning Address
- LNURL LUD-21 verify
- BitcoinMints Cashu filter
- Open Secret
- Spark documentation
- Breez SDK Spark package family
- Supabase row level security guide
- MakePrisms terms page referenced by Boardwalk
