CraysBrick Wallet
Brick Wallet turns a Nostr Wallet Connect string into a small web wallet: send, receive, scan, paste, list history and hand the real money movement to the wallet service behind the connection.
A small web wallet for NWC
Brick Wallet is a deliberately simple browser wallet interface for Nostr Wallet Connect. The repository description says it plainly: a web frontend for NWC. The live app is served from SuperTestnet's GitHub Pages site, and the repository is mostly HTML, JavaScript and static assets. That makes the product easy to open, easy to inspect and easy to misunderstand if the word wallet is read too quickly.
The wallet part is the screen and the flow. A user can see a balance, send a payment, receive an invoice, scan QR codes, paste invoices, enter a Lightning Address and review a short transaction history. The custody part is somewhere else. Brick Wallet expects the user to connect a backend that already supports NWC, such as Bankify or another wallet service that can answer NIP-47 requests.
That distinction matters for readers. Brick Wallet is not a new Lightning node, not an account provider and not a social Nostr client. It is a control surface. The page turns a NWC pairing string into wallet actions, and those actions are executed by the wallet service named inside the connection.
SuperTestnet built it as a public experiment
The public repository is `supertestnet/brick-wallet`. GitHub lists the project as HTML, with a CC0-1.0 license, GitHub Pages enabled and a homepage at `https://supertestnet.github.io/brick-wallet/`. At the time checked for this article, the repository had nine stars, no forks, no open issues and was not archived.
The repository was created on September 11, 2024. The latest checked push was on February 10, 2026, and the most recent commits updated `chain_client.js` and `brick_wallet_for_testnet_generator.html`. That recent activity matters because Brick Wallet is not a frozen historical demo. It is a small public tool that has moved through several iterations.
SuperTestnet's wider GitHub profile also gives context. The account has a large set of public repositories and is associated with many small Bitcoin, Lightning, Nostr and protocol experiments. Brick Wallet fits that pattern: compact, public, permissively released and built for people who are comfortable testing sharp protocol edges.
The app has its own visual identity
Brick Wallet ships its own assets. The repository includes `favicon.ico`, `brick-wallet-logo.png` and a screenshot image named `brick wallet.png`. The live page declares the favicon from the Brick Wallet GitHub Pages origin, and the 512 by 512 logo gives the project a real hub icon without depending on a generic favicon service.
For readers, this is a small trust detail. A NWC interface asks for a sensitive connection string, so the page identity should be checked carefully. The icon alone is not proof of authenticity, but a real project asset is better than a guessed globe or a reused placeholder. The URL and repository still matter more than the picture.
In a crowded wallet directory, that real icon helps the reader separate Brick Wallet from nearby NWC tools with similar jobs. The logo points back to the actual project, while the page URL, repository and source links provide the evidence a cautious user should check before pasting a wallet connection.
The first prompt asks for serious authority
On first load, Brick Wallet checks whether it already has a saved NWC string. If it does not, the app opens a modal asking the user to enter an NWC string with full permissions. The code then stores the entered value in the app state and passes it to `nwcjs.processNWCstring`.
That prompt should make readers slow down. A Nostr Wallet Connect string is not just a login token. It can contain the wallet service public key, relay information and a secret used by the client app to authorize requests. Depending on the wallet service's permission model, that connection can allow payments, invoice creation, balance reads and transaction history reads.
A good way to test Brick Wallet is with a disposable or limited NWC connection first. A broad production connection may be convenient, but it also gives the browser page meaningful control over money. If the wallet service can create a budgeted, revocable or low-balance connection, that is the safer starting point.
NWC is the bridge, not the custody model
NIP-47 describes a request-response protocol where a client sends encrypted wallet requests as Nostr events and a wallet service responds with encrypted result events. It also defines the `nostr+walletconnect://` URI that lets a wallet service hand a client the relay, wallet pubkey and secret needed for that connection.
Brick Wallet uses that bridge through SuperTestnet's `nwcjs` library. The app does not implement every NIP-47 detail inline. It loads `nwcjs.js`, processes the NWC string, calls wallet methods and then renders a practical wallet screen. The technical shape is simple: Nostr relays carry the wallet messages, while the wallet service talks to the actual Lightning or wallet backend.
The custody model therefore comes from the connected service. If the NWC string points to a self-hosted backend, the user's risk profile is different from a custodial service or a test mint bridge. Brick Wallet can make those backends feel similar, but it does not make them equally safe, private or durable.
State is kept in the browser
Brick Wallet persists its state with the localStorage key `brick_wallet_state`. Near the end of the page, the code reloads that saved state if it exists and then writes the current state back to localStorage on an interval. Disconnecting the wallet removes the same key and stops the save loop.
This is convenient. The user can refresh the page and keep the connection, selected currencies, transaction history state and other wallet UI details. It also means the browser profile becomes part of the wallet security boundary. Anyone or anything with access to that localStorage value may learn sensitive wallet connection material.
The right mental model is not a normal website preference. This is closer to storing a remote-control key for a wallet. Browser extensions, shared devices, synced profiles, malware, local users and injected scripts are all relevant. Brick Wallet's simplicity is helpful for inspection, but it does not remove the need to protect the browser environment.
Balance and history come from the backend
After the NWC string is processed, Brick Wallet asks the connected service for transactions and balance. The `index.html` code calls `nwcjs.listTransactions` for recent records and `nwcjs.getBalance` for the wallet balance. It then stores returned transactions by payment hash and renders a five-item history page with forward and back controls.
That history screen is useful but intentionally small. It can show payment direction, amount, description, invoice data, payment hash, preimage, fees paid and settlement time where the backend supplies those fields. It is not an accounting export, a tax tool or a full node ledger.
Readers should treat the transaction view as a working wallet surface. If a backend does not expose history cleanly, Brick Wallet cannot invent it. If a user needs audit-grade records, the underlying wallet service, node or accounting tool remains the source of truth.
Sending is built around invoices and confirmation
The send flow opens a QR scanner by default. It uses the `html5-qrcode` library, strips a `lightning:` prefix when present, accepts BOLT11 invoices and can also handle LNURL values. There is also a paste flow for manually entering an invoice.
Before payment, Brick Wallet decodes the invoice amount where possible and asks the user to confirm. The payment call is `nwcjs.tryToPayInvoice`. The nwcjs README explains why this method is named as a try operation: Lightning payments may not settle immediately, so the library sends the command and then the app checks the invoice status separately.
That makes the interface feel practical rather than magical. A send button does not guarantee immediate settlement. Brick Wallet shows progress, checks invoice status with `nwcjs.checkInvoice`, updates history when it sees the result and returns the user to the wallet screen.
Receiving creates invoices through NWC
The receive flow asks for a sat amount, calls `nwcjs.makeInvoice`, shows the returned invoice, creates a `lightning:` link and renders a QR code. The displayed invoice can then be copied or scanned by another wallet.
After the invoice is created, the app watches for settlement. It polls `nwcjs.checkInvoice` and, when paid, adds the incoming transaction to local history, clears the invoice box, updates the wallet body and shows a success state. The connected backend still decides whether invoice creation and invoice lookup are supported.
This is one of the cleanest uses of NWC. The browser interface does not need to hold Lightning channel state or run payment infrastructure. It asks the wallet service to make an invoice and then displays the result in a form that ordinary Lightning wallets understand.
LNURL support broadens the payment surface
Brick Wallet handles two important LNURL flows: `payRequest` and `withdrawRequest`. For a pay request, it reads the minimum and maximum sendable amounts, asks the user for a value, calls the LNURL callback for an invoice and then pays that invoice through the connected NWC wallet.
For a withdraw request, it asks for an amount, creates a Lightning invoice through `makeInvoice`, sends that invoice back to the LNURL callback with `k1`, and then checks whether the invoice settles. That maps directly onto the LNURL withdraw pattern: a service displays a withdraw code, the wallet creates an invoice, and the service pays it.
The useful point for readers is that Brick Wallet is not only a raw BOLT11 input box. It can act like a daily wallet in common Lightning situations: scan a payment code, paste a withdraw code, pay a static LNURL, or receive from a service that asks the wallet to provide an invoice.
Lightning Address is translated into LNURL
The send screen includes an Enter LN address button. When the user enters something like a Lightning Address, the code splits the string around `@`, builds the standard `https://domain/.well-known/lnurlp/name` URL, bech32-encodes that URL as an LNURL and sends it through the same invoice-handling path.
That is a helpful bridge because many people think of Lightning payments as names, not invoices. NWC services pay invoices. Brick Wallet turns the human-readable address into the LNURL invoice request that the wallet service can pay.
The app does not turn this into a Nostr zap with NIP-57 social context. It is a Lightning Address payment from a wallet interface. If the reader wants zap receipts tied to notes or profiles, a social client or a zap-specific tool is the better surface.
The QR scanner is a convenience layer
The app imports `html5-qrcode` from jsDelivr and uses it for both send and receive screens. On send, the scanner can read invoices and LNURLs. On receive, the scanner can also catch cases where the scanned code actually means the user is about to send rather than receive, and it asks for confirmation in those confusing cases.
Those confirmations are not cosmetic. Lightning payment data can be directionally confusing, especially when LNURL pay and withdraw codes are mixed into one wallet screen. Brick Wallet's code repeatedly checks whether the scanned tag means pay or withdraw and prompts the user when the action is the opposite of the current screen.
A mobile-friendly web app lives or dies by small details like this. QR scanning makes Brick Wallet usable on a phone, but the real value is that the scanner is tied to invoice, LNURL and confirmation logic rather than only dumping scanned text into a field.
Price conversion is pulled from public APIs
Brick Wallet includes a small price conversion layer. The code asks Coinbase, Kraken, CoinDesk, Gemini and CoinGecko for BTC to USD price data, pushes the numeric results into an array, sorts that array and uses the middle value. It then supports display in sats, BTC, USD and a broader set of fiat currencies.
That median-style approach is sensible for a small wallet interface because it reduces dependence on a single price source. It also has limits. If an API endpoint changes, blocks browser requests or returns a stale value, Brick Wallet falls back as the code allows, but the visible fiat amount should still be read as an estimate.
The amount that matters for payment settlement is the sat amount and the invoice data, not the fiat display. Price conversion helps humans reason about value. It should not be treated as a quote, exchange rate guarantee or accounting record.
The dependency chain is visible
Brick Wallet is easy to inspect because most behavior is in one HTML file, but it still loads several remote scripts. The live page imports `html5-qrcode`, QR generation code from SuperTestnet's Bitcoin Chess project, a BOLT11 decoder script, `nwcjs.js`, `browserify-cipher`, `noble-secp256k1` and `bech32`.
That dependency chain is normal for a small static prototype. It also deserves wallet-grade attention. If a page stores a NWC secret and executes remote JavaScript, readers should care which origin serves that JavaScript, whether versions are pinned and whether the app can be self-hosted after review.
The good news is that the code is public and compact. A cautious user can open the repository, read the script imports, inspect `nwcjs`, verify the favicon and app URL, and test with a low-permission connection before using anything valuable.
The testnet generator file is a separate clue
The repository also contains `brick_wallet_for_testnet_generator.html` and `chain_client.js`. That file is not the same as the main live wallet page. It includes testnet-generator-oriented code, local file references in comments and commands for a browser-driven testnet network.
For readers, the presence of that file is useful context rather than a reason to treat the main app as a base-layer wallet. The main `index.html` is the NWC wallet interface. The testnet generator file shows SuperTestnet's broader experimentation around browser-based Bitcoin tooling, but it is a different path.
This is another reason the repository deserves a real read. Small experimental repos often contain adjacent prototypes, alternate builds and local testing hooks. The live page, README and current `index.html` should guide the product understanding.
Bankify is the natural companion
The README points users toward Bankify as an example backend that supports NWC. That pairing makes sense. Bankify is a service-side experiment that lets a Cashu mint behave like a Lightning wallet for apps through Nostr Wallet Connect. Brick Wallet is the browser interface that can operate a NWC backend once the user has the connection string.
Together they show why NWC is interesting. A web page does not need to know whether the backend is a normal Lightning node, an ecash bridge, a custodial wallet or a self-hosted service. It needs the wallet service to answer the NIP-47 methods it calls and to enforce the right permissions.
That abstraction is powerful, but it should not flatten risk. A Cashu-backed NWC service, a hosted Lightning account and a self-hosted node can all produce a connection string. The user still needs to understand what actually holds the balance and who can change or revoke access.
Who should try it first
Brick Wallet is best for builders, protocol testers and users who already understand what a NWC connection string represents. It is also useful for people evaluating a backend: paste a connection, check whether balance appears, receive an invoice, pay a small invoice, scan an LNURL withdraw code and see what transaction history comes back.
It is less suitable as a first Bitcoin wallet for someone who has never seen NWC, LNURL, BOLT11 or a wallet permission screen. The UI is simple, but the object being pasted is powerful. A beginner can use it safely only if the backend creates narrow permissions and explains what the connection can do.
For teams building NWC services, Brick Wallet can be a quick compatibility surface. If a backend cannot handle `get_balance`, `list_transactions`, `make_invoice`, `lookup_invoice` or payment status checks as expected, the interface will reveal that quickly.
What to verify before real use
First, verify the exact URL. The public app is served from `https://supertestnet.github.io/brick-wallet/`. A fake page asking for a NWC string could be enough to steal wallet authority, so bookmarking the checked URL is better than searching for it casually.
Second, inspect the connection at the wallet service. Look for spending limits, method permissions, revocation controls, relay choice and whether the service supports the methods Brick Wallet will call. A connection with full payment rights should be treated like a hot wallet credential.
Third, start with small amounts and a browser profile you trust. Brick Wallet is inspectable and useful, but it stores state locally and imports remote scripts. That combination is fine for learning and low-risk use. It is not a reason to paste a high-value connection into an unreviewed browser session.
The honest read
Brick Wallet is a good example of the thin-client promise behind Nostr Wallet Connect. It gives a user a wallet-like screen without becoming the wallet service. The interface is small, public, mobile-friendly and direct: connect, send, receive, scan, paste, review history and disconnect.
Its limits are equally clear. Custody lives elsewhere, permissions live elsewhere, the NWC secret is sensitive, localStorage matters, remote script imports matter, and transaction history depends on the connected backend. Those are not side notes. They are the product's actual trust boundary.
Used with that boundary in mind, Brick Wallet is valuable. It turns a protocol string into something a person can operate, and it gives NWC builders a compact way to see whether their backend feels usable from the other side of the connection.
Sources worth opening
Start with the live app, the GitHub repository and the README, then read the `index.html` code paths for NWC parsing, localStorage, invoice payment, invoice creation, LNURL handling, scanning and price conversion. The most useful companion sources are NIP-47, nwc.dev, the nwcjs README, the Awesome NWC listing and the LNURL specifications.
- Brick Wallet live app
- Brick Wallet GitHub repository
- Brick Wallet README
- Brick Wallet main index
- Brick Wallet simplified page
- Brick Wallet testnet generator page
- Brick Wallet chain client
- Brick Wallet logo asset
- Brick Wallet favicon
- Brick Wallet license
- Brick Wallet commit history
- Latest checked Brick Wallet commit
- SuperTestnet GitHub profile
- Awesome NWC repository
- Awesome NWC Wallet Interfaces section
- nwc.dev
- NIP-47 Nostr Wallet Connect
- NIP-47 source on GitHub
- nwcjs GitHub repository
- nwcjs README
- nwcjs browser script
- LNURL LUD-03 withdrawRequest
- LNURL LUD-06 payRequest
- LNURL LUD-16 Lightning Address
- BOLT11 payment encoding
- html5-qrcode project
- QRCode script used by Brick Wallet
- BOLT11 script used by Brick Wallet
- browserify-cipher package
- noble-secp256k1 package
- bech32 package
- Coinbase spot price endpoint
- Kraken ticker endpoint
- Gemini ticker endpoint
- CoinGecko simple price endpoint
- MDN Web Storage API
